Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 98 additions & 0 deletions modules/concepts/pages/observability/telemetry.adoc
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
= Telemetry signals in operators
:page-aliases: ../telemetry.adoc
:env-filter-syntax: https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#example-syntax
:vector-helm-chart: https://github.com/vectordotdev/helm-charts/tree/develop/charts/vector

[NOTE]
====
Expand Down Expand Up @@ -93,3 +94,100 @@ telemetry:
<1> Boolean: `true`, `false`
<2> String: `error`, `warn`, `info`, `debug`, `trace`, `off` (or {env-filter-syntax}[more complex filters,window=_blank])
<3> String: E.g. `https://my-collector:4317` (Note: it must contain the scheme)

== OpenTelemetry with Vector

OpenTelemetry signals can be configured to behave like xref:logging.adoc[product logging]. Using the {vector-helm-chart}[vector helmChart] requires to configure `containerPorts` and `service.ports` as well as `customConfig.sources.otel`:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
OpenTelemetry signals can be configured to behave like xref:logging.adoc[product logging]. Using the {vector-helm-chart}[vector helmChart] requires to configure `containerPorts` and `service.ports` as well as `customConfig.sources.otel`:
OpenTelemetry signals can be configured to behave like xref:logging.adoc[product logging]. Using the {vector-helm-chart}[Vector Helm Chart] requires `containerPorts`, `service.ports`, and `customConfig.sources.otel` to be configured:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "behave like product logging" mean exactly? A short explanation what that refers to, would be nice.

Copy link
Copy Markdown
Member

@xeniape xeniape Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
OpenTelemetry signals can be configured to behave like xref:logging.adoc[product logging]. Using the {vector-helm-chart}[vector helmChart] requires to configure `containerPorts` and `service.ports` as well as `customConfig.sources.otel`:
OpenTelemetry signals can be configured to behave like xref:logging.adoc[product logging]. Using the {vector-helm-chart}[Vector Helm Chart{external-link-icon}^] requires to configure the Helm values `containerPorts`, `service.ports`, and `customConfig.sources.otel`:

Copy link
Copy Markdown
Member

@xeniape xeniape Apr 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adjusted the suggestion to include the external link indicator for the external Helm Chart


[source,yaml]
----
containerPorts:
- {name: vector, containerPort: 6000, protocol: TCP}
- {name: otel-grpc, containerPort: 4317, protocol: TCP}
- {name: otel-http, containerPort: 4318, protocol: TCP}
service:
ports:
- {name: vector, port: 6000, targetPort: 6000, protocol: TCP}
- {name: otel-grpc, port: 4317, targetPort: 4317, protocol: TCP}
- {name: otel-http, port: 4318, targetPort: 4318, protocol: TCP}
customConfig:
sources:
otel:
type: opentelemetry
grpc:
address: 0.0.0.0:4317
http:
address: 0.0.0.0:4318
----

The `endpoint` in the operator's Helm values must point to the ports defined above.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The `endpoint` in the operator's Helm values must point to the ports defined above.
The `endpoint` Helm values for the telemetry exporters in the Stackable Operator Helm Chart must point to the otel-grpc ports defined above.


[source,yaml]
----
telemetry:
otelLogExporter:
enabled: true
endpoint: http://vector-aggregator.<namespace>.svc.cluster.local:4317
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, if there is a specific reason why this port was used and not otel-http for example, even though they are defined in Vector, feel free to elaborate why. If any of them can be used, maybe the above sentence can be adjusted to reflect that.

otelTraceExporter:
enabled: true
endpoint: http://vector-aggregator.<namespace>.svc.cluster.local:4317
----

=== Normalizing operator logs to the Stackable log schema
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a bit confused, above the sections starts with OpenTelemetry signals (but behaving like logs?), but here the subsection is about logs, so something different? So either that's something general for logs, so maybe needs to be a separate 2nd level section (==) or at least for me it needs a bit more of an explanation connecting the two concepts here.


Operators do not run vector sidecars. Using OpenSearch, a VRL transform that maps the OTLP fields onto the
Copy link
Copy Markdown
Member

@xeniape xeniape Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Operators do not run vector sidecars. Using OpenSearch, a VRL transform that maps the OTLP fields onto the
Stackable Operators do not run Vector sidecars. Using OpenSearch, a VRL transform that maps the OTLP fields onto the

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VRL? I think the abbrevation written out (or written out in parentheses next to it) would be more useful for people not knowing what that is (me :D)

xref:tutorials:logging-vector-aggregator.adoc#_watch_the_logs[Stackable log schema] is needed to avoid re-indexing:

[source,yaml]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these Helm values for Opensearch now? (Because of "using Opensearch" above) Maybe this also needs a linked Helm Chart then or mentioning that it's our own Opensearch Operator Helm Chart? And a clarification where to set the values.

----
customConfig:
transforms:
normalize_otel_logs:
type: remap
inputs:
- otel.logs # <1>
source: |
service_name = get(.resources, ["service.name"]) ?? null
.pod = service_name # <2>
.container = service_name # <2>
.namespace = get(.resources, ["k8s.namespace.name"]) ?? null
.logger = string(.scope.name) ?? null # <3>
.level = string(.severity_text) ?? null
.built_info = object(.attributes) ?? {} # <4>
.cluster = null
.role = null
.roleGroup = null
.file = null
.source_type = "opentelemetry"
del(.severity_text)
del(.severity_number)
del(.resources)
del(.attributes)
del(.scope)
del(.trace_id)
del(.span_id)
del(.flags)
del(.observed_timestamp)
del(.dropped_attributes_count)
sinks:
opensearch:
inputs:
- vector
- normalize_otel_logs # <5>
----

<1> The `opentelemetry` source fans out into `otel.logs`, `otel.metrics`, and
`otel.traces`. Unconsumed sub-streams produce a startup warning.
Comment on lines +179 to +180
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<1> The `opentelemetry` source fans out into `otel.logs`, `otel.metrics`, and
`otel.traces`. Unconsumed sub-streams produce a startup warning.
<1> The `opentelemetry` source type diverges into `otel.logs`, `otel.metrics`, and
`otel.traces` signals. Unconsumed sub-streams produce a startup warning.

(Don't know if "signals" is the right word, but some kind of naming would sound better I think. Oh, or is sub-stream the correct term? Then feel free to use that instead of signal in the suggestion)

<2> Operators emit `service.name` (e.g. `stackable-airflow-operator`) as their
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is service.name correct here? Or should it be service_name like in the line it references?

primary identity. It is mapped to both `.pod` and `.container` but can be
adapted to individual needs.
<3> The OTLP `scope.name` contains the Rust module path (e.g.
`kube_runtime::controller`) and maps to the `.logger` field.
<4> Log-record attributes (e.g. `built_info.*`) are collected into a single object
to keep the top-level schema flat.
<5> Reference transformer output as sinks input.

[NOTE]
====
Namespace information is currently not emitted by the operator
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Namespace information is currently not emitted by the operator
Namespace information is currently not emitted by the operator.

====
Loading