Logs

Edgio provides the following types of log data:

• Build logs capture the build output from your Edgio deployments.
• Server logs captures console messages defined within your application and data logged by Deep Request Inspection.
• Access logs describes requests served by Edgio.

Build Logs #

Edgio captures deployment information and the build output whenever you run the edgio deploy command. You may view this log data from within the Edgio Developer console either in real time or after the deployment has completed by loading the desired deployment and then scrolling down to the DEPLOYMENT tab.

Serverless Compute Console Logs (Server Logs) #

Serverless Compute supports the ability to log console messages. Console messages are defined within your application using methods, such as console.log(), console.warn(), and console.error().

Learn more about the console object.

You may view these console messages in real time or as log data.

• Real Time: From within the Edgio Developer console, load the desired deployment and then click on the SERVER tab. Focus on specific data by limiting the output to your IP address or through a regular expression.

• Log Data: Retrieve log data from an AWS S3 bucket.

  Access to log data requires an Enterprise account. Contact your account manager or our sales department at 1 (866) 200 - 5463 to upgrade your account.

  • Availability for this log data is only guaranteed for 2 hours.
  • Use the following environment-specific data, which is available from the desired environment’s Logs tab, to access log data:
    • Base AWS S3 bucket URL (Server Logs)
    • Key ID
    • Secret access key

View log field definitions.

Deep Request Inspection (DRI) #

Use DRI to view the headers and body for:

• Every request served through Edgio Serverless Compute.
• Each upstream API request made by your application.

One use case for DRI is to analyze traffic during a deployment by tailing the server logs for that environment.

To enable Deep Request Inspection

1. From within the Edgio Developer console, navigate to the desired environment.
2. Click the Configuration tab.
3. From the banner at the top of the page, click Edit v#.
4. Mark the Deep Request Inspection is disabled option.
5. From the banner at the top of the page, click Activate.

Serverless Compute Console Log Fields #

Log data for Serverless Compute console messages may contain the following fields:

• awsTag: Reserved for future use.

• clientIp: Indicates the IP address (IPv4 or IPv6) for the computer that submitted the request.

• requestId: Indicates the request’s unique ID.

• fn: Indicates the function’s ID.

• level: Indicates the severity of the console message. Valid values are:

  • 60: Fatal. This severity, which requires immediate attention, typically indicates that your application will stop or become unusable soon.
  • 50: Error. This severity typically indicates that the request was unsuccessful. Errors require investigation and remediation to ensure optimal performance for all users.
  • 40: Warn. This severity typically indicates an issue that should be investigated as time allows.
  • 30: Info. This severity indicates information describing normal operation within your application.
  • 20: Debug. This severity contains more detailed information than Info console messages.
  • 10: Trace. This severity is indicative of detailed application logging or log data generated by an external library used by your application.

• rg: Requires Edgio Applications version 5.0.3 or higher. Indicates the region your serverless code was processed.

• time: Indicates the Unix time, in milliseconds, at which the request was submitted.

• wi: Requires Edgio Applications version 5.0.3 or higher. Indicates the unique ID of the Serverless Compute instance that ran your serverless code.

Access Logs #

Our access log data describes each request served by Edgio.

• Availability for this log data is only guaranteed for 2 hours.
• Use the following environment-specific data, which is available from the desired environment’s Logs tab, to access log data:
  • Base AWS S3 bucket URL
  • Key ID
  • Secret access key

Access Log Fields #

An access log file may contain the following fields:

