Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Beobachtbarkeit von Anwendungen für Action AWS
Application Observability for AWS GitHub Action bietet einen Workflow zur Untersuchung der end-to-end Anwendungsbeobachtbarkeit, der Ihren Quellcode und Ihre Telemetriedaten aus der Produktion in Echtzeit mit dem KI-Agenten verbindet. Er nutzt CloudWatch MCPs und generiert benutzerdefinierte Eingabeaufforderungen, um den Kontext bereitzustellen, den KI-Agenten für die Fehlerbehebung und die Anwendung von Codekorrekturen benötigen.
[Die Aktion richtet den MCP-Server und den [MCP-Server von CloudWatch Application Signals](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server) ein und CloudWatch konfiguriert sie, sodass sie auf Live-Telemetriedaten als Kontext zur Fehlerbehebung zugreifen können.](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server) Sie können Ihr bevorzugtes KI-Modell — sei es über Ihren eigenen API-Schlüssel, ein Drittanbietermodell oder Amazon Bedrock — für Untersuchungen zur Anwendungsleistung verwenden.
Geben Sie zunächst `@awsapm` in Ihren GitHub Problemen an, ob der KI-Agent ausgelöst werden soll. Der Agent behebt Produktionsprobleme, implementiert Korrekturen und verbessert die Observability-Abdeckung auf der Grundlage Ihrer Live-Anwendungsdaten.
Für diese Maßnahme selbst fallen keine direkten Kosten an. Die Nutzung dieser Aktion kann jedoch zu Gebühren für AWS Dienste und die Nutzung von KI-Modellen führen. Ausführliche Informationen zu möglichen [Kosten finden Sie in der Dokumentation zu den Kostenerwägungen](https://github.com/marketplace/actions/application-observability-for-aws#-cost-considerations).
## Erste Schritte
Mit dieser Aktion werden KI-Agenten in Ihrem GitHub Workflow konfiguriert, indem AWS spezifische MCP-Konfigurationen und benutzerdefinierte Observability-Prompts generiert werden. Sie müssen lediglich die IAM-Rolle angeben, die Sie übernehmen möchten, und eine [Bedrock-Model-ID](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html), die Sie verwenden möchten, oder ein API-Token aus Ihrem bestehenden LLM-Abonnement. Das folgende Beispiel zeigt eine Workflow-Vorlage, die diese Aktion in die von [Anthropic integriert, claude-code-base-action um automatisierte Untersuchungen](https://github.com/anthropics/claude-code-base-action) durchzuführen.
### Voraussetzungen
Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ **GitHub Repository-Berechtigungen**: Schreibzugriff oder höher auf das Repository (erforderlich, um die Aktion auszulösen)
+ **AWS IAM-Rolle**: Eine mit OpenID Connect (OIDC) konfigurierte IAM-Rolle für Aktionen mit Berechtigungen für GitHub :
+ CloudWatch Anwendungssignale und Zugriff CloudWatch
+ Zugriff auf Amazon Bedrock-Modelle (bei Verwendung von Bedrock-Modellen)
+ **GitHub Token**: Der Workflow verwendet automatisch GITHUB\$1TOKEN mit den erforderlichen Berechtigungen
### Schritte zur Einrichtung
#### Schritt 1: AWS Anmeldeinformationen einrichten
Diese Aktion basiert auf der Aktion [aws-actions/](https://github.com/aws-actions/configure-aws-credentials), um die AWS Authentifizierung in Ihrer configure-aws-credentials Aktionsumgebung einzurichten. GitHub Wir empfehlen die Verwendung von OpenID Connect (OIDC) zur Authentifizierung mit. AWS OIDC ermöglicht Ihren GitHub Actions-Workflows den Zugriff auf AWS Ressourcen mit kurzlebigen Anmeldeinformationen, sodass Sie keine langfristigen AWS Anmeldeinformationen in Ihrem Repository speichern müssen.
1. **Erstellen Sie einen IAM-Identitätsanbieter**
Erstellen Sie zunächst einen IAM-Identitätsanbieter, der seinem OIDC-Endpunkt in GitHub der Management Console vertraut: AWS
1. Öffnen Sie die IAM-Konsole
1. Klicken Sie unter **Zugriffsverwaltung** auf **Identitätsanbieter**
1. Klicken Sie auf die Schaltfläche **Anbieter hinzufügen**, um den GitHub Identitätsanbieter hinzuzufügen, falls er noch nicht erstellt wurde
1. Wählen Sie den **OpenID Connect-Typ** des Identitätsanbieters
1. Geben Sie in `https://token.actions.githubusercontent.com` das **Eingabefeld Provider-URL** ein
1. Geben Sie in `sts.amazonaws.com` das Eingabefeld „**Zielgruppe**“ ein
1. Klicken Sie auf die Schaltfläche **Anbieter hinzufügen**
1. **Erstellen Sie eine IAM-Richtlinie**
Erstellen Sie eine IAM-Richtlinie mit den erforderlichen Berechtigungen für diese Aktion. Einzelheiten finden Sie [Erforderliche Berechtigungen](#Service-Application-Observability-for-AWS-GitHub-Action-required-permissions) im folgenden Abschnitt.
1. **Erstellen Sie eine IAM-Rolle**
Erstellen Sie eine IAM-Rolle (z. B.`AWS_IAM_ROLE_ARN`) in der AWS Management Console mit der folgenden Vorlage für eine Vertrauensrichtlinie. Dadurch können autorisierte GitHub Repositorys die Rolle übernehmen:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:/:ref:refs/heads/"
}
}
}
]
}
```
Ersetzen Sie die folgenden Platzhalter in der Vorlage:
+ ``- Ihre AWS Konto-ID
+ ``- Der Name Ihrer GitHub Organisation
+ ``- Ihr Repository-Name
+ ``- Ihr Branchenname (z. B. main)
1. **Hängen Sie die IAM-Richtlinie an**
Fügen Sie auf der Registerkarte „Berechtigungen“ der Rolle die IAM-Richtlinie an, die Sie in Schritt 2 erstellt haben.
Weitere Informationen zur Konfiguration von OIDC mit AWS finden Sie in der [configure-aws-credentials OIDC-Schnellstartanleitung](https://github.com/aws-actions/configure-aws-credentials/tree/main?tab=readme-ov-file#quick-start-oidc-recommended).
#### Schritt 2: Secrets konfigurieren und Workflow hinzufügen
1. **Konfigurieren Sie Repository-Geheimnisse**
Gehe zu deinem Repository → Einstellungen → Geheimnisse und Variablen → Aktionen.
+ Erstellen Sie ein neues Repository-Geheimnis mit dem Namen `AWS_IAM_ROLE_ARN` und legen Sie seinen Wert auf den ARN der IAM-Rolle fest, die Sie in Schritt 1 erstellt haben.
+ (Optional) Erstellen Sie eine Repository-Variable mit `AWS_REGION` dem Namen Ihrer AWS Region (standardmäßig auf, `us-east-1` falls nicht festgelegt)
1. **Fügen Sie die Workflow-Datei hinzu**
Im Folgenden finden Sie einen Beispiel-Workflow, der die Verwendung dieser Aktion mit Amazon Bedrock-Modellen demonstriert. Erstellen Sie anhand dieser Vorlage in Ihrem GitHub Repository-Verzeichnis einen Workflow zur Untersuchung von Application Observability. `.github/workflows`
```
name: Application observability for AWS
on:
issue_comment:
types: [created, edited]
issues:
types: [opened, assigned, edited]
jobs:
awsapm-investigation:
if: |
(github.event_name == 'issue_comment' && contains(github.event.comment.body, '@awsapm')) ||
(github.event_name == 'issues' && (contains(github.event.issue.body, '@awsapm') || contains(github.event.issue.title, '@awsapm')))
runs-on: ubuntu-latest
permissions:
contents: write # To create branches for PRs
pull-requests: write # To post comments on PRs
issues: write # To post comments on issues
id-token: write # Required for AWS OIDC authentication
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_IAM_ROLE_ARN }}
aws-region: ${{ vars.AWS_REGION || 'us-east-1' }}
# Step 1: Prepare AWS MCP configuration and investigation prompt
- name: Prepare Investigation Context
id: prepare
uses: aws-actions/application-observability-for-aws@v1
with:
bot_name: "@awsapm"
cli_tool: "claude_code"
# Step 2: Execute investigation with Claude Code
- name: Run Claude Investigation
id: claude
uses: anthropics/claude-code-base-action@beta
with:
use_bedrock: "true"
# Set to any Bedrock Model ID
model: "us.anthropic.claude-sonnet-4-5-20250929-v1:0"
prompt_file: ${{ steps.prepare.outputs.prompt_file }}
mcp_config: ${{ steps.prepare.outputs.mcp_config_file }}
allowed_tools: ${{ steps.prepare.outputs.allowed_tools }}
# Step 3: Post results back to GitHub issue/PR (reuse the same action)
- name: Post Investigation Results
if: always()
uses: aws-actions/application-observability-for-aws@v1
with:
cli_tool: "claude_code"
comment_id: ${{ steps.prepare.outputs.awsapm_comment_id }}
output_file: ${{ steps.claude.outputs.execution_file }}
output_status: ${{ steps.claude.outputs.conclusion }}
```
**Hinweis zur Konfiguration:**
+ Dieser Workflow `@awsapm` wird automatisch ausgelöst, wenn er in einem Problem oder Kommentar erwähnt wird
+ Der Workflow verwendet das im vorherigen Schritt konfigurierte `AWS_IAM_ROLE_ARN` Geheimnis
+ Aktualisieren Sie den Modellparameter in Schritt 2, um Ihre bevorzugte Amazon Bedrock-Modell-ID anzugeben
+ Sie können den Bot-Namen (z. B.`@awsapm-prod`,`@awsapm-staging`) im Parameter bot\$1name anpassen, um verschiedene Umgebungen zu unterstützen
#### Schritt 3: Fangen Sie an, die Aktion zu verwenden
Sobald der Workflow konfiguriert ist, können Sie jedes GitHub Problem erwähnen`@awsapm`, um eine KI-gestützte Untersuchung auszulösen. Die Aktion analysiert Ihre Anfrage, greift auf Live-Telemetriedaten zu und gibt Empfehlungen oder implementiert automatisch Korrekturen.
**Beispiele für Anwendungsfälle:**
1. Untersuchen Sie Leistungsprobleme und korrigieren Sie Folgendes:
`@awsapm, can you help me investigate availability issues in my appointment service?`
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-investigate.png)
`@awsapm, can you post a fix?`
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-pr-fix.png)
1. Instrumentierung aktivieren:
`@awsapm, please enable Application Signals for lambda-audit-service and create a PR with the required changes.`
1. Telemetriedaten abfragen:
`@awsapm, how many GenAI tokens have been consumed by my services in the past 24 hours?`
**Was passiert als Nächstes:**
1. Der Workflow erkennt die `@awsapm` Erwähnung und löst die Untersuchung aus
1. Der AI-Agent greift über die konfigurierten MCP-Server auf Ihre AWS Live-Telemetriedaten zu
1. Der Agent analysiert das Problem und entweder:
+ Veröffentlicht Ergebnisse und Empfehlungen direkt in der Ausgabe
+ Erstellt eine Pull-Anfrage mit Codeänderungen (für Instrumentierung oder Problembehebungen)
1. Du kannst die Ergebnisse überprüfen und die Konversation fortsetzen, indem du @awsapm erneut mit weiteren Fragen erwähnst
## Sicherheit
Bei dieser Aktion wird der Sicherheit mit strengen Zugriffskontrollen, OIDC-basierter AWS Authentifizierung und integriertem Schutz vor Prompt-Injection-Angriffen Priorität eingeräumt. Nur Benutzer mit Schreibzugriff oder höher können die Aktion auslösen, und alle Operationen sind auf das jeweilige Repository beschränkt.
Für detaillierte Sicherheitsinformationen, einschließlich:
+ Zugriffskontrolle und Genehmigungsanforderungen
+ AWS IAM-Berechtigungen und OIDC-Konfiguration
+ Sofortige Injektionsrisiken und Abhilfemaßnahmen
+ Bewährte Methoden für die Gewährleistung der Sicherheit
Weitere Informationen finden Sie in der [Sicherheitsdokumentation](https://github.com/aws-actions/application-observability-for-aws/blob/main/docs/security.md).
## Konfiguration
### Erforderliche Berechtigungen
Die von GitHub Actions übernommene IAM-Rolle muss über die folgenden Berechtigungen verfügen.
**Hinweis**: `bedrock:InvokeModel` und `bedrock:InvokeModelWithResponseStream` sind nur erforderlich, wenn Sie Amazon Bedrock-Modelle verwenden
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-signals:ListServices",
"application-signals:GetService",
"application-signals:ListServiceOperations",
"application-signals:ListServiceLevelObjectives",
"application-signals:GetServiceLevelObjective",
"application-signals:ListAuditFindings",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:ListMetrics",
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"logs:DescribeLogGroups",
"logs:DescribeQueryDefinitions",
"logs:ListLogAnomalyDetectors",
"logs:ListAnomalies",
"logs:StartQuery",
"logs:StopQuery",
"logs:GetQueryResults",
"logs:FilterLogEvents",
"xray:GetTraceSummaries",
"xray:GetTraceSegmentDestination",
"xray:BatchGetTraces",
"xray:ListRetrievedTraces",
"xray:StartTraceRetrieval",
"servicequotas:GetServiceQuota",
"synthetics:GetCanary",
"synthetics:GetCanaryRuns",
"s3:GetObject",
"s3:ListBucket",
"iam:GetRole",
"iam:ListAttachedRolePolicies",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*"
}
]
}
```
## Dokumentation
Weitere Informationen finden Sie unter:
+ [CloudWatch Dokumentation zu Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Intro.html) — Erfahren Sie mehr über CloudWatch die Funktionen und Möglichkeiten von Application Signals
+ [Öffentliche Dokumentation zur Anwendungsbeobachtung für AWS Action](https://github.com/marketplace/actions/application-observability-for-aws) — ausführliche Anleitungen und Tutorials