- Installieren Sie das SDK-Paket für Ihre Laufzeit.
- Halten Sie den projektbezogenen Ingest-Schlüssel aus der Versionsverwaltung heraus.
- Legen Sie stabile Werte für Dienst, Umgebung und Release fest.
- Senden Sie ein sicheres Testereignis aus der Anwendung.
- Lesen Sie das Ergebnis der Zustellung. Suchen Sie das Ereignis dann in LogBrew.
Signale und gemeinsamer Kontext
Die ersten fünf Karten sind Signale. Release und Umgebung sind Kontext für diese Signale. Sie sind kein eigener Ereignistyp.log
Eine strukturierte Nachricht mit Schweregrad, Quelle, Zeit und sicherem
Kontext.
trace_span
Eine zeitlich gemessene Operation, die über Trace- und Span-IDs mit ihrem
Trace verknüpft ist.
issue
Ein erfasster Fehler, sein Schweregrad und die Fehlerdetails, die die App
gesendet hat.
action
Eine Aktion in Ihrer App, optional mit Subjekt, Sitzung und sicheren
Eigenschaften.
metric
Ein numerischer Messwert mit Name, Art, Wert, Einheit und Temporalität.
release und environment
Die Codeversion und die Umgebung, die an spätere Ereignisse im selben
SDK-Bereich angehängt werden.
Werte für den Schweregrad
Verwenden Sie für Logs und Issuesinfo, warning, error oder critical.
SDKs und Laufzeiten können Aliasse wie trace, debug, warn oder fatal
senden. LogBrew normalisiert angenommene Aliasse auf die kanonischen Werte.
Installation per Paketmanager
Installieren Sie das SDK-Paket für die Laufzeit, die Telemetrie sendet. Verwenden Sie die projektbezogene SDK- oder Ingest-Konfiguration von LogBrew. Verwenden Sie keine Zugangsdaten Ihres Kontos als SDK-Konfiguration.Anfrage-Tracing in Node.js
Für die Trace-Korrelation mit der Anfrage als Root verwenden Sie@logbrew/sdk 0.1.16 oder neuer und @logbrew/node 0.1.11 oder neuer.
Express braucht @logbrew/express 0.1.5 oder neuer. Fastify und NestJS
brauchen ihr LogBrew-Paket in Version 0.1.6 oder neuer.
Diese Integrationen erstellen einen Anfrage-Span oder setzen ihn fort. Der
Name des Spans verwendet die passende Routenvorlage. Logs, Issues, Aktionen
und Metriken innerhalb der Anfrage erben ihren Trace- und Span-Kontext. Ein
neueres Paket fügt Ereignissen, die vor dem Update gesendet wurden, keinen
Kontext hinzu.
Die Standard-Integration für Anfragen erfasst keine Anfrage- oder
Antwort-Bodys, keine Query-Strings, keine beliebigen Header und keine rohen
traceparent-Werte.
ASP.NET Core
CLI v0.1.55 oder neuer erkennt .NET-10-Projekte, dieMicrosoft.NET.Sdk.Web
verwenden. Sehen Sie sich den Einrichtungsplan im Stammverzeichnis des
Projekts an. Dieser Befehl ändert Ihre Dateien nicht:
LOGBREW_SERVER_API_KEY, LOGBREW_SERVICE_NAME,
LOGBREW_ENVIRONMENT und LOGBREW_RELEASE außerhalb der Versionsverwaltung
fest. Registrieren Sie LogBrew beim Host, und setzen Sie die Middleware hinter
das Routing:
LOGBREW_SERVER_API_KEY tun beide Registrierungsaufrufe gefahrlos
nichts. Das
ASP.NET-Core-NuGet-Paket
bezeichnet die veröffentlichte Host-Integration. Sein öffentlicher
Paketleitfaden beschreibt Host-Lebenszyklus, Erfassung von Anfragen und
Issues, Datenschutzgrenzen und Wiederherstellung.
Java mit Maven oder Gradle
CLI v0.1.54 oder neuer erkenntpom.xml, build.gradle und
build.gradle.kts. Sehen Sie sich den Einrichtungsplan im Stammverzeichnis
des Projekts an. Dieser Befehl ändert Ihre Dateien nicht:
LogBrewClient-Bean
bereitstellen. Sie aktiviert optionale Integrationen für Anfragen, Ausnahmen,
HTTP-Clients, JDBC und Caches.
Die Erfassung für Spring Kafka müssen Sie ausdrücklich mit
logbrew.kafka.enabled=true einschalten. Sie nutzt die vorhandene
Spring-Kafka-Abhängigkeit und die Client-Bean der Anwendung.
Das
Java-SDK-Artefakt in Maven Central
bezeichnet das veröffentlichte Paket. Sein öffentlicher Leitfaden beschreibt
begrenzte HTTP-Zustellung, Herunterfahren, Logging, Spring-Konfiguration,
Kafka-Korrelation und Datenschutzgrenzen.
C++ mit CMake
Das C++-SDK braucht C++17 und CMake 3.16 oder neuer. CLI v0.1.39 oder neuer erkennt eineCMakeLists.txt im Stammverzeichnis. Führen Sie
logbrew setup --json aus, um diesen Einrichtungsplan anzusehen, ohne Ihre
Dateien zu ändern:
FetchContent_MakeAvailable und das Target-Linking oben durch:
logbrew-cpp-0.2.3.tar.gz aus dem
Release C++ 0.2.3.
Das entpackte Paket unterstützt cmake --install und
find_package(LogBrew 0.2.3 CONFIG REQUIRED). Sein Paketleitfaden beschreibt
typisierten Kontext, Issue-Belege, Span-Ereignisse, Metriken, Aktionen und
HTTP-Zustellung.
JavaScript-Source-Maps
Für Vite-Builds folgen Sie JavaScript-Source-Maps. Der Leitfaden beschreibt das Plugin, den Artefakt-Schlüssel, die Prüfungen beim Hochladen und ein neues Issue mit den ursprünglichen Stellen im Quellcode.Apple, Flask und React Native
Verwenden Sie für Telemetrie das Swift-ProduktLogBrew. Fügen Sie
LogBrewCrash nur hinzu, um Abstürze oder Hänger auf Apple-Geräten zu
erfassen. Für das Hochladen von dSYM-Dateien und die gehostete Symbolisierung
folgen Sie Apple-Abstürze und Hänger erfassen.
Für Flask folgen Sie Flask einrichten.
Für React Native und Expo folgen Sie React Native.
Der Leitfaden beschreibt den Projektschlüssel, ein sicheres Test-Log,
Zustellfehler und die Expo-Metro-Konfiguration für Source Maps in
Produktion.
Queue-Tracing in JavaScript
Queue-Integrationen für Node sind eigene npm-Pakete. Installieren Sie die LogBrew-Basispakete für JavaScript, das Integrationspaket und den Queue- oder Broker-Client, den Ihre App bereits nutzt.
Verwenden Sie diese Pakete für eine ausdrückliche Trace-Korrelation, die Ihre
App selbst steuert, rund um die Queue-Aufrufe, die Sie auswählen. LogBrew
übernimmt nicht Ihre Broker-Verbindung, erstellt keine Queues und patcht
standardmäßig nicht global jeden Client.
Nativer Umschlag direkt senden
Verwenden SiePOST /api/telemetry/ingest nur für einen eigenen Client, den
kein öffentliches LogBrew-SDK abdeckt. Öffentliche SDKs verwenden ihr eigenes
Batch-Format. Dieser Endpunkt akzeptiert dieses Format nicht.
Senden Sie 1 bis 512 Einträge in einem nativen Umschlag. Alle Einträge eines
Umschlags teilen sich Projekt, Dienst, Release, Umgebung und den optionalen
Trace-Kontext.
Felder eines Eintrags
Jeder Eintrag hat einentype und ein data-Objekt. Ein Log-Eintrag
verwendet level. Ein Issue-Eintrag verwendet severity. Beide akzeptieren
die Werte unter Werte für den Schweregrad.
Senden Sie zu jedem Eintrag eine
id, wenn Ihr Client Anfragen wiederholen
kann. Sendet eine Wiederholung einen angenommenen Eintrag mit derselben id
und demselben Inhalt erneut, speichert LogBrew ihn nicht noch einmal. Die
Antwort zählt diesen Eintrag in already_accepted.
Beispielanfrage
Speichern Sie das JSON unten alstelemetry-envelope.json. Ersetzen Sie die
Beispiel-Projekt-ID durch die genaue Projekt-ID Ihres Ingest-Schlüssels.
Setzen Sie die Zeitstempel auf die aktuelle UTC-Zeit des Testereignisses.
Verwenden Sie Ihre eigenen Werte für Dienst und Release.
telemetry-envelope.json
LOGBREW_INGEST_BEARER. Geben Sie ihn nicht aus, und verwenden Sie keine
Konto-Zugangsdaten. Der folgende Befehl sendet die Datei einmal. Er braucht
curl 7.76.0 oder neuer:
--fail-with-body behält einen Fehler-Body
und liefert bei HTTP-Fehlern einen Exit-Status ungleich null. Ein
Netzwerkfehler oder eine Zeitüberschreitung sagt Ihnen nicht, ob LogBrew die
Anfrage angenommen hat. Senden Sie dieselbe Datei nur dann erneut, wenn ihre
Einträge id-Werte haben. Ohne id-Werte kann ein zweites Senden die
Einträge doppelt speichern.
Antwort
Eine erfolgreiche Anfrage liefert200 mit der Anzahl der neuen Einträge pro
Datenstrom. already_accepted zählt Einträge, die eine frühere Anfrage
bereits zugestellt hat.
Fehler
Ein ungültiger oder widerrufener Ingest-Schlüssel liefert401. Ein Schlüssel
für ein anderes Projekt liefert ebenfalls 401:
422 mit dem Code
validation_failed. Das Feld error nennt die Regel. Das Feld next sagt
Ihnen, wie Sie die Anfrage korrigieren. Zum Beispiel liefert "items": []:
422 mit dem Fehler
native telemetry envelope exceeds the item limit. Teilen Sie ihn in Batches
mit höchstens 512 Einträgen auf. Behalten Sie in jedem Batch das Projekt und
den gemeinsamen Kontext bei.
Bei Nutzungslimits, Ratenlimits und Dienstausfällen folgen Sie dem
zurückgegebenen code unter API-Fehler.
