docs(observability): consolidate OTLP signal guidance - #795
Conversation
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
The OTLP signal documentation is comprehensive, but this PR does not yet update the two experimental source-first binding entry points:
Please add concise C FFI and Go guidance for the #783 surface: structured marks with data schemas and severities, metric emission, independent OTLP log/metric subscriber lifecycle (register, force flush, deregister, shutdown, free/Close), and Go observability configuration v4 with logs/metrics and endpoint derivation. Keep the existing experimental/source-first positioning; this does not need framework-integration documentation. |
|
Follow-up for the direct C/Go surface: #783 now also adds bounded per-subscriber runtime diagnostics. Please document that each direct trace, log, and metric subscriber can return stable code/message/count failure summaries (C returns an owned JSON array; Go exposes RuntimeDiagnostics()), alongside the lifecycle guidance above. |
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
Overview
Consolidate the OTLP log, metric, and dynamic-plugin runtime-diagnostics documentation after the implementation PRs land.
This is a draft fan-in documentation PR. It is independently based on
mainand has no branch-history dependency on the implementation PRs. Do not merge it until #781, #782, #783, and #779 have merged.Details
runtime_diagnostics()usage: the host-level{ code, message, count }snapshot, stable code ordering, 32-entry bound, lack of per-plugin attribution, ABI-v4struct_sizenegotiation, and old-worker-hostUNIMPLEMENTEDbehavior.Validation:
git diff --check origin/main...docs/otel-signals-fan-injust docsjust docs-linkcheckremains to be run before this draft is marked ready.Breaking changes: none.
Where should the reviewer start?
Start with
docs/configure-plugins/observability/opentelemetry.mdx, then review the dynamic-plugin runtime-diagnostics additions indocs/build-plugins/dynamic-plugins/native-dynamic/about.mdxanddocs/build-plugins/dynamic-plugins/grpc-worker/grpc-worker-protocol.mdx.Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)