Debug functions with Data Stream
Send the log messages of your functions, with their level and request ID, to an endpoint with Data Stream, in Azion Console or with the Azion API.
You can send the log messages of your functions to an endpoint with a Data Stream stream, from Azion Console or with the Azion API. To trace which Rules Engine rules ran on a request instead, refer to Debug rules created with Rules Engine.
A function writes log messages with console.log. The Functions data source carries each message with its level, its source, and the ID of the request, and the Functions Event Collector template places them in one log line per message. For every variable of the data source, refer to Data sources and variables.
Select your interface once. The prerequisites and every task below show only that path.
Prerequisites
- An Azion account with the Edit Data Stream permission. For the permissions, refer to Stream settings.
- A function that writes log messages with
console.log, running in an application that a workload serves. To create one, refer to Functions. - An endpoint that receives the log lines, such as an HTTP endpoint. For the endpoints a stream can send to, refer to Endpoints.
- Access to Azion Console. To sign in, refer to How to access Azion Console.
Create the stream
The stream reads the Functions data source of one workload through a workload filter. Unlike sampling, a workload filter leaves your other streams active.
To create the stream with the API, send a POST request to https://api.azion.com/v4/workspace/stream/streams. This example sends the log lines to an HTTP endpoint. Replace <workload-id> with the ID of your workload, and the url and the header with the values of your endpoint:
The functions_console data source is Functions in the Console, and template 86 is Functions Event Collector. A 201 answer carries the stored stream under data. Keep its id: it identifies the stream in every later request, such as /v4/workspace/stream/streams/<stream-id>. For every key of the body, refer to Stream settings.
Saving the stream checks the format of each field and does not contact the endpoint. A wrong URL or credential surfaces only when the stream sends. An activation takes effect after one to two minutes.
Confirm the delivery
Real-Time Events records every send of a stream, delivered or not, with the status code the endpoint returned. Send a few requests that run the function, then wait about a minute: a stream sends a batch every 60 seconds, or sooner when it reaches 2,000 log lines.
To read the sends with the API, query the dataStreamedEvents dataset of the Real-Time Events GraphQL API. Replace the dates with a range that covers the activation of the stream:
The API answers 200 with one record for each send, the latest first:
statusCode carries the status the endpoint answered, and streamedLines the log lines of the batch. A statusCode of 200 means the endpoint accepted the batch, and an empty dataStreamedEvents list means the stream has not sent in the range. For every field, refer to Real-Time Events GraphQL fields.
A status other than 200 is the answer of the endpoint, and 503 means Data Stream found the endpoint unavailable. For the causes, refer to Troubleshoot Data Stream.
At the endpoint, each log line carries the keys of the Functions Event Collector template. Read these keys to debug the function:
logLevelholds the level of the message:ERROR,WARN,INFO,DEBUG, orTRACE. It carries the$log_levelvariable.logMessageholds the message the function passed to the log function. It carries the$log_messagevariable.messageSourcereadsCONSOLEfor a message written with the console API, such asconsole.log, andRUNTIMEfor an error message.requestIDidentifies the request, so the messages of one request share it.
To keep the variable names as keys, or to send fewer of them, select a custom template instead. For an example data set, refer to Templates and payload.