LLM Observability für Claude: EU-Stacks im Vergleich

TL;DR

LLM Observability für Claude braucht in der EU drei Ebenen: Cloud-Metriken für Latenz, Tokens und Fehler, ein Request-Log unter Ihrer Kontrolle und Traces mit Evals für die Qualität. Auf Bedrock ist Invocation Logging standardmäßig aus, und CloudWatch hält Logs unbegrenzt, bis Sie eine Aufbewahrung setzen. Vertex schreibt Claude-Logs als Preview nach BigQuery.

Was sollten Sie beim Claude-Betrieb überhaupt messen?

LLM Observability beantwortet pro Anfrage fünf Fragen: Wie lange hat sie gedauert, wie viele Tokens hat sie verbraucht, was hat sie gekostet, ist sie fehlgeschlagen, und war die Antwort brauchbar? Die ersten vier liefert Ihre Cloud fast umsonst. Qualität braucht Traces, Scores und menschliche Prüfung. Prompts mit personenbezogenen Daten machen jedes Log zum DSGVO-Thema.

Wir trennen die Signale so:

Signal	Quelle	Personenbezogene Daten?
Latenz, Zeit bis zum ersten Token	Cloud-Metriken (InvocationLatency, TimeToFirstToken auf Bedrock)	Nein
Input-, Output- und Cache-Tokens	Cloud-Metriken und Invocation Logs	Nein
Kosten pro Team oder Anwendung	Tokenzahl mal Preis, gruppiert nach Aufrufer	Nein
Fehler und Drosselung	Cloud-Metriken, Fehlercodes im Client	Selten
Prompt- und Antworttext	Invocation Logs, Traces	Oft
Qualitätsscores, Evals	Langfuse oder ein vergleichbares Trace-Tool	Je nachdem, was Sie bewerten

Für den Datenschutz ist diese Trennung der Kern. Metriken sind Aggregate ohne Inhalt. Sie dürfen länger liegen und breit lesbar sein. Prompt-Logs sind Inhalt. Behandeln Sie sie wie eine Kundendatenbank: kurze Aufbewahrung, wenige Leser, ein dokumentierter Zweck im Verzeichnis der Verarbeitungstätigkeiten. Wer den Zweck nicht benennen kann, schaltet Text-Logging nicht ein.

Claude Code ist eine eigene Quelle mit eigener Telemetrie. Die Claude-Code-Doku zum Monitoring verlangt CLAUDE_CODE_ENABLE_TELEMETRY=1 und exportiert Metriken wie claude_code.token.usage und claude_code.cost.usage alle 60 Sekunden, Logs alle 5 Sekunden. Prompt-Text wird nur mit OTEL_LOG_USER_PROMPTS=1 geloggt. Diesen Standard lassen wir so. Die Bedrock-Seite dazu beschreibt unsere Anleitung Claude Code auf Bedrock einrichten.

Wie schlagen sich Bedrock Invocation Logging und CloudWatch gegen die Alternativen?

Bedrock liefert Metriken automatisch und ein vollständiges Request-Log auf Wunsch. Vertex liefert ein Dashboard und ein Preview-Log nach BigQuery. OpenTelemetry liefert portable Traces, die Sie überallhin schicken. Langfuse setzt Evals obendrauf. Für ein deutsches Unternehmen zählen drei Spalten: wo der Text landet, wie lange er bleibt und wer ihn demaskieren kann.

Option	Wo die Daten liegen	EU-Standort	Standard-Aufbewahrung	Maskierung	Kostenmodell	Evals
Bedrock Invocation Logging + CloudWatch Logs	Ihre Log-Gruppe oder Ihr S3-Bucket, gleicher Account und gleiche Region wie der Aufruf	Jede EU-Region, aus der Sie Bedrock aufrufen, etwa Frankfurt	Unbegrenzt, bis Sie 1 bis 3653 Tage setzen	CloudWatch Data Protection bei der Aufnahme	0,50 USD/GB Ingestion, 0,12 USD/GB Maskierung (Liste US East)	Keine
Vertex Request-Response-Logging	Ihre BigQuery-Tabelle	Multi-Region EU oder eine EU-Einzelregion	Tabelle läuft ohne Expiration nie ab	Keine im Logging-Feature	BigQuery-Speicher; Sampling 0 bis 1	Keine
Cloud Logging (Audit- und App-Logs)	Log-Bucket im Projekt	Bucket-Standort nach Wahl	30 Tage, einstellbar 1 bis 3650	In der Anwendung schwärzen	0,50 USD/GiB, 50 GiB frei pro Projekt	Keine
OpenTelemetry + eigenes Backend	Wohin Ihr Collector exportiert	Ihre Entscheidung	Ihre Entscheidung	Inhaltsattribute sind Opt-In	Eigene Infrastruktur	Je nach Backend
Langfuse (EU-Cloud oder selbst gehostet)	Langfuse EU-Cloud in Irland oder Ihr Cluster	AWS eu-west-1 oder Ihre VPC	30 Tage Hobby, 90 Core, 3 Jahre Pro	Maskierungsfunktion im SDK, clientseitig	Gratis-Stufe, 29 USD, 199 USD; 8 USD pro 100k Units	LLM-as-a-Judge, Datasets, Annotation Queues

