Router Logging

Configure logging in the router


GraphOS Router and Apollo Router Core provide built-in logging to capture records about their activity.

The router supports configurable log levels and stdout output of log messages (with configurable output formats ).

Log level

The router accepts a command-line argument to set its log level:

Name Description
--log
The log level, indicating the most severe log message type to include. In ascending order of verbosity, can be one of: off, error, warn, info, debug, or trace.The default value is info.

The router also accepts both RUST_LOG and APOLLO_ROUTER_LOG environment variables with the same possible values as the command-line argument. With multiple ways to set the log level, the router checks for them in the following order, and it uses the first one that is set:

  1. RUST_LOG

  2. Command-line argument

  3. APOLLO_ROUTER_LOG

RUST_LOG is supported for advanced users with specific filtering requirements who may wish to see log messages from crates consumed by the router. Most users should use the command-line argument or APOLLO_ROUTER_LOG. Both of these options constrain log output to the router.

For example, every environment variable and command-line argument below sets the log level to debug:

Text
1RUST_LOG=apollo_router::debug
2APOLLO_ROUTER_LOG=debug
3--log=debug

For another example, every line below sets the same log levels:

Text
1RUST_LOG=hyper=debug,apollo_router::info,h2=trace
2APOLLO_ROUTER_LOG=hyper=debug,info,h2=trace
3--log=hyper=debug,info,h2=trace

In both examples, the actual filter used by the router the value defined by RUST_LOG.

For more information about specifying filters for more granular control over router logging, see the Env Logger documentation .

Logging common configuration

The router supports configuration options that apply to all logging exporters:

Service name

Set a service name for your router's logs so they can be easily searched and found in your metrics dashboards.

The service name can be set by an environment variable or in router.yaml. With multiple ways to set the service name, the router checks for them in the following order, and it uses the first one that is set:

  1. OTEL_SERVICE_NAME environment variable

  2. OTEL_RESOURCE_ATTRIBUTES environment variable

  3. telemetry.exporters.logging.common.service_name in router.yaml

    Example service_name
    Example setting service name in telemetry.exporters.logging.common.service_name:
    YAML
    router.yaml
    1telemetry:
    2  exporters:
    3    logging:
    4      common:
    5        # (Optional) Set the service name to easily find logs related to the apollo-router in your metrics dashboards
    6        service_name: "router" #highlight-line
  4. telemetry.exporters.logging.common.resource in router.yaml

    Example resource
    Example setting service name in telemetry.exporters.logging.common.resource:
    YAML
    router.yaml
    1telemetry:
    2  exporters:
    3    logging:
    4      common:
    5        resource:
    6          # (Optional) Set the service name to easily find logs related to the apollo-router in your metrics dashboards
    7          "service.name": "router" #highlight-line

If the service name isn't explicitly set, then it is set by default to unknown_service:apollo_router (or unknown_service if the executable name cannot be determined).

Resource attribute

A resource attribute is a set of key-value pairs that provide additional information to an exporter. Application performance monitors (APM) may interpret and display resource information.

In router.yaml, resource attributes are set in telemetry.exporters.logging.common.resource. For example:

YAML
router.yaml
1telemetry:
2  exporters:
3     logging:
4       common:
5         resource:
6           "environment.name": "production"
7           "environment.namespace": "{env.MY_K8_NAMESPACE_ENV_VARIABLE}"

For OpenTelemetry conventions for resources, see Resource Semantic Conventions .

Request/Response logging

This feature is experimental. Your questions and feedback are highly valued—don't hesitate to get in touch with your Apollo contact. If you want to give feedback or participate in the feature, feel free to join [the discussion on GitHub](https://github.com/apollographql/router/discussions/1961).

By default, the router doesn't log the following values that might contain sensitive data, even if a sufficient log level is set:

  • Request bodies

  • Response bodies

  • Headers

You can enable selective logging of these values via the experimental_when_header option:

YAML
router.yaml
1telemetry:
2  exporters:
3    logging:
4      # If one of these headers matches we will log supergraph and subgraphs requests/responses
5      experimental_when_header:
6        - name: apollo-router-log-request
7          value: my_client
8          headers: true # default: false
9          body: true # default: false
10        # log request for all requests coming from Iphones
11        - name: user-agent
12          match: ^Mozilla/5.0 (iPhone*
13          headers: true

Logging common reference

AttributeDefaultDescription
service_nameunknown_service:routerThe OpenTelemetry service name.
service_namespaceThe OpenTelemetry namespace.
resourceThe OpenTelemetry resource to attach to generated log events.

Experimental logging of broken pipe errors

You can emit a log message each time the client closes the connection early, which can help you debug issues with clients that close connections before the server can respond.

This feature is disabled by default but can be enabled by setting the experimental_log_broken_pipe option to true:

YAML
router.yaml
1supergraph:
2   experimental_log_on_broken_pipe: true
AttributeDefaultDescription
experimental_log_on_broken_pipefalseEmit a log message if a broken pipe was detected.