Logging
Last updated
Was this helpful?
Last updated
Was this helpful?
FLAT Server writes most of its logs in JSON format to the standard error output (stderr). One line is written for each event. I.e. one line each for a client request, an upstream request or an error.
For comfortable log processing, events are discriminated with the type field that is one of
flat_access
flat_request
flat_alert
The access log can be augmented with .
All JSON log lines have a requestID field. Its value can be used to correlate log events.
Client requests received by FLAT are recorded as type flat_access and have the following format:
timestamp: Start time of the request in ISO 8601 format
type: Event type discriminator, fixed string flat_access
url: client request URL
path: path, query string and fragment of the client request URL
status: HTTP status code of the client response (number) (200, 404, 500, …)
method: HTTP method of the client request (GET, POST, …)
agent: User-Agent header of the client request
referrer: Referer [sic] header of the client request
mime: Content-Type header of the client response (text/html, application/json…)
realtime: request duration in seconds (number)
bytes: uncompressed size of the outgoing response body (number)
requestbytes: uncompressed size of the incoming request body (number)
requestmime: Content-Type header of the client request i.e. MIME type of the incoming request body
location: Location header of the client response
timestamp: Start time of the request in ISO 8601 format
type: Event type discriminator, fixed string flat_request
requestID: Log Correlation ID
url: Absolute URL of the upstream request including query-string
method: HTTP method of the upstream request (GET, POST, …)
status: HTTP status code of the upstream response (number) (0 for failed requests)
mime: Content-Type header of the upstream response (text/html, application/json…)
bytes: Size of the (possibly compressed) response body in bytes (number) (0 if the body is empty; when read from the internal cache, the original response length is used)
duration: Time spent waiting for the response in seconds (number)
refresh: Indicating whether the response was a 304 response to a request revalidating the local cache (boolean)
timing: Contains timing information about request phases
DNS: Time to perform name lookup in ms (number)
TCP: Time to establish a TCP connection in ms (number) (may be near zero for keep-alive requests)
TTFB: Time to first byte in ms since request was sent (number)
curlErrorMessage: Text error message of libcurl for failed requests (optional)
These log events should be monitored!
timestamp: Start time of the request in ISO 8601 format
type: Event type discriminator, fixed string flat_alert
requestID: Log Correlation ID
message: An informative error message
In rare cases plain text log lines may be written to stdout or stderr. For example, this happens during startup.
requestID: Log Correlation ID, accessible in flows as and
flow: filename of the applied
Outgoing to upstream APIs are recorded as type flat_request and have the following format:
id: Request/Content identifier as configured with the request's or content attribute (suffixed with .N where N is incremented for each followed redirect starting with 0)
cacheHit: Indicating whether the response was read from FLAT's HTTP Cache (boolean) (activated with request option )
curlErrorCode: for failed requests (number, optional) (e.g. 28)
Errors that have occurred during processing, such as are recorded as type flat_alert.
topic: Log topic of the alert, corresponds to
These lines are usually error log messages of the included that look like this:
(Cookbook)
(Reference)
(Reference)