Die Preise sind Listenpreise von der CloudWatch-Preisseite, die US East (N. Virginia) zeigt und regionale Abweichungen ankündigt, von der Preisseite von Google Cloud Observability und von der Langfuse-Preisseite. Prüfen Sie den Preis in Ihrer EU-Region, bevor Sie budgetieren.

Unsere Empfehlung: Beginnen Sie mit der nativen Ebene der Cloud, über die Sie Claude ohnehin beziehen. Sie liegt im bestehenden AVV mit AWS oder Google, braucht keinen neuen Unterauftragsverarbeiter und kennt die Tokenzahlen bereits. Ergänzen Sie OpenTelemetry für Traces der Anwendung. Langfuse kommt erst dazu, wenn jemand tatsächlich Evals betreibt. Teams, die mit einem Trace-Tool und ohne Cloud-Metriken starten, übersehen Drosselung. Die sieht nur die Cloud.

Wie aktivieren Sie Bedrock Invocation Logging per AWS CLI?

Model Invocation Logging ist standardmäßig deaktiviert und gilt pro Region. Eingeschaltet erfasst es vollständige Anfrage, Antwort und Metadaten für Converse, ConverseStream, InvokeModel und InvokeModelWithResponseStream am Endpunkt bedrock-runtime. Ziele müssen im selben Account und in derselben Region liegen. Setzen Sie zuerst die Aufbewahrung, denn CloudWatch hält Logs sonst unbegrenzt.

Der Leitfaden zum Invocation Logging nennt die Voraussetzungen: eine Log-Gruppe, eine IAM-Rolle, die bedrock.amazonaws.com übernehmen darf, mit logs:CreateLogStream und logs:PutLogEvents, und optional einen S3-Bucket für Bodies über 100 KB.

1. Legen Sie die Log-Gruppe in der Region an, aus der Sie Bedrock aufrufen, zum Beispiel im Rechenzentrum Frankfurt (eu-central-1).
2. Setzen Sie die Aufbewahrung. Die Referenz zu put-retention-policy erlaubt feste Werte von 1 bis 3653 Tagen. Für Prompt-Text nehmen wir 30.
3. Erstellen Sie die IAM-Rolle mit der Trust Policy aus dem AWS-Leitfaden, beschränkt auf Ihren Account und Ihre Region.
4. Aktivieren Sie das Logging mit Text an und allen nicht benötigten Modalitäten aus.
5. Lesen Sie die Konfiguration zurück und schicken Sie eine Testanfrage.

aws logs create-log-group --log-group-name /bedrock/invocations --region eu-central-1
aws logs put-retention-policy --log-group-name /bedrock/invocations --retention-in-days 30 --region eu-central-1
aws bedrock put-model-invocation-logging-configuration --region eu-central-1 --logging-config '{"cloudWatchConfig":{"logGroupName":"/bedrock/invocations","roleArn":"arn:aws:iam::123456789012:role/BedrockInvocationLogging","largeDataDeliveryS3Config":{"bucketName":"example-bedrock-logs-eu","keyPrefix":"large"}},"textDataDeliveryEnabled":true,"imageDataDeliveryEnabled":false,"embeddingDataDeliveryEnabled":false,"videoDataDeliveryEnabled":false}'
aws bedrock get-model-invocation-logging-configuration --region eu-central-1

