Edgio
Edgio

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.

build

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
server

View log field definitions.

Deep Request Inspection (DRI)

Deep Request Inspection (DRI) requires enablement for each desired environment.

Use DRI to view the headers and body for:

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

Edgio automatically scrubs Social Security Numbers and common credit card formats from our log data. However, it is unaware of other personally identifiable information (PII). Any team member that has been assigned the Admin role will have access to this data.

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

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.

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 ID of the AWS Lambda function.

  • 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 version 5.0.3 or higher. Indicates the region where the Lambda instance that ran your serverless code is hosted.

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

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

Access Logs

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.

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

Access Log Fields

An access log file may contain the following fields:

  • ac: Indicates the value for the Accept-Encoding request header.
  • asn: Reserved for future use.
  • be: 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: Indicates the IP address of the backend that responded to the request.
  • bk: 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: Indicates the application’s build number.
  • bot: Indicates whether the request was generated by a bot.
  • br: Indicates the type of browser (e.g., chrome, safari, firefox, and generic).
  • bse: Reserved for future use.
  • cc: Indicates the code for the country from which the request originated.
  • ce: Indicates the value for the Content-Encoding response header.
  • clv: Indicates the level at which the request was served from cache. Returns 0 for a cache miss.
  • code: Indicates the HTTP status code for the response.
  • cs: Indicates whether the response was cached or the reason why it was not cached. Learn more.
  • ct: Indicates the response’s media type (aka content type).
  • cv: Reserved for future use.
  • cy: Reserved for future use.
  • done: 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: 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: Indicates the type of device (e.g., desktop, smartphone, tablet, and mobile) that submitted the request.
  • eid: Indicates the system-defined ID for the Edgio environment through which the request was processed.
  • er: 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: Indicates the version for the Edgio environment through which the request was processed.
  • h2: 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: Indicates the Host header value submitted by the client.
  • hrid: 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: Indicates whether this request was eligible to be cached. This field does not indicate whether the response was actually cached.
  • ip: Indicates the client’s IP address.
  • jwt: Reserved for future use.
  • lo: Reserved for future use.
  • lp: Reserved for future use.
  • lt: Reserved for future use.
  • met: Indicates the request’s HTTP method (e.g., GET, HEAD, and POST).
  • pc: Reserved for future use.
  • pre: 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: Reserved for future use.
  • prod: Reserved for future use.
  • psh: 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: Indicates the value for the Referer request header.
  • rid: Indicates the system-defined ID assigned to the request.
  • s_rq: Indicates the size, in bytes, of the request.
  • s_rs: Indicates the size, in bytes, of the response.
  • sc: Reserved for future use.
  • sec: Reserved for future use.
  • sh: Returns 1 for requests that were shielded by a global POP and 0 for all other requests.
  • ssl: Reserved for future use.
  • stl: Indicates whether a cached response was stale. Returns 1 when the Time-To-Live (TTL) for the cached response has expired. Returns 0 for all other requests.
  • t: Reserved for future use.
  • timestamp: Indicates the Unix time, in milliseconds, at which our network received the request.
  • ttl: Indicates the Time-To-Live (TTL) for a cached response.
  • ua: Indicates the user agent that submitted the request.
  • url: 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: 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: Indicates the version of Edgio that processed this request.
  • vn: Indicates the vendor (e.g., apple, microsoft, android, or generic) of the device that submitted the request.
  • waf: 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: Reserved for future use.
  • xff: Reserved for future use.
  • xmr: Indicates the value for the x-0-matched-routes request header. The x-0-matched-routes request header identifies all matched routes.
  • xms: Indicates the value for the x-0-status response header. The x-0-status response header indicates the status codes for key POP components.
  • xmt: Indicates the value for the x-0-t response header. The x-0-t response header contains time measurements for each Edgio POP component through which a request was routed.
  • xut: Indicates the value for the x-0-user-t response header. The x-0-user-t response header contains performance metrics.
  • zip: 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: