This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [go.opentelemetry.io/collector/confmap](https://github.com/open-telemetry/opentelemetry-collector) | `v1.54.0` → `v1.55.0` |  |  | --- ### Release Notes <details> <summary>open-telemetry/opentelemetry-collector (go.opentelemetry.io/collector/confmap)</summary> ### [`v1.55.0`](https://github.com/open-telemetry/opentelemetry-collector/blob/HEAD/CHANGELOG.md#v1550v01490) ##### 🛑 Breaking changes 🛑 - `pkg/service`: Remove `service_name`, `service_instance_id`, and `service_version` as constant labels on every internal metric datapoint. These attributes are already present in `target_info` and were being duplicated on each series for OpenCensus backwards compatibility. ([#​14811](https://github.com/open-telemetry/opentelemetry-collector/issues/14811)) Previously, the collector stamped every internal metric series (e.g. `otelcol_process_runtime_heap_alloc_bytes`) with `service_name`, `service_instance_id`, and `service_version` labels to match the old OpenCensus behavior. These attributes are now only present in the `target_info` metric, which is the correct Prometheus/OTel convention. Users who filter or group by these labels on individual metrics will need to update their queries to use `target_info` joins instead. ##### 💡 Enhancements 💡 - `all`: Move aix/ppc64 to tier 3 support ([#​13380](https://github.com/open-telemetry/opentelemetry-collector/issues/13380)) - `all`: Upgrade the profiles stability status to alpha ([#​14817](https://github.com/open-telemetry/opentelemetry-collector/issues/14817)) The following components have their profiles status upgraded from development to alpha: - pdata/pprofile - connector/forward - exporter/debug - receiver/nop - exporter/nop - exporter/otlp\_grpc - exporter/otlp\_http - `cmd/mdatagen`: Add semconv reference for attributes ([#​13297](https://github.com/open-telemetry/opentelemetry-collector/issues/13297)) ##### 🧰 Bug fixes 🧰 - `cmd/mdatagen`: Fix entity code generation so `extra_attributes` are emitted as resource attributes instead of entity descriptive attributes. ([#​14778](https://github.com/open-telemetry/opentelemetry-collector/issues/14778)) <!-- previous-version --> </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My41LjQiLCJ1cGRhdGVkSW5WZXIiOiI0My41LjQiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbXX0=--> Reviewed-on: https://gitea.t000-n.de/t.behrendt/tracebasedlogsampler/pulls/44 Reviewed-by: t.behrendt <t.behrendt@noreply.localhost> Co-authored-by: Renovate Bot <renovate@t00n.de> Co-committed-by: Renovate Bot <renovate@t00n.de>
Trace-based Log Sampler
This processor is used to sample logs based on the sampling decision of the trace they correlate to.
How It Works
When a trace is sampled, the processor caches its traceId.
Logs are then filtered:
- If a log references a known sampled
traceId, it is beimg forwarded. - If a log references an unknown or unsampled
traceId, it is buffered for a certain amount of time. After the buffer time expires, thetraceIdis checked again. If it exists, the log is forwarded. If not, it is discarded.
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
| buffer_duration_traces | duration | 180s | The duration for which traceIds are being remembered. The timer starts when the first trace or span of one traceId is received. |
| buffer_duration_logs | duration | 90s | The duration for which logs are being buffered for, before being re-evaluated. If your pipeline includes e.g. a tailbasedsampler processor, set this to above it's collection time. This ensures that logs "wait" until the traces have been processed |
Example Configuration
The followinh config is an example configuration for the processor. It is configured to buffer traceIds for 180 seconds and logs for 90 seconds.
Note that both a traces and logs pipeline is required and both have to use the same instance of the processor.
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
exporters:
otlp:
endpoint: 0.0.0.0:4317
processors:
logtracesampler:
buffer_duration_traces: 180s
buffer_duration_logs: 90s
service:
pipelines:
traces:
receivers: [otlp]
processors: [logtracesampler]
exporters: [otlp]
logs:
receivers: [otlp]
processors: [logtracesampler]
exporters: [otlp]
Building
When building a custom collector you can add this processor to the mainfest like the following (refer to Building a custom collector for more information):
processors:
- gomod: gitea.t000-n.de/t.behrendt/tracebasedlogsampler v0.0.0
Languages
Go
99.7%
Makefile
0.3%