Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feat][doc] PIP-264: Update OpenTelemetry deployment documentation #934

Merged
Merged
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
15 changes: 9 additions & 6 deletions docs/deploy-monitoring.md
Original file line number Diff line number Diff line change
Expand Up @@ -195,12 +195,7 @@ OTEL_EXPORTER_PROMETHEUS_PORT
This endpoint must be accessible by the remote Prometheus scrape server. Note that the exporter is less resource
efficient than the OTLP exporter.

Prometheus currently exports the resource attributes in metric `target_info`. In practice, if you have more than one
cluster, it forces you to use PromQL joins to obtain the cluster ID label.

The Pulsar community has added the option to the OpenTelemetry Java SDK Prometheus Exporter to embed (copy) the cluster
ID label (`pulsar.cluster`) to each outgoing time series labels. Once this is finalized it will be added by default into
Pulsar.
All OpenTelemetry resource attributes are automatically copied to Prometheus labels on each time series.

For further configuration details, refer to the exporter
[documentation](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/README.md#prometheus-exporter).
Expand Down Expand Up @@ -234,3 +229,11 @@ OpenTelemetry provides an experimental mechanism to control the maximum cardinal
limiting the resource usage of the exporter. Pulsar sets the value to 10000 attributes by default. For brokers with a
large number of topics, this can prove insufficient. The value is controlled by environment variable
`OTEL_EXPERIMENTAL_METRICS_CARDINALITY_LIMIT`.

#### Memory Reuse Configuration

OpenTelemetry provides an experimental mechanism to control the reuse of metric attributes. This is particularly useful
for systems with high cardinality metrics, as it reduces the number of memory allocations caused by collector runs. The
mechanism is enabled by default in Pulsar, and can be overridden by environment variable
`OTEL_JAVA_EXPERIMENTAL_EXPORTER_MEMORY_MODE`. For further details and valid configuration values, refer to the
exporter configuration [documentation](https://opentelemetry.io/docs/languages/java/configuration/#exporters).
Loading