Zum Inhalt springen
GigadriveDocs

Runtime logs

What your Functions write to standard output and standard error, where it appears, and how long it is kept.

Whatever your code prints while it runs is captured line by line and shown next to the request that caused it. Read runtime logs when a response was wrong and you need to know what your code was doing at the time.

What is captured

Each line a Function writes to standard output or standard error becomes one record carrying the stream it came from and the time it was written. In a JavaScript Function, console.log, console.info and console.debug are recorded as stdout, while console.warn and console.error are recorded as stderr.

Lines written through console also carry the id of the request being handled. Gigadrive Network keeps that id in scope for the whole invocation, so a line printed from an awaited call still lands on the right request. Output written straight to the file descriptors, by a logging library that calls process.stdout.write or by a subprocess, arrives with no request attached.

Two limits apply to the capture itself. A line longer than 16,000 bytes is cut there and ends with [truncated]; for plain ASCII text that is 16,000 characters. Under a burst, up to 4,096 lines are buffered, and once that buffer is full the lines arriving next are discarded rather than slowing your code down. A Function printing tens of thousands of lines a second loses some of them.

Containers and sidecars

A container Function records each line its process writes to standard output or standard error exactly as written. Those lines carry no request id, so they appear as entries of their own instead of on the request that caused them.

Each line a sidecar writes is labeled with the sidecar's name, so redis output is easy to tell apart from your Function's own. Gigadrive Network also writes a line to stderr when a sidecar or your container's process exits, is restarted, or cannot be started, for example Sidecar redis exited with code 1; restarting in 0.4 s. When a sidecar keeps crashing, a final line says it will not be started again, and the copy of your Function it runs in is replaced.

A Function on a managed runtime gets the same lines when its process ends unexpectedly. A line such as Your function's process was stopped by signal SIGKILL (possibly out of memory); restarting in 0.2 s tells you why requests failed and that a restart follows. If the process keeps exiting without staying up, a final line says it will not be started again and that requests fail until it is replaced. A graceful shutdown writes nothing.

Where it appears

Open an environment in the console and select Logs. That view merges runtime output with Request logs. A line correlated to a request is folded into that request's row, which shows how many lines the request produced, how many of them were stderr, and the most recent message; opening the row shows the full output. Lines with no request appear as entries of their own.

The filter panel narrows by activity kind, stream, deployment, function, and a time range between the past 30 minutes and the past 7 days. When your application runs sidecars, it also narrows by source: Function for your Function's own output, or the name of a sidecar. Search matches a substring of the message, and on request rows also the hostname, path and query.

What never reaches your logs

This section applies to Functions built from your source files, not to container Functions. The platform writes one accounting line at the end of every invocation, and that line is filtered out before storage. The filter matches the literal marker "event":"gd.invocation", so a line of your own output containing that string is dropped along with it.

How long they are kept

Runtime logs are deleted 30 days after they are written. There is no setting that extends or shortens that window. Deleting a Function or a deployment does not delete its logs: they stay readable and age out on the same schedule.

Tailing output as it happens

The activity stream carries runtime lines as well as requests, so filtering it to kind=runtime gives you a live tail of output alone. This example narrows it further to stderr, which is the stream you want open while reproducing a failure.

curl -N \
  -H "Authorization: Bearer $GIGADRIVE_TOKEN" \
  -H "Accept: text/event-stream" \
  "https://api.gigadrive.network/applications/0197b2f1-2f4a-7a0b-8a2d-222222222222/logs/stream?kind=runtime&streams=stderr"

The token needs the network:requests:read scope; see Authentication. Each line arrives as an item event, and the stream closes with an end event once it reaches its time budget. Request logs covers the event catalogue, the resume rules and the per-credential stream limits.