Jeder Eintrag enthält identity.arn, modelId, inputTokenCount, outputTokenCount und optional ein requestMetadata-Objekt, das Sie pro Aufruf mitgeben. Damit bekommen Sie Kosten pro Team ohne weiteres Tool: in Logs Insights nach identity.arn gruppieren. Das Logging erzeugt außerdem eigene Zustellmetriken wie ModelInvocationLogsCloudWatchDeliveryFailure. Setzen Sie darauf einen Alarm, sonst fällt eine kaputte IAM-Rolle erst im Audit auf.

Zwei Fallen. Erstens: Aufrufe über bedrock-mantle werden nicht erfasst. Wer Sonnet 5 als Single-Region über Mantle nutzt, hat Metriken und CloudTrail, aber kein Invocation Log. Zweitens gilt die Konfiguration pro Region. Mit dem EU-Geo-Profil rufen Sie aus einer Quellregion auf; konfigurieren Sie jede Quellregion, die Ihre Anwendungen nutzen. Welche Modell-IDs dahinterstehen, erklärt unser Leitfaden zu Claude auf AWS Bedrock in Frankfurt.

Für personenbezogene Daten hängen Sie vor dem Einschalten eine Data Protection Policy für CloudWatch Logs an die Log-Gruppe. Sie maskiert Treffer bei der Aufnahme. Ereignisse von vor der Policy bleiben unmaskiert. Klartext sehen nur Principals mit logs:Unmask. Das ist eine Zugriffskontrolle, die Sie im AVV-Kontext dokumentieren können.

Was bietet Google Cloud für Claude auf Vertex AI?

Google liefert ein fertiges Observability-Dashboard für verwaltete Modelle, Partnermodelle eingeschlossen, und Request-Response-Logging nach BigQuery. Das Logging ist Preview, unterstützt Claude über rawPredict und streamRawPredict und lässt sich für Anthropic-Modelle nur über die REST-API konfigurieren. Die Sampling-Rate wählen Sie zwischen 0 und 1.

Die Seite zum Request-Response-Logging nutzt setPublisherModelConfig mit publisher gleich anthropic. Im Body stehen enabled, samplingRate, eine BigQuery-outputUri und optional enableOtelLogging, das eine Spalte otel_log im OpenTelemetry-Format ergänzt. Paare über dem Zeilenlimit von 10 MB in BigQuery werden nicht gespeichert. Ein langes Agenten-Transkript fällt so still aus dem Log.

Der Standort ist Ihre Aufgabe. Legen Sie das Dataset in der Multi-Region EU oder einer EU-Einzelregion an, bevor die Konfiguration darauf zeigt. BigQuery dokumentiert, dass Daten der Multi-Region EU in europe-west1 (Belgien) oder europe-west4 (Niederlande) liegen. Wer Frankfurt will, wählt europe-west3 als Einzelregion. Tabellen laufen ohne Expiration nie ab, also setzen Sie eine auf dem Dataset. Die EU-Endpunkte für Claude selbst stehen in unserem Leitfaden zu Claude auf Vertex AI in Europa.

Eine Einstellung braucht eine Richtlinie. Für Claude Mythos Preview, Claude Mythos 5 und Claude Fable 5 auf Google Cloud kann Vertex protokollierte Anfragen und Antworten in Echtzeit mit Anthropic teilen, sobald dataSharingEnabledProvider auf ANTHROPIC steht, unter dem Advanced AI Safety Addendum. Das ist eine Übermittlung an einen zweiten Empfänger. Wer das nicht will, sperrt das Feld mit einer Custom Constraint der Organisationsrichtlinie. VPC Service Controls blockieren das Teilen standardmäßig.

Cloud Logging ist der Ort für Audit-Logs und eigene Anwendungslogs, nicht für Modell-Payloads. Log-Buckets halten standardmäßig 30 Tage und akzeptieren 1 bis 3650. Die Aufnahme kostet 0,50 USD pro GiB inklusive 30 Tagen, 50 GiB pro Projekt und Monat sind frei.

Wo passen OpenTelemetry und Langfuse hinein?

OpenTelemetry ist der herstellerneutrale Weg, die eigene Anwendung zu tracen: ein Span pro Claude-Aufruf, verknüpft mit der HTTP-Anfrage und den Tool-Calls drumherum. Die GenAI Semantic Conventions definieren Namen für Modell, Anbieter und Tokenverbrauch. Langfuse verarbeitet diese Traces und ergänzt, was den Clouds fehlt: Datasets, LLM-as-a-Judge und menschliche Annotation.

