{"id":75019,"date":"2026-03-19T13:13:11","date_gmt":"2026-03-19T21:13:11","guid":{"rendered":"https:\/\/www.sumologic.com\/blog\/claude-code-fuehrt-bash-befehle-auf-ihrer-infrastruktur-aus-so-behalten-sie-es-im-blick"},"modified":"2026-06-24T08:32:03","modified_gmt":"2026-06-24T16:32:03","slug":"claude-code-bash-monitoring","status":"publish","type":"blog","link":"https:\/\/www.sumologic.com\/de\/blog\/claude-code-bash-monitoring","title":{"rendered":"Claude Code f\u00fchrt Bash-Befehle auf Ihrer Infrastruktur aus. So behalten Sie es im Blick."},"content":{"rendered":"\n
\n
\n
\n
\n
\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Ich beobachte Claude Code-Telemetrie<\/a> seit einigen Wochen und mir f\u00e4llt immer wieder dasselbe auf: Die meisten Teams integrieren es in ihre Umgebung, sagen \u201ees ist gro\u00dfartig\u201c und haben absolut keine Ahnung, was es auf Systemebene tats\u00e4chlich tut.<\/p>\n\n\n\n

F\u00fcr ein pers\u00f6nliches Entwicklungstool ist das in Ordnung. Das ist nicht in Ordnung, wenn Sie es bereits f\u00fcr 50 Engineers ausgerollt haben.<\/p>\n\n\n\n

Was Claude Code tats\u00e4chlich ausgibt<\/strong><\/h2>\n\n\n\n

Claude Code wird mit nativer OpenTelemetry<\/a>-Unterst\u00fctzung ausgeliefert. Zwei Umgebungsvariablen, und sie exportieren:<\/p>\n\n\n\nexport CLAUDE_CODE_ENABLE_TELEMETRY=1export OTEL_METRICS_EXPORTER=otlpexport OTEL_LOGS_EXPORTER=otlpexport OTEL_EXPORTER_OTLP_PROTOCOL=http\/protobufexport OTEL_EXPORTER_OTLP_ENDPOINT=https:\/\/collectors.sumologic.com\/receiver\/v1\/otlp\/<unique-id>export OTEL_EXPORTER_OTLP_HEADERS=\"Authorization=x-sumo-token your-token\"<\/code>\n\n\n\n

<\/p>\n\n\n\n

Die Endpunkt-URL erhalten Sie, indem Sie unter \u201eDaten verwalten\u201c, dann \u201eErfassung\u201c und anschlie\u00dfend \u201eHosted Collectors\u201c 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\u00fcnf.<\/p>\n\n\n\n

Die Metriken sind der langweilige Teil (aber Sie wollen sie trotzdem haben)<\/strong><\/h2>\n\n\n\n

Tokenverwendung nach Benutzer, nach Modell, nach Typ (Eingabe\/Ausgabe\/Cache). Kosten pro Sitzung in USD. Gestartete Sitzungen. Hinzugef\u00fcgte und entfernte Codezeilen. Commits erstellt. Pull Requests erstellt. Zeitaufwand f\u00fcr aktive Interaktion vs. Zeit, in der Claude verarbeitet.<\/p>\n\n\n\n

Dies ist Ihr ROI-Dashboard. Es beantwortet die Frage, die Ihr VP Engineering in drei Monaten stellen wird: \u201eWir bezahlen daf\u00fcr. Wird es tats\u00e4chlich von irgendjemandem benutzt?\u201c<\/p>\n\n\n\n

Segmentieren Sie nach user.account_uuid<\/code> und organization.id<\/code>. Erstellen Sie ein Sumo Logic-Dashboard. Weiter.<\/p>\n\n\n\n

Die Ereignisse sind der interessante Teil<\/strong><\/h2>\n\n\n\n

Darauf sollten Sie achten.<\/p>\n\n\n\n

Jedes Mal, wenn Claude ein Tool ausf\u00fchrt, erhalten Sie ein claude_code.tool_result<\/code>-Ereignis. Dieses Ereignis enth\u00e4lt den Namen des Tools, die Ausf\u00fchrungszeit, Erfolg oder Fehlschlag und f\u00fcr Bash: den vollst\u00e4ndigen bash_command<\/code>, der ausgef\u00fchrt wurde.<\/p>\n\n\n\n

Jeder betroffene Dateipfad. Jeder Git-Befehl. Jedes aufgerufene Skript. Protokolliert, strukturiert, durchsuchbar.<\/p>\n\n\n\n

Jedes Mal, wenn ein Benutzer eine Eingabeaufforderung absendet, erhalten Sie ein claude_code.user_prompt<\/code>-Ereignis \u2013 standardm\u00e4\u00dfig die L\u00e4nge der Eingabeaufforderung, den vollst\u00e4ndigen Inhalt, wenn Sie OTEL_LOG_USER_PROMPTS=1<\/code> aktivieren. Jeder API-Aufruf erh\u00e4lt ein eigenes claude_code.api_request<\/code>-Ereignis mit Modell, Kosten, Latenz und Tokenanzahl.<\/p>\n\n\n\n

Das, was das alles zusammenh\u00e4lt: prompt.id<\/code>. Jedem Ereignis wird eine UUID zugeordnet, die auf die urspr\u00fcngliche Eingabeaufforderung verweist, die das Ereignis ausgel\u00f6st hat. Mit einem einzigen Filter in der Sumo Logic Log Search l\u00e4sst sich die gesamte Ausf\u00fchrungskette rekonstruieren: die Benutzeranfrage, die API-Aufrufe, die ausgef\u00fchrten Tools \u2013 alles in chronologischer Reihenfolge.<\/p>\n\n\n\n

Das ist mehr als nur ein Protokoll, das ist ein Pr\u00fcfpfad.<\/strong><\/p>\n\n\n\n

Das Feld, das niemand beachtet<\/strong><\/h2>\n\n\n\n

decision_source<\/code>.<\/p>\n\n\n\n

Bei jeder Tool-Ausf\u00fchrung wird protokolliert, wie die Berechtigungsentscheidung getroffen wurde: config<\/code>, hook<\/code>, user_permanent<\/code>, user_temporary<\/code>, user_abort<\/code>, user_reject<\/code>.<\/p>\n\n\n\n

user_permanent<\/code> bedeutet, dass der Benutzer auf \u201eImmer zulassen\u201c geklickt hat. Einmal. F\u00fcr dieses Tool. F\u00fcr immer.<\/p>\n\n\n\n

Ziehen Sie dieses Feld in Sumo Logic heran und betrachten Sie die Verteilung. Wenn die meisten Ihrer Tool-Entscheidungen user_permanent<\/code> 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.<\/p>\n\n\n\n

Was Sie in Sumo Logic tats\u00e4chlich aufbauen sollten<\/strong><\/h2>\n\n\n\n

Hier sind drei Dashboards, die es wert sind, in Sumo Logic eingerichtet zu werden:<\/p>\n\n\n\n