Skip to main content
Legen Sie ein Entwicklungsprojekt an. Senden Sie ein Node.js-Log. Lesen Sie es in LogBrew wieder aus. Die CLI legt das Projekt an und speichert seinen Ingest-Schlüssel. Eine Anmeldung im Browser ist nur nötig, wenn die CLI keinen gültigen Kontozugriff hat.
Verwenden Sie --json für Agenten-Workflows. Bewahren Sie Zugangsdaten in einer geschützten lokalen Konfiguration auf. Geben Sie zwischen Personen, Tools und Agenten nur Variablennamen weiter.

Voraussetzungen

Halten Sie Folgendes bereit:
  • Node.js 18 oder neuer.
  • LogBrew-CLI v0.1.30 oder neuer.
  • jq.
  • Bash oder Zsh.
  • Ein Paketverzeichnis für eine serverseitige Node.js-App.
Das Beispiel verwendet das Projekt quickstart-node, die Umgebung development und das Release quickstart@1. Halten Sie diesen Test von der Produktion getrennt. Für eine andere Laufzeit verwenden Sie den Leitfaden zur SDK-Integration.
Bewahren Sie die Datei mit dem Ingest-Schlüssel außerhalb des Repositorys auf, sodass nur Sie sie lesen können. Schreiben Sie diesen Server-Schlüssel nicht in Browser-Code, ein öffentliches Bundle oder einen Prompt.

Erstes Log senden und lesen

1

Kontostatus lesen

Installieren Sie die CLI mit dem Befehl aus dem CLI-Leitfaden. Lesen Sie dann ihren Kontostatus.
Kontrollpunkt: Der Status meldet einen authentifizierten Kontozugriff. Wenn nicht, führt ein Mensch einmal logbrew login aus. Führen Sie dann logbrew status --json erneut aus. Ein Agent darf keine neue Anmeldung starten, wenn die aktuelle Authentifizierung funktioniert.
2

Ein Projekt mit der CLI anlegen

Wählen Sie eine neue Datei in einem Verzeichnis, auf das nur der Eigentümer zugreifen kann. Die CLI schreibt den Ingest-Schlüssel des Projekts in diese Datei, bevor sie Erfolg meldet. Sie gibt weder den Schlüssel noch den Dateipfad aus.
Das Anlegen eines Projekts ändert den Kontozustand. Die Zieldatei darf noch nicht existieren. Ist das Ergebnis unklar, führen Sie genau denselben Befehl erneut aus. Die CLI verwendet die Identität ihrer ausstehenden Anfrage erneut. Verwenden Sie --abandon-retry nur, um einen anderen Versuch zu starten.Kontrollpunkt: Die Ausgabe meldet status: "created", den Einrichtungsstatus created und eine Art des Ingest-Schlüssels. Das Projekt existiert, und der Schlüssel ist gespeichert. Das zeigt noch keine Zustellung von Telemetrie. Siehe Projekte.
3

Node.js-SDK installieren

Verwenden Sie nie Konto-Zugangsdaten als SDK-Konfiguration. Halten Sie den Projektschlüssel aus Befehlsausgaben, Prompts, Tickets, Quelldateien und der Paketkonfiguration heraus.
4

Ein sicheres SDK-Log senden

Senden Sie Release- und Umgebungsmarker mit einem info-Log, das nur Platzhalter enthält. Der Schlüssel gilt nur für diesen Node.js-Prozess. Die Identität der Anwendung steht in context.Jeder Lauf erzeugt neue Ereignis-IDs. Wiederholt das SDK die Zustellung im selben Lauf, sendet es denselben Body mit denselben IDs. LogBrew speichert ein angenommenes Ereignis kein zweites Mal, wenn eine Wiederholung es erneut sendet.
Schreiben Sie keine Zugangsdaten, Header, Anfrageinhalte, Kundendaten oder lokalen Pfade in das Ereignis.Kontrollpunkt: Das Skript gibt "ok":true mit einem 2xx als status_code aus. Nach einer Wiederholung ist attempts größer als 1. Ein erfolgreiches Senden ist nicht die letzte Prüfung.Schlägt die Zustellung fehl, beendet sich das Skript mit dem Code 1 und gibt einen kurzen JSON-Fehler aus, zum Beispiel {"ok":false,"error":"unauthenticated"}. Es gibt weder den Body der Anfrage noch den Schlüssel aus. Ein abgelehnter Projektschlüssel führt zu unauthenticated. Eine neue Anmeldung in der CLI behebt das nicht.
5

