Logging
Mayros loggt an zwei Stellen:
- Datei-Logs (JSON-Zeilen), die vom Gateway geschrieben werden.
- Konsolenausgabe, die in Terminals und der Control UI angezeigt wird.
Diese Seite erklärt, wo sich Logs befinden, wie man sie liest und wie man Log-Level und Formate konfiguriert.
Wo sich Logs befinden
Standardmäßig schreibt das Gateway eine rollierende Log-Datei unter:
/tmp/mayros/mayros-YYYY-MM-DD.log
Das Datum verwendet die lokale Zeitzone des Gateway-Hosts.
Sie können dies in ~/.mayros/mayros.json überschreiben:
json{ "logging": { "file": "/pfad/zu/mayros.log" } }
Wie man Logs liest
CLI: Live-Tail (empfohlen)
Verwenden Sie die CLI, um die Gateway-Log-Datei via RPC zu verfolgen:
bashmayros logs --follow
Ausgabemodi:
- TTY-Sessions: hübsch, farbig, strukturierte Log-Zeilen.
- Nicht-TTY-Sessions: einfacher Text.
--json: Zeilen-delimitiertes JSON (ein Log-Event pro Zeile).--plain: erzwingt einfachen Text in TTY-Sessions.--no-color: deaktiviert ANSI-Farben.
Im JSON-Modus gibt die CLI type-markierte Objekte aus:
meta: Stream-Metadaten (Datei, Cursor, Größe)log: geparster Log-Eintragnotice: Kürzungs-/Rotationshinweiseraw: ungeparste Log-Zeile
Wenn das Gateway nicht erreichbar ist, zeigt die CLI einen kurzen Hinweis zur Ausführung:
bashmayros doctor
Control UI (Web)
Der Logs-Tab der Control UI verfolgt dieselbe Datei mit logs.tail.
Siehe /web/control-ui zum Öffnen.
Nur-Channel-Logs
Um Channel-Aktivität zu filtern (WhatsApp/Telegram/etc), verwenden Sie:
bashmayros channels logs --channel whatsapp
Log-Formate
Datei-Logs (JSONL)
Jede Zeile in der Log-Datei ist ein JSON-Objekt. Die CLI und Control UI parsen diese Einträge, um strukturierte Ausgabe zu rendern (Zeit, Level, Subsystem, Nachricht).
Konsolenausgabe
Konsolen-Logs sind TTY-aware und für Lesbarkeit formatiert:
- Subsystem-Präfixe (z.B.
gateway/channels/whatsapp) - Level-Färbung (info/warn/error)
- Optionaler kompakter oder JSON-Modus
Die Konsolenformatierung wird durch logging.consoleStyle gesteuert.
Logging konfigurieren
Alle Logging-Konfigurationen befinden sich unter logging in ~/.mayros/mayros.json.
json{ "logging": { "level": "info", "file": "/tmp/mayros/mayros-YYYY-MM-DD.log", "consoleLevel": "info", "consoleStyle": "pretty", "redactSensitive": "tools", "redactPatterns": ["sk-.*"] } }
Log-Level
logging.level: Datei-Logs (JSONL) Level.logging.consoleLevel: Konsolen-Verbositätslevel.
--verbose beeinflusst nur die Konsolenausgabe; es ändert nicht die Datei-Log-Level.
Konsolen-Stile
logging.consoleStyle:
pretty: benutzerfreundlich, farbig, mit Zeitstempeln.compact: kompaktere Ausgabe (am besten für lange Sessions).json: JSON pro Zeile (für Log-Prozessoren).
Schwärzung
Tool-Zusammenfassungen können sensible Tokens schwärzen, bevor sie die Konsole erreichen:
logging.redactSensitive:off|tools(Standard:tools)logging.redactPatterns: Liste von Regex-Strings zum Überschreiben des Standardsatzes
Schwärzung betrifft nur Konsolenausgabe und ändert keine Datei-Logs.
Diagnostics + OpenTelemetry
Diagnostics sind strukturierte, maschinenlesbare Events für Modell-Runs und Nachrichten-Fluss-Telemetrie (Webhooks, Queuing, Session-State). Sie ersetzen nicht Logs; sie existieren, um Metriken, Traces und andere Exporters zu füttern.
Diagnostics-Events werden In-Process ausgegeben, aber Exporters hängen sich nur an, wenn Diagnostics + der Exporter-Plugin aktiviert sind.
OpenTelemetry vs OTLP
- OpenTelemetry (OTel): das Datenmodell + SDKs für Traces, Metriken und Logs.
- OTLP: das Wire-Protokoll zum Exportieren von OTel-Daten zu einem Collector/Backend.
- Mayros exportiert via OTLP/HTTP (protobuf) heute.
Exportierte Signale
- Metriken: Zähler + Histogramme (Token-Nutzung, Nachrichten-Fluss, Queuing).
- Traces: Spans für Modell-Nutzung + Webhook/Nachrichten-Verarbeitung.
- Logs: über OTLP exportiert, wenn
diagnostics.otel.logsaktiviert ist. Log-Volumen kann hoch sein; behalten Sielogging.levelund Exporter-Filter im Auge.
Diagnostic-Event-Katalog
Modell-Nutzung:
model.usage: Tokens, Kosten, Dauer, Kontext, Provider/Model/Channel, Session-IDs.
Nachrichten-Fluss:
webhook.received: Webhook-Ingress pro Channel.webhook.processed: Webhook behandelt + Dauer.webhook.error: Webhook-Handler-Fehler.message.queued: Nachricht zur Verarbeitung in Warteschlange.message.processed: Ergebnis + Dauer + optionaler Fehler.
Queue + Session:
queue.lane.enqueue: Command-Queue-Lane enqueue + Tiefe.queue.lane.dequeue: Command-Queue-Lane dequeue + Wartezeit.session.state: Session-State-Übergang + Grund.session.stuck: Session-Stuck-Warnung + Alter.run.attempt: Run-Retry/Versuchs-Metadaten.diagnostic.heartbeat: Aggregierte Zähler (Webhooks/Queue/Session).
Diagnostics aktivieren (kein Exporter)
Verwenden Sie dies, wenn Sie möchten, dass Diagnostics-Events für Plugins oder benutzerdefinierte Sinks verfügbar sind:
json{ "diagnostics": { "enabled": true } }
Diagnostics-Flags (gezielte Logs)
Verwenden Sie Flags, um zusätzliche, gezielte Debug-Logs zu aktivieren, ohne logging.level zu erhöhen.
Flags sind case-insensitive und unterstützen Wildcards (z.B. telegram.* oder *).
json{ "diagnostics": { "flags": ["telegram.http"] } }
Env-Override (einmalig):
MAYROS_DIAGNOSTICS=telegram.http,telegram.payload
Hinweise:
- Flag-Logs gehen in die Standard-Log-Datei (gleich wie
logging.file). - Ausgabe ist weiterhin geschwärzt gemäß
logging.redactSensitive. - Vollständiger Leitfaden: /diagnostics/flags.
Nach OpenTelemetry exportieren
Diagnostics können via diagnostics-otel-Plugin (OTLP/HTTP) exportiert werden. Dies
funktioniert mit jedem OpenTelemetry-Collector/Backend, das OTLP/HTTP akzeptiert.
json{ "plugins": { "allow": ["diagnostics-otel"], "entries": { "diagnostics-otel": { "enabled": true } } }, "diagnostics": { "enabled": true, "otel": { "enabled": true, "endpoint": "http://otel-collector:4318", "protocol": "http/protobuf", "serviceName": "mayros-gateway", "traces": true, "metrics": true, "logs": true, "sampleRate": 0.2, "flushIntervalMs": 60000 } } }
Hinweise:
- Sie können das Plugin auch mit
mayros plugins enable diagnostics-otelaktivieren. protocolunterstützt derzeit nurhttp/protobuf.grpcwird ignoriert.- Metriken umfassen Token-Nutzung, Kosten, Kontextgröße, Run-Dauer und Nachrichten-Fluss- Zähler/Histogramme (Webhooks, Queuing, Session-State, Queue-Tiefe/Wartezeit).
- Traces/Metriken können mit
traces/metricsumgeschaltet werden (Standard: on). Traces umfassen Modell-Nutzungs-Spans plus Webhook/Nachrichten-Verarbeitungs-Spans wenn aktiviert. - Setzen Sie
headers, wenn Ihr Collector Auth benötigt. - Umgebungsvariablen werden unterstützt:
OTEL_EXPORTER_OTLP_ENDPOINT,OTEL_SERVICE_NAME,OTEL_EXPORTER_OTLP_PROTOCOL.
Exportierte Metriken (Namen + Typen)
Modell-Nutzung:
mayros.tokens(Zähler, Attrs:mayros.token,mayros.channel,mayros.provider,mayros.model)mayros.cost.usd(Zähler, Attrs:mayros.channel,mayros.provider,mayros.model)mayros.run.duration_ms(Histogramm, Attrs:mayros.channel,mayros.provider,mayros.model)mayros.context.tokens(Histogramm, Attrs:mayros.context,mayros.channel,mayros.provider,mayros.model)
Nachrichten-Fluss:
mayros.webhook.received(Zähler, Attrs:mayros.channel,mayros.webhook)mayros.webhook.error(Zähler, Attrs:mayros.channel,mayros.webhook)mayros.webhook.duration_ms(Histogramm, Attrs:mayros.channel,mayros.webhook)mayros.message.queued(Zähler, Attrs:mayros.channel,mayros.source)mayros.message.processed(Zähler, Attrs:mayros.channel,mayros.outcome)mayros.message.duration_ms(Histogramm, Attrs:mayros.channel,mayros.outcome)
Queues + Sessions:
mayros.queue.lane.enqueue(Zähler, Attrs:mayros.lane)mayros.queue.lane.dequeue(Zähler, Attrs:mayros.lane)mayros.queue.depth(Histogramm, Attrs:mayros.laneodermayros.channel=heartbeat)mayros.queue.wait_ms(Histogramm, Attrs:mayros.lane)mayros.session.state(Zähler, Attrs:mayros.state,mayros.reason)mayros.session.stuck(Zähler, Attrs:mayros.state)mayros.session.stuck_age_ms(Histogramm, Attrs:mayros.state)mayros.run.attempt(Zähler, Attrs:mayros.attempt)
Exportierte Spans (Namen + Schlüssel-Attribute)
mayros.model.usagemayros.channel,mayros.provider,mayros.modelmayros.sessionKey,mayros.sessionIdmayros.tokens.*(input/output/cache_read/cache_write/total)
mayros.webhook.processedmayros.channel,mayros.webhook,mayros.chatId
mayros.webhook.errormayros.channel,mayros.webhook,mayros.chatId,mayros.error
mayros.message.processedmayros.channel,mayros.outcome,mayros.chatId,mayros.messageId,mayros.sessionKey,mayros.sessionId,mayros.reason
mayros.session.stuckmayros.state,mayros.ageMs,mayros.queueDepth,mayros.sessionKey,mayros.sessionId
Sampling + Flushing
- Trace-Sampling:
diagnostics.otel.sampleRate(0.0–1.0, nur Root-Spans). - Metrik-Export-Intervall:
diagnostics.otel.flushIntervalMs(min 1000ms).
Protokoll-Hinweise
- OTLP/HTTP-Endpoints können via
diagnostics.otel.endpointoderOTEL_EXPORTER_OTLP_ENDPOINTgesetzt werden. - Wenn der Endpoint bereits
/v1/tracesoder/v1/metricsenthält, wird er wie ist verwendet. - Wenn der Endpoint bereits
/v1/logsenthält, wird er wie ist für Logs verwendet. diagnostics.otel.logsaktiviert OTLP-Log-Export für die Haupt-Logger-Ausgabe.
Log-Export-Verhalten
- OTLP-Logs verwenden dieselben strukturierten Records, die in
logging.filegeschrieben werden. - Respektieren
logging.level(Datei-Log-Level). Konsolen-Schwärzung gilt nicht für OTLP-Logs. - High-Volume-Installationen sollten OTLP-Collector-Sampling/Filterung bevorzugen.
Troubleshooting-Tipps
- Gateway nicht erreichbar? Führen Sie zuerst
mayros doctoraus. - Logs leer? Prüfen Sie, dass das Gateway läuft und in den Dateipfad
in
logging.fileschreibt. - Mehr Details benötigt? Setzen Sie
logging.levelaufdebugodertraceund versuchen Sie es erneut.