Add otel.sdk.processor.log.processed metric - #7486
Conversation
Implement the otel.sdk.processor.log.processed counter metric for
BatchLogRecordExportProcessor and SimpleLogRecordExportProcessor.
The metric is emitted on meter 'otel.sdk.experimental' which requires
explicit opt-in via .AddMeter("otel.sdk.experimental") — zero overhead
without a listener.
Attributes:
- otel.component.type: batching_log_processor | simple_log_processor
- otel.component.name: unique instance identifier (e.g. batching_log_processor/0)
- error.type (conditional): queue_full | already_shutdown
Design:
- SdkSelfObservability internal helper owns the Meter and Counter
- Pre-allocated KeyValuePair[] tag arrays (no per-call allocation)
- Batch processor uses TryExport return value to classify success vs queue_full
- Both processors detect post-shutdown state via OnShutdown override
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #7486 +/- ##
==========================================
+ Coverage 90.43% 90.48% +0.05%
==========================================
Files 290 292 +2
Lines 15989 16077 +88
==========================================
+ Hits 14459 14547 +88
Misses 1530 1530
Flags with carried forward coverage won't be shown. Click here to find out more.
|
The test was flaky on Windows ARM / net462 because with maxQueueSize=1 and maxExportBatchSize=1, the worker thread could drain the queue faster than items were being emitted, resulting in no drops. Use a blocking DelegatingExporter to hold the worker in Export() while filling the queue.
| break; | ||
| } | ||
|
|
||
| // TODO: Consider switching to an ObservableCounter that piggybacks on |
There was a problem hiding this comment.
Will file a tracking issue for this.
There was a problem hiding this comment.
Cool - just add a link to the TODO once created.
c6a9a18 to
8c89abe
Compare
- Copy MeterFactory from contrib for auto-versioning - Make Meter internal (removes SA1202 suppression) - Share base tags between success/error arrays - Single Counter.Add() call with local tag assignment - Shorten README overhead note
8c89abe to
6c5df34
Compare
| /// </summary> | ||
| public class BatchLogRecordExportProcessor : BatchExportProcessor<LogRecord> | ||
| { | ||
| private static int instanceCounter = -1; |
There was a problem hiding this comment.
While unlikely there'd ever be that many created in the lifetime of a process, maybe use long to give more headroom against overflow?
| break; | ||
| } | ||
|
|
||
| // TODO: Consider switching to an ObservableCounter that piggybacks on |
There was a problem hiding this comment.
Cool - just add a link to the TODO once created.
|
This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day. |
|
@cijothomas, I asked Codex /GPT 5.6 Sol. Briefly checked findings and it looks valid to me: Following comment is AI driven Reviewed commit: 1. Count batch success at exporter submission, not queue admissionPriority: P1
The semantic convention says that, for simple and batching processors, a log The successful increment should happen at the worker/export boundary. Queue Specification: 2. The simple processor reports exported records as
|
| { | ||
| using (var batch = new Batch<T>(this.CircularBuffer, this.MaxExportBatchSize)) | ||
| { | ||
| this.exportStarted?.Invoke(batch.Count); |
There was a problem hiding this comment.
Should we defend against this callback throwing so that Export() is still called?
| SpinWait spinner = default; | ||
| while (Volatile.Read(ref this.activeOnEndCount) != 0) | ||
| { | ||
| spinner.SpinOnce(); | ||
| } |
There was a problem hiding this comment.
Should this honour timeoutMilliseconds too?
| SpinWait spinner = default; | ||
| while (Volatile.Read(ref this.activeOnEndCount) != 0) |
Pull request dashboard statusWaiting on the author · refreshed 2026-07-31 19:36 UTC Respond to 4 review items (e.g. link a commit, explain why not, ask a follow-up): Status above doesn't look right?
|
…bs-processor-log-processed # Conflicts: # src/OpenTelemetry/.publicApi/Stable/PublicAPI.Unshipped.txt # src/OpenTelemetry/CHANGELOG.md
|
Hi @cijothomas — just a friendly reminder that this pull request is waiting on you. There are still items that need your attention. See the dashboard status comment for the full list. You don't need to push a code change to hand it back — replying to move each discussion forward is enough, whether that's answering a question, explaining why no change is needed, or asking a follow-up. The dashboard then automatically routes it back to reviewers. If you believe this pull request is incorrectly routed as waiting on the author, comment |
Towards #3880
Adds the
otel.sdk.processor.log.processedcounter metric toBatchLogRecordExportProcessorandSimpleLogRecordExportProcessor, following the OTel SDK self-observability semantic conventions.This is the first SDK self-observability metric in the .NET SDK. More metrics (queue size, exporter counters, etc.) will follow in subsequent PRs.
Design
otel.sdk.experimental- requires explicit opt-in via.AddMeter("otel.sdk.experimental"). Without this,Counter.Add()is a no-op with zero overhead.Counter<long>namedotel.sdk.processor.log.processedotel.component.type-batching_log_processororsimple_log_processorotel.component.name- unique per instance (e.g.batching_log_processor/0)error.type(conditional) -queue_fullwhen buffer rejects,already_shutdownwhen processor has been shut downOpt-in example
Why .AddMeter() instead of env variable or compile-time flag?
Metrics in .NET are inherently opt-in: without a
MeterProvidersubscribing to the meter,Counter.Add()is a no-op at near-zero cost. The.AddMeter("otel.sdk.experimental")call provides natural gating without requiring additional mechanisms like env variables or feature flags.