Doctor-Bericht des Projekts lesen

Die CLI verwendet für diese Abfrage ihren gespeicherten Kontozugriff. Verwenden Sie nicht den Ingest-Schlüssel des Projekts.
Kontrollpunkt: Der Bericht hat status: "ready". Lesen Sie auch jeden Eintrag in checks. Der Exit-Code 0 zeigt nicht, dass alle Prüfungen bestanden sind. Bei einem anderen Status folgen Sie next und der Referenz zum Doctor-Bericht. Ein Projekt mit ready zeigt nicht, dass dieses Test-Log angekommen ist.
6

Test-Log lesen

Verwenden Sie Projekt, Release und Umgebung aus dem SDK-Batch.
Kontrollpunkt: LogBrew quickstart check erscheint für dieses Projekt, Release und diese Umgebung. Das zeigt nur die Zustellung des Test-Logs.

Testergebnis lesen

Das Beispiel sendet drei Ereignisse. Nur eines davon ist ein Log. Die Marker für Release und Umgebung geben dem Log Kontext. Lassen Sie den Test auf info. Ändern Sie ihn nicht auf error, nur damit Sie ihn leichter finden. Verwenden Sie stattdessen die Filter für Projekt und Zeit. Siehe Werte für den Schweregrad. Die Zeile console.log gibt das Ergebnis der Zustellung im Terminal aus. Der Aufruf client.log sendet das Log an LogBrew. Eine erfolgreiche erste Zustellung gibt Folgendes aus:
Der Ingest-Schlüssel bestimmt das Projekt, das das Log erhält. Ein --project-Filter in der CLI verschiebt keine Ereignisse. Dieses Log hat keinen Trace-Kontext, weil das Beispiel keinen Anfrage-Span erstellt. Das zeigt nicht, dass das Log fehlgeschlagen ist. Die Abfrage in der CLI ist eine Momentaufnahme. Führen Sie sie erneut aus, um spätere Ereignisse zu lesen, oder verwenden Sie logbrew watch logs --json für einen Live-Datenstrom.

Häufige Entscheidungen zur Wiederherstellung

Fehlt die Telemetrie weiterhin, verwenden Sie die Prüfungen für die erste Telemetrie. Helfen diese Prüfungen nicht, nutzen Sie Problem melden. Hängen Sie keine Zugangsdaten, rohe Telemetrie, Kundendaten, lokalen Pfade oder Quellcode an.

In Ihre Anwendung übernehmen

  • Erstellen Sie den Client einmal im Einrichtungscode Ihrer App.
  • Pinnen Sie die SDK-Versionen in Ihren Paketdateien. Testen Sie Updates außerhalb der Produktion.
  • Laden Sie den Ingest-Schlüssel aus Ihrer vorhandenen Secret-Konfiguration. Rotieren Sie ihn, wenn er offengelegt worden sein könnte. Siehe Ingest-Schlüssel rotieren.
  • Verwenden Sie stabile Namen für Dienst, Umgebung und Release aus Ihrer Bereitstellungskonfiguration. Siehe Releases.
  • Schreiben Sie Log-Nachrichten, die die Operation und ihr Ergebnis nennen, zum Beispiel Report generation completed. Halten Sie private Werte aus der Nachricht heraus. Kopieren Sie keine ganze Anfrage und keinen ganzen Nutzerdatensatz in ein Log.
  • Lassen Sie jedes Anwendungs-Log von nur einem Sender schicken, um doppelte Einträge zu vermeiden. Suchen Sie die Integration, die jeden Eintrag bereits sendet, bevor Sie LogBrew hinzufügen.
  • Senden Sie vor einem Rollout in Produktion ein sicheres Ereignis über den echten Codepfad, und lesen Sie es wieder aus. Prüfen Sie Nachricht, Dienst, Release und Umgebung. Ein eigenständiges Beispiel testet nicht den Codepfad Ihrer Anwendung.
Dieses Beispiel richtet keine Erfassung im Browser, keine Source Maps und keine mobile Erfassung ein. Dafür beginnen Sie mit dem Leitfaden zur SDK-Integration.

Projekte

Lesen Sie den Einrichtungsstatus, und verwalten Sie die Ingest-Schlüssel des Projekts.

SDK-Signalaufnahme

Wählen Sie das SDK-Paket für Ihre Laufzeit.

Issue untersuchen

Folgen Sie den Belegen aus Trace und zugehörigen Logs für ein Issue.

Problem melden

Senden Sie eine sichere, private Meldung an den Support.