• ac (String): Indicates the value for the Accept-Encoding request header (e.g., gzip).
• asn (String): Indicates the autonomous system number (ASN) (e.g., 15133) for the autonomous system (AS) from which the request originated.
• be (String): Identifies the backend associated with the route that corresponds to this request. The name for this backend is defined within your edgio.config.js file’s backends structure.
• bip (String): Indicates the IP address of the backend that responded to the request.
• bk (String): Indicates the value associated with the edgio_bucket cookie. This cookie reports the random number assigned to a user when A/B Testing has been enabled.
• bld (String): Indicates the application’s build number (e.g., 1021).
• bot (Number): Indicates whether the request was generated by a bot. Returns 1 for bot traffic and 0 for all other traffic.
• br (String): Indicates the type of browser (e.g., chrome, safari, firefox, and generic) that submitted the request.
• bse: Reserved for future use.
• cc (String): Indicates the code for the country from which the request originated.
• ce (String): Indicates the value for the Content-Encoding response header (e.g., gzip).
• ckh (String): Indicates the cache key hash.
• clv (Number): Indicates the level at which the request was served from cache. Returns 0 for a cache miss, 1 for a cache hit on an edge POP (L1), and 2 for a cache hit on a global POP (L2).
• code (String): Indicates the HTTP status code for the response.
• cs (String): Indicates whether the response was cached or the reason why it was not cached. Learn more.
• ct (String): Indicates the response’s media type (aka content type).
• cv (String): Indicates the version of the Edgio edge compiler (e.g., 1.7.3).
• cy (String): Indicates the name of the city from which the request originated (e.g., new york).
• done (String): Indicates whether the client was able to complete the request. This field is analogous to Nginx’s 499 error code. Returns 1 for completed requests and 0 for uncompleted requests.
• ds (String): Indicates the A/B testing destination assigned to this request. Returns default if a destination has not been assigned to this request or when you have not configured A/B testing.
• dv (String): Indicates the type of device (e.g., desktop, smartphone, tablet, and mobile) that submitted the request.
• eid (String): Indicates the system-defined ID for the Edgio environment through which the request was processed.
• er (Number): Indicates whether we sent a custom response as a result of the send method. Returns 1 for custom responses and 0 for all other responses.
• ev (Number): Indicates the version for the Edgio environment through which the request was processed (e.g., 95).
• h2 (String): Indicates whether the connection between the client and our network is HTTP/2. Returns 1 for HTTP/2 and 0 for HTTP/1.1.
• hh (String): Indicates the Host header value submitted by the client.
• hrid (String): If the response is served from cache, this field indicates the unique ID of the request whose response was cached. This value matches the ID reported by the x-0-hit-request-id response header.
• ic (Number): Indicates whether this request was eligible to be cached. This field does not indicate whether the response was actually cached.
• ip (String): Indicates the client’s IP address (e.g., 192.0.2.22).
• jwt (String): Reserved for future use.
• lo (String): Indicates the longitude (e.g., -73.98) from which the request originated.
• lp (Number): Indicates whether a static loading page was served as a result of Incremental Static (Re)Generation. Returns 1 when a landing page was served and 0 for all other responses.
• lt (String): Indicates the latitude (e.g., 40.76) from which the request originated.
• met (String): Indicates the request’s HTTP method (e.g., GET, HEAD, and POST).
• pc (String): Indicates the postal code from which the request originated (e.g., 90405).
• pre (Number): Indicates whether the request was prefetched. Returns 1 for requests that have the edgio_prefetch=1 query string parameter and 0 for all other requests.
• prl (Number): Indicates whether the request was due to static prerendering. Returns 1 for static prerendering requests and 0 for all other traffic.
• prod (Number): Indicates whether the request was directed at the production environment. Returns 1 for the production environment and 0 for all other environments.
• psh (Number): Indicates whether this response was sent due to HTTP/2 server push. Returns 1 for a HTTP/2 server push and 0 for client-driven requests.
• rfr (String): Indicates the value for the Referer request header.
• rid (String): Indicates the system-defined ID assigned to the request.
• s_rq (Number): Indicates the size, in bytes, of the request.
• s_rs (Number): Indicates the size, in bytes, of the response.
• sc (String): Indicates the code of the state from which the request originated (e.g., NY).
• sec (String): Returns ip_block_list for requests blocked by IP address and country_block_list for requests blocked by country.
• sh (Number): Returns 1 for requests that were shielded by a global POP and 0 for all other requests.
• ssl (Number): Indicates whether the request was served using the HTTPS protocol. Returns 1 for HTTPS requests and 0 for HTTP requests.
• stl (Number): Indicates whether a cached response was stale. Returns 1 when the Time-To-Live (TTL) for the cached response has expired and 0 for all other responses.
• t (String): Returns the same value as the xmt access log field.
• timestamp (Number): Indicates the Unix time, in milliseconds, at which our network received the request.
• ua (String): Indicates the user agent that submitted the request.
• url (String): Indicates the URL path for the content that was requested, posted, or deleted. This URL, which excludes the query string, is reported as a relative path that starts directly after the hostname.
• uv (String): Indicates the Vary response header value as received from the upstream. Although this value may be different from the one sent to the client, it determines how we split the cache.
• v (String): Indicates the version of Edgio (e.g., 4.19.3) that processed this request.
• vn (String): Indicates the vendor (e.g., apple, microsoft, android, or generic) of the device that submitted the request.
• waf (String): Indicates the state of WAF security: geo for geo blocking, bl for block list, dl-<LIST NAME> for dynamic lists, wl for allow list, and by for bypass.
• wafv (String): Indicates the WAF version (e.g., WAF-1,2) that screened the request.
• xff (String): Indicates the value for the x-forwarded-for request header.
• xmr (String): Indicates the value for the x-0-matched-routes request header. The x-0-matched-routes request header identifies all matched routes.
• xms (String): Indicates the value for the x-0-status response header (e.g., eh=200,ed=200,gh=200,gd=200,p=200,w=200). The x-0-status response header indicates the status codes for key POP components.
• xmt (String): Indicates the value for the x-0-t response header (e.g., eh=4,ect=2,ecc=hit). The x-0-t response header contains time measurements for each Edgio POP component through which a request was routed.
• xut (String): Indicates the value for the x-0-user-t response header (e.g., fetch:/path=123). The x-0-user-t response header contains performance metrics.
• zip (String): Indicates whether the response was compressed. Returns 1 for compressed responses and 0 for uncompressed responses.

Log Aggregation Tools #

Edgio temporarily stores log data within Amazon S3. Use a log aggregation tool to extract log data from AWS S3. Here are a few popular log aggregation tools:

• Sematext | [Logagent docs]
• Sumo Logic | [S3 ingest docs]
• AWS Athena | [docs]
• Splunk | [S3 ingest docs]
• Loggly | [S3 ingest docs]