instrumenting-first-party-metrics

Instrument PostHog application metrics via SDK or OpenTelemetry fallback paths.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill instrumenting-first-party-metrics
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: instrumenting-first-party-metrics
Source: https://github.com/PostHog/posthog-foss/tree/main/.agents/skills/instrumenting-first-party-metrics
Command: npx skills add https://github.com/PostHog/posthog-foss --skill instrumenting-first-party-metrics

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Developers working in the PostHog monorepo or PostHog-owned services need to ship application metrics (counters, gauges, histograms) into the PostHog Metrics product, but the correct path depends on the environment and pinned SDK versions, and wrong choices lead to silently dropped metrics or hand-rolled OTel plumbing.

Core Features & Use Cases

  • Environment-based path selection: Decision table mapping monorepo Python (web, Celery, Temporal), Node services, and standalone services to the right SDK or OTel fallback.
  • Version gate checks: Verifies posthog-python 7.23.0, posthog-node 5.43.0, and posthog-js ~1.399.0 before choosing the SDK path, with the OTel factory as fallback.
  • Validation workflow: Confirms metrics actually arrive via MCP metric queries, the Metrics UI, or SQL against posthog.metrics, plus unit testing guidance.
  • Use Case: Adding a counter for processed jobs in a Celery worker — check the pinned posthoganalytics version, record via posthoganalytics.default_client.metrics or the OtelInstrumentFactory twin, then verify arrival with a SQL query.

Quick Start

Ask the assistant to add a counter metric for jobs processed in the monorepo Celery worker and verify it arrives in posthog.metrics.

Frequently Asked Questions about instrumenting-first-party-metrics

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add application metrics in the PostHog monorepo?

First check the pinned posthoganalytics version in pyproject.toml against 7.23.0. If supported, record via posthoganalytics.default_client.metrics; otherwise use OtelInstrumentFactory from posthog/otel_metrics.py as the fallback.

Which PostHog SDK versions support posthog.metrics?

posthog.metrics shipped in posthog-python 7.23.0 (posthoganalytics is the same renamed package), posthog-node 5.43.0, and posthog-js around 1.399.0. Below these gates, use the OTel fallback rather than a workaround.

Why are my metrics not appearing in the PostHog Metrics UI?

In monorepo DEBUG and TEST modes the default client is disabled, so the SDK path records nothing locally, and unset OTEL_METRICS_EXPORT_URL makes the OTel factory a no-op. Verify arrival with SQL against posthog.metrics after about one minute of ingestion lag.

Should I use the PostHog SDK or OpenTelemetry for metrics?

Prefer the SDK path per the public docs whenever the pinned version supports posthog.metrics. Use the internal OtelInstrumentFactory only as a fallback when the SDK path is unavailable, and never hand-roll MeterProviders or exporters.

Can I keep existing Prometheus metrics alongside PostHog metrics?

Yes, keep a prometheus_client instrument when a Grafana dashboard depends on it, and mirror it with record_counter_twin, record_histogram_twin, or record_gauge_twin so the twin derives names and buckets from the existing instrument.