Docs
Launch GraphOS Studio

Sending Apollo Router traces and metrics to APM tools using OpenTelemetry

Gain insight into your graph's performance and stability

observabilityrouter

Self-hosting the is limited to

. Other plan types use
managed cloud routing with GraphOS
. Check out the
pricing page
to learn more.

💡 TIP

If you're an enterprise customer looking for more material on this topic, try the

course on .

Not an enterprise customer?

Application performance monitoring (APM) tools are critical for many organizations, and having direct insight into how your is performing is an important piece of overall observability into your systems' stability and performance. The and aren't any different. While you may currently instrument your existing subgraphs with your APM's tooling, you may need to connect Apollo Router as well to get a clear view of your graph's health.

Thankfully, there's an answer on connecting the two pieces of software together:

. We've previously discussed utilizing
OpenTelemetry previously to connect to Prometheus
, and much of the same will apply to this use-case as well.

There are two ways to connect the to your APM using OpenTelemetry:

  • Using an OpenTelemetry Collector
  • Connecting directly

For our examples, we'll be connecting to New Relic, however this would apply to any APM that supports OpenTelemetry as an ingest option, such as Honeycomb or Dynatrace.

We recommend using the OpenTelemetry Collector to send metrics to your APM tool for the following reasons:

  • The collector provides a centralized reporter when running multiple instances.
  • The collector enables you to processing and send metrics to multiple locations beyond your APM tool, such as a local Prometheus instance.

You'll need an instance of the

to export to your APM tool. A basic configuration requires both an OpenTelemetry Protocol (OTLP) receiver (for the ) and an exporter (to forward to your APM tool).

Additionally, we recommend adding the batch processor to enable batch requests to each listed exporter.

Here's an example collector configuration for New Relic:

collector-config.yaml
receivers:
otlp:
protocols:
grpc:
http:
cors:
allowed_origins:
- http://*
- https://*
exporters:
otlp:
endpoint: ${OTEL_EXPORTER_OTLP_ENDPOINT}
headers:
api-key: ${NEW_RELIC_LICENSE_KEY}
processors:
batch:
service:
pipelines:
traces:
receivers: [otlp]
exporters: [otlp]
processors: [batch]
metrics:
receivers: [otlp]
exporters: [otlp]
processors: [batch]

The then needs to connect directly to the collector instance. Here's an example router configuration for that:

router.yaml
cors:
allow_any_origin: true
supergraph:
listen: 0.0.0.0:4000
telemetry:
metrics:
otlp:
endpoint: http://COLLECTOR_ADDRESS:4317
tracing:
trace_config:
service_name: 'router'
service_namespace: 'apollo'
otlp:
endpoint: http://COLLECTOR_ADDRESS:4317

For more information on configuration options, see the documentation on both

and
capturing traces
using OpenTelemetry Collector.

Connecting directly

Instead of using the OpenTelemetry Collector, you can configure your instances to send data directly to your APM tool. To do so, you modify the router's YAML configuration file to set the export to use a header (or in this case, metadata), along with the traces/metrics for passing the token.

Here's an example configuration for connecting directly to New Relic:

router.yaml
cors:
allow_any_origin: true
supergraph:
listen: 0.0.0.0:4000
telemetry:
metrics:
otlp:
endpoint: https://otlp.nr-data.net
grpc:
metadata:
'api-key': ['${env.NEW_RELIC_LICENSE_KEY}']
tracing:
trace_config:
service_name: 'router'
service_namespace: 'apollo'
otlp:
endpoint: https://otlp.nr-data.net
grpc:
metadata:
'api-key': ['${env.NEW_RELIC_LICENSE_KEY}']

This uses the NEW_RELIC_LICENSE_KEY environment variable for passing the key using the 's

to avoid including sensitive tokens in the configuration.

Next
Home
Edit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc.

Privacy Policy

Company