open-telemetry/opentelemetry-collector-contrib

Component(s) receiver/flinkmetrics Details Code owners for this component have explicitly stated they will no longer maintain the code or have been unresponsive to issues/pull requests. Wait 6 weeks for the code owner to provide feedback, either here or in the linked issue Attempt to recruit new code owners, potentially from the community (cc @JonathanWamsley) On 19-Nov-2026, 6 weeks from now, the component will be labeled as unmaintained if the original code owner is still unresponsive and no other code owner for the component has been found On 8-Apr-2027, 6 months from now, the component will be removed https://github.com/open-telemetry/opentelemetry-collector#unmaintained Pull requests / Issues #49624 #51638 Tip React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.

Component processor/filter Description Many collector components emit internal telemetry defined in their metadata.yaml, but these self-observability metrics are not always documented in the component's README. The filter processor defines internal metrics in metadata.yaml to track dropped telemetry across signals: otelcol_processor_filter_datapoints.filtered: Number of metric data points dropped otelcol_processor_filter_logs.filtered: Number of logs dropped otelcol_processor_filter_profiles.filtered: Number of profiles dropped otelcol_processor_filter_spans.filtered: Number of spans dropped However, processor/filterprocessor/README.md currently lacks a Telemetry section for these metrics. Expected Behavior Add a "Telemetry" section to processor/filterprocessor/README.md documenting what each metric means, its type, and when it is emitted.

Component(s) receiver/kafka Is your feature request related to a problem? Please describe. The fetch limits (max_fetch_size, max_partition_fetch_size) bound compressed bytes only. franz-go decompresses a whole record batch before PollRecords returns, so a small, highly compressible batch on a consumed topic can expand to far more memory than the fetch limits suggest. franz-go v1.22.0 added kgo.MaxDecompressBatchBytes (default 1 GiB) to bound this, and the receiver now builds with v1.22.1, so it inherits that default. Two gaps remain: The bound is not configurable. 1 GiB per batch is more than many collector deployments can absorb. The memory_limiter processor runs after the receiver, so it cannot refuse this allocation. An over-limit batch stalls its partition. franz-go returns *kgo.ErrDecompressTooLarge once and stops consuming that partition until the application calls SetOffsets past the batch or recreates the client. franzConsumer.consume currently handles it like any other fetch

Component: pkg/ottl (ottlfuncs), as used by processor/transform Version: v0.161.0 (pdata v1.67.0); the loop is unchanged on main as of v0.162.0 Summary replace_all_patterns(target, "key", pattern, replacement) rebuilds the target map by moving every entry into a fresh pcommon.Map through PutEmpty. PutEmpty first calls Map.Get, which is a linear scan. Inserting n keys therefore costs 1 + 2 + … + n comparisons, which is O(n²), even when the pattern matches nothing. Any sender that controls attribute keys can use this to stall a collector's pipeline goroutine. For example, one OTLP request carrying a resource with tens of thousands of attributes is enough. Where pkg/ottl/ottlfuncs/func_replace_all_patterns.go:86-107 (case modeKey): updated.PutEmpty(key) for every key, matched or not. pdata/pcommon/map.go: PutEmpty (lines 114-122) calls m.Get(k). Get (lines 65-73) is for i := range *m.getOrig(), a linear scan. Reproduction The benchmark below reproduces the loop with pdata v1.67.0

Component(s) pkg/ottl What happened? Description When Time() is called without a location and the format ends with %Z, it parses in time.UTC instead of time.Local, so abbreviations like KST fail with unknown time zone KST even when the local time zone is KST. #50225 fixed the same problem in stanza, but OTTL still has it. Root cause timeutils.GetLocation returns UTC when the layout ends with Z, which is meant for a literal Zulu Z in a Go layout. // internal/coreinternal/timeutils/parser.go if layout != nil && strings.HasSuffix(*layout, "Z") { return time.UTC, nil } Since v0.155.0 Time() passes the raw strptime format, so the Z of %Z matches this check. Steps to Reproduce Local time zone set to KST. Input read by filelog: {"case":"suffix","ts":"2026-09-08 19:02:42 KST"} {"case":"middle","ts":"Tue Sep 08 19:02:42 KST 2026"} receivers: filelog: include: [/data/sample.log] start_at: beginning operators: - type: json_parser parse_to: body processors: transfor