aws-observability
aws/agent-toolkit-for-aws
Erstellt, konfiguriert, debuggt und optimiert die AWS-Observability mithilfe von CloudWatch (Logs Insights, Metrics, Alarms, Dashboards, EMF), X-Ray, CloudTrail und ADOT. Behandelt die Abfragesyntax von Log Insights (Felder, Filter, Statistiken, Parsing, Muster, Verknüpfungen, Unterabfragen), die Alarmkonfiguration (Metriken, zusammengesetzte Metriken, Anomalieerkennung, Behandlung fehlender Daten), das Dashboard-Design, benutzerdefinierte Metriken (PutMetricData, EMF, Metrikfilter), X-Ray-Tracing (ADOT, Stichprobenregeln, Anmerkungen vs. Metadaten), die Konfiguration des ADOT-Kollektors sowie CloudT
...Alle erweiternÜber aws-observability
AWS Observability bietet Fachwissen für die Erstellung, Konfiguration, Fehlerbehebung und Optimierung der Observability auf AWS in den Bereichen Metriken, Protokolle und Traces. Es umfasst die Funktionen der CloudWatch-Plattform – Logs Insights, Metrics, Alarms, Dashboards und EMF – sowie X-Ray-Tracing, CloudTrail-Betriebsüberwachung und den AWS Distro for OpenTelemetry (ADOT)-Collector. Zu den spezifischen Bereichen gehören die Abfragesyntax von Log Insights (Felder, Filter, Statistiken, Parsing, Muster, Verknüpfungen, Unterabfragen), die Alarmkonfiguration (Metriken, zusammengesetzte Metriken, Anomalieerkennung, Behandlung fehlender Daten), das Dashboard-Design, benutzerdefinierte Metriken über `PutMetricData`, EMF und Metrikfilter sowie X-Ray-Sampling-Regeln und die Unterscheidung zwischen Anmerkungen und Metadaten.
Wenden Sie diese Kompetenz an, wenn in einer Aufgabe CloudWatch, Log Insights, Alarme, INSUFFICIENT_DATA, Dashboards, benutzerdefinierte Metriken, EMF, X-Ray, Traces, Stichproben, CloudTrail, „Wer hat gelöscht?“, ADOT, OpenTelemetry, Observability, Überwachung, synthetische Tests, Canaries oder die Fehlerbehebung beim Alarmverhalten. Die Einrichtung der Anwendungsprotokollierung, Container-Protokolltreiber oder die Erkennung von Sicherheitsbedrohungen werden ausdrücklich nicht behandelt. Sie funktioniert am besten in Verbindung mit dem AWS MCP-Server, der es dem Agenten ermöglicht, CLI-Befehle auszuführen, CloudWatch abzufragen und Konfigurationen direkt zu validieren, wobei alle Anleitungen auch bei Standardzugriff über die AWS CLI gelten.
Die Skill ist als Routing-Tabelle organisiert, die jeden Benutzerbedarf einer bestimmten Referenzdatei zuordnet: `log-insights.md` für Abfragen, `alarms.md` für Alarmkonfiguration und Standardwerte, `metrics.md` für benutzerdefinierte Metriken und EMF, `tracing.md für X-Ray und ADOT, „dashboards.md“ für das Widget-Design und die konten- und regionenübergreifende Freigabe, „troubleshooting.md“ (das mit den fünf häufigsten Lösungen beginnt), „synthetics.md“ für Canary-Einschränkungen und häufige Fehler sowie „cloudtrail.md“ für die Betriebsüberwachung mit S3 und Athena. Zwei einsatzbereite Assets sind enthalten: „alarm-template.ts“, eine CDK-Vorlage nach Best-Practice-Prinzipien für die Lambda-Überwachung mit Alarmen und einem Dashboard, sowie „otel-config.yaml“, eine ADOT-Collector-Konfiguration für X-Ray-Traces sowie CloudWatch-EMF-Metriken. Da Referenzdateien Laufzeitversionen, Quotenwerte und Funktionsmatrizen enthalten, die sich ändern können, empfiehlt die Anleitung, präzisionskritische Werte anhand der aktuellen AWS-Dokumentation zu überprüfen, bevor man sich in der Produktion darauf verlässt.
FAQ
Welche AWS-Dienste deckt dieses Skill ab?
Er deckt CloudWatch (Logs Insights, Metriken, Alarme, Dashboards, EMF), X-Ray-Traces, CloudTrail-Betriebsüberwachung und den ADOT-Kollektor (OpenTelemetry) für Metriken, Logs und Traces ab.
Wann sollte ich diesen Skill nicht verwenden?
Verwenden Sie ihn nicht für die Einrichtung der Anwendungsprotokollierung, für Container-Protokolltreiber oder zur Erkennung von Sicherheitsbedrohungen. Diese Bereiche fallen ausdrücklich nicht in den Anwendungsbereich.
Benötige ich den AWS MCP-Server, um ihn zu nutzen?
Nein. Er funktioniert am besten mit dem AWS MCP-Server, der die Ausführung von CLI-Befehlen und die direkte Überprüfung von Konfigurationen ermöglicht, aber alle Anleitungen funktionieren auch mit dem Standardzugriff über die AWS CLI.
Wo finde ich Hilfe zur Fehlerbehebung bei einem Alarm, der im Status „INSUFFICIENT_DATA“ hängen geblieben ist?
Beginnen Sie mit der Datei „troubleshooting.md“, die mit den fünf häufigsten Lösungen beginnt, und lesen Sie „alarms.md“ für Konfigurationsdetails, einschließlich der Behandlung fehlender Daten bei Metrik-, Composite- und Anomalieerkennungsalarmen.
Sind vorgefertigte Vorlagen enthalten?
Ja. Es enthält „alarm-template.ts“, eine CDK-Vorlage nach Best Practices für die Lambda-Überwachung mit Alarmen und einem Dashboard, sowie „otel-config.yaml“, eine ADOT-Collector-Konfiguration für X-Ray-Traces und CloudWatch-EMF-Metriken.
Alle Dateien
11Dateien: references/alarms.md 10,9KB Anzeigen references/log-insights.md 6,9KB Anzeigen references/tracing.md 8,9KB Anzeigen assets/alarm-template.ts 3,9KB Anzeigen references/cloudtrail.md 3,9KB Anzeigen references/metrics.md 7,4KB Anzeigen references/troubleshooting.md 6,7KB Anzeigen assets/otel-config.yaml 1,4KB Anzeigen references/dashboards.md 5,8KB Anzeigen references/synthetics.md 6,5KB Anzeigen SKILL.md 4,1 KB AnzeigenOverview
Domain expertise for AWS observability across metrics, logs, and traces, covering the full lifecycle: enabling/onboarding a service to Application Signals using ADOT (AWS Distro for OpenTelemetry) auto-instrumentation SDKs and ServiceEvents — making the service show up in Application Signals — on EC2, ECS, EKS, and Lambda in Python, Node.js, Java, and .NET.
Works best with the AWS MCP server — enables running CLI commands, querying CloudWatch, and validating configurations directly. All guidance also works with standard AWS CLI access.
Note: Reference files contain specific runtime versions, quota values, and feature matrices that may change. When precision matters (e.g., deploying to production, choosing a runtime, or checking a quota), confirm values against current AWS documentation rather than relying solely on the values in these files.
Routing
| User need | Action |
|---|---|
| Enabling/onboarding a service to Application Signals (auto-instrumentation) | Read application-signals-onboarding.md |
| Propagating ServiceEvents git/deployment metadata through CI/CD | Read application-signals-cicd-metadata.md |
| Per-platform/per-language enablement steps | Read the matching references/appsignals-guides/<platform>-<language>.md (e.g. eks-python.md) |
| Writing Log Insights queries | Read log-insights.md |
| Configuring alarms (metric, composite, anomaly) | Read alarms.md |
| Publishing custom metrics or using EMF | Read metrics.md |
| Setting up X-Ray tracing or ADOT | Read tracing.md |
| Building dashboards | Read dashboards.md |
| Debugging observability issues | Read troubleshooting.md — starts with the 5 most common fixes |
| Debugging canary failures | Read synthetics.md — see Common failures table |
| CloudTrail operational auditing | Read cloudtrail.md |
| Setting up Lambda monitoring with CDK | Use alarm-template.ts as a starting point |
| Creating synthetic canaries | Read synthetics.md |
| Configuring ADOT collector | Use otel-config.yaml as a starting point |
| Debugging a running service with breakpoints/snapshots — Dynamic Instrumentation (modifies live services and capture live data) | Read dynamic-instrumentation.md in full before acting. Confirm with the user before any create/delete, and narrate before significant actions: observation → hypothesis → proposed action → expected result. Diagnosing running-service root cause from source/code inspection. Source inspection alone identifies hypotheses, not confirmed root causes. Keep suspected causes tentative until runtime evidence confirms them. |
| Spans multiple areas | Read the most specific reference first, then consult others as needed |
Files
| File | Content |
|---|---|
| application-signals-onboarding.md | Enable Application Signals auto-instrumentation: EKS add-on, CloudWatch Agent IAM, OTLP endpoints, ServiceEvents env vars, Dynamic Instrumentation — two-tier scope by platform/language |
| application-signals-cicd-metadata.md | ServiceEvents git & deployment metadata propagation through CI/CD (the 5 OTEL_AWS_SERVICE_EVENTS_* vars) |
references/appsignals-guides/ (e.g. eks-python.md) | 16 per-platform × per-language enablement guides (EC2/ECS/EKS/Lambda × Python/Node.js/Java/.NET) |
| alarms.md | Metric, composite, anomaly detection alarms — configuration, constraints, recommended defaults |
| log-insights.md | Complete query syntax, commands, functions, known issues, reusable query library |
| metrics.md | Custom metrics, EMF spec, metric filters, high-resolution, retention |
| tracing.md | X-Ray → ADOT migration, sampling rules, annotations vs metadata, collector config |
| dashboards.md | Widget types, cross-account/region, dynamic labels, sharing |
| troubleshooting.md | Error → cause → fix for all observability services |
| cloudtrail.md | Operational auditing, event types, S3+Athena queries |
| synthetics.md | Canary runtime/blueprint constraints, VPC networking, common failures |
| alarm-template.ts | Best-practice CDK Lambda monitoring (alarms + dashboard) |
| otel-config.yaml | ADOT collector config for X-Ray traces + CloudWatch EMF metrics |
| dynamic-instrumentation.md | Dynamic Instrumentation debugging loop — breakpoints/probes on live code, snapshot capture + correlation analysis, create/delete gating, snapshot PII handling. Runs via scripts/di_instrumentation.py + scripts/di_snapshots.py. |
Alle Dateien
0 Dateienaws-observability installieren
Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihr Verzeichnis „.claude/skills/“.
ZIP herunterladenKlonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.
git clone https://github.com/aws/agent-toolkit-for-aws/blob/main/skills/core-skills/aws-observability/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Kopieren





Heim
