Claude Code führt Bash-Befehle auf Ihrer Infrastruktur aus. So behalten Sie es im Blick.

Ich beobachte Claude Code-Telemetrie seit einigen Wochen und mir fällt immer wieder dasselbe auf: Die meisten Teams integrieren es in ihre Umgebung, sagen „es ist großartig“ und haben absolut keine Ahnung, was es auf Systemebene tatsächlich tut.

Für ein persönliches Entwicklungstool ist das in Ordnung. Das ist nicht in Ordnung, wenn Sie es bereits für 50 Engineers ausgerollt haben.

Was Claude Code tatsächlich ausgibt

Claude Code wird mit nativer OpenTelemetry-Unterstützung ausgeliefert. Zwei Umgebungsvariablen, und sie exportieren:

Die Endpunkt-URL erhalten Sie, indem Sie unter „Daten verwalten“, dann „Erfassung“ und anschließend „Hosted Collectors“ in Sumo Logic eine OTLP/HTTP-Quelle erstellen. Sobald die Quelle erstellt ist, erhalten Sie eine eindeutige Ingest-URL. Setzen Sie Ihre Umgebungsvariablen auf diese URL, und fertig. Kein Collector erforderlich. Kein SDK. Kein Wrapper. Was dann ins Rollen kommt: Metriken alle 60 Sekunden, Ereignisse alle fünf.

Die Metriken sind der langweilige Teil (aber Sie wollen sie trotzdem haben)

Tokenverwendung nach Benutzer, nach Modell, nach Typ (Eingabe/Ausgabe/Cache). Kosten pro Sitzung in USD. Gestartete Sitzungen. Hinzugefügte und entfernte Codezeilen. Commits erstellt. Pull Requests erstellt. Zeitaufwand für aktive Interaktion vs. Zeit, in der Claude verarbeitet.

Dies ist Ihr ROI-Dashboard. Es beantwortet die Frage, die Ihr VP Engineering in drei Monaten stellen wird: „Wir bezahlen dafür. Wird es tatsächlich von irgendjemandem benutzt?“

Segmentieren Sie nach user.account_uuid und organization.id. Erstellen Sie ein Sumo Logic-Dashboard. Weiter.

Die Ereignisse sind der interessante Teil

Darauf sollten Sie achten.

Jedes Mal, wenn Claude ein Tool ausführt, erhalten Sie ein claude_code.tool_result-Ereignis. Dieses Ereignis enthält den Namen des Tools, die Ausführungszeit, Erfolg oder Fehlschlag und für Bash: den vollständigen bash_command, der ausgeführt wurde.

Jeder betroffene Dateipfad. Jeder Git-Befehl. Jedes aufgerufene Skript. Protokolliert, strukturiert, durchsuchbar.

Jedes Mal, wenn ein Benutzer eine Eingabeaufforderung absendet, erhalten Sie ein claude_code.user_prompt-Ereignis – standardmäßig die Länge der Eingabeaufforderung, den vollständigen Inhalt, wenn Sie OTEL_LOG_USER_PROMPTS=1 aktivieren. Jeder API-Aufruf erhält ein eigenes claude_code.api_request-Ereignis mit Modell, Kosten, Latenz und Tokenanzahl.

Das, was das alles zusammenhält: prompt.id. Jedem Ereignis wird eine UUID zugeordnet, die auf die ursprüngliche Eingabeaufforderung verweist, die das Ereignis ausgelöst hat. Mit einem einzigen Filter in der Sumo Logic Log Search lässt sich die gesamte Ausführungskette rekonstruieren: die Benutzeranfrage, die API-Aufrufe, die ausgeführten Tools – alles in chronologischer Reihenfolge.

Das ist mehr als nur ein Protokoll, das ist ein Prüfpfad.

Das Feld, das niemand beachtet

decision_source.

Bei jeder Tool-Ausführung wird protokolliert, wie die Berechtigungsentscheidung getroffen wurde: config, hook, user_permanent, user_temporary, user_abort, user_reject.

user_permanent bedeutet, dass der Benutzer auf „Immer zulassen“ geklickt hat. Einmal. Für dieses Tool. Für immer.

Ziehen Sie dieses Feld in Sumo Logic heran und betrachten Sie die Verteilung. Wenn die meisten Ihrer Tool-Entscheidungen user_permanent sind, haben Ihre Entwickler Claude im Grunde vorab autorisiert, mit allen Tools, die es verwendet, zu tun, was es will. Sie haben das einmal vor Monaten getan und es dann vergessen. Das ist keine Sicherheitskrise. Aber es ist etwas, das Sie wissen sollten, und im Moment wissen Sie es wahrscheinlich nicht.

Was Sie in Sumo Logic tatsächlich aufbauen sollten

Hier sind drei Dashboards, die es wert sind, in Sumo Logic eingerichtet zu werden:

• Nutzung und Kosten: Tokenverbrauch pro Benutzer und Modell im Zeitverlauf. Kosten pro Sitzung. Aktive Zeit vs. Leerlaufzeit. Das ist das, wonach Ihr Finanzteam früher oder später fragen wird.
• Tool-Ausführung: Welche Tools werden ausgeführt, wie oft, Erfolgsquote und durchschnittliche Dauer. Filtern Sie nach dem Bash-Tool und sehen Sie sich die Befehlsmuster an. Sie werden erfahren, wie Ihre Entwickler das Tool tatsächlich nutzen – im Vergleich dazu, wie Sie dachten, dass sie es nutzen.
• Sitzungsrekonstruktion: Eine gespeicherte Suche, gefiltert nach prompt.id mit Feldern für event.name, event.timestamp, tool_name, bash_command, cost_usd. Falls etwas schiefgeht und eine falsche Datei gelöscht wird, ein unerwarteter API-Aufruf erfolgt oder ein mysteriöser Commit durchgeführt wird, finden Sie so heraus, was passiert ist.

Eine Sache, die Sie klären sollten, bevor Sie breit ausrollen

Das tool_parameters-Feld kann Geheimnisse enthalten. Wenn Entwickler Bash-Befehle ausführen, die Tokens, Passwörter oder API-Schlüssel direkt im Befehl enthalten, landen diese Werte in Ihren Protokollen.

Konfigurieren Sie eine Sumo Logic-Feldextraktionsregel, um tool_parameters vor der Erfassung zu maskieren oder zu verwerfen, falls dies für Ihre Umgebung ein Problem darstellt. Warten Sie nicht, bis Sie es an 50 Personen verschickt haben.

Abschließende Gedanken

Claude Code ist nützlich. Das ist unbestritten. Nützlich und beobachtbar sind aber nicht dasselbe. Und in einer Entwicklungsorganisation führen unbeobachtbare Tools häufig dazu, dass Überraschungen genau dann auftreten, wenn es am ungünstigsten ist.

Integrieren Sie es. Sie werden es wahrscheinlich nicht bereuen, es zu wissen.

Überzeugen Sie sich selbst mit unserer 30-tägigen Gratis-Testversion.