LogBrew Docs

Wählen Sie zuerst App oder Framework, erstellen Sie das Projekt in Add Project und prüfen Sie das erste Signal, bevor Sie CLI- und Dashboard-Referenzen nutzen.

Plattform wählen

Beginnen Sie mit der passenden App oder dem passenden Framework. Verwenden Sie dieselbe Auswahl in Add Project.

Plattformen filtern
6 von 26 angezeigt

Node.js

Node.js-Service

Nutzen Sie das Node.js-Paket, wenn ein Backend-Service Logs, Request-Spans, Actions, Releases und Metrics sendet.

npm install @logbrew/sdk @logbrew/node
Node First-Signal-Pfad nutzen

Express

Express-Service

Nutzen Sie das Express-Paket, wenn ein Node-Service Requests über Express-Middleware verarbeitet.

npm install @logbrew/sdk @logbrew/express express
Add Project öffnen

Fastify

Fastify-Service

Nutzen Sie das Fastify-Paket, wenn ein Node-Service Routes über Fastify-Plugins verarbeitet.

npm install @logbrew/sdk @logbrew/fastify fastify
Add Project öffnen

NestJS

NestJS-Service

Nutzen Sie das NestJS-Paket, wenn ein Node-Service um Nest-Module und Request Handling aufgebaut ist.

npm install @logbrew/sdk @logbrew/nestjs @nestjs/common @nestjs/core @nestjs/platform-express reflect-metadata rxjs
Add Project öffnen

Python

Python-Service

Beginnen Sie mit dem Core-Paket für Python-Worker und Services.

python3 -m pip install logbrew-sdk
Add Project öffnen

Django

Django-App

Nutzen Sie das Django-Paket für Request- und App-Signale aus einem Django-Projekt.

python3 -m pip install logbrew-sdk logbrew-django
Add Project öffnen

Installationsbefehl

Erster erfolgreicher SDK-Lauf

Halten Sie die erste Sitzung knapp: Paket installieren, Projekt erstellen, eine nicht geheime Produktaktion senden und in LogBrew prüfen.

  1. 1SDK installierenNutzen Sie die Node-Pakete für einen Backend-Service mit Logs, Spans, Actions, Releases und Metriken.
    npm install @logbrew/sdk @logbrew/node
  2. 2Projekt erstellenÖffnen Sie Add Project, wählen Sie eine Plattform und kopieren Sie die einmalige Ingest-Berechtigung aus dem Setup-Panel.Add Project öffnen
  3. 3Eine Produktaktion sendenFühren Sie das Paketbeispiel aus, bevor Produktionscode angebunden wird, damit die erste Form bekannt und tokenfrei ist.
    node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs
  4. 4In LogBrew prüfenLesen Sie das erste Info-Signal in den Logs, bevor weitere Instrumentierung hinzukommt.
    logbrew logs info --json
KI-Assistentenkontext

Geben Sie einem Agenten die öffentliche LogBrew-Übersicht, bevor er Ihre App oder den Setup-Befehl bearbeitet.

curl -L https://logbrew.co/llms.txt
KI-Setup-PromptLies https://logbrew.co/llms.txt und wähle danach die passende SDK-Karte unter https://logbrew.co/en/docs#docs-sdk-choice-title. Verwende npm install @logbrew/sdk @logbrew/node nur für einen server-side Node.js Service; für Next.js, React, iOS, Android oder React Native nutze die gewählte Karte und den Add Project Prompt. Bitte den angemeldeten Nutzer, Add Project zu öffnen und Berechtigungen nur in der passenden App-Umgebung abzulegen. Für server-side Node.js heißt die Env-Variable LOGBREW_SERVER_API_KEY. Führe node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs nur für Node Services aus und prüfe danach mit logbrew logs info --json. Frage im Chat oder in Commits nicht nach Berechtigungen.
Agent-Leitfaden öffnen
Das erste Node-SDK-Event an LogBrew senden

Nutzen Sie diesen Node-Pfad, wenn Sie echte Projektdaten brauchen statt noch eines Setup-Artikels. Das Dashboard erstellt das Projekt und zeigt die einmalige Ingest-Berechtigung; die öffentlichen Docs halten Paket- und Prüfschritte sicher.

  1. JavaScript-SDK-Pakete hinzufügen

    Beginnen Sie mit dem Core-SDK und dem Node-Helfer, wenn ein Backend-Service Logs, Request-Spans, Actions, Releases und Metriken senden soll.

    npm install @logbrew/sdk @logbrew/node
  2. Projekt über Add Project erstellen

    Melden Sie sich an, öffnen Sie Add Project, wählen Sie eine Plattform und kopieren Sie die einmalige Ingest-Berechtigung aus diesem Setup-Panel. Nach dem Verlassen zeigt die Website sie nicht erneut.

    Add Project öffnen
  3. Beispiel für das erste SDK-Event ausführen

    Prüfen Sie mit dem installierten Paketbeispiel die Form von Release, Environment, Request-Span, Product Action, Network Milestone und Metrik, bevor Sie Ihre App verdrahten.

    node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs
  4. Erstes Signal in LogBrew lesen

    Nachdem das SDK ein info-Event mit der Projektberechtigung gesendet hat, bestätigen Sie es per CLI oder Dashboard-Logs, bevor Sie weitere Instrumentierung hinzufügen.

    logbrew logs info --json
