You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the consumer is wired with `errs.AlwaysRetryableProcessor` (DLQ reconciliation), the framework overrides this: every non-nil error is forced retryable so the DLQ message comes back for another attempt. See `submitqueue/orchestrator/controller/dlq/README.md`.
120
120
121
-
The consumer records `process.controller_latency` after the error processor runs. Every series has `result=success|error|cancel`; error and cancellation series also include `error_origin=user|infra`, `retryable=true|false`, and `dependency=true|false`. These dimensions therefore describe the processed error that drives ack, nack, or reject behavior rather than the controller's raw return value.
121
+
The consumer records controller operations with `process.start` and `process.finish`. The finish histogram records both latency and completion count with `result=success|error|cancel`; error and cancellation series also include `origin=infra|infra_retryable|user` and `dependency=yes|no`. These dimensions are added after error processing, so they describe the classified error that drives ack, nack, or reject behavior rather than the controller's raw return value. The lifecycle histogram count replaces separate received, processed, and controller-error counters.
Copy file name to clipboardExpand all lines: platform/metrics/README.md
+10-2Lines changed: 10 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ The `metrics` package provides reusable helpers for emitting counters and histog
8
8
9
9
**Operation lifecycle** — `Begin` and `Complete` tie operation metrics together. `Begin` captures the start time and emits `{name}.start`; `Complete` records duration and count on `{name}.finish`.
10
10
11
-
**Result tagging** — the finish histogram is tagged with `result=success`, `result=error`, or `result=cancel`. Cancellation is detected with `errors.Is(err, context.Canceled)`. Error classification tags are intentionally omitted because many call sites complete before classification occurs.
11
+
**Result tagging** — the finish histogram is tagged with `result=success`, `result=error`, or `result=cancel`. Cancellation is detected with `errors.Is(err, context.Canceled)`. Callers that accumulate tags while the operation runs can pass them to `Complete`.
12
12
13
13
**Consistent naming** — named helpers follow the `{name}.{sub}` sub-scope pattern, producing metric paths such as `process.start` and `publish.attempts`.
14
14
@@ -19,7 +19,7 @@ For any operation with a clear start and end, use `Begin` and `Complete`:
19
19
| Function | Emits |
20
20
|----------|-------|
21
21
|`Begin(scope, name, buckets, ...tags)`|`{name}.start` counter +1 and returns an `Op`|
22
-
|`op.Complete(err)`|`{name}.finish` histogram tagged with `result=success\|error\|cancel`|
22
+
|`op.Complete(err, ...tags)`|`{name}.finish` histogram tagged with `result=success\|error\|cancel` and any completion tags|
23
23
24
24
`buckets` is required at `Begin` because operations differ widely in expected latency. The finish histogram records both the duration distribution and the number of completed operations, so `Complete` does not emit a separate counter.
Tags passed to `Begin` apply to both lifecycle metrics. Tags known only after execution, such as an error classification, can be attached to the finish histogram:
0 commit comments