Die GenAI Semantic Conventions liegen inzwischen in einem eigenen Repository und tragen weiter den Status Development. Rechnen Sie mit Umbenennungen. Für Claude ist gen_ai.provider.name gleich anthropic, über Bedrock aws.bedrock. Tokenzahlen stehen in gen_ai.usage.input_tokens und gen_ai.usage.output_tokens, Cache-Lesen und Cache-Schreiben haben eigene Attribute. Für die DSGVO zählt: gen_ai.input.messages und gen_ai.output.messages sind Opt-In. Eine konforme Instrumentierung speichert keinen Prompt-Text, solange Sie das nicht anfordern.

Langfuse halten wir hier kurz und bleiben bei den EU-Fakten. Die EU-Cloud läuft unter cloud.langfuse.com in Irland auf AWS eu-west-1. Self-Hosting ist kostenlos. Der OTLP-Endpunkt ist /api/public/otel über HTTP/JSON oder HTTP/protobuf. gRPC wird nicht unterstützt. Ein Exporter mit OTEL_EXPORTER_OTLP_PROTOCOL=grpc erreicht Langfuse also nicht. Die Maskierung läuft clientseitig im SDK vor dem Export.

Ein Referenz-Stack, den wir für ein deutsches Unternehmen auf Bedrock bauen würden:

1. CloudWatch-Alarme auf InvocationThrottles, InvocationServerErrors und TimeToFirstToken pro ModelId.
2. Invocation Logging in jeder EU-Quellregion, 30 Tage Aufbewahrung, Data Protection Policy, große Bodies in einen EU-S3-Bucket mit Lifecycle-Regel.
3. OpenTelemetry in der Anwendung, Inhaltsattribute aus, Export an einen Collector in Ihrer EU-VPC.
4. Langfuse selbst gehostet oder EU-Cloud mit AVV, gespeist aus einer Stichprobe der Traces für Evals.
5. Claude-Code-Telemetrie an denselben Collector, nur Metriken.

Auf Google Cloud ersetzen Sie Schritt 1 durch das Observability-Dashboard und Schritt 2 durch BigQuery-Logging mit Sampling. Läuft vor Claude ein selbst betriebenes Gateway, liefert auch das Kostenprotokolle; unser Artikel zum LiteLLM-Gateway in der EU zeigt, wo diese Daten liegen.

Selbst betreiben oder auslagern?

LLM Observability im eigenen Haus ist vor allem laufende Arbeit, kaum Setup. Jemand muss Alarmschwellen nachziehen, wenn sich der Verkehr ändert, Aufbewahrung und Löschung gegen das Verarbeitungsverzeichnis halten, Dashboards pflegen und die Eval-Schleife betreiben. Das Setup oben schafft ein erfahrener Platform Engineer in Tagen. Den Dauerbetrieb unterschätzen fast alle.

Aufwand im eigenen Haus nach Rolle (unsere Einschätzung, keine belegte Benchmark):

Aufgabe	Wer	Rhythmus
Alarm-Tuning (Drosselung, Latenz, Fehlerrate)	Plattform oder SRE	Anfangs wöchentlich, dann monatlich
Aufbewahrung, Löschung, Zugriffsreviews für Prompt-Logs	Plattform mit Datenschutzbeauftragtem	Quartalsweise
Dashboards pro Team, Kostenzuordnung	Plattform oder FinOps	Monatlich
Eval-Datasets, Judge-Prompts, Annotation	Product Owner und Fachexperten	Laufend
Upgrades von Collector und Langfuse beim Self-Hosting	Plattform	Pro Release

Auslagern lohnt sich, wenn Sie mehrere Claude-Anwendungen, aber kein SRE-Team haben, wenn Rufbereitschaft für eine Log-Pipeline nicht drin ist oder wenn Sie schnell prüffeste Nachweise zur Aufbewahrung brauchen. Für Evals lohnt es sich kaum: Ein Dienstleister kann nicht beurteilen, ob eine Antwort für Ihre Fachdomäne stimmt. Das bleibt intern.

Was Sie von einem Managed-Service-Anbieter für dieses Thema verlangen sollten:

