OpenTelemetry - Plugin - v3.1.x

古いプラグインバージョンのドキュメントを閲覧しています。

Looking for the plugin's configuration parameters? You can find them in the OpenTelemetry configuration reference doc.

Propagate distributed tracing spans and report low-level spans to a OTLP-compatible server.

The OpenTelemetry plugin is fully compatible with the OpenTelemetry specification and can be used with any OpenTelemetry compatible backend.

How it works

This section describes how the OpenTelemetry plugin works.

Collecting telemetry data

There are two ways to set up an OpenTelemetry backend:

Using a OpenTelemetry compatible backend directly, like Jaeger (v1.35.0+) All the vendors supported by OpenTelemetry are listed in the OpenTelemetry’s Vendor support.
Using the OpenTelemetry Collector, which is middleware that can be used to proxy OpenTelemetry spans to a compatible backend. You can view all the available OpenTelemetry Collector exporters at open-telemetry/opentelemetry-collector-contrib.

Tracing

Built-in tracing instrumentations

Kong Gateway has a series of built-in tracing instrumentations which are configured by the opentelemetry_tracing configuration. Kong Gateway creates a top-level span for each request by default when opentelemetry_tracing is enabled.

The top level span has the following attributes:

http.method: HTTP method
http.url: HTTP URL
http.host: HTTP host
http.scheme: HTTP scheme (http or https)
http.flavor: HTTP version
net.peer.ip: Client IP address

Propagation

The OpenTelemetry plugin supports propagation of the following header formats:

w3c: W3C trace context
b3 and b3-single: Zipkin headers
jaeger: Jaeger headers
ot: OpenTracing headers
datadog: Datadog headers

The plugin detects the propagation format from the headers and will use the appropriate format to propagate the span context. If no appropriate format is found, the plugin will fallback to the default format, which is w3c.

OTLP exporter

The OpenTelemetry plugin implements the OTLP/HTTP exporter, which uses Protobuf payloads encoded in binary format and is sent via HTTP/1.1.

connect_timeout, read_timeout, and write_timeout are used to set the timeouts for the HTTP request.

batch_span_count and batch_flush_delay are used to set the maximum number of spans and the delay between two consecutive batches.

Troubleshooting

The OpenTelemetry spans are printed to the console when the log level is set to debug in the Kong configuration file.

An example of debug logs output:

2022/06/02 15:28:42 [debug] 650#0: *111 [lua] instrumentation.lua:302: runloop_log_after(): [tracing] collected 6 spans:
Span #1 name=GET /wrk duration=1502.994944ms attributes={"http.url":"/wrk","http.method":"GET","http.flavor":1.1,"http.host":"127.0.0.1","http.scheme":"http","net.peer.ip":"172.18.0.1"}
Span #2 name=rewrite phase: opentelemetry duration=0.391936ms
Span #3 name=router duration=0.013824ms
Span #4 name=access phase: cors duration=1500.824576ms
Span #5 name=cors: heavy works duration=1500.709632ms attributes={"username":"kongers"}
Span #6 name=balancer try #1 duration=0.99328ms attributes={"net.peer.ip":"104.21.11.162","net.peer.port":80}

Known issues

Only supports the HTTP protocols (http/https) of Kong Gateway.
May impact the performance of Kong Gateway. It’s recommended to set the sampling rate (opentelemetry_tracing_sampling_rate) via Kong configuration file when using the OpenTelemetry plugin.

More information

次へ OpenTelemetry Configuration