All Products
Search

This Product

    Dynamic Content Delivery Network:Log fields

    Document Center

    Dynamic Content Delivery Network:Log fields

    Last Updated:Sep 04, 2023

    When you enable the real-time log feature, Dynamic Content Delivery Network (DCDN) starts to generate real-time logs. The tables in this topic describe the fields that you may encounter when analyzing different types of real-time logs.

    Note

    • The tables in this topic provide an extensive list of fields available for real-time logs. To avoid unnecessary costs, we recommend that you select the log fields to ship out of DCDN based on your business requirements.

    • If real-time logs that you collect are of the same type, all log delivery tasks share a set of fields. Field edits made for a task take effect globally. For example, the domain field is selected by default for user access logs. If a user removes the domain field for a task, the field will be immediately removed from other delivery tasks of access logs.

    Usage notes

    Before you transfer Domain A from Account 1 to Account 2, you need to disable real-time log delivery for Domain A in Account 1. After Domain A is transferred to Account 2, you can enable real-time log delivery for Domain A in Account 2. If you do not perform the preceding operations, real-time logs are still delivered to Account 1. This incurs charges to Account 1.

    Access logs

    When you enable the access log delivery feature, DCDN starts to generate access logs. The following table describes the fields available in access log entries.

    Field

    Description

    Indexed by Log Service

    Used for built-in visualized analysis

    unixtime

    The timestamp of the request.

    Yes

    Yes

    domain

    The domain name to which the request was sent.

    Yes

    Yes

    method

    The request method.

    Yes

    Yes

    scheme

    The protocol over which the request was sent.

    Yes

    No

    uri

    The resource that was requested.

    Yes

    Yes

    uri_param

    The request body parameters.

    Yes

    No

    client_ip

    The real IP address of the client that made the request. The first IP address in the X-Forwarded-For request header that is carried in the request, which is client_ip. If the client does not use a proxy to connect to the point of presence (POP), the IP address is used by the client to connect to the POP.

    Yes

    Yes

    proxy_ip

    The IP address of the proxy. The second IP address in the X-Forwarded-For request header that is carried in the request, which is proxy_ip. If the client does not use a proxy to connect to the POP, the value of this field is -.

    Yes

    No

    remote_ip

    The public IP address of the client that is connected to the DCDN point of presence (POP).

    Yes

    No

    remote_port

    The port to which a POP sends requests over the Internet.

    Yes

    No

    refer_protocol

    The protocol in the HTTP Referer header.

    Yes

    No

    refer_domain

    The domain name in the HTTP Referer header.

    Yes

    Yes

    refer_uri

    The URI in the HTTP Referer header.

    Yes

    No

    refer_param

    The parameters in the HTTP Referer header.

    Yes

    No

    request_size

    The size of a request that includes the request body and the request header. Unit: bytes.

    Yes

    No

    request_time

    The response time. Unit: milliseconds.

    Yes

    Yes

    response_size

    The size of a response. Unit: bytes.

    Yes

    No

    return_code

    The HTTP status code that was returned.

    Yes

    Yes

    sent_http_content_range

    The value of the Range header in the response, which is configured on the origin server. Example: bytes=0-99/200.

    Yes

    No

    server_addr

    The IP address of the POP that responded to the request.

    Yes

    No

    server_port

    The port on the POP that responded to a request.

    Yes

    No

    body_bytes_sent

    The size of the request body. Unit: bytes.

    Yes

    No

    content_type

    The type of the requested resource.

    Yes

    No

    hit_info

    The cache hit result. The cache hit results of requests for live streaming resources or dynamic content are not included. Valid values:

    • HIT: a cache hit.

    • MISS: a cache miss.

    Yes

    Yes

    http_range

    The value of the Range header in the request. Example: bytes=0-100.

    Yes

    No

    user_agent

    The information about the proxy of the client.

    Yes

    Yes

    user_info

    The information about the user.

    Yes

    No

    uuid

    The ID of the request.

    Yes

    No

    via_info

    The HTTP Via header.

    Yes

    No

    xforwordfor

    The X-Forwarded-For header in the request.

    Yes

    No

    EdgeRoutine logs

    When you enable the EdgeRoutine log delivery feature, DCDN starts to generate EdgeRoutine logs. The following table describes the fields available in EdgeRoutine log entries.

    Field

    Description

    Indexed by Log Service

    Used for built-in visualized analysis

    console_alert

    The custom logs printed after the user calls console.alert() in JavaScript code.

    Yes

    Yes

    error_code

    The error code 0 indicates that no error occurred.

    Yes

    Yes

    error_message

    The error description that corresponds to error_code.

    Yes

    Yes

    fetch_status

    The status of each subrequest.

    Yes

    Yes

    fetch_uuid

    The UUID of the subrequest.

    Yes

    Yes

    http_2xx

    The number of 2xx status codes returned for subrequests.

    Yes

    Yes

    http_3xx

    The number of 3xx status codes returned for subrequests.

    Yes

    Yes

    http_4xx

    The number of 4xx status codes returned for subrequests.

    Yes

    Yes

    http_5xx

    The number of 5xx status codes returned for subrequests.

    Yes

    Yes

    http_status_other

    The number of other status codes returned for subrequests.

    Yes

    Yes

    host

    The HOST header of the request.

    Yes

    Yes

    in_method

    The HTTP method of the request.

    Yes

    Yes

    in_path

    The path of the request.

    Yes

    Yes

    out_size

    The size of the response.

    Yes

    Yes

    out_status

    The response status code.

    Yes

    Yes

    code_ver

    The version number of the code.

    Yes

    Yes

    routine_spec

    The specifications of an EdgeRoutine.

    Yes

    Yes

    total_cpu_time_μs

    The CPU time of the request. Unit: microseconds.

    Yes

    Yes

    total_real_time_ms

    The time consumed to execute a request in an EdgeRoutine. The time includes the wait time and I/O time of the subrequest. Unit: milliseconds.

    Yes

    Yes

    uuid

    The EagleTraceID of the request.

    Yes

    Yes

    UnixTime

    The timestamp of the request.

    Yes

    Yes

    WAF logs

    When you enable Web Application Firewall (WAF) Log Service, DCDN starts to generate WAF logs. The following table describes the fields available in WAF log entries.

    Field

    Description

    Indexed by Log Service

    Example

    unixtime

    The timestamp of the request.

    Yes

    1640966400

    domain

    The domain name to which the request was sent.

    Yes

    api.aliyun.com

    method

    The request method.

    Yes

    GET

    scheme

    The protocol over which the request was sent.

    Yes

    http

    uri

    The resource that was requested.

    Yes

    /news/search.php

    uri_param

    The request body parameters.

    Yes

    title=tm_content%3Darticle&pid=123

    content_type

    The type of the requested content.

    Yes

    application/x-www-form-urlencoded

    matched_host

    The domain name that is matched by WAF. The domain name is added to WAF for protection.

    Yes

    *.aliyun.com

    request_id

    The ID of the request.

    Yes

    792a121e16405968501823589e

    return_code

    The HTTP status code that was returned.

    Yes

    200

    referer

    The Referer field in the HTTP request.

    Yes

    http://example.com

    user_agent

    The information about the proxy of the client.

    Yes

    Dalvik/2.1.0 (Linux; U; Android 10; Android SDK built for x86 Build/QSR1.200715.002)

    x_forwarded_for

    The X-Forwarded-For (XFF) header. This field is used to identify the real IP address of the client that is connected to the web server by using an HTTP proxy or a load balancing service.

    Yes

    101.XX.XX.120

    client_ip

    The real IP address of the client that made the request.

    Yes

    1.XX.XX.1

    final_test

    Specifies that the monitoring mode is enabled.

    Yes

    FALSE

    cookie

    The HTTP Cookie header. This field contains information about the client.

    Yes

    k1=v1;k2=v2

    final_action

    The executed protection action.

    • block: The request is blocked by the basic web protection module.

    • deny: The request is blocked by modules other than the basic web protection module.

    • captcha: common slider CAPTCHA verification is performed.

    • js: JavaScript verification is performed.

    • Empty string: The request is not blocked. No protection rule is triggered, a whitelist rule or monitor rule is triggered, or the request is allowed after the client passes the slider CAPTCHA verification or JavaScript verification.

    Note

    If a request matches multiple protection modules at the same time, the field records only the action that is performed. The following actions are listed in descending order of priority: block, slider CAPTCHA verification, dynamic token-based authentication, and JavaScript verification.

    Yes

    block

    final_plugin

    The matched protection module.

    • If final_action is not empty, this field has only one value and the value of this field is the name of the protection module that corresponds to the protection action (final_action) that is performed on the request.

    • If final_action is empty, this field can have multiple values and the values of this field are the names of the protection modules to which all protection rules are matched. If a matched module is not a basic web protection module or a whitelist module, and the module name contains a suffix "-T", the request matches the monitor rule of the module.

    Separate multiple values with commas (,). Protection modules:

    • whitelist: Rules of the whitelist module are matched.

    • waf: Rules of the basic web protection module are matched.

    • custom_acl: Rules of the custom rule module are matched.

    • ip_blacklist: Rules of the IP blacklist module are matched.

    • region_block: Rules of the region blacklist module are matched.

    • bot: Rules of the bot management module are matched.

    • anti_scan: Rules of the scan protection module are matched.

    Yes

    • Example 1: "waf"

    • Example 2: "whitelist"

    • Example 3: "custom_acl"

    • Example 4: "custom_acl-T"

    • Example 5: "custom_acl-T,ip_blacklist-T,waf"

    final_rule_id

    The matched protection rule.

    • If final_action is not empty, the value of this field is the ID of the protection rule that is applied to the request, which is the ID of the protection rule that corresponds to final_action.

    • If final_action is empty, this field contains the information about all protection rules that are matched. The information is in the following format: [module name]-[protection rule ID](-T). If a matched rule is a whitelist rule or a basic web protection rule, the information about the rule does not contain the suffix "-T". If a matched rule is a monitor rule of other protection modules, the information about the rule contains the suffix "-T".

    Separate multiple values with commas (,).

    Yes

    • Example 1: "200106"

    • Example 2: "whitelist-20010060"

    • Example 3: "custom_acl-20010065"

    • Example 4: "custom_acl-20010063-T"

    • Example 5: "custom_acl-20010063-T,ip_blacklist-20010066-T,waf-200106"

    remote_addr

    The IP address of the client.

    Yes

    1.XX.XX.1