Docs-Oberflächen3

docs.logbrew.co

Vollständige Docs-Website

Nutzen Sie die dedizierte Docs-Website für ausführliches Setup, API-Details und Beispiele, die die Produktseiten nicht überladen sollen.

Docs-Website öffnen

Klartext

Markdown-Docs-Spiegel

Nutzen Sie den lokalisierten Markdown-Spiegel, wenn ein Agent oder Terminal-Workflow dieselben Docs ohne browsergebundenen Zustand lesen soll.

Markdown öffnen

Klartext

Agent-Spiegel

Nutzen Sie llms.txt, Markdown-Spiegel, robots und sitemap, wenn ein Agent vorhersehbare öffentliche Lesepfade braucht.

llms.txt öffnen
Startpfad wählen3

Setup

Prüfen, ob LogBrew bereit ist

Zuerst status ausführen, um Erreichbarkeit, Anmeldestatus und den nächsten sicheren Read zu bestätigen.

logbrew status --json

Triage

Mit den neuesten Fehlern starten

Aktuelle error Logs lesen und dann zu Issues oder Traces wechseln, wenn Release oder Projekt Kontext brauchen.

logbrew logs error --json

Übergabe

Eine stabile Issue-Ansicht teilen

Offene Issues auflisten, wenn ein Teammitglied dieselben Fehlergruppen braucht.

logbrew issues open --json
Befehlsübersicht6

Befehlsübersicht

Status

Lokale Authentifizierung, API-Erreichbarkeit und Recovery-Schritte vor jedem privaten Read prüfen.

logbrew status --json

Befehlsübersicht

Logs

Mit aktuellen Fehlern starten, wenn ein Release, Projekt oder Trace Kontext braucht.

logbrew logs error --json

Befehlsübersicht

Issues

Offene Fehlergruppen auflisten, bevor resolve, close, ignore oder reopen entschieden wird.

logbrew issues open --json

Befehlsübersicht

Trace-Detail

Eine bekannte Trace-ID lesen, wenn Logs oder Issues auf einen fehlgeschlagenen Request zeigen.

logbrew trace <trace_id> --json

Befehlsübersicht

Actions

User-Events nach Name filtern, wenn der wichtige Kontext eine Produktaktion ist.

logbrew actions --name checkout_failed --json

Befehlsübersicht

Releases

Rollout-Kontext mit Log-, Issue-, Trace-Span- und Action-Zahlen vergleichen.

logbrew releases --json
LogBrew Docs4

CLI zuerst

Lokale Authentifizierung und API-Erreichbarkeit prüfen

Der erste Read sollte zeigen, ob die CLI die LogBrew API erreicht, ohne Token-Material offenzulegen.

  • JSON-Modus nutzen, wenn ein Script oder eine Automatisierung stabile Felder braucht.
  • Menschliche Ausgabe nutzen, wenn eine Entwicklerin oder ein Entwickler den nächsten Befehl braucht.
  • Auth-Recovery immer zurück zu Login und Status führen.

Beobachten

Produktionssignale nach Ressource lesen

Logs, Issues, Actions, Traces, Releases und Projekte sollten getrennt genug für schnelles Scannen und verbunden genug für Kontext-Recovery bleiben.

  • Logs behalten Schweregrad-, Release-, Umgebungs-, Projekt-, Trace- und Suchfilter.
  • Issues behalten Status, Trace-Kontext und Mutationsvokabular.
  • Traces behalten Span-Namen, Release-Kontext, Umgebungskontext und Projektumfang.

Teilen

Nützlichen Kontext senden, ohne Projektdaten offenzulegen

Nutzen Sie öffentliche Docs, Markdown und kopierbare Befehle, wenn jemand Setup-Hilfe oder eine sichere Übergabe braucht.

  • Einen Docs-Link teilen, wenn der nächste Schritt Setup oder Befehlsfindung ist.
  • Markdown teilen, wenn Klartext besser als ein Screenshot ist.
  • Dashboard-Projektdaten hinter Anmeldung und Backend-Auth halten.

API-Karte

Dashboard an Backend-Routen ausrichten

Der Web-Arbeitsbereich sollte dokumentierten LogBrew API-Verträgen folgen, ohne Dashboard-only-Speicher oder alternative Verträge zu erfinden.

  • Logs werden über /api/logs mit Schweregrad-, Release-, Umgebungs-, Projekt-, Trace- und Suchfiltern gelesen.
  • Issues werden über /api/telemetry/issues und /api/telemetry/issues/{issue_id} gelesen und geändert.
  • Actions, Releases und Trace-Details werden über /api/telemetry/actions, /api/telemetry/releases und /api/telemetry/traces/{trace_id} gelesen.
  • Projekte und Auth-Status kommen aus /api/projects, /api/auth und CLI-Statusbefehlen.