The Edgio platform exposes three types of logs to users:
- Build logs capture all the build output from your Edgio deploys.
- Server logs capture your Edgio serverless console output at real time.
- Access logs capture information about all the requests served by Edgio.
Build Logs
Each time you deploy to Edgio using the 0 deploy command, information about the deployment is logged, including the output of the 0 deploy command itself. You can view these logs in real-time by viewing your deployment on app.layer0.co.
Server Logs
All messages logged using console.log, console.warn, console.error, etc… within your application can be viewed in real time from the “Server” tab on any deployment:
Here you can limit the output to only those statements coming from your IP address, or filter by regex. This can use useful when trying to sift through noisy logs on high-traffic sites.
Deep Request Inspection
By enabling Deep Request Inspection in your environment, you can also see the headers and body of every request and response served by your application via the Edgio serverless cloud. You can also see each upstream API request made by your application. To enable Deep Request Inspection, navigate to the environment in the Edgio Developer Console, select the configuration tab, click “Edit” and enable “Deep Request Inspection” in the Debugging section.
Finally, activate the new environment configuration and tail the server logs on any deployment to see detailed information about every request served by that deployment.
Setting up Log Aggregation Tools
Edgio saves its logs to Amazon S3. Most log aggregation tools are able to ingest logs from S3. We attempt to link to the docs that explain how to ingest logs from S3 for each popular log aggregation tool below. Even if your tool is not listed, there’s a good chance it can ingest logs from S3.
- Sematext | [Logagent docs]
- Sumo Logic | [S3 ingest docs]
- AWS Athena | [docs]
- Splunk | [S3 ingest docs]
- Loggly | [S3 ingest docs]
Access Logs
Edgio Enterprise tier customers can receive streaming access logs that capture information about each request served by Edgio. To do so refer to the “Access Logs” tab:
Note that if you are not an Enterprise tier customer you will see a message to contact support to upgrade your account.
Access logs contain the following fields:
timestamp
Millisecond resolution of the request start time in UNIX epoch.
layer0
The application’s Edgio version processing this request.
bld
The application’s build number processing this request.
eid
The active environment ID in Edgio.
Available since Edgio v2.9.0.
ev
The active environment version number.
ip
IP of the most downstream client, determined either through XFF or by reading socket information.
met
HTTP method.
hh
Host header as received from the downstream.
url
HTTP path.
h2
Flag indicating whether downstream connection is http/2 or not.
psh
Flag indicating whether this request is an http/2 server-side push or not.
code
HTTP response status code.
ic
Flag indicating whether this request was cacheable even in theory.
cc
Country code per geo-location.
s_rq
Size of the request in bytes.
s_rs
Size of the response in bytes.
ds
Destination, determined by split testing rules, if any; if no rules, the value is left as the default router.
be
Backend, determined by the routing rules. The names come from the backends structure exported from your layer0.config.js file.
bk
Split testing bucket cookie value.
zip
Flag indicating whether the response is compressed or not.
rid
Unique request ID.
waf
WAF security state: geo for geo blocking, bl for block list, dl-{list name} for dynamic lists if the request was blocked; wl for allow list, by for bypass if the request was passed.
sh
Flag indicating whether the request was shielded.
dv
Device type desktop, smartphone, tablet, mobile.
vn
Vendor: apple, microsoft, android.
br
Browser: chrome, safari, firefox.
bot
Flag indicating whether the request was made by a bot.
er
Flag indicating whether the request was responded from edge (not true for cache hits, just for synthetic requests).
clv
Cache level on which the request was responded or 0 if it was a miss.
stl
Indicates if the response was stale or not (0, 1).
done
Flag indicating if the response has completed (analogous to 499 in Nginx).
cs
Caching status (why something was or wasn’t cached).
ct
Response content type.
xmr
Request header x-0-matched-routes, logs all routes matched and is required to order the routes table in caching metrics.
rfr
Referrer request header (note the misspelling per HTTP standard).
ua
User agent.
xmt
Response x-0-t header with different critical path timings.
xut
Response x-0-user-t header with different user performance metrics.
xms
Response x-0-status header with different critical path status codes.
pre
If layer0_prefetch parameter was specified value of 1, otherwise not present.
ttl
Time to live in seconds of the response if it was cached.
uv
The response vary header received from upstream; it’s sometimes different to what’s sent downstream as we inject user-agent in moov_deliver, but it’s this value what actually splits the cache; we don’t have access to beresp from moov_log so we preserve it in req.
bip
IP of the backend that responded to the request.
hrid
Request ID of the response hit in the cache. Corresponds to x-0-hit-request-id response header.