PostHog-Observability

Die gesamte Telemetrie des Repositorys gehört zum RD Dashboard-PostHog-Projekt (279829, US Cloud). Die Build-Tools lehnen eine andere Projekt-ID ab. Verbinden Sie Entwicklungs-, Bereitstellungs- oder Quellkarten-Tools niemals mit einem anderen PostHog-Projekt.

Bereitstellungskonfiguration

Web-, Admin-, sämtliche Dokumentations- und Kinky Makers-Bereitstellungen verwenden Folgendes:

• NEXT_PUBLIC_POSTHOG_KEY
• NEXT_PUBLIC_POSTHOG_HOST=https://us.i.posthog.com
• POSTHOG_PROJECT_ID=279829
• POSTHOG_API_KEY als optionaler persönlicher, nur serverseitig verwendeter Schlüssel mit ausschließlich den für den Quellkarten-Upload erforderlichen Berechtigungen. Ohne ihn ist die Bereitstellung erfolgreich, überspringt jedoch den Quellkarten-Upload.

Dokumentationsbereitstellungen erfordern außerdem NEXT_PUBLIC_SUPABASE_URL und NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY des Release-Tracks, damit die gemeinsame Dashboard-Sitzung die numerische User.id auflösen kann.

Native EAS-Umgebungen erfordern EXPO_PUBLIC_POSTHOG_KEY, EXPO_PUBLIC_POSTHOG_HOST und EXPO_PUBLIC_APP_ENV. Native Quellkarten und Symbole erfordern zusätzlich POSTHOG_CLI_API_KEY, POSTHOG_CLI_HOST=https://us.posthog.com und POSTHOG_CLI_PROJECT_ID=279829.

Supabase-Edge-Funktionen erfordern POSTHOG_PROJECT_KEY, POSTHOG_HOST und DEPLOYMENT_ENVIRONMENT. Leiten Sie fehlgeschlagene Anfragen an Logs weiter. Erfolgreiche Geräte-Telemetrie wird vom Web-Proxy als Produktereignisse zusammengefasst.

Geben Sie niemals einen persönlichen API-Schlüssel über eine Variable mit dem Präfix NEXT_PUBLIC_ oder EXPO_PUBLIC_ preis.

Identitätsvertrag

• RAD-Web-, Dokumentations-, native, Admin- und Serverereignisse identifizieren eine angemeldete Person anhand der dezimalen Anwendungs-ID User.id, die als Zeichenfolge serialisiert wird.
• Kinky Makers verwendet km:<Supabase auth UUID>, bis es das RAD-Profilmodell teilt. Das Präfix verhindert versehentliche Identitätszusammenführungen.
• Browser- und native Clients rufen beim Abmelden und vor dem Wechsel zu anderen identifizierten Konten reset() auf.
• Hardware ist eine device-Gruppe. Eine MAC-Adresse ist niemals eine Personen-ID oder ein Gruppenschlüssel; verwenden Sie den gehashten stabilen Gerätebezeichner.

Diese Regeln ermöglichen es Supportmitarbeitenden, anhand einer Anwendungsbenutzer-ID die Web-, nativen, Server-, Sitzungs-, Fehler- und Protokolldatensätze dieser Person zu finden, ohne private Hardware-IDs offenzulegen.

Erforderlicher Kontext und Privatsphäre

Jeder Dienst fügt, sofern verfügbar, service_name, platform, environment, eine Release- oder Versionsnummer sowie Bereitstellungskennungen hinzu. Fehlgeschlagene Serveranfragen enthalten außerdem Route, Methode, Anforderungs-ID und traceparent.

Senden Sie keine Anfragekörper, Zugriffstoken, E-Mail-Adressen, intimen Inhalte, Prompts oder Antworten, Suchtexte, lokale Dateiinhalte, rohe MAC-Adressen oder Geräteanmeldedaten. Die Docs-Wiedergabe maskiert Eingaben und blockiert Gerätepanels. Die Admin-Wiedergabe ist nur strukturell: Sie maskiert Text, Eingaben und Attribute und blockiert Datensätze, Nachrichten, Abfragen, Bilder, Video und Canvas. Beide Oberflächen unterdrücken lokal die Aufzeichnung von Konsole und Netzwerkverkehr. Abfragezeichenfolgen und Fragmente werden aus Ereignis- und Replay-URLs entfernt. Die Analytics-Präferenz der übergeordneten Domäne ermöglicht Besuchern, sich auf den kanonischen Browseroberflächen abzumelden.

Release-Verifizierung

Nach jeder Staging- oder Produktionsbereitstellung:

1. Bestätigen Sie, dass ein Ereignis die erwartete environment, den Git-SHA, die Bereitstellungs-ID, die Anwendungsversion, den Dienst und die Plattform enthält.
2. Bestätigen Sie, dass Web- und native Ereignisse für dasselbe RAD-Konto dieselbe numerische distinct ID verwenden.
3. Bestätigen Sie, dass nach der Abmeldung und einer anderen Anmeldung keine Warnung zur Identitätszusammenführung bei der Erfassung entsteht.
4. Bestätigen Sie, dass sich Daten aus Web, Admin, Kinky Makers, nativen Clients und Edge-Funktionen nach Dienst und Umgebung trennen lassen.
5. Bestätigen Sie, dass eine Testausnahme über die hochgeladene Quellzuordnung oder native Symbole bis zur Quelle aufgelöst werden kann.
6. Bestätigen Sie, dass ein Serverfehler ein Fehler-Issue und ein korreliertes OTLP-Log erzeugt.
7. Bestätigen Sie, dass Geräteereignisse eine device-Gruppe und keine rohe MAC-Adresse enthalten.

Das Repository-Runbook unter docs/posthog-observability.md enthält die entsprechende Betreiber-Checkliste.