• Ein SLA auf Log-Zustellung und Reaktionszeit bei Alarmen, nicht nur auf Dashboard-Verfügbarkeit.
• Einen AVV, der jeden Speicherort von Prompt-Text nennt, plus die Liste der Unterauftragsverarbeiter, inklusive jedes Observability-SaaS, das der Anbieter einbringt.
• Ein Zugriffsmodell nach Least Privilege, Demaskierung nur über eine benannte Rolle, jeder Zugriff protokolliert.
• Aufbewahrung passend zu Ihrem Verarbeitungsverzeichnis, mit nachprüfbarer Löschung.
• Exit: Logs und Dashboards bleiben in Ihrem eigenen AWS- oder Google-Cloud-Account, exportierbar, ohne proprietären Agenten, den Sie nicht entfernen können.

FAQ

Was kostet LLM Observability für Claude auf AWS?

Metriken im Namespace AWS/Bedrock gehören zum Dienst. Invocation Logs kosten CloudWatch-Logs-Ingestion, gelistet mit 0,50 USD pro GB in US East, dazu 0,03 USD pro GB Archiv und 0,12 USD pro GB, wenn eine Data Protection Policy scannt. 5 GB sind frei. In EU-Regionen weichen die Preise ab.

CloudWatch oder Langfuse: Was brauchen Sie?

Beides, für verschiedene Aufgaben. CloudWatch sieht, was nur AWS sieht: Drosselung, Serverfehler, Zeit bis zum ersten Token und ein Log mit IAM-Identität. Langfuse ergänzt Evals, Datasets und menschliche Prüfung. Bewertet niemand Antworten, reicht CloudWatch allein.

Protokolliert Bedrock Prompts standardmäßig?

Nein. Model Invocation Logging ist standardmäßig deaktiviert. Mit Text-Zustellung landen Anfrage- und Antwort-Bodies bis 100 KB in Ihrer CloudWatch-Log-Gruppe, größere in S3. Die Aufbewahrung ist unbegrenzt, bis Sie sie setzen.

Erfasst Invocation Logging Aufrufe über bedrock-mantle?

Nein. AWS schreibt, dass Invocation Logging nur den Endpunkt bedrock-runtime abdeckt. Aufrufe über bedrock-mantle, auch die Anthropic Messages API dort, fehlen im Log. CloudWatch-Metriken und CloudTrail gibt es für Mantle trotzdem.

Kann Google meine Claude-Logs an Anthropic weitergeben?

Nur wenn jemand es einschaltet. Für Claude Mythos Preview, Mythos 5 und Fable 5 auf Google Cloud teilt dataSharingEnabledProvider gleich ANTHROPIC protokollierte Anfragen und Antworten in Echtzeit. Eine Custom Constraint der Organisationsrichtlinie oder ein VPC-Service-Controls-Perimeter verhindert das.

Speichern die OpenTelemetry GenAI Conventions Prompt-Text?

Nicht standardmäßig. In den GenAI Semantic Conventions sind gen_ai.input.messages und gen_ai.output.messages Opt-In-Attribute. Die Conventions stehen noch auf Development. Pinnen Sie die Version Ihrer Instrumentierung und rechnen Sie mit Umbenennungen.

Quellen

1. AWS: Modellaufrufe mit CloudWatch Logs und Amazon S3 überwachen (1. Oktober 2026)
2. AWS: CloudWatch-Metriken für bedrock-runtime (1. Oktober 2026)
3. AWS CLI: put-model-invocation-logging-configuration (1. Oktober 2026)
4. AWS: CloudWatch Logs Data Protection (Maskierung) (1. Oktober 2026)
5. AWS: Log-Gruppen und Aufbewahrung (1. Oktober 2026)
6. AWS CLI: logs put-retention-policy (1. Oktober 2026)
7. Amazon CloudWatch Preise (1. Oktober 2026)
8. Google Cloud: Anfragen und Antworten protokollieren und teilen (1. Oktober 2026)
9. Google Cloud: Modelle überwachen (1. Oktober 2026)
10. Google Cloud: BigQuery-Standorte (1. Oktober 2026)
11. Google Cloud: Log-Buckets konfigurieren (1. Oktober 2026)
12. Google Cloud Observability Preise (1. Oktober 2026)
13. OpenTelemetry GenAI Semantic Conventions (1. Oktober 2026)
14. Claude Code: Nutzung überwachen (1. Oktober 2026)
15. Langfuse: Datenregionen (1. Oktober 2026)
16. Langfuse Preise (1. Oktober 2026)
17. Langfuse: OpenTelemetry-Integration (1. Oktober 2026)
18. AWS: Modellkarte Claude Sonnet 5 (1. Oktober 2026)