ComputeSphereLearn
Console
Learning paths / Operate your application / Logs

Searching and streaming logs, including cron runs

Video and reading · 10 min · Module 2, lesson 3 of 540 min left in this module

Module 2 · LogsLesson 3 of 5

Goal: Filter logs to what matters, follow them live, and read one cron job run's log.

2:45 · captions and chapters · narrated with an AI-generated voice
Transcript

Narration uses an AI-generated voice.

[00:00] Where we're going

This shop API has written nearly seven hundred log lines in under half an hour. By the end of this video, you'll cut that down to the few lines you need, and watch new ones arrive as they're written.

[00:13] Narrow first, then read

The trick is to narrow first, then read. First, the time range. Look only at the stretch when the problem happened. Second, search. Type text you know is in the line, like an error or a request ID. Third, the level. Errors only, for example. And fourth, the spherelet, when only one of them misbehaves. A thousand lines become the ten you need.

[00:39] Search in the console

Here's the shop API's Logs tab, on the Runtime view. The time range is at the top. Here, the last hour. Search matches text exactly as you type it, ignoring case. Quote marks count as text. So this search finds one field in a JSON line: missing, signing key. Seven lines, out of nearly seven hundred.

Now look at the level buttons. All seven count as Error. These lines say fatal, and a fatal line counts as Error. Clear the search and select Error. Now it's every failed request, and nothing else. The spherelet filter works the same way. Pick the spherelets whose lines you want to see.

[01:25] Follow it live

To watch a problem happen, follow the log live. Live means new lines appear as they're written. Here come the shop's requests, one by one. Select Live to pause. The list holds still while you read.

[01:42] From the terminal

The terminal has the same tools. The search flag matches the same way as the console. When the text has spaces or double quotes, wrap it in single quotes. Same seven lines.

And the follow flag streams new lines as they arrive. It works for runtime logs only. Press Control C to stop.

[02:05] Cron job runs

One last thing. A cron job has a Runs tab instead. One row per run, with its status. Running, Success, or Failed. And when it started. Select a run to read its log. And to find the night it broke, filter by Failed.

[02:22] Recap

So, narrow first, then read. Pick a time range, search, and filter by level or spherelet. To watch a problem happen, follow the log live. Next, it's your turn. You'll fix a service that crashes on start, using only its logs.

Key idea

Narrow first, then read. Pick a time range, search, filter by level or spherelet: a thousand lines become the ten you need. To watch a problem happen, follow the log live.

In the console

On the service's Logs tab, Runtime view:

  • Time range at the top. The bar chart under it counts lines over time; select a bar to zoom into that stretch.
  • Search logs in this time range: text matched exactly as you type it, ignoring case, such as failed, a request ID or request failed. Quote marks count as text, so "missing":"SIGNING_KEY" finds that field in a JSON line.
  • All, Error, Warn, Info, Debug filter by level. A fatal line counts as Error.
  • The spherelet filter shows lines from chosen spherelets only.
  • Live means new lines appear as they're written; select it to pause.

From the terminal

Don't run these yet: shop-api arrives in the next lab.

csph logs shop-api --search failed             # search
csph logs shop-api --search '"missing":"SIGNING_KEY"'   # a JSON field
csph logs shop-api --since 30m --timestamps    # last 30 minutes, with times
csph logs shop-api --follow                    # stream live; Ctrl-C to stop
csph logs shop-api --kind deploy               # the deploy log, newest first

--search matches the same way as the console; wrap text with spaces or double quotes in single quotes. --follow works for runtime logs only. --tail sets how many recent lines to fetch; 200 by default.

Cron job runs

A cron job has a Runs tab instead: one row per run, with its status (Running, Success or Failed) and start time. Select a run to read its log; filter by Failed to find the night it broke. No need to deploy one for this path.

Check yourself

A user gives you the request ID from a failed call an hour ago. What's the quickest way to its log lines?

In the docs