docs(metrics): add the standard instrumentation recipe for internal teams - #70805
Closed
DanielVisca wants to merge 3 commits into
Closed
docs(metrics): add the standard instrumentation recipe for internal teams#70805DanielVisca wants to merge 3 commits into
DanielVisca wants to merge 3 commits into
Conversation
…eams One page teams can follow without asking the APM team: which SDK per runtime, the standard service_name/environment config, naming and cardinality conventions, the throughput/failures/latency/backlog starter set, and the verify-then-alert loop now that metric alerting is merged. Generated-By: PostHog Code Task-Id: 0d65d94c-c18a-4d84-93f6-18eb54876551
Contributor
🤖 CI reportℹ️ Docs preview — preview build triggeredDocs from this PR will be published at posthog.com.
The preview should be ready in about 10 minutes. Open the preview at |
Explicit environment fallback (unset env var silently omitted the attribute, defeating the staging/production split the doc promises), version prerequisite note for the metrics client option, configurable-cap wording instead of "hard-caps", clearer backlog phrasing, and a sharper prefork gotcha for module-level Django clients. Generated-By: PostHog Code Task-Id: 0d65d94c-c18a-4d84-93f6-18eb54876551
…ecipe" This reverts commit ed5a70b.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
With the Metrics alpha live in the nav and metric alerting merged, internal teams are the first adopters — but there's no single standard answer to "how do I add metrics to my service?". Without one, each team picks its own naming, its own service_name convention, and (worst case) stands up a Prometheus registry + bridge, which we've already decided against for application instrumentation.
Changes
Adds
docs/internal/metrics/instrumenting-your-service.md— one page: SDK decision table (js released / node + python in review / OTel for the rest), the standard config block (service_name= k8s deployment name,environmentfrom the deploy env), dot-separated domain-first naming, cardinality rules, the 4-metric starter set (throughput/failures/latency/backlog), and the verify → save insight → alert → dashboard loop.Companion PRs it links: posthog-js#4117 (node wiring, rebased + ready), posthog-python#739 (new python port).
How did you test this code?
Docs-only. Snippets match the actual SDK APIs in the linked PRs (
metricsclient option shape verified against both implementations).🤖 Agent context
Autonomy: Human-driven (agent-assisted) — Daniel directed this; assigned as DRI. Written by Claude as part of the metrics SDK-onboarding track; conventions distilled from the existing
/docs/metricspublic docs, the dogfood-SDK-first decision, and the alerting work that just merged.