Skip to content

Commit 90ef61d

Browse files
authored
Merge pull request openshift#11 from pavolloffay/distributed-tracing-3.0-span-red
Document Tempo monitor tab and span RED metrics
2 parents 1c86957 + 7785d6e commit 90ef61d

File tree

3 files changed

+122
-0
lines changed

3 files changed

+122
-0
lines changed

distr_tracing/distr_tracing_tempo/distr-tracing-tempo-configuring.adoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,8 @@ include::modules/distr-tracing-tempo-config-storage.adoc[leveloffset=+2]
2121

2222
include::modules/distr-tracing-tempo-config-query-frontend.adoc[leveloffset=+2]
2323

24+
include::modules/distr-tracing-tempo-config-spanmetrics.adoc[leveloffset=+2]
25+
2426
[id="setting-up-monitoring-for-tempo"]
2527
== Setting up monitoring for the {TempoShortName}
2628

modules/distr-tracing-otel-config-collector.adoc

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,8 @@ Processors:: Optional. Processors run through the data between it is received an
1414

1515
Exporters:: An exporter, which can be push or pull based, is how you send data to one or more back ends or destinations. By default, no exporters are configured. One or more exporters must be configured. Exporters can support one or more data sources. Exporters might be used with their default settings, but many exporters require configuration to specify at least the destination and security settings.
1616

17+
Connectors:: A connector connects two pipelines: It consumes data as an exporter at the end of one pipeline and emits data as a receiver at the start of another pipeline. It can consume and emit data of the same or different data type. It can generate and emit data to summarize the consumed data, or it can merely replicate or route data.
18+
1719
You can define multiple instances of components in a custom resource YAML file. When configured, these components must be enabled through pipelines defined in the `spec.config.service` section of the YAML file. As a best practice, only enable the components that you need.
1820

1921
.Example of the OpenTelemetry Collector custom resource file
@@ -418,3 +420,30 @@ service:
418420
<4> The client password is configured as a client authenticator for the BasicAuth extension.
419421
<5> The authenticator configuration can be assigned to an OTLP receiver.
420422
<6> The authenticator configuration can be assigned to an OTLP exporter.
423+
424+
[id="connectors_{context}"]
425+
=== Connectors
426+
427+
[id="spanmetrics-connector_{context}"]
428+
==== Spanmetrics connector
429+
430+
Aggregates Request, Error, and Duration (R.E.D) OpenTelemetry metrics from span data.
431+
432+
* Support level: link:https://access.redhat.com/support/offerings/techpreview[Technology Preview]
433+
* Supported signals: traces
434+
435+
.OpenTelemetry Collector custom resource with an enabled spanmetrics connector
436+
[source,yaml]
437+
----
438+
config: |
439+
connectors:
440+
spanmetrics:
441+
metrics_flush_interval: 15s <1>
442+
service:
443+
pipelines:
444+
traces:
445+
exporters: [spanmetrics]
446+
metrics:
447+
receivers: [spanmetrics]
448+
----
449+
<1>: Defines the flush interval of the generated metrics. Defaults to `15s`.
Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * distr_tracing_tempo/distr-tracing-tempo-configuring.adoc
4+
5+
:_content-type: REFERENCE
6+
[id="distr-tracing-tempo-config-spanmetrics_{context}"]
7+
= Configuration of the monitor tab in Jaeger UI
8+
9+
Trace data contains rich information, and the data is normalized across instrumented languages and frameworks.
10+
Therefore, additional metrics can be extracted from traces. These metrics are request count, duration, and error count (RED).
11+
The metrics can be visualized in Jaeger console in the *Monitor* tab.
12+
13+
The metrics are derived from spans in the OpenTelemetry Collector that are scraped from the Collector by the Prometheus deployed in the user-workload monitoring stack.
14+
The Jaeger UI queries these metrics from the Prometheus endpoint and visualizes them.
15+
16+
== OpenTelemetry Collector configuration
17+
18+
The OpenTelemetry Collector requires configuration of the `spanmetrics` connector that derives metrics from traces and exports the metrics in the Prometheus format.
19+
20+
.OpenTelemetry Collector custom resource for span RED
21+
[source,yaml]
22+
----
23+
kind: OpenTelemetryCollector
24+
apiVersion: opentelemetry.io/v1alpha1
25+
metadata:
26+
name: otel
27+
spec:
28+
mode: deployment
29+
observability:
30+
metrics:
31+
enableMetrics: true <1>
32+
config: |
33+
connectors:
34+
spanmetrics: <2>
35+
metrics_flush_interval: 15s
36+
37+
receivers:
38+
otlp: <3>
39+
protocols:
40+
grpc:
41+
http:
42+
43+
exporters:
44+
prometheus: <4>
45+
endpoint: 0.0.0.0:8889
46+
resource_to_telemetry_conversion:
47+
enabled: true # by default resource attributes are dropped
48+
49+
service:
50+
pipelines:
51+
traces:
52+
receivers: [otlp]
53+
exporters: [otlp, spanmetrics] <5>
54+
metrics:
55+
receivers: [spanmetrics] <6>
56+
exporters: [prometheus]
57+
----
58+
<1> Creates the `ServiceMonitor` custom resource to enable scraping of the Prometheus exporter.
59+
<2> The Spanmetrics connector receives traces and exports metrics.
60+
<3> The OTLP receiver to receive spans in the OpenTelemetry protocol.
61+
<4> The Prometheus exporter is used to export metrics in the Prometheus format.
62+
<5> The Spanmetrics connector is configured as exporter in traces pipeline.
63+
<6> The Spanmetrics connector is configured as receiver in metrics pipeline.
64+
65+
== Tempo configuration
66+
67+
The `TempoStack` custom resource must specify the following: the *Monitor* tab is enabled, and the Prometheus endpoint is set to the Thanos querier service to query the data from the user-defined monitoring stack.
68+
69+
.TempoStack custom resource with the enabled Monitor tab
70+
[source,yaml]
71+
----
72+
kind: TempoStack
73+
apiVersion: tempo.grafana.com/v1alpha1
74+
metadata:
75+
name: simplest
76+
spec:
77+
template:
78+
gateway:
79+
enabled: false <1>
80+
queryFrontend:
81+
jaegerQuery:
82+
enabled: true
83+
monitorTab:
84+
enabled: true <2>
85+
prometheusEndpoint: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 <3>
86+
ingress:
87+
type: route
88+
----
89+
<1> Gateway must be enabled because the Monitor tab is not supported thorough the gateway deployment.
90+
<2> Enables the monitoring tab in the Jaeger console.
91+
<3> The service name for Thanos Querier from user-workload monitoring.

0 commit comments

Comments
 (0)