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.
# Erfassen Sie Metriken, Logs und Traces mithilfe des CloudWatch Agenten
CloudWatch Agent ist eine Softwarekomponente, die Metriken, Protokolle und Traces von Ihren Amazon EC2 EC2-Instances, lokalen Servern und containerisierten Anwendungen sammelt. Damit können Sie Ihre Infrastruktur und Anwendungen umfassender überwachen als mit der Standardüberwachung.
**Die wichtigsten Vorteile**
+ Erfassen von Metriken auf Systemebene (CPU, Arbeitsspeicher, Festplatte, Netzwerk)
+ Erfassen von benutzerdefinierten Metriken aus Ihren Anwendungen
+ Erfassen und zentralisieren von Protokollen aus verschiedenen Quellen
+ Überwachen Sie AWS sowohl Umgebungen als auch lokale Umgebungen mit einem einzigen Tool
+ Richten Sie Alarme und Benachrichtigungen auf der Grundlage der erfassten Daten ein
Mit dem CloudWatch Agenten können Sie Folgendes tun:
+ Erfassen Sie intern betriebssystemübergreifend mehr Metriken auf Systemebene von Amazon-EC2-Instances. Die Metriken können neben den Metriken für EC2-Instances auch Gast-Metriken enthalten. Eine Aufstellung der zusätzlichen Metriken, die erfasst werden können, finden Sie unter [Vom CloudWatch Agenten gesammelte Metriken](metrics-collected-by-CloudWatch-agent.md).
+ Erfassen Sie Metriken auf Systemebene von On-Premises-Servern. Dazu können sowohl Server in einer Hybridumgebung als auch Server gehören, die nicht von verwaltet werden AWS.
+ Rufen Sie benutzerdefinierte Metriken aus Ihren Anwendungen oder Services mithilfe der Protokolle `StatsD` und `collectd` ab. `StatsD` wird sowohl auf Linux-Servern als auch auf Servern mit Windows Server unterstützt. `collectd` wird nur auf Linux-Servern unterstützt.
+ Erfassen Sie Protokolle von Amazon-EC2-Instances und On-Premises-Servern mit Linux oder Windows Server.
**Anmerkung**
Der CloudWatch Agent unterstützt das Sammeln von Protokollen aus FIFO-Pipes nicht.
+ Senden Sie die Metriken CloudWatch entweder an Amazon Managed Service for Prometheus oder an beide. Die CloudWatch Agenten-Konfigurationsdatei enthält einen `metrics_destinations` Parameter im `metrics` Abschnitt. Sie können `cloudwatch`, `amp` oder beides in diesem Parameter angeben.
+ Version 1.300031.0 und höher können verwendet werden, um Application Signals zu aktivieren CloudWatch . Weitere Informationen finden Sie unter [Anwendungssignale](CloudWatch-Application-Monitoring-Sections.md).
+ Version 1.300025.0 und höher können Traces von [OpenTelemetry](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-opentel)unserem X-Ray-Client SDKs sammeln und an [X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-xray-sdk) senden.
Mit dem CloudWatch Agenten können Sie Traces sammeln, ohne einen separaten Trace-Collection-Daemon ausführen zu müssen, wodurch die Anzahl der Agents, die Sie ausführen und verwalten, reduziert wird.
Metriken, an die gesendet wurde, CloudWatch können CloudWatch wie alle anderen CloudWatch Messwerte angezeigt werden. Der CloudWatch Standard-Namespace für vom CloudWatch Agenten gesammelte Metriken ist`CWAgent`, obwohl Sie bei der Konfiguration des Agenten einen anderen Namespace angeben können.
Die vom CloudWatch Agenten gesammelten Protokolle werden verarbeitet und in Amazon CloudWatch Logs gespeichert, genau wie die vom älteren Logs-Agenten gesammelten CloudWatch Protokolle. Informationen zu den Preisen für CloudWatch Logs finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing).
Die vom CloudWatch Agenten gesammelten Metriken werden als benutzerdefinierte Metriken in Rechnung gestellt. Weitere Informationen zu den Preisen von CloudWatch Metriken finden Sie unter [ CloudWatchAmazon-Preise](https://aws.amazon.com/cloudwatch/pricing).
Der CloudWatch Agent ist Open Source unter der MIT-Lizenz und wird [auf GitHub gehostet](https://github.com/aws/amazon-cloudwatch-agent/). Wenn Sie den CloudWatch Agenten erstellen, anpassen oder dazu beitragen möchten, finden Sie die neuesten Anweisungen im GitHub Repository. Wenn Sie glauben, ein potenzielles Sicherheitsproblem gefunden zu haben, posten Sie es nicht in einem öffentlichen Forum. GitHub Folgen Sie stattdessen den Anweisungen unter [Schwachstellenmeldung](https://aws.amazon.com/security/vulnerability-reporting/) oder wenden Sie sich [direkt an die AWS E-Mail-Sicherheit](mailto:aws-security@amazon.com).
Sie können den CloudWatch Agenten manuell über die Befehlszeile herunterladen und installieren oder ihn in AWS Systems Manager integrieren. Der allgemeine Ablauf der Installation des CloudWatch Agenten sieht wie folgt aus:
1. Erstellen Sie IAM-Rollen oder -Benutzer, die es dem Agenten ermöglichen, Metriken vom Server zu sammeln und optional in AWS Systems Manager zu integrieren.
1. Laden Sie das Agentenpaket herunter.
1. Ändern Sie die CloudWatch Agent-Konfigurationsdatei und geben Sie die Metriken an, die Sie sammeln möchten.
1. Installieren und starten Sie den Agenten auf Ihren Servern.
**Topics**
+ [Unterstützte Betriebssysteme](supported-operating-systems.md)
+ [Voraussetzungen](prerequisites.md)
+ [Laden Sie das CloudWatch Agentenpaket herunter](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md)
+ [Überprüfung der Signatur des Agentenpakets CloudWatch](verify-CloudWatch-Agent-Package-Signature.md)
+ [Den CloudWatch Agenten installieren](install-CloudWatch-Agent-on-EC2-Instance.md)
+ [Richten Sie den CloudWatch Agenten mit Linux mit verbesserter Sicherheit ein () SELinux](CloudWatch-Agent-SELinux.md)
+ [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md)
+ [Der CloudWatch Agent wird gestartet](start-CloudWatch-Agent-on-premise-SSM-onprem.md)
+ [Vom CloudWatch Agenten gesammelte Metriken](metrics-collected-by-CloudWatch-agent.md)
+ [Verwenden des Agenten mit zugehöriger Telemetrie CloudWatch](CloudWatch-Agent-RelatedEntities.md)
+ [Allgemeine Szenarien mit dem CloudWatch Agenten](CloudWatch-Agent-common-scenarios.md)
+ [CloudWatch Präferenz für Agenten-Anmeldeinformationen](CloudWatch-Agent-Credentials-Preference.md)
+ [Fehlerbehebung beim Agenten CloudWatch](troubleshooting-CloudWatch-Agent.md)
# Unterstützte Betriebssysteme
Der CloudWatch Agent wird auf den folgenden Betriebssystemen unterstützt:
## x86-64-Architektur
+ Amazon Linux 2023
+ Amazon Linux 2
+ Ubuntu Server-Versionen 25.04, 24.04 und 22.04
+ Red Hat Enterprise Linux (RHEL) Versionen 10, 9 und 8
+ Debian-Version 12
+ SUSE Linux Enterprise Server (SLES) Version 15
+ Oracle Linux Versionen 9 und 8
+ AlmaLinux Versionen 10, 9 und 8
+ Rocky Linux-Versionen 10, 9 und 8
+ macOS-Computer: EC2-M1-Mac1-Instances und Computer mit macOS 14 (Sonoma), macOS 13 (Ventura) und macOS 12 (Monterey)
+ Windows Server 2025, Windows Server 2022, Windows Server 2019 und Windows Server 2016
+ Windows 11
+ Windows 10 (64 Bit)
## ARM64 Architektur
+ Amazon Linux 2023
+ Amazon Linux 2
+ Ubuntu Server Version 22.04
+ Red Hat Enterprise Linux (RHEL) Versionen 9 und 8
+ Debian-Version 12
+ SUSE Linux Enterprise Server 15
+ macOS-Computer: macOS 14 (Sonoma), macOS 13 (Ventura) und macOS 12 (Monterey)
# Voraussetzungen
Stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind, bevor Sie den CloudWatch Agenten zum ersten Mal installieren.
## IAM-Rollen und Benutzer für den Agenten CloudWatch
Für den Zugriff auf AWS Ressourcen sind Berechtigungen erforderlich. Sie erstellen eine IAM-Rolle, einen IAM-Benutzer oder beides, um Berechtigungen zu erteilen, für die der CloudWatch Agent Metriken schreiben muss. CloudWatch
### Eine IAM-Rolle für Amazon-EC2-Instances erstellen
Wenn Sie den CloudWatch Agenten auf Amazon EC2 EC2-Instances ausführen möchten, erstellen Sie eine IAM-Rolle mit den erforderlichen Berechtigungen.
1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**.
1. Stellen Sie sicher, dass unter **Trusted entity type (Typ der vertrauenswürdigen Entität auswählen** der **AWS -Service** ausgewählt ist.
1. Wählen Sie für **Anwendungsfall** die Option **EC2** unter **Häufige Anwendungsfälle**.
1. Wählen Sie **Weiter** aus.
1. Aktivieren Sie in der Liste der Richtlinien das Kontrollkästchen neben **CloudWatchAgentServerPolicy**. Verwenden Sie ggf. das Suchfeld, um die Richtlinie zu finden.
1. Wählen Sie **Weiter** aus.
1. Geben Sie unter **Rollenname** einen Namen für die Rolle ein, z. B. `CloudWatchAgentServerRole`. Geben Sie optional eine Beschreibung dafür ein. Wählen Sie dann **Create Role**.
(Optional) Wenn der Agent Protokolle an Logs senden soll und Sie möchten, dass der Agent Aufbewahrungsrichtlinien für diese Protokollgruppen festlegen kann, müssen Sie der Rolle die `logs:PutRetentionPolicy` entsprechende Berechtigung hinzufügen. CloudWatch
### Einen IAM-Benutzer für On-Premises-Server erstellen
Wenn Sie den CloudWatch Agenten auf lokalen Servern ausführen möchten, erstellen Sie einen IAM-Benutzer mit den erforderlichen Berechtigungen.
**Anmerkung**
Dieses Szenario erfordert IAM-Benutzer mit programmatischem Zugriff und langfristigen Anmeldeinformationen, was ein Sicherheitsrisiko darstellt. Um dieses Risiko zu minimieren, empfehlen wir, diesen Benutzern nur die Berechtigungen zu gewähren, die sie für die Ausführung der Aufgabe benötigen, und diese Benutzer zu entfernen, wenn sie nicht mehr benötigt werden.
1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich **Benutzer** und dann **Benutzer hinzufügen**.
1. Geben Sie den Benutzernamen für den neuen Benutzer an.
1. Wählen Sie **Access key - Programmatic access (Zugriffsschlüssel – programmgesteuerter Zugriff)** und **Next: Permissions (Weiter: Berechtigungen)** aus.
1. Wählen Sie **Vorhandene Richtlinien direkt zuordnen**.
1. Aktivieren Sie in der Liste der Richtlinien das Kontrollkästchen neben **CloudWatchAgentServerPolicy**. Verwenden Sie ggf. das Suchfeld, um die Richtlinie zu finden.
1. Wählen Sie **Weiter: Tags** aus.
1. Erstellen Sie optional Tags für den neuen IAM-Benutzer und wählen Sie dann **Weiter: Prüfung** aus.
1. Prüfen Sie, ob die richtigen Richtlinie aufgelistet ist, und klicken Sie auf **Benutzer erstellen**.
1. Klicken Sie neben dem Namen des neuen Benutzers auf **Show**. Kopieren Sie den Zugriffsschlüssel und den geheimen Schlüssel in eine Datei, damit Sie sie bei der Installation des Agenten verwenden können. Klicken Sie auf **Schließen**.
### Anfügen einer IAM-Rolle an eine Amazon-EC2-Instance
Damit der CloudWatch Agent Daten von einer Amazon EC2 EC2-Instance senden kann, müssen Sie die von Ihnen erstellte IAM-Rolle an die Instance anhängen.
Weitere Informationen zum Anhängen einer IAM-Rolle an eine Instance finden Sie unter [Anhängen einer IAM-Rolle an eine Instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) im Benutzerhandbuch von Amazon Elastic Compute Cloud.
### Erlauben Sie dem CloudWatch Agenten, eine Richtlinie zur Aufbewahrung von Protokollen festzulegen
Sie können den CloudWatch Agenten so konfigurieren, dass er die Aufbewahrungsrichtlinie für Protokollgruppen festlegt, an die er Protokollereignisse sendet. Wenn Sie dies tun, müssen Sie der IAM-Rolle oder dem Benutzer, den der Agent verwendet, die Berechtigung `logs:PutRetentionPolicy` gewähren. Der Agent verwendet eine IAM-Rolle für die Ausführung auf Amazon-EC2-Instances und nutzt für On-Premises-Server einen IAM-Benutzer.
**Um der IAM-Rolle des CloudWatch Agenten die Berechtigung zu erteilen, Richtlinien zur Aufbewahrung von Protokollen festzulegen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Geben Sie in das Suchfeld den Anfang des Namens der IAM-Rolle des CloudWatch Agenten ein. Das ist der Name, den Sie beim Erstellen der Rolle gewählt haben. Ein möglicher Name ist `CloudWatchAgentServerRole`.
Wenn Sie die Rolle sehen, wählen Sie den Namen der Rolle aus.
1. Wählen Sie auf der Registerkarte **Berechtigungen** die Optionen **Berechtigungen hinzufügen** und dann **Create Inline Policy (Inline-Richtlinie erstellen)** aus.
1. Wählen Sie die Registerkarte **JSON** aus und kopieren Sie die folgende Richtlinie in das Feld. Dabei ersetzen Sie den Standard-JSON-Code im Feld:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutRetentionPolicy",
"Resource": "*"
}
]
}
```
------
1. Wählen Sie **Richtlinie prüfen**.
1. Geben Sie für **Name** die Bezeichnung **CloudWatchAgentPutLogsRetention** oder etwas ähnliches ein und wählen Sie dann **Create policy** (Richtlinie erstellen) aus.
**Um dem IAM-Benutzer des CloudWatch Agenten die Erlaubnis zu erteilen, Richtlinien zur Aufbewahrung von Protokollen festzulegen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im linken Navigationsbereich **Benutzer** aus.
1. Geben Sie in das Suchfeld den Anfang des Namens des IAM-Benutzers des CloudWatch Agenten ein. Das ist der Name, den Sie beim Erstellen des Benutzers gewählt haben.
Wenn Sie den Benutzer sehen, wählen Sie den Namen des Benutzers aus.
1. Wählen Sie auf der Registerkarte **Permissions** (Berechtigungen) die Option **Add inline policy** (Eingebundene Richtlinie hinzufügen).
1. Wählen Sie die Registerkarte **JSON** aus und kopieren Sie die folgende Richtlinie in das Feld. Dabei ersetzen Sie den Standard-JSON-Code im Feld:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutRetentionPolicy",
"Resource": "*"
}
]
}
```
------
1. Wählen Sie **Richtlinie prüfen**.
1. Geben Sie für **Name** die Bezeichnung **CloudWatchAgentPutLogsRetention** oder etwas ähnliches ein und wählen Sie dann **Create policy** (Richtlinie erstellen) aus.
## Netzwerkanforderungen
**Anmerkung**
Wenn sich der Server in einem öffentlichen Subnetz befindet, stellen Sie sicher, dass Zugriff auf ein Internet-Gateway besteht. Wenn sich der Server in einem privaten Subnetz befindet, erfolgt der Zugriff über die NAT-Gateways oder den VPC-Endpunkt. Weitere Informationen zu NAT-Gateways finden Sie unter [https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
Ihre Amazon EC2 EC2-Instances müssen über ausgehenden Internetzugang verfügen, um Daten an CloudWatch oder CloudWatch Logs senden zu können. Weitere Informationen dazu, wie Sie den Internetzugang konfigurieren, finden Sie unter [Internet-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) im Benutzerhandbuch zu Amazon VPC.
### Verwenden eines VPC-Endpunkts
Wenn Sie eine VPC verwenden und einen CloudWatch Agenten ohne öffentlichen Internetzugang verwenden möchten, können Sie VPC-Endpunkte für CloudWatch und Logs konfigurieren. CloudWatch
Folgende auf Ihrem Proxy zu konfigurierende Endpunkte und Ports sind möglich:
+ Wenn Sie den Agenten zum Sammeln von Metriken verwenden, müssen Sie die CloudWatch Endpunkte für die entsprechenden Regionen zur Zulassungsliste hinzufügen. Diese Endpunkte sind unter [ CloudWatchAmazon-Endpunkte und](https://docs.aws.amazon.com/general/latest/gr/cw_region.html) Kontingente aufgeführt.
+ Wenn Sie den Agenten zum Sammeln von Protokollen verwenden, müssen Sie die CloudWatch Logs-Endpunkte für die entsprechenden Regionen zur Zulassungsliste hinzufügen. Diese Endpunkte sind in [Amazon CloudWatch Logs Endpoints and](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html) Quotas aufgeführt.
+ Wenn Sie den Agenten mit dem Systems Manager installieren oder die Konfigurationsdatei mit Parameter Store speichern, müssen Sie die Systems-Manager-Endpunkte für die entsprechenden Regionen zur Allow-Liste hinzufügen. Diese Endpunkte sind unter [AWS -Systems-Manager-Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/ssm.html) aufgeführt.
# Laden Sie das CloudWatch Agentenpaket herunter
**Anmerkung**
Um den CloudWatch Agenten herunterzuladen, muss Ihre Verbindung TLS 1.2 oder höher verwenden.
Der CloudWatch Agent ist als Paket in Amazon Linux 2023 und Amazon Linux 2 verfügbar. Wenn Sie dieses Betriebssystem verwenden, können Sie das Paket installieren, indem Sie den folgenden Befehl eingeben. Sie müssen außerdem sicherstellen, dass der IAM-Rolle, die der Instance zugewiesen ist, die **CloudWatchAgentServerPolicy**angehängt ist.
```
sudo yum install amazon-cloudwatch-agent
```
Auf allen unterstützten Betriebssystemen können Sie den CloudWatch Agenten über die Befehlszeile herunterladen und installieren.
Für jeden Download-Link gibt es einen allgemeinen Link sowie Links für jede AWS Region.
Wenn Sie die regionsspezifischen Links verwenden, ersetzen Sie die Standardregion (*us-east-1*) durch die entsprechende Region für Ihr Konto. Beispiel: Für Amazon Linux 2023 and Amazon Linux 2 sowie die x86-64-Architektur sind drei der gültigen Download-Links:
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
+ `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
+ `https://amazoncloudwatch-agent-eu-central-1.s3.eu-central-1.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
Sie können auch eine README-Datei über die neuesten Änderungen am Agenten sowie eine Datei mit der Versionsnummer herunterladen, die zum Download verfügbar ist. Diese Dateien befinden sich an den folgenden Speicherorten:
**Anmerkung**
Wenn Sie die regionsspezifischen Links verwenden, ersetzen Sie die Standardregion (*us-east-1*) durch die entsprechende Region für Ihr Konto.
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/info/latest/RELEASE_NOTES` oder `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/info/latest/RELEASE_NOTES`
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/info/latest/CWAGENT_VERSION` oder `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/info/latest/CWAGENT_VERSION`
| Architektur | Plattform | Download-Link | Link zur Signaturdatei |
| --- | --- | --- | --- |
| x86-64 | Amazon Linux 2023 und Amazon Linux 2 | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/amd64/latest/ .rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Centos | https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/neueste/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/centos/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/centos/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Redhat | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/neueste/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | SUSE | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/amd64/neueste/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/suse/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/suse/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Debian | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/neuest/.deb amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/debian/amd64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/neuest/ .deb.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/debian/amd64/latest/amazon-cloudwatch-agent.deb.sig |
| x86-64 | Ubuntu | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/neueste/.deb amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/neuest/ .deb.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb.sig |
| x86-64 | Oracle | https://amazoncloudwatch-agent.s3.amazonaws.com/oracle\$1linux/amd64/neueste/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/oracle\$1linux/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | macOS | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/neueste/.pkg amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/neuest/ .pkg.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg.sig |
| x86-64 | Windows | https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/neueste/.msi amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/windows/amd64/latest/amazon-cloudwatch-agent.msi | https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/neuest/ .msi.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/windows/amd64/latest/amazon-cloudwatch-agent.msi.sig |
| ARM64 | Amazon Linux 2023 und Amazon Linux 2 | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/arm64/neuest/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/arm64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | Redhat | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/arm64/neuest/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/arm64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | Ubuntu | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/arm64/neuest/.deb amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/arm64/neuest/ .deb.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb.sig |
| ARM64 | Debian | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/arm64/neueste/.deb amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/debian/arm64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/arm64/neuest/ .deb.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/debian/arm64/latest/amazon-cloudwatch-agent.deb.sig |
| ARM64 | SUSE | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/arm64/neuest/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/suse/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/arm64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/suse/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | MacOS | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/arm64/neuest/.pkg amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/arm64/neuest/ .pkg.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg.sig |
# Überprüfung der Signatur des Agentenpakets CloudWatch
GPG-Signaturdateien sind für CloudWatch Agentenpakete auf Linux-Servern enthalten. Sie können einen öffentlichen Schlüssel verwenden, um sicherzustellen, dass die Download-Datei des Agenten original und unverändert ist.
Für Windows Server können Sie den MSI verwenden, um die Signatur zu überprüfen. Bei macOS-Computern ist die Signatur im Agenten-Download-Paket enthalten.
Die richtige Signaturdatei finden Sie in der folgenden Tabelle. Für jede Architektur und jedes Betriebssystem gibt es einen allgemeinen Link sowie Links für jede Region.
Wenn Sie die regionsspezifischen Links verwenden, ersetzen Sie die Standardregion (*us-east-1*) durch die entsprechende Region für Ihr Konto. Beispiel: Für Amazon Linux 2023 und Amazon Linux 2 sowie die x86-64-Architektur sind drei der gültigen Links:
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig`
+ `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
+ `https://amazoncloudwatch-agent-eu-central-1.s3.eu-central-1.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
**Anmerkung**
Um den CloudWatch Agenten herunterzuladen, muss Ihre Verbindung TLS 1.2 oder höher verwenden.
| Architektur | Plattform | Download-Link | Link zur Signaturdatei |
| --- | --- | --- | --- |
| x86-64 | Amazon Linux 2023 und Amazon Linux 2 | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/amd64/latest/ .rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Centos | https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/neueste/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/centos/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/centos/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Redhat | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/neueste/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | SUSE | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/amd64/neueste/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/suse/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/suse/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Debian | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/neuest/.deb amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/debian/amd64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/neuest/ .deb.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/debian/amd64/latest/amazon-cloudwatch-agent.deb.sig |
| x86-64 | Ubuntu | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/neueste/.deb amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/neuest/ .deb.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb.sig |
| x86-64 | Oracle | https://amazoncloudwatch-agent.s3.amazonaws.com/oracle\$1linux/amd64/neueste/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/oracle\$1linux/amd64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | macOS | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/neueste/.pkg amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/neuest/ .pkg.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg.sig |
| x86-64 | Windows | https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/neueste/.msi amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/windows/amd64/latest/amazon-cloudwatch-agent.msi | https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/neuest/ .msi.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/windows/amd64/latest/amazon-cloudwatch-agent.msi.sig |
| ARM64 | Amazon Linux 2023 und Amazon Linux 2 | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/arm64/neuest/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/arm64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | Redhat | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/arm64/neuest/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/arm64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | Ubuntu | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/arm64/neuest/.deb amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/arm64/neuest/ .deb.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb.sig |
| ARM64 | Debian | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/arm64/neueste/.deb amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/debian/arm64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/arm64/neuest/ .deb.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/debian/arm64/latest/amazon-cloudwatch-agent.deb.sig |
| ARM64 | SUSE | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/arm64/neuest/.rpm amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/suse/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/arm64/neuest/ .rpm.sig amazon-cloudwatch-agent https://amazoncloudwatch-agent - .s3. *us-east-1* *us-east-1*.amazon.aws. com/suse/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
**Um das Agentenpaket auf einem Linux-Server zu verifizieren CloudWatch**
1. Laden Sie den öffentlichen Schlüssel herunter.
```
shell$ wget https://amazoncloudwatch-agent.s3.amazonaws.com/assets/amazon-cloudwatch-agent.gpg
```
1. Importieren Sie den öffentlichen Schlüssel in Ihren Schlüsselbund.
```
shell$ gpg --import amazon-cloudwatch-agent.gpg
gpg: key 3B789C72: public key "Amazon CloudWatch Agent" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
Notieren Sie sich den Schlüsselwert. Sie brauchen ihn im nächsten Schritt. Im vorangegangenen Beispiel ist der Schlüsselwert `3B789C72`.
1. Überprüfen Sie den Fingerabdruck, indem Sie den folgenden Befehl ausführen und *key-value* ihn durch den Wert aus dem vorherigen Schritt ersetzen:
```
shell$ gpg --fingerprint key-value
pub 2048R/3B789C72 2017-11-14
Key fingerprint = 9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
uid Amazon CloudWatch Agent
```
Die Fingerabdruck-Zeichenfolge muss der folgenden entsprechen:
`9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72`
Wenn die Fingerabdruck-Zeichenfolge nicht übereinstimmt, installieren Sie den Agent nicht. Wenden Sie sich an Amazon Web Services.
Nachdem Sie den Fingerabdruck verifiziert haben, können Sie ihn verwenden, um die Signatur des CloudWatch -Agenten-Pakets zu verifizieren.
1. Laden Sie die Paket-Signaturdatei mittels **wget** herunter. Um die richtige Signaturdatei zu bestimmen, lesen Sie die vorherige Tabelle.
```
wget Signature File Link
```
1. Führen Sie **gpg --verify** aus, um die Signatur zu überprüfen.
```
shell$ gpg --verify signature-filename agent-download-filename
gpg: Signature made Wed 29 Nov 2017 03:00:59 PM PST using RSA key ID 3B789C72
gpg: Good signature from "Amazon CloudWatch Agent"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
```
Wenn die Ausgabe die Bezeichnung `BAD signature`enthält, überprüfen Sie, ob Sie das Verfahren korrekt durchgeführt haben. Wenn Sie diese Antwort weiterhin erhalten, wenden Sie sich bitte an Amazon Web Services und vermeiden Sie die Verwendung der heruntergeladenen Datei.
Beachten Sie die Warnung zu vertrauenswürdigen Inhalten. Beachten Sie die Warnung zu vertrauenswürdigen Inhalten. Das bedeutet nicht, dass die Signatur ungültig ist, sondern nur, dass Sie den öffentlichen Schlüssel nicht überprüft haben.
**Um das CloudWatch Agentenpaket auf einem Server zu überprüfen, auf dem Windows Server ausgeführt wird**
1. Laden Sie GnuPG für Windows unter [https://gnupg.org/download/](https://gnupg.org/download/) herunter und installieren Sie es. Fügen Sie bei der Installation die Option **Shell Extension (GpgEx)** hinzu.
Sie können die verbleibenden Schritte in Windows ausführen PowerShell.
1. Laden Sie den öffentlichen Schlüssel herunter.
```
PS> wget https://amazoncloudwatch-agent.s3.amazonaws.com/assets/amazon-cloudwatch-agent.gpg -OutFile amazon-cloudwatch-agent.gpg
```
1. Importieren Sie den öffentlichen Schlüssel in Ihren Schlüsselbund.
```
PS> gpg --import amazon-cloudwatch-agent.gpg
gpg: key 3B789C72: public key "Amazon CloudWatch Agent" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
Notieren Sie sich den Schlüsselwert. Sie benötigen ihn im nächsten Schritt. Im vorangegangenen Beispiel ist der Schlüsselwert `3B789C72`.
1. Überprüfen Sie den Fingerabdruck, indem Sie den folgenden Befehl ausführen und *key-value* ihn durch den Wert aus dem vorherigen Schritt ersetzen:
```
PS> gpg --fingerprint key-value
pub rsa2048 2017-11-14 [SC]
9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
uid [ unknown] Amazon CloudWatch Agent
```
Die Fingerabdruck-Zeichenfolge muss der folgenden entsprechen:
`9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72`
Wenn die Fingerabdruck-Zeichenfolge nicht übereinstimmt, installieren Sie den Agent nicht. Wenden Sie sich an Amazon Web Services.
Nachdem Sie den Fingerabdruck verifiziert haben, können Sie ihn verwenden, um die Signatur des CloudWatch -Agenten-Pakets zu verifizieren.
1. Laden Sie die Paket-Signaturdatei mit wget herunter. Informationen zum Bestimmen der richtigen Signaturdatei finden Sie unter [CloudWatch -Agent-Download-Links](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md#agent-download-link-table).
1. Führen Sie **gpg --verify** aus, um die Signatur zu überprüfen.
```
PS> gpg --verify sig-filename agent-download-filename
gpg: Signature made 11/29/17 23:00:45 Coordinated Universal Time
gpg: using RSA key D58167303B789C72
gpg: Good signature from "Amazon CloudWatch Agent" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
```
Wenn die Ausgabe die Bezeichnung `BAD signature`enthält, überprüfen Sie, ob Sie das Verfahren korrekt durchgeführt haben. Wenn Sie diese Antwort weiterhin erhalten, wenden Sie sich bitte an Amazon Web Services und vermeiden Sie die Verwendung der heruntergeladenen Datei.
Beachten Sie die Warnung zu vertrauenswürdigen Inhalten. Beachten Sie die Warnung zu vertrauenswürdigen Inhalten. Das bedeutet nicht, dass die Signatur ungültig ist, sondern nur, dass Sie den öffentlichen Schlüssel nicht überprüft haben.
**So verifizieren Sie das CloudWatch Agentenpaket auf einem macOS-Computer**
+ Es gibt zwei Methoden zur Signaturenverifizierung unter macOS.
+ Überprüfen Sie den Fingerabdruck, indem Sie den folgenden Befehl ausführen.
```
pkgutil --check-signature amazon-cloudwatch-agent.pkg
```
Das Ergebnis sollte in etwa wie folgt aussehen.
```
Package "amazon-cloudwatch-agent.pkg":
Status: signed by a developer certificate issued by Apple for distribution
Signed with a trusted timestamp on: 2020-10-02 18:13:24 +0000
Certificate Chain:
1. Developer ID Installer: AMZN Mobile LLC (94KV3E626L)
Expires: 2024-10-18 22:31:30 +0000
SHA256 Fingerprint:
81 B4 6F AF 1C CA E1 E8 3C 6F FB 9E 52 5E 84 02 6E 7F 17 21 8E FB
0C 40 79 13 66 8D 9F 1F 10 1C
------------------------------------------------------------------------
2. Developer ID Certification Authority
Expires: 2027-02-01 22:12:15 +0000
SHA256 Fingerprint:
7A FC 9D 01 A6 2F 03 A2 DE 96 37 93 6D 4A FE 68 09 0D 2D E1 8D 03
F2 9C 88 CF B0 B1 BA 63 58 7F
------------------------------------------------------------------------
3. Apple Root CA
Expires: 2035-02-09 21:40:36 +0000
SHA256 Fingerprint:
B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED 7E 2C
68 C5 BE 91 B5 A1 10 01 F0 24
```
+ Oder laden Sie die SIG-Datei herunter und verwenden Sie sie. Gehen Sie folgendermaßen vor, um diese Methode zu verwenden.
1. Installieren Sie die GPG-Anwendung auf Ihrem macOS-Host, indem Sie den folgenden Befehl eingeben.
```
brew install GnuPG
```
+ Laden Sie die Paket-Signaturdatei mittels Curl herunter. Informationen zum Bestimmen der richtigen Signaturdatei finden Sie unter [CloudWatch -Agent-Download-Links](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md#agent-download-link-table).
+ Führen Sie **gpg --verify** aus, um die Signatur zu überprüfen.
```
PS> gpg --verify sig-filename agent-download-filename
gpg: Signature made 11/29/17 23:00:45 Coordinated Universal Time
gpg: using RSA key D58167303B789C72
gpg: Good signature from "Amazon CloudWatch Agent" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
```
Wenn die Ausgabe die Bezeichnung `BAD signature`enthält, überprüfen Sie, ob Sie das Verfahren korrekt durchgeführt haben. Wenn Sie diese Antwort weiterhin erhalten, wenden Sie sich bitte an Amazon Web Services und vermeiden Sie die Verwendung der heruntergeladenen Datei.
Beachten Sie die Warnung zu vertrauenswürdigen Inhalten. Beachten Sie die Warnung zu vertrauenswürdigen Inhalten. Das bedeutet nicht, dass die Signatur ungültig ist, sondern nur, dass Sie den öffentlichen Schlüssel nicht überprüft haben.
# Den CloudWatch Agenten installieren
Sie können den CloudWatch Agenten auf Ihren Amazon EC2 EC2-Instances, lokalen Servern und in containerisierten Umgebungen installieren, um Metriken, Protokolle und Traces zu sammeln. Der Agent unterstützt die Betriebssysteme Linux, Windows und macOS. Es gibt mehrere Möglichkeiten, den Agenten zu installieren, z. B. mithilfe von Systems Manager, von der CloudWatch Konsole aus, von der Befehlszeile aus oder mithilfe einer Konfigurationsdatei. Vor der Installation stellen Sie bitte sicher, dass Sie die erforderlichen IAM-Berechtigungen und den Netzwerkzugriff konfiguriert haben.
**Topics**
+ [Installieren und konfigurieren Sie Amazon CloudWatch Agent with Workload Detection in der CloudWatch Konsole](install-cloudwatch-agent-workload-detection.md)
+ [Manuelle Installation auf Amazon EC2](manual-installation.md)
+ [Installieren Sie den CloudWatch Agenten mit AWS Systems Manager](installing-cloudwatch-agent-ssm.md)
+ [Installieren Sie den CloudWatch Agenten auf lokalen Servern](install-CloudWatch-Agent-on-premise.md)
+ [Installieren Sie den CloudWatch Agenten auf neuen Instanzen mit CloudFormation](Install-CloudWatch-Agent-New-Instances-CloudFormation.md)
+ [Installieren Sie den CloudWatch Agenten mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm](install-CloudWatch-Observability-EKS-addon.md)
# Installieren und konfigurieren Sie Amazon CloudWatch Agent with Workload Detection in der CloudWatch Konsole
## Einführung
Sie können die CloudWatch Getting Started-Konsole verwenden, um den CloudWatch Agenten auf Amazon EC2 EC2-Instances zu installieren und zu konfigurieren. Der CloudWatch Amazon-Agent ist eine einfache Softwarekomponente, die Metriken, Protokolle und Traces auf Systemebene von Ihren Amazon EC2-Instances sammelt. Durch die Automatisierung der Erfassung und Übermittlung von Überwachungsdaten ermöglicht Ihnen der Agent CloudWatch, umsetzbare Erkenntnisse zu gewinnen, die Ressourcennutzung zu optimieren und sicherzustellen, dass Ihre Anwendungen mit minimalem Konfigurationsaufwand reibungslos funktionieren.
Konfigurieren Sie den CloudWatch Agenten mit vordefinierten, workload-spezifischen Konfigurationen, die die automatische Workload-Erkennung nutzen, um laufende Anwendungen und Dienste auf Ihren Instanzen zu identifizieren. Sie können die Datenerfassung mit spezifischen Metriken, Protokollen und Traces individuell anpassen, sodass Sie die Anwendungsleistung überwachen und Probleme effektiv beheben können.
## Funktionsweise
Der CloudWatch Agent erkennt Workloads, die auf Ihren Amazon EC2 EC2-Instances ausgeführt werden, mithilfe automatischer Funktionen zur Workload-Erkennung. Diese Funktion identifiziert laufende Anwendungen und Dienste auf Ihren Instances und ermöglicht so eine intelligente Überwachung ohne manuelle Konfiguration.
Observability-Lösungen bieten vordefinierte, workload-spezifische Konfigurationen, die auf gängige Anwendungen wie Apache Kafka, Apache Tomcat, Java Virtual Machines (JVM), NGINX und NVIDIA GPU-Workloads zugeschnitten sind. Diese Lösungen optimieren die Einrichtung der Überwachung, indem sie automatisch die richtigen Metriken, Protokolle und Traces für jeden erkannten Workload sammeln, sodass keine manuelle Instrumentierung und Konfiguration erforderlich ist.
Wenn die Workload-Erkennung aktiviert ist, analysiert der Agent Ihre Instanzumgebung und wählt automatisch relevante vorkonfigurierte Überwachungsvorlagen aus. Diese Konfigurationen werden von AWS Fachexperten so optimiert, dass sie die wichtigsten Telemetriedaten für jeden Workload-Typ erfassen, sodass Sie von Anfang an eine umfassende Beobachtbarkeit haben.
## Voraussetzungen
### Installation des SSM-Agenten (erforderlich)
Auf Ihren Amazon EC2 EC2-Instances muss der AWS Systems Manager (SSM) -Agent installiert sein. [Der SSM-Agent ist auf den meisten AWS mitgelieferten Amazon Machine Images (AMIs) vorinstalliert. Wenn Sie den SSM-Agenten manuell installieren oder aktualisieren müssen, lesen Sie in der Systems Manager Manager-Dokumentation nach.](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)
**Anmerkung**
Die Standard-Host-Management-Konfiguration (DHMC) ist eine Systems Manager-Funktion, die Amazon EC2 EC2-Instances automatisch die Erlaubnis erteilt, sich mit Systems Manager zu verbinden, ohne dass Sie jeder Instance manuell ein IAM-Instance-Profil zuordnen müssen. Wenn Ihre Amazon EC2 EC2-Instances DHMC verwenden und der CloudWatch Agenteninstallationsprozess die CloudWatch Richtlinie an Ihre Instances anhängt, kann es bis zu 30 Minuten dauern, bis die neue Richtlinie wirksam wird. Durch diese Verzögerung kann sich die Veröffentlichung von Metriken, Protokollen und Traces für verzögern. CloudWatch [Um dies zu verhindern, können Sie Ihre Amazon EC2 EC2-Instances mit einer IAM-Rolle erstellen, die die Amazon-Richtlinie enthält. SSMManaged InstanceCore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html)
### Erkennung von Arbeitslasten (empfohlen)
Die Workload-Erkennung ist eine optionale Funktion, mit der automatisch laufende Anwendungen und Dienste auf Ihren Instances identifiziert werden. Wir empfehlen, die Workload-Erkennung zu aktivieren, um die Vorteile vorkonfigurierter, workload-spezifischer Überwachungsvorlagen nutzen zu können. [Sie können die Workload-Erkennung in den CloudWatch Konsoleneinstellungen aktivieren.](https://console.aws.amazon.com/cloudwatch/home#settings)
## Erste Schritte
Öffnen Sie die CloudWatch Agentenseite Getting Started with Amazon in der CloudWatch Amazon-Konsole: [https://console.aws.amazon.com/cloudwatch/home \$1cloudwatch -agent](https://console.aws.amazon.com/cloudwatch/home#cloudwatch-agent)
**Manuelle Instanzbereitstellung für Agent CloudWatch **
Wählen Sie manuell bis zu 50 Instanzen für die Installation und Konfiguration CloudWatch des Agenten aus. Dieser gezielte Ansatz ermöglicht es Ihnen, die Überwachung für bestimmte Amazon EC2 EC2-Instances zu verbessern.
**Tag-basierte Bereitstellung für Agent CloudWatch **
Verwenden Sie die Tag-basierte Bereitstellung, um den CloudWatch Agenten auf Flotten von Amazon EC2 EC2-Instances zu installieren und zu konfigurieren. Diese Methode gilt für alle aktuellen und future Instanzen mit passenden Tags.
**Tag-basierte Konfiguration**
Tag-basierte Konfigurationen ermöglichen es Ihnen, Konfigurationen effizient zu organisieren, anzuzeigen und zu ändern, sodass Sie den CloudWatch Agenten und seine Konfiguration für Flotten von Amazon EC2 EC2-Instances verwalten können.
**CloudWatch Installation des Agenten**
Installieren Sie den CloudWatch Agenten, um Metriken, Protokolle und Traces von Amazon EC2 EC2-Instances und lokalen Hosts zu sammeln. Diese Telemetrie liefert wichtige Integritäts- und Leistungsdaten über Ihre Infrastruktur und Anwendungen.
**CloudWatch Agentenkonfiguration**
Konfigurieren Sie den CloudWatch Agenten mit vordefinierten, workload-spezifischen Konfigurationen. Sie können die Datenerfassung mit spezifischen Metriken, Protokollen und Traces individuell anpassen, sodass Sie die Anwendungsleistung überwachen und Probleme effektiv beheben können.
## Kosten
Zusätzliche Metriken, die Sie während dieses Vorgangs hinzufügen, werden als benutzerdefinierte Metriken abgerechnet. Weitere Informationen zu den Preisen von CloudWatch Metriken finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing).
# Manuelle Installation auf Amazon EC2
**Anmerkung**
Stellen Sie sicher, dass die Voraussetzungen erfüllt sind, bevor Sie den CloudWatch Agenten zum ersten Mal installieren.
**Topics**
+ [Installation mithilfe des Paketmanagers auf Amazon Linux](#amazon-linux-package)
+ [Installation unter Amazon Linux über die Befehlszeile](#linux-manual-install)
+ [Installation unter Windows](#windows-installation)
+ [Installieren unter macOS](#macos-installation)
## Installation mithilfe des Paketmanagers auf Amazon Linux
Der CloudWatch Agent ist als Paket in Amazon Linux 2023 und Amazon Linux 2 verfügbar. Wenn Sie eines dieser Betriebssysteme verwenden, können Sie das Paket installieren, indem Sie den folgenden Befehl eingeben:
```
sudo yum install amazon-cloudwatch-agent
```
Sie müssen außerdem sicherstellen, dass der IAM-Rolle, die der Instance zugewiesen ist, die **CloudWatchAgentServerPolicy**angehängt ist.
## Installation unter Amazon Linux über die Befehlszeile
Auf allen unterstützten Linux-Betriebssystemen können Sie den CloudWatch Agenten über die Befehlszeile herunterladen und installieren.
1. Laden Sie den CloudWatch Agenten herunter. Geben Sie auf einem Linux-Server folgenden Befehl ein. Verwenden Sie für `download-link` den entsprechenden Download-Link aus der folgenden Tabelle.
```
wget download-link
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/manual-installation.html)
1. Nachdem Sie das Paket heruntergeladen haben, können Sie optional die Paketsignatur überprüfen. Weitere Informationen finden Sie unter [Überprüfung der Signatur des Agentenpakets CloudWatch](verify-CloudWatch-Agent-Package-Signature.md).
1. Installieren Sie das Paket . Wenn Sie ein RPM-Paket auf einen Linux-Server heruntergeladen haben, wechseln Sie in das Verzeichnis, das das Paket enthält, und geben Sie Folgendes ein:
```
sudo rpm -U ./amazon-cloudwatch-agent.rpm
```
Wenn Sie ein DEB-Paket auf einen Linux-Server heruntergeladen haben, wechseln Sie in das Verzeichnis, das das Paket enthält, und geben Sie Folgendes ein:
```
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb
```
## Installation unter Windows
Auf Windows Server können Sie den Agenten über die Befehlszeile herunterladen und installieren. CloudWatch
1. Laden Sie die folgende Datei herunter:
```
https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi
```
1. Nachdem Sie das Paket heruntergeladen haben, können Sie optional die Paketsignatur überprüfen. Weitere Informationen finden Sie unter [Überprüfung der Signatur des Agentenpakets CloudWatch](verify-CloudWatch-Agent-Package-Signature.md).
1. Installieren Sie das Paket . Wechseln Sie in das Verzeichnis, das das Paket enthält, und geben Sie Folgendes ein:
```
msiexec /i amazon-cloudwatch-agent.msi
```
Dieser Befehl funktioniert auch von innen heraus PowerShell. Weitere Informationen zu den MSI-Befehlsoptionen finden Sie unter [Command-Line Options](https://docs.microsoft.com/en-us/windows/desktop/Msi/command-line-options) in der Microsoft Windows-Dokumentation.
## Installieren unter macOS
Auf macOS-Computern können Sie den CloudWatch Agenten über die Befehlszeile herunterladen und installieren.
1. Laden Sie das entsprechende Paket für Ihre Architektur herunter:
```
https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg
```
Für die ARM64 Architektur:
```
https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg
```
1. Nachdem Sie das Paket heruntergeladen haben, können Sie optional die Paketsignatur überprüfen. Weitere Informationen finden Sie unter [Überprüfung der Signatur des Agentenpakets CloudWatch](verify-CloudWatch-Agent-Package-Signature.md).
1. Installieren Sie das Paket . Wechseln Sie in das Verzeichnis, das das Paket enthält, und geben Sie Folgendes ein:
```
sudo installer -pkg ./amazon-cloudwatch-agent.pkg -target /
```
# Installieren Sie den CloudWatch Agenten mit AWS Systems Manager
Die Verwendung AWS Systems Manager erleichtert die Installation des CloudWatch Agenten auf einer Flotte von Amazon EC2 EC2-Instances. Sie können den Agenten auf einen Server herunterladen und Ihre CloudWatch Agenten-Konfigurationsdatei für alle Server in der Flotte erstellen. Anschließend können Sie Systems Manager verwenden, um den Agenten auf den anderen Servern zu installieren. Verwenden Sie dazu die Konfigurationsdatei, die Sie erstellt haben. Verwenden Sie die folgenden Themen, um den CloudWatch Agenten mit zu installieren und auszuführen AWS Systems Manager.
**Topics**
+ [Installieren oder Aktualisieren des SSM-Agenten.](#update-SSM-Agent-EC2instance-first)
+ [Überprüfen der Voraussetzungen für Systems Manager](#install-CloudWatch-Agent-minimum-requirements-first)
+ [Überprüfen des Internetzugangs](#install-CloudWatch-Agent-internet-access-first)
+ [Laden Sie das CloudWatch Agentenpaket auf Ihre erste Instanz herunter](#install-CloudWatch-Agent-EC2-first)
+ [Erstellen und Ändern der Agentenkonfigurationsdatei](#CW-Agent-Instance-Create-Configuration-File-first)
+ [Installieren und starten Sie den CloudWatch Agenten mithilfe Ihrer Agentenkonfiguration auf weiteren EC2-Instances](#install-CloudWatch-Agent-on-EC2-Instance-fleet)
+ [Installieren Sie den CloudWatch Agenten mithilfe Ihrer Agentenkonfiguration auf weiteren EC2-Instances](#install-CloudWatch-Agent-on-EC2-Instance-fleet)
+ [(Optional) Ändern Sie die allgemeine Konfiguration und das benannte Profil für den CloudWatch Agenten](#CloudWatch-Agent-profile-instance-fleet)
## Installieren oder Aktualisieren des SSM-Agenten.
Auf einer Amazon EC2 EC2-Instance erfordert der CloudWatch Agent, dass auf der Instance Version 2.2.93.0 oder höher des SSM-Agenten ausgeführt wird. Bevor Sie den CloudWatch Agenten installieren, aktualisieren oder installieren Sie den SSM-Agent auf der Instance, falls Sie dies noch nicht getan haben.
Informationen über das Installieren oder Aktualisieren des SSM Agent auf einer Instance, auf der Linux ausgeführt wird, finden Sie unter [Installieren und Konfigurieren von SSM Agent auf Linux-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) im *AWS Systems Manager -Benutzerhandbuch*.
Informationen über das Installieren oder Aktualisieren des SSM Agenten finden Sie unter [Installieren und Konfigurieren des SSM-Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) im *AWS Systems Manager -Benutzerhandbuch*.
## Überprüfen der Voraussetzungen für Systems Manager
Bevor Sie Systems Manager Run Command zur Installation und Konfiguration des CloudWatch Agenten verwenden, stellen Sie sicher, dass Ihre Instances die Mindestanforderungen von Systems Manager erfüllen. Weitere Informationen finden Sie unter [Voraussetzungen für Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up.html#systems-manager-prereqs) im *AWS Systems Manager -Benutzerhandbuch*.
## Überprüfen des Internetzugangs
Ihre Amazon EC2 EC2-Instances müssen in der Lage sein, eine Verbindung zu CloudWatch Endpunkten herzustellen. Dies kann über Internet Gateway-, NAT-Gateway- oder CloudWatch Interface-VPC-Endpunkte erfolgen. Weitere Informationen dazu, wie Sie den Internetzugang konfigurieren, finden Sie unter [Internet-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) im *Benutzerhandbuch zu Amazon VPC*.
Folgende auf Ihrem Proxy zu konfigurierende Endpunkte und Ports sind möglich:
+ Wenn Sie den Agenten zum Sammeln von Metriken verwenden, müssen Sie zulassen, dass Sie die CloudWatch Endpunkte für die entsprechenden Regionen auflisten. Diese Endpunkte sind [bei Amazon CloudWatch](https://docs.aws.amazon.com/general/latest/gr/rande.html#cw_region) in der *Allgemeine Amazon Web Services-Referenz*aufgeführt.
+ Wenn Sie den Agenten zum Sammeln von Protokollen verwenden, müssen Sie die Liste der CloudWatch Logs-Endpunkte für die entsprechenden Regionen zulassen. Diese Endpunkte sind in [Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/rande.html#cwl_region) im *Allgemeine Amazon Web Services-Referenz*aufgeführt.
+ Wenn Sie den Agenten mit Systems Manager installieren oder die Konfigurationsdatei mit Parameter Store speichern, müssen Sie die Systems-Manager-Endpunkte für die entsprechenden Regionen der Zulassungsliste hinzufügen. Diese Endpunkte sind unter [AWS -Systems Manager](https://docs.aws.amazon.com/general/latest/gr/rande.html#ssm_region) im *Allgemeine Amazon Web Services-Referenz* aufgeführt.
## Laden Sie das CloudWatch Agentenpaket auf Ihre erste Instanz herunter
Gehen Sie wie folgt vor, um das CloudWatch Agentenpaket mit Systems Manager herunterzuladen.
**So laden Sie den CloudWatch Agenten mit Systems Manager herunter**
1. Öffnen Sie die Systems Manager Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
–oder–
Wenn die AWS Systems Manager Startseite geöffnet wird, scrollen Sie nach unten und wählen Sie **Explore Run Command**.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste der **Befehlsdokumente** die Option **AWSPackageAWS-Configure** aus.
1. Wählen Sie im Bereich **Targets (Ziele)** die Instance, auf der der CloudWatch-Agent installiert werden soll. Wenn Sie eine bestimmte Instance nicht sehen, ist sie möglicherweise nicht als verwaltete Instance für die Verwendung mit Systems Manager konfiguriert. Weitere Informationen finden Sie im *AWS Systems Manager Benutzerhandbuch* unter [Einrichtung AWS Systems Manager für Hybridumgebungen](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html).
1. Klicken Sie in der Liste **Action** auf **Install**.
1. Geben Sie im Feld **Name** *AmazonCloudWatchAgent* ein.
1. Lassen Sie **Version** auf **latest (aktuell)** eingestellt, damit die neueste Version des Agenten installiert wird.
1. Klicken Sie auf **Ausführen**.
1. Wählen Sie optional in den Bereichen **Targets and outputs** (Ziele und Ausgaben) die Schaltfläche neben einem Instance-Namen aus und wählen Sie **View output** (Ausgabe anzeigen) aus. Systems Manager zeigt jetzt an, dass der Agent erfolgreich installiert wurde.
## Erstellen und Ändern der Agentenkonfigurationsdatei
Nachdem Sie den CloudWatch Agenten heruntergeladen haben, müssen Sie die Konfigurationsdatei erstellen, bevor Sie den Agenten auf beliebigen Servern starten.
Wenn Sie die Agentenkonfigurationsdatei in Systems Manager Parameter Store speichern, müssen Sie eine EC2-Instance zum Speichern in Parameter Store verwenden. Darüber hinaus müssen Sie dieser Instance zunächst die IAM-Rolle `CloudWatchAgentAdminRole` anfügen. Weitere Informationen zum Anhängen von Rollen finden Sie unter [Anhängen einer IAM-Rolle an eine Instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) im *Amazon-EC2-Benutzerhandbuch*.
Weitere Informationen zum Erstellen der CloudWatch Agent-Konfigurationsdatei finden Sie unter[Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md).
## Installieren und starten Sie den CloudWatch Agenten mithilfe Ihrer Agentenkonfiguration auf weiteren EC2-Instances
Nachdem Sie eine CloudWatch Agentenkonfiguration im Parameter Store gespeichert haben, können Sie sie verwenden, wenn Sie den Agenten auf anderen Servern installieren.
Führen Sie für jeden dieser Server die zuvor in diesem Abschnitt aufgeführten Schritte aus, um die Systems Manager-Voraussetzungen, die Version des SSM-Agenten und den Internetzugang zu überprüfen. Verwenden Sie dann die folgenden Anweisungen, um den CloudWatch Agenten mithilfe der von Ihnen erstellten CloudWatch Agenten-Konfigurationsdatei auf den zusätzlichen Instanzen zu installieren.
**Schritt 1: Laden Sie den CloudWatch Agenten herunter und installieren Sie ihn**
Um die CloudWatch Daten in eine andere Region senden zu können, stellen Sie sicher, dass die IAM-Rolle, die Sie dieser Instanz zugewiesen haben, berechtigt ist, die CloudWatch Daten in dieser Region zu schreiben.
Im Folgenden finden Sie ein Beispiel für die Verwendung des `aws configure` Befehls zum Erstellen eines benannten Profils für den CloudWatch Agenten. Bei diesem Beispiel wird davon ausgegangen, dass Sie den Standardprofilnamen von `AmazonCloudWatchAgent` verwenden.
**Um das AmazonCloudWatchAgent Profil für den CloudWatch Agenten zu erstellen**
+ Geben Sie auf Linux-Servern den folgenden Befehl ein und befolgen Sie die Anweisungen:
```
sudo aws configure --profile AmazonCloudWatchAgent
```
Öffnen Sie Windows Server PowerShell als Administrator, geben Sie den folgenden Befehl ein und folgen Sie den Anweisungen.
```
aws configure --profile AmazonCloudWatchAgent
```
## Installieren Sie den CloudWatch Agenten mithilfe Ihrer Agentenkonfiguration auf weiteren EC2-Instances
Nachdem Sie eine CloudWatch Agentenkonfiguration im Parameter Store gespeichert haben, können Sie sie verwenden, wenn Sie den Agenten auf anderen Servern installieren.
Führen Sie für jeden dieser Server die zuvor in diesem Abschnitt aufgeführten Schritte aus, um die Systems Manager-Voraussetzungen, die Version des SSM-Agenten und den Internetzugang zu überprüfen. Verwenden Sie dann die folgenden Anweisungen, um den CloudWatch Agenten mithilfe der von Ihnen erstellten CloudWatch Agenten-Konfigurationsdatei auf den zusätzlichen Instanzen zu installieren.
**Schritt 1: Laden Sie den CloudWatch Agenten herunter und installieren Sie ihn**
Sie müssen den Agenten auf jedem Server installieren, auf dem Sie den Agenten ausführen. Der CloudWatch Agent ist als Paket in Amazon Linux 2023 und Amazon Linux 2 verfügbar. Wenn Sie dieses Betriebssystem verwenden, können Sie das Paket mit Systems Manager installieren, indem Sie die folgenden Schritte befolgen.
**Anmerkung**
Sie müssen außerdem sicherstellen, dass der IAM-Rolle, die der Instance zugewiesen ist, die **CloudWatchAgentServerPolicy**angehängt ist. Weitere Informationen finden Sie unter [Voraussetzungen](prerequisites.md).
**So verwenden Sie Systems Manager zur Installation des CloudWatch Agentenpakets**
1. Öffnen Sie die Systems Manager Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
–oder–
Wenn die AWS Systems Manager Startseite geöffnet wird, scrollen Sie nach unten und wählen Sie **Explore Run Command**.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste **Command-Dokument** die Option **AWS-** ausRunShellScript. Fügen Sie dann Folgendes in die **Befehlsparameter** ein.
```
sudo yum install amazon-cloudwatch-agent
```
1. Wählen Sie **Ausführen** aus
Auf allen unterstützten Betriebssystemen können Sie das CloudWatch Agentenpaket entweder über Systems Manager Run Command oder über einen Amazon S3 S3-Download-Link herunterladen.
**Anmerkung**
Wenn Sie den CloudWatch Agenten installieren oder aktualisieren, wird nur die Option **Deinstallieren und Neuinstallieren** unterstützt. Sie können die Option **In-place update** (Direkte Aktualisierung) nicht verwenden.
Systems Manager Run Command ermöglicht Ihnen die bedarfsgerechte Verwaltung der Konfiguration Ihrer Instances. Sie geben ein Systems-Manager-Dokument und Parameter an und führen Sie den Befehl auf einer oder mehreren Instances aus. Der SSM-Agent auf der Instance verarbeitet den Befehl und konfiguriert die Instance wie angegeben.
**Um den CloudWatch Agenten mit Run Command herunterzuladen**
1. Öffnen Sie die Systems Manager Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
–oder–
Wenn die AWS Systems Manager Startseite geöffnet wird, scrollen Sie nach unten und wählen Sie **Explore Run Command**.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste der **Befehlsdokumente** die Option **AWSPackageAWS-Configure** aus.
1. Wählen Sie im Bereich **Ziele** die Instanz aus, auf der der Agent installiert werden soll. CloudWatch Wenn Sie eine bestimmte Instance nicht sehen, ist sie möglicherweise nicht für Run Command konfiguriert. Weitere Informationen finden Sie im *AWS Systems Manager Benutzerhandbuch* unter [Einrichtung AWS Systems Manager von Hybridumgebungen](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html).
1. Klicken Sie in der Liste **Action** auf **Install**.
1. Geben Sie im Feld **Name (Name)** *AmazonCloudWatchAgent* ein.
1. Lassen Sie **Version** auf **latest (aktuell)** eingestellt, damit die neueste Version des Agenten installiert wird.
1. Klicken Sie auf **Ausführen**.
1. Wählen Sie optional in den Bereichen **Targets and outputs** (Ziele und Ausgaben) die Schaltfläche neben einem Instance-Namen aus und wählen Sie **View output** (Ausgabe anzeigen) aus. Systems Manager zeigt jetzt an, dass der Agent erfolgreich installiert wurde.
**Schritt 2: Starten Sie den CloudWatch Agenten mithilfe Ihrer Agenten-Konfigurationsdatei**
Führen Sie diese Schritte aus, um den Agenten mit dem Systems Manager Run Command zu starten.
Informationen zum Einrichten des Agenten auf einem System, auf dem das sicherheitserweiterte Linux (SELinux) aktiviert ist, finden Sie unter. [Richten Sie den CloudWatch Agenten mit Linux mit verbesserter Sicherheit ein () SELinux](CloudWatch-Agent-SELinux.md)
**So starten Sie den CloudWatch Agenten mit Run Command**
1. Öffnen Sie die Systems Manager Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
–oder–
Wenn die AWS Systems Manager Startseite geöffnet wird, scrollen Sie nach unten und wählen Sie **Explore Run Command**.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der **Command-Dokumentliste** die Option **AmazonCloudWatch- ManageAgent**.
1. Wählen Sie im Bereich **Ziele** die Instanz aus, auf der Sie den CloudWatch Agenten installiert haben.
1. Klicken Sie in der Liste **Action** auf **Configure**.
1. Klicken Sie in der Liste **Optional Configuration Source** auf **ssm**.
1. Geben Sie in das Feld **Optionaler Konfigurationsstandort** den Namen des Systems-Manager-Parameternamens der Agenten-Konfigurationsdatei ein, die Sie erstellt und im Systems-Manager-Parameter-Speicher gespeichert haben, wie in [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md) erläutert.
1. Klicken Sie in der Liste **Optional Restart** auf **yes**, um den Agent zu starten, nachdem Sie diese Schritte abgeschlossen haben.
1. Klicken Sie auf **Ausführen**.
1. Wählen Sie optional in den Bereichen **Targets and outputs** (Ziele und Ausgaben) die Schaltfläche neben einem Instance-Namen aus und wählen Sie **View output** (Ausgabe anzeigen) aus. Systems Manager zeigt jetzt an, dass der Agent erfolgreich gestartet wurde.
## (Optional) Ändern Sie die allgemeine Konfiguration und das benannte Profil für den CloudWatch Agenten
Der CloudWatch Agent enthält eine Konfigurationsdatei mit dem Namen`common-config.toml`. Sie können diese Datei verwenden, um optional Proxy- und Regionsinformationen anzugeben.
Auf einem Server, auf dem Linux ausgeführt wird, befindet sich diese Datei im Verzeichnis `/opt/aws/amazon-cloudwatch-agent/etc`. Auf einem Server, auf dem Windows Server ausgeführt wird, befindet sich diese Datei im Verzeichnis `C:\ProgramData\Amazon\AmazonCloudWatchAgent`.
`common-config.toml` lautet standardmäßig folgendermaßen:
```
# This common-config is used to configure items used for both ssm and cloudwatch access
## Configuration for shared credential.
## Default credential strategy will be used if it is absent here:
## Instance role is used for EC2 case by default.
## AmazonCloudWatchAgent profile is used for onPremise case by default.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
## Configuration for proxy.
## System-wide environment-variable will be read if it is absent here.
## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy
## Note: system-wide environment-variable is not accessible when using ssm run-command.
## Absent in both here and environment-variable means no proxy will be used.
# [proxy]
# http_proxy = "{http_url}"
# https_proxy = "{https_url}"
# no_proxy = "{domain}"
```
Alle Zeilen sind anfangs auskommentiert. Zum Festlegen des Anmeldeinformationsprofils oder der Proxy-Einstellungen entfernen Sie `#` aus der Zeile und geben einen Wert an. Sie können diese Datei manuell oder mithilfe von `RunShellScript` Run Command in Systems Manager: bearbeiten:
+ `shared_credential_profile`— Für lokale Server gibt diese Zeile das Profil mit den IAM-Benutzeranmeldeinformationen an, an das Daten gesendet werden sollen. CloudWatch Wenn diese Zeile auskommentiert bleibt, wird `AmazonCloudWatchAgent` verwendet.
Auf einer EC2-Instance können Sie diese Zeile verwenden, damit der CloudWatch Agent Daten von dieser Instance CloudWatch in eine andere Region sendet. AWS Geben Sie hierzu ein benanntes Profil an, das ein Feld `region` zur Angabe der Zielregion enthält.
Wenn Sie einen `shared_credential_profile` angeben, müssen Sie auch das `#` am Anfang der `[credentials]`-Zeile entfernen.
+ `shared_credential_file` – Damit der Agent in einer nicht im Standardpfad abgelegten Datei nach Anmeldeinformationen sucht, müssen Sie den vollständigen Pfad und den Dateinamen hier angeben. Der Standardpfad ist unter Linux `/root/.aws` und unter Windows Server `C:\\Users\\Administrator\\.aws`.
Das erste Beispiel unten zeigt die Syntax einer gültigen `shared_credential_file`-Zeile für Linux-Server, und das zweite Beispiel ist für Windows-Server gültig. Auf Windows Server müssen Sie die \$1-Zeichen mit einem Escape-Zeichen versehen.
```
shared_credential_file= "/usr/username/credentials"
```
```
shared_credential_file= "C:\\Documents and Settings\\username\\.aws\\credentials"
```
Wenn Sie einen `shared_credential_file` angeben, müssen Sie auch das `#` am Anfang der `[credentials]`-Zeile entfernen.
+ Proxy-Einstellungen – Falls Ihre Server HTTP- oder HTTPS-Proxys verwenden, um AWS -Services zu kontaktieren, geben Sie diese Proxys in den Feldern `http_proxy` und `https_proxy` an. Falls es URLs welche gibt, die vom Proxying ausgeschlossen werden sollen, geben Sie sie in das `no_proxy` Feld ein, getrennt durch Kommas.
# Installieren Sie den CloudWatch Agenten auf lokalen Servern
Wenn Sie den CloudWatch Agenten auf einen Computer heruntergeladen und Ihre Agenten-Konfigurationsdatei erstellt haben, können Sie diese Konfigurationsdatei verwenden, um den Agenten auf anderen lokalen Servern zu installieren.
## Laden Sie den CloudWatch Agenten auf einen lokalen Server herunter
Sie können das CloudWatch Agentenpaket entweder über Systems Manager Run Command oder über einen Amazon S3 S3-Download-Link herunterladen.
### Download mithilfe des Systems Manager
Um Systems Manager Run Command verwenden zu können, müssen Sie Ihren On-Premises-Server bei Amazon EC2 Systems Manager registrieren. Weitere Informationen erhalten Sie unter [Einrichten von Systems Manager in Hybridumgebungen](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) im *AWS Systems Manager -Benutzerhandbuch*.
Wenn Sie Ihren Server bereits registriert haben, aktualisieren Sie SSM Agent auf die neueste Version.
Weitere Informationen zum Aktualisieren von SSM Agent auf einem Server, auf dem Linux ausgeführt wird, finden Sie unter [Installieren von SSM Agent für eine Hybridumgebung (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html#sysman-install-managed-linux) im *AWS Systems Manager -Benutzerhandbuch*.
Weitere Informationen zum Aktualisieren von SSM Agent auf einem Server, auf dem Windows Server ausgeführt wird, finden Sie unter [Installieren von SSM Agent für eine Hybridumgebung (Windows)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html#sysman-install-managed-win) im *AWS Systems Manager -Benutzerhandbuch*.
**Um den SSM-Agenten zum Herunterladen des CloudWatch Agentenpakets auf einen lokalen Server zu verwenden**
1. Öffnen Sie die Systems Manager Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
–oder–
Wenn die AWS Systems Manager Startseite geöffnet wird, scrollen Sie nach unten und wählen Sie **Explore Run Command**.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste der **Befehlsdokumente** die Schaltfläche neben **AWSPackageAWS-Configure** aus.
1. Wählen Sie im Bereich **Targets (Ziele)** den Server aus, auf dem der CloudWatch-Agent installiert werden soll. Wenn Sie einen bestimmten Server nicht sehen, ist er möglicherweise nicht für Run Command konfiguriert. Weitere Informationen finden Sie im *AWS Systems Manager Benutzerhandbuch* unter [Einrichtung AWS Systems Manager für Hybridumgebungen](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html).
1. Klicken Sie in der Liste **Action** auf **Install**.
1. Geben Sie im Feld **Name (Name)** *AmazonCloudWatchAgent* ein.
1. Lassen Sie **Version** leer, damit die aktuelle Version des Agenten installiert wird.
1. Klicken Sie auf **Ausführen**.
Das Agent-Paket wird heruntergeladen und die nächsten Schritte sind die Konfiguration und der Start.
## (Installation auf einem lokalen Server) Geben Sie die IAM-Anmeldeinformationen und die Region an AWS
Damit der CloudWatch Agent Daten von einem lokalen Server senden kann, müssen Sie den Zugriffsschlüssel und den geheimen Schlüssel des IAM-Benutzers angeben, den Sie zuvor erstellt haben.
In diesem Feld müssen Sie auch die AWS Region angeben, an die die Messwerte gesendet werden sollen. `region`
Im Folgenden wird ein Beispiel für diese Datei gezeigt.
```
[AmazonCloudWatchAgent]
aws_access_key_id=my_access_key
aws_secret_access_key=my_secret_key
region = us-west-1
```
Verwenden Sie für *my\$1access\$1key* und *my\$1secret\$1key* die Schlüssel des IAM-Benutzers, der nicht über die erforderlichen Schreibberechtigungen für den Systems Manager Parameter Store verfügt.
Wenn Sie das Profil `AmazonCloudWatchAgent` nennen, müssen Sie nichts weiter tun. Optional können Sie einen anderen Namen vergeben und diesen Namen als Wert für `shared_credential_profile` in der Datei ` common-config.toml` angeben (siehe folgender Abschnitt).
Im Folgenden finden Sie ein Beispiel für die Verwendung des **aws configure** Befehls, um ein benanntes Profil für den CloudWatch Agenten zu erstellen. Bei diesem Beispiel wird davon ausgegangen, dass Sie den Standardprofilnamen `AmazonCloudWatchAgent` verwenden.
**Um das AmazonCloudWatchAgent Profil für den CloudWatch Agenten zu erstellen**
1. Falls Sie dies noch nicht getan haben, installieren Sie das AWS Command Line Interface auf dem Server. Weitere Informationen finden Sie unter [Installieren der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
1. Geben Sie auf Linux-Servern den folgenden Befehl ein und befolgen Sie die Anweisungen:
```
sudo aws configure --profile AmazonCloudWatchAgent
```
Öffnen Sie Windows Server PowerShell als Administrator, geben Sie den folgenden Befehl ein und folgen Sie den Anweisungen.
```
aws configure --profile AmazonCloudWatchAgent
```
## (Optional) Ändern der allgemeinen Konfiguration und des benannten Profils für den Agenten CloudWatch
Der CloudWatch Agent enthält eine Konfigurationsdatei namens`common-config.toml`. Sie können optional diese Datei verwenden, um Proxy- und Regionsinformationen anzugeben.
Auf einem Server, auf dem Linux ausgeführt wird, befindet sich diese Datei im Verzeichnis `/opt/aws/amazon-cloudwatch-agent/etc`. Auf einem Server, auf dem Windows Server ausgeführt wird, befindet sich diese Datei im Verzeichnis `C:\ProgramData\Amazon\AmazonCloudWatchAgent`.
`common-config.toml` lautet standardmäßig folgendermaßen:
```
# This common-config is used to configure items used for both ssm and cloudwatch access
## Configuration for shared credential.
## Default credential strategy will be used if it is absent here:
## Instance role is used for EC2 case by default.
## AmazonCloudWatchAgent profile is used for onPremise case by default.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
## Configuration for proxy.
## System-wide environment-variable will be read if it is absent here.
## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy
## Note: system-wide environment-variable is not accessible when using ssm run-command.
## Absent in both here and environment-variable means no proxy will be used.
# [proxy]
# http_proxy = "{http_url}"
# https_proxy = "{https_url}"
# no_proxy = "{domain}"
```
Alle Zeilen sind anfangs auskommentiert. Zum Festlegen des Anmeldeinformationsprofils oder der Proxy-Einstellungen entfernen Sie `#` aus der Zeile und geben einen Wert an. Sie können diese Datei manuell oder mithilfe von `RunShellScript` Run Command in Systems Manager: bearbeiten:
+ `shared_credential_profile`— Für lokale Server gibt diese Zeile das Profil mit den IAM-Benutzeranmeldeinformationen an, an das Daten gesendet werden sollen. CloudWatch Wenn diese Zeile auskommentiert bleibt, wird `AmazonCloudWatchAgent` verwendet. Weitere Informationen zum Erstellen dieses Profils finden Sie unter [(Installation auf einem lokalen Server) Geben Sie die IAM-Anmeldeinformationen und die Region an AWS](#install-CloudWatch-Agent-iam_user-SSM-onprem).
Auf einer EC2-Instance können Sie diese Zeile verwenden, damit der CloudWatch Agent Daten von dieser Instance CloudWatch in eine andere Region sendet. AWS Geben Sie hierzu ein benanntes Profil an, das ein Feld `region` zur Angabe der Zielregion enthält.
Wenn Sie einen `shared_credential_profile` angeben, müssen Sie auch das `#` am Anfang der `[credentials]`-Zeile entfernen.
+ `shared_credential_file` – Damit der Agent in einer nicht im Standardpfad abgelegten Datei nach Anmeldeinformationen sucht, müssen Sie den vollständigen Pfad und den Dateinamen hier angeben. Der Standardpfad ist unter Linux `/root/.aws` und unter Windows Server `C:\\Users\\Administrator\\.aws`.
Das erste Beispiel unten zeigt die Syntax einer gültigen `shared_credential_file`-Zeile für Linux-Server, und das zweite Beispiel ist für Windows-Server gültig. Auf Windows Server müssen Sie die \$1-Zeichen mit einem Escape-Zeichen versehen.
```
shared_credential_file= "/usr/username/credentials"
```
```
shared_credential_file= "C:\\Documents and Settings\\username\\.aws\\credentials"
```
Wenn Sie einen `shared_credential_file` angeben, müssen Sie auch das `#` am Anfang der `[credentials]`-Zeile entfernen.
+ Proxy-Einstellungen – Falls Ihre Server HTTP- oder HTTPS-Proxys verwenden, um AWS -Services zu kontaktieren, geben Sie diese Proxys in den Feldern `http_proxy` und `https_proxy` an. Falls es URLs welche gibt, die vom Proxying ausgeschlossen werden sollen, geben Sie sie in das `no_proxy` Feld ein, getrennt durch Kommas.
# Installieren Sie den CloudWatch Agenten auf neuen Instanzen mit CloudFormation
In diesem Abschnitt wird beschrieben, wie Sie den CloudWatch Agenten auf neuen Amazon EC2 EC2-Instances mithilfe von AWS CloudFormation installieren.
**Anmerkung**
Amazon hat mehrere CloudFormation Vorlagen hochgeladen GitHub , die Ihnen bei der Installation und Aktualisierung des CloudWatch Agenten auf neuen Amazon EC2 EC2-Instances helfen können. Weitere Informationen zur Verwendung finden Sie CloudFormation unter [Was ist AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) .
Der Speicherort der Vorlage lautet [Deploy the Amazon CloudWatch Agent to EC2 Instances using CloudFormation](https://github.com/aws-cloudformation/aws-cloudformation-templates/tree/main/Solutions/AmazonCloudWatchAgent). Dort finden Sie die beiden Verzeichnisse `inline` und `ssm`. Jedes dieser Verzeichnisse enthält Vorlagen für Linux- und Windows-Instances.
+ Bei den Vorlagen im `inline` Verzeichnis ist die CloudWatch Agentenkonfiguration in die CloudFormation Vorlage eingebettet. Standardmäßig erfassen die Linux-Vorlagen die Metriken `mem_used_percent` und `swap_used_percent`, die Windows-Vorlagen dagegen `Memory % Committed Bytes In Use` und `Paging File % Usage`.
Sie können diese Vorlagen ändern, um andere Metriken zu erfassen, indem Sie den folgenden Abschnitt der Vorlage ändern. Das folgende Beispiel stammt aus der Vorlage für Linux-Server. Befolgen Sie das Format und die Syntax der Agentenkonfigurationsdatei, um diese Änderungen vorzunehmen. Weitere Informationen finden Sie unter [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md).
```
{
"metrics":{
"append_dimensions":{
"AutoScalingGroupName":"${!aws:AutoScalingGroupName}",
"ImageId":"${!aws:ImageId}",
"InstanceId":"${!aws:InstanceId}",
"InstanceType":"${!aws:InstanceType}"
},
"metrics_collected":{
"mem":{
"measurement":[
"mem_used_percent"
]
},
"swap":{
"measurement":[
"swap_used_percent"
]
}
}
}
}
```
**Anmerkung**
In den Inline-Vorlagen müssen alle Platzhaltervariablen ein Ausrufezeichen (\$1) als Escape-Zeichen vor sich haben. Dies sehen Sie in der Beispielvorlage. Wenn Sie weitere Platzhaltervariablen hinzufügen, achten Sie darauf, dass Sie vor dem Namen ein Ausrufezeichen hinzufügen.
+ Die Vorlagen im Verzeichnis `ssm` laden eine Agentenkonfigurationsdatei aus Parameter Store. Um diese Vorlagen verwenden zu können, müssen Sie zunächst eine Konfigurationsdatei erstellen und diese in Parameter Store hochladen. Sie stellen dann den Parameter-Store-Namen der Datei in der Vorlage bereit. Sie können die Konfigurationsdatei manuell oder mit Hilfe des Assistenten erstellen. Weitere Informationen finden Sie unter [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md).
Sie können beide Arten von Vorlagen für die Installation des CloudWatch Agenten und für die Aktualisierung der Agentenkonfiguration verwenden.
Hinweise zur Einrichtung des Agenten auf einem System, auf dem die erweiterte Sicherheit von Linux (SELinux) aktiviert ist, finden Sie unter. [Richten Sie den CloudWatch Agenten mit Linux mit verbesserter Sicherheit ein () SELinux](CloudWatch-Agent-SELinux.md)
## Tutorial: Installieren und konfigurieren Sie den CloudWatch Agenten mithilfe einer CloudFormation Inline-Vorlage
In diesem Tutorial erfahren Sie CloudFormation , wie Sie den CloudWatch Agenten auf einer neuen Amazon EC2 EC2-Instance installieren. Dieses Tutorial wird auf einer neuen Instance installiert, die Amazon Linux 2 mit den Inline-Vorlagen ausführt, für die weder die JSON-Konfigurationsdatei noch Parameter Store benötigt wird. Die Inline-Vorlage enthält die Agent-Konfiguration in der Vorlage. In diesem Tutorial verwenden Sie die in der Vorlage enthaltene Standardagentenkonfiguration.
Nach der Vorgehensweise zur Installation des Agenten fährt das Tutorial mit der Aktualisierung des Agenten fort.
**Wird verwendet CloudFormation , um den CloudWatch Agenten auf einer neuen Instance zu installieren**
1. Laden Sie die Vorlage von herunter GitHub. Laden Sie in diesem Tutorial die Inline-Vorlage für Amazon Linux 2 wie folgt herunter:
```
curl -O https://raw.githubusercontent.com/aws-cloudformation/aws-cloudformation-templates/main/Solutions/AmazonCloudWatchAgent/inline/amazon_linux.yaml
```
1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie **Stack erstellen** aus.
1. Wählen Sie für **Choose a template (Vorlage auswählen)** **Upload a template to Amazon S3 (Vorlage auf Amazon S3 hochladen)**, wählen Sie die heruntergeladene Vorlage aus und klicken Sie auf **Next (Weiter)**.
1. Geben Sie auf der Seite **Specify Details (Details angeben)** die folgenden Parameter ein und wählen Sie **Next (Weiter)** aus:
+ **Stack-Name**: Wählen Sie einen Stack-Namen für Ihren CloudFormation Stack.
+ **IAMRole**: Wählen Sie eine IAM-Rolle aus, die berechtigt ist, CloudWatch Metriken, Logs und Traces zu schreiben. Weitere Informationen finden Sie unter [Voraussetzungen](prerequisites.md).
+ **InstanceAMI**: Wählen Sie ein AMI, das in der Region gültig ist, in der Sie Ihren Stack starten werden.
+ **InstanceType**: Wählen Sie einen gültigen Instance-Typ.
+ **KeyName**: Um den SSH-Zugriff auf die neue Instance zu aktivieren, wählen Sie ein vorhandenes Amazon EC2 EC2-Schlüsselpaar aus. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Amazon-EC2-Benutzerhandbuch*.
+ **SSHLocation**: Gibt den IP-Adressbereich an, der für die Verbindung mit der Instance über SSH verwendet werden kann. Der Standard erlaubt den Zugriff von jeder IP-Adresse aus.
1. Auf der Seite **Options (Optionen)** können Sie auswählen, Ihre Stack-Ressourcen zu markieren. Wählen Sie **Weiter** aus.
1. Überprüfen Sie auf der Seite **Review (Überprüfen)** Ihre Informationen, bestätigen Sie, dass der Stack IAM-Ressourcen erstellen kann, und wählen Sie dann **Create (Erstellen)** aus.
Wenn Sie die Konsole aktualisieren, sehen Sie, dass der neue Stack den `CREATE_IN_PROGRESS` Status hat.
1. Wenn die Instance erstellt wird, können Sie sie in der Amazon-EC2-Konsole sehen. Optional können Sie sich mit dem Host verbinden und den Fortschritt überprüfen.
Verwenden Sie den folgenden Befehl, um zu bestätigen, dass der Agent installiert ist:
```
rpm -qa amazon-cloudwatch-agent
```
Verwenden Sie den folgenden Befehl, um zu bestätigen, dass der Agent ausgeführt wird:
```
ps aux | grep amazon-cloudwatch-agent
```
Das nächste Verfahren zeigt CloudFormation , wie Sie den CloudWatch Agenten mithilfe einer Inline-Vorlage aktualisieren können. Die standardmäßige Inline-Vorlage erfasst die `mem_used_percent`-Metrik. In diesem Tutorial ändern Sie die Agent-Konfiguration, um die Erfassung dieser Metrik zu stoppen.
**Wird verwendet CloudFormation , um den CloudWatch Agenten zu aktualisieren**
1. Entfernen Sie in der Vorlage, die Sie im vorherigen Verfahren heruntergeladen haben, die folgenden Zeilen und speichern Sie die Vorlage:
```
"mem": {
"measurement": [
"mem_used_percent"
]
},
```
1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie im CloudFormation Dashboard den Stack aus, den Sie erstellt haben, und wählen Sie Stack **aktualisieren** aus.
1. Wählen Sie für **Select Template (Vorlage auswählen)** **Upload a template to Amazon S3 (Vorlage auf Amazon S3 hochladen)**, wählen Sie die von Ihnen modifizierte Vorlage aus und klicken Sie auf **Next (Weiter)**.
1. Wählen Sie auf der Seite **Options (Optionen)** die Option **Next (Weiter)** gefolgt von **Next (Weiter)** aus.
1. Prüfen Sie auf der Seite **Review (Überprüfen)** die Daten, und wählen Sie **Update (Aktualisieren)** aus.
Nach einiger Zeit sehen Sie `UPDATE_COMPLETE`.
## Tutorial: Installieren Sie den CloudWatch Agenten mithilfe von CloudFormation Parameter Store
In diesem Tutorial erfahren Sie CloudFormation , wie Sie den CloudWatch Agenten auf einer neuen Amazon EC2 EC2-Instance installieren. Dieses Tutorial wird auf einer neuen Instance installiert, die Amazon Linux 2 mit einer Agent-Konfigurationsdatei ausführt, die Sie in Parameter Store erstellt und gespeichert haben.
Nach der Vorgehensweise zur Installation des Agenten fährt das Tutorial mit der Aktualisierung des Agenten fort.
**Wird verwendet CloudFormation , um den CloudWatch Agenten mithilfe einer Konfiguration aus dem Parameter Store auf einer neuen Instance zu installieren**
1. Falls Sie dies noch nicht getan haben, laden Sie das CloudWatch Agentenpaket auf einen Ihrer Computer herunter, damit Sie die Agenten-Konfigurationsdatei erstellen können. Weitere Informationen zum Herunterladen des Agenten mittels Parameter Store finden Sie unter [Laden Sie das CloudWatch Agentenpaket herunter](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md).
1. Erstellen Sie die Agentenkonfigurationsdatei und speichern Sie sie in Parameter Store. Weitere Informationen finden Sie unter [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md).
1. Laden Sie die Vorlage GitHub wie folgt herunter:
```
curl -O https://raw.githubusercontent.com/awslabs/aws-cloudformation-templates/master/aws/solutions/AmazonCloudWatchAgent/ssm/amazon_linux.template
```
1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie **Stack erstellen** aus.
1. Wählen Sie für **Choose a template (Vorlage auswählen)** **Upload a template to Amazon S3 (Vorlage auf Amazon S3 hochladen)**, wählen Sie die Vorlage aus, die Sie heruntergeladen haben, und klicken Sie auf **Next (Weiter)**.
1. Füllen Sie auf der Seite **Specify Details (Details angeben)** die folgenden Parameter entsprechend aus, und klicken Sie dann auf **Next (Weiter)**:
+ **Stack-Name**: Wählen Sie einen Stack-Namen für Ihren CloudFormation Stack.
+ **IAMRole**: Wählen Sie eine IAM-Rolle aus, die berechtigt ist, CloudWatch Metriken, Logs und Traces zu schreiben. Weitere Informationen finden Sie unter [Voraussetzungen](prerequisites.md).
+ **InstanceAMI**: Wählen Sie ein AMI, das in der Region gültig ist, in der Sie Ihren Stack starten werden.
+ **InstanceType**: Wählen Sie einen gültigen Instance-Typ.
+ **KeyName**: Um den SSH-Zugriff auf die neue Instance zu aktivieren, wählen Sie ein vorhandenes Amazon EC2 EC2-Schlüsselpaar aus. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Amazon-EC2-Benutzerhandbuch*.
+ **SSHLocation**: Gibt den IP-Adressbereich an, der für die Verbindung mit der Instance über SSH verwendet werden kann. Der Standard erlaubt den Zugriff von jeder IP-Adresse aus.
+ **SSMKey**: Gibt die Agent-Konfigurationsdatei an, die Sie im Parameter Store erstellt und gespeichert haben.
1. Auf der Seite **Options (Optionen)** können Sie auswählen, Ihre Stack-Ressourcen zu markieren. Wählen Sie **Weiter** aus.
1. Überprüfen Sie auf der Seite **Review (Überprüfen)** Ihre Informationen, bestätigen Sie, dass der Stack IAM-Ressourcen erstellen kann, und wählen Sie dann **Create (Erstellen)** aus.
Wenn Sie die Konsole aktualisieren, sehen Sie, dass der neue Stack den `CREATE_IN_PROGRESS` Status hat.
1. Wenn die Instance erstellt wird, können Sie sie in der Amazon-EC2-Konsole sehen. Optional können Sie sich mit dem Host verbinden und den Fortschritt überprüfen.
Verwenden Sie den folgenden Befehl, um zu bestätigen, dass der Agent installiert ist:
```
rpm -qa amazon-cloudwatch-agent
```
Verwenden Sie den folgenden Befehl, um zu bestätigen, dass der Agent ausgeführt wird:
```
ps aux | grep amazon-cloudwatch-agent
```
Das nächste Verfahren zeigt, wie CloudFormation Sie den CloudWatch Agenten mithilfe einer Agentenkonfiguration aktualisieren, die Sie im Parameter Store gespeichert haben.
**Wird verwendet CloudFormation , um den CloudWatch Agenten mithilfe einer Konfiguration im Parameter Store zu aktualisieren**
1. Ändern Sie die Agentenkonfigurationsdatei, die in Parameter Store gespeichert ist, auf die neue Konfiguration, die Sie wünschen.
1. Ändern Sie in der CloudFormation Vorlage, die Sie im [Tutorial: Installieren Sie den CloudWatch Agenten mithilfe von CloudFormation Parameter Store](#installing-CloudWatch-Agent-using-CloudFormation-Templates) Thema heruntergeladen haben, die Versionsnummer. Sie können z. B. `VERSION=1.0` zu `VERSION=2.0` ändern.
1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie im CloudFormation Dashboard den Stack aus, den Sie erstellt haben, und wählen Sie Stack **aktualisieren** aus.
1. Wählen Sie für **Select Template (Vorlage auswählen)** **Upload a template to Amazon S3 (Vorlage auf Amazon S3 hochladen)**, wählen Sie die Vorlage aus, die Sie gerade geändert haben, und klicken Sie auf **Next (Weiter)**.
1. Wählen Sie auf der Seite **Options (Optionen)** die Option **Next (Weiter)** gefolgt von **Next (Weiter)** aus.
1. Prüfen Sie auf der Seite **Review (Überprüfen)** die Daten, und wählen Sie **Update (Aktualisieren)** aus.
Nach einiger Zeit sehen Sie `UPDATE_COMPLETE`.
## Fehlerbehebung bei der Installation des CloudWatch Agenten mit CloudFormation
Dieser Abschnitt hilft Ihnen bei der Behebung von Problemen bei der Installation und Aktualisierung des CloudWatch Agenten mithilfe von CloudFormation.
### Erkennen, wenn eine Aktualisierung fehlschlägt
Wenn Sie Ihre CloudWatch Agentenkonfiguration aktualisieren und eine ungültige Konfiguration verwenden, sendet der Agent keine Metriken mehr an CloudWatch. CloudFormation Eine schnelle Möglichkeit, um zu überprüfen, ob ein Update der Agentenkonfiguration erfolgreich war, ist ein Blick in die Datei `cfn-init-cmd.log`. Auf einem Linux-Server befindet sich die Datei unter `/var/log/cfn-init-cmd.log`. Auf einer Windows-Instance befindet sich die Datei unter `C:\cfn\log\cfn-init-cmd.log`.
### Metriken fehlen
Wenn Sie die nach der Installation oder Aktualisierung des Agenten erwarteten Metriken nicht sehen, stellen Sie sicher, dass der Agent so konfiguriert ist, dass er diese Metrik erfasst. Überprüfen Sie dazu die Datei `amazon-cloudwatch-agent.json`, um sicherzustellen, dass die Metrik aufgelistet ist. Prüfen Sie auch, ob die Suche im korrekten Metrik-Namespace erfolgt. Weitere Informationen finden Sie unter [CloudWatch Agentendateien und Speicherorte](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-files-and-locations).
# Installieren Sie den CloudWatch Agenten mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm
Sie können entweder das Amazon CloudWatch Observability EKS-Add-on oder das Amazon CloudWatch Observability Helm-Diagramm verwenden, um den CloudWatch Agenten und den Fluent-Bit-Agenten auf einem Amazon EKS-Cluster zu installieren. Sie können das Helm-Diagramm auch verwenden, um den CloudWatch Agenten und den Fluent-Bit-Agenten auf einem Kubernetes-Cluster zu installieren, der nicht auf Amazon EKS gehostet wird.
Die Verwendung einer der beiden Methoden auf einem Amazon EKS-Cluster ermöglicht standardmäßig sowohl [Container Insights](ContainerInsights.md) mit verbesserter Observability für Amazon EKS als auch [CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md). Mit beiden Features können Sie Infrastrukturmetriken, Anwendungs-Leistungstelemetrie und Container-Protokolle aus dem Amazon-EKS-Cluster erfassen.
Mit der Version `v6.0.1-eksbuild.1` oder einer späteren Version des Add-ons ist Container Insights with OpenTelemetry metrics aktiviert, das Metriken mithilfe des OpenTelemetry Protokolls (OTLP) sammelt und ProMQL-Abfragen unterstützt. Weitere Informationen finden Sie unter [Container Insights mit OpenTelemetry Metriken für Amazon EKS](container-insights-otel-metrics.md).
Bei Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS werden die Container-Insights-Metriken pro Beobachtung abgerechnet, anstatt pro gespeicherter Metrik oder aufgenommenem Protokoll. Bei Application Signals basiert die Abrechnung auf eingehenden Anforderungen an Ihre Anwendungen, ausgehenden Anforderungen von Ihren Anwendungen und jedem konfigurierten Servicelevel-Ziel (SLO). Jede eingehende Anforderung generiert ein Anwendungssignal, und jede ausgehende Anforderung generiert ein Anwendungssignal. Jeder SLO erzeugt zwei Anwendungssignale pro Messzeitraum. Weitere Informationen zur CloudWatch Preisgestaltung finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing/).
Beide Methoden aktivieren Container Insights sowohl auf Linux- als auch auf Windows-Worker-Knoten im Amazon-EKS-Cluster. Um Container Insights unter Windows zu aktivieren, müssen Sie Version 1.5.0 oder höher des Amazon-EKS-Add-ons oder das Helm-Chart verwenden. Application Signals wird unter Windows in Amazon-EKS-Clustern nicht unterstützt.
Das Amazon CloudWatch Observability EKS-Add-on wird auf Amazon EKS-Clustern unterstützt, die mit Kubernetes Version 1.23 oder höher ausgeführt werden.
Wenn Sie das Add-on oder das Helm-Diagramm installieren, müssen Sie auch IAM-Berechtigungen erteilen, damit der CloudWatch Agent Metriken, Protokolle und Traces an senden kann. CloudWatch Es gibt zwei Möglichkeiten dafür:
+ Fügen Sie eine Richtlinie an die IAM-Rolle Ihrer Worker-Knoten an. Diese Option gewährt Worker-Knoten die Erlaubnis, Telemetrie an sie zu senden. CloudWatch
+ Verwenden Sie eine IAM-Rolle für Servicekonten für die Agenten-Pods und fügen Sie die Richtlinie an diese Rolle an. Dies funktioniert nur für Amazon-EKS-Cluster. Diese Option gewährt nur CloudWatch Zugriff auf die entsprechenden Agenten-Pods.
**Topics**
+ [Option 1: Installation mithilfe von EKS Pod Identity](#install-CloudWatch-Observability-EKS-pod-identity)
+ [Option 2: Installation mit IAM-Berechtigungen auf Worker-Knoten](#install-CloudWatch-Observability-EKS-addon-workernodes)
+ [Option 3: Installation mithilfe der IAM-Servicekonto-Rolle (gilt nur für die Verwendung des Add-ons)](#install-CloudWatch-Observability-EKS-addon-serviceaccountrole)
+ [Hinweise zu Amazon EKS Hybrid Nodes](#install-CloudWatch-Observability-EKS-addon-hybrid)
+ [(Optional) Zusätzliche Konfiguration](#install-CloudWatch-Observability-EKS-addon-configuration)
+ [Erfassung von Java Management Extensions (JMX)-Metriken](#install-CloudWatch-Observability-EKS-addon-JMX-metrics)
+ [Aktivieren von Kueue-Metriken](#enable-Kueue-metrics)
+ [OpenTelemetry Collector-Konfigurationsdateien anhängen](#install-CloudWatch-Observability-EKS-addon-OpenTelemetry)
+ [Aktivierung von APM über Application Signals für Ihren Amazon EKS-Cluster](#Container-Insights-setup-EKS-appsignalsconfiguration)
+ [Fehlerbehebung beim Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm](#Container-Insights-setup-EKS-addon-troubleshoot)
+ [Melden Sie sich von Application Signals ab](#Opting-out-App-Signals)
## Option 1: Installation mithilfe von EKS Pod Identity
Bei Verwendung von Version 3.1.0 oder höher des Add-ons können Sie EKS Pod Identity nutzen, um dem Add-On die erforderlichen Berechtigungen zu erteilen. EKS Pod Identity ist die empfohlene Option und bietet Vorteile wie geringste Berechtigung, Rotation von Anmeldeinformationen und Überprüfbarkeit. Darüber hinaus ermöglicht Ihnen die Nutzung von EKS Pod Identity, das EKS-Add-on als Teil der Clustererstellung selbst zu installieren.
Zur Verwendung dieser Methode befolgen Sie die Schritte zur [EKS-Pod-Identity-Zuordnung](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create/), um die IAM-Rolle zu erstellen und den EKS-Pod-Identity-Agenten einzurichten.
Installieren Sie anschließend das Amazon CloudWatch Observability EKS-Add-on. Um das Add-on zu installieren, können Sie die AWS CLI Amazon EKS-Konsole oder Terraform verwenden. CloudFormation
------
#### [ AWS CLI ]
**AWS CLI Um das Amazon CloudWatch Observability EKS-Add-on zu installieren**
Geben Sie die folgenden Befehle ein. `my-cluster-name`Ersetzen Sie es durch den Namen Ihres Clusters und *111122223333* ersetzen Sie es durch Ihre Konto-ID. *my-role*Ersetzen Sie durch die IAM-Rolle, die Sie im Zuordnungsschritt EKS Pod Identity erstellt haben.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name my-cluster-name \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role
```
------
#### [ Amazon EKS console ]
**So verwenden Sie die Amazon EKS-Konsole, um das Amazon CloudWatch Observability EKS-Add-on hinzuzufügen**
1. Öffnen Sie die Amazon EKS-Konsole unter [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** aus.
1. Wählen Sie den Namen des Clusters, für den Sie das Amazon CloudWatch Observability EKS-Add-on konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie **Weitere Add-Ons erhalten**.
1. Führen Sie auf der Seite **Add-Ons auswählen** die folgenden Schritte aus:
1. Aktivieren Sie im Bereich **Amazon EKS-Addons** das Kontrollkästchen **Amazon CloudWatch Observability**.
1. Wählen Sie **Weiter** aus.
1. Gehen Sie auf der Seite **Konfigurieren ausgewählter Add-Ons-Einstellungen** wie folgt vor:
1. Wählen Sie die **Version** aus, die Sie verwenden möchten.
1. Wählen Sie für **Add-on-Zugriff** die Option **EKS Pod Identity** aus.
1. Wenn Sie keine IAM-Rolle konfiguriert haben, wählen Sie **Empfohlene Rolle erstellen** und dann **Weiter** aus, bis Sie bei **Schritt 3 Name, Überprüfung und Erstellung** angelangt sind. Sie können Ihren Rollennamen bei Bedarf ändern. Andernfalls wählen Sie **Rolle erstellen** aus, kehren Sie dann zur Add-on-Seite zurück und wählen Sie die IAM-Rolle aus, die Sie gerade erstellt haben.
1. (Optional) Sie können **Optionale Konfigurationseinstellungen** erweitern. Wenn Sie **Überschreiben** für **Methode zur Konfliktlösung** auswählen, können eine oder mehrere der Einstellungen für das vorhandene Add-on mit den Einstellungen des Amazon-EKS-Add-ons überschrieben werden. Wenn Sie diese Option nicht aktivieren und ein Konflikt mit Ihren vorhandenen Einstellungen vorliegt, schlägt der Vorgang fehl. Sie können die sich daraus ergebende Fehlermeldung heranziehen, um den Konflikt zu beheben. Stellen Sie vor der Auswahl dieser Option sicher, dass das Amazon-EKS-Add-on keine Einstellungen verwaltet, die Sie selbst verwalten müssen.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie auf der Seite **Überprüfen und hinzufügen** die Option **Erstellen** aus. Nachdem die Installation der Add-Ons abgeschlossen ist, wird Ihr installiertes Add-On angezeigt.
------
#### [ CloudFormation ]
**CloudFormation Zur Installation des Amazon CloudWatch Observability EKS-Add-ons**
1. Führen Sie zunächst den folgenden AWS CLI Befehl aus, um die erforderliche IAM-Richtlinie an Ihre IAM-Rolle anzuhängen. *my-role*Ersetzen Sie sie durch die Rolle, die Sie im Zuordnungsschritt EKS Pod Identity erstellt haben.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. Erstellen Sie dann die folgende Ressource: `my-cluster-name`Ersetzen Sie es durch den Namen Ihres Clusters, *111122223333* ersetzen Sie es durch Ihre Konto-ID und *my-role* ersetzen Sie es durch die IAM-Rolle, die im Zuordnungsschritt EKS Pod Identity erstellt wurde. Weitere Informationen finden Sie unter [ AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html).
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name",
"PodIdentityAssociations": [
{
"ServiceAccount": "cloudwatch-agent",
"RoleArn": "arn:aws:iam::111122223333:role/my-role"
}
]
}
}
}
}
```
------
#### [ Terraform ]
**Um Terraform zur Installation des Amazon CloudWatch Observability EKS-Add-ons zu verwenden**
1. Verwenden Sie Folgendes: `my-cluster-name`Ersetzen Sie es durch den Namen Ihres Clusters, ersetzen *111122223333* Sie es durch Ihre Konto-ID und *my-service-account-role* ersetzen Sie es durch die IAM-Rolle, die im Zuordnungsschritt EKS Pod Identity erstellt wurde.
Weitere Informationen finden Sie unter [Resource: aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_addon) in der Terraform-Dokumentation.
1.
```
resource "aws_iam_role_policy_attachment" "CloudWatchAgentServerPolicy" {
policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
role = "my-role"
}
resource "aws_eks_addon" "example" {
cluster_name = "my-cluster-name"
addon_name = "amazon-cloudwatch-observability"
pod_identity_associations {
roleArn = "arn:aws:iam::111122223333:role/my-role"
serviceAccount = "cloudwatch-agent"
}
}
```
------
## Option 2: Installation mit IAM-Berechtigungen auf Worker-Knoten
Um diese Methode zu verwenden, fügen Sie zunächst die **CloudWatchAgentServerPolicy**IAM-Richtlinie Ihren Worker-Knoten hinzu, indem Sie den folgenden Befehl eingeben. Ersetzen Sie *my-worker-node-role* diesen Befehl durch die IAM-Rolle, die von Ihren Kubernetes-Worker-Knoten verwendet wird.
```
aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
Installieren Sie anschließend das Amazon CloudWatch Observability EKS-Add-on. Um das Add-on zu installieren, können Sie die AWS CLI, die Konsole oder CloudFormation Terraform verwenden.
------
#### [ AWS CLI ]
**AWS CLI Um das Amazon CloudWatch Observability EKS-Add-on zu installieren**
Geben Sie den folgenden Befehl ein. Ersetzen Sie `my-cluster-name` mit dem Namen Ihres Clusters.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name
```
------
#### [ Amazon EKS console ]
**So verwenden Sie die Amazon EKS-Konsole, um das Amazon CloudWatch Observability EKS-Add-on hinzuzufügen**
1. Öffnen Sie die Amazon EKS-Konsole unter [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** aus.
1. Wählen Sie den Namen des Clusters, für den Sie das Amazon CloudWatch Observability EKS-Add-on konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie **Weitere Add-Ons erhalten**.
1. Führen Sie auf der Seite **Add-Ons auswählen** die folgenden Schritte aus:
1. Aktivieren Sie im Bereich **Amazon EKS-Addons** das Kontrollkästchen **Amazon CloudWatch Observability**.
1. Wählen Sie **Weiter** aus.
1. Gehen Sie auf der Seite **Konfigurieren ausgewählter Add-Ons-Einstellungen** wie folgt vor:
1. Wählen Sie die **Version** aus, die Sie verwenden möchten.
1. (Optional) Sie können **Optionale Konfigurationseinstellungen** erweitern. Wenn Sie **Überschreiben** für **Methode zur Konfliktlösung** auswählen, können eine oder mehrere der Einstellungen für das vorhandene Add-on mit den Einstellungen des Amazon-EKS-Add-ons überschrieben werden. Wenn Sie diese Option nicht aktivieren und ein Konflikt mit Ihren vorhandenen Einstellungen vorliegt, schlägt der Vorgang fehl. Sie können die sich daraus ergebende Fehlermeldung heranziehen, um den Konflikt zu beheben. Stellen Sie vor der Auswahl dieser Option sicher, dass das Amazon-EKS-Add-on keine Einstellungen verwaltet, die Sie selbst verwalten müssen.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie auf der Seite **Überprüfen und hinzufügen** die Option **Erstellen** aus. Nachdem die Installation der Add-Ons abgeschlossen ist, wird Ihr installiertes Add-On angezeigt.
------
#### [ CloudFormation ]
**CloudFormation Zur Installation des Amazon CloudWatch Observability EKS-Add-ons**
Ersetzen Sie `my-cluster-name` mit dem Namen Ihres Clusters. Weitere Informationen finden Sie unter [ AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html).
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name"
}
}
}
}
```
------
#### [ Helm chart ]
**Um das `amazon-cloudwatch-observability` Helm-Chart zu verwenden**
1. Helm muss installiert sein, um dieses Diagramm verwenden zu können. Weitere Informationen zur Installation von Helm finden Sie in der [Helm-Dokumentation](https://helm.sh/docs/).
1. Geben Sie nach der Installation von Helm die folgenden Befehle ein. *my-cluster-name*Ersetzen Sie es durch den Namen Ihres Clusters und *my-cluster-region* ersetzen Sie es durch die Region, in der der Cluster ausgeführt wird.
```
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm repo update aws-observability
helm install --wait --create-namespace --namespace amazon-cloudwatch amazon-cloudwatch-observability aws-observability/amazon-cloudwatch-observability --set clusterName=my-cluster-name --set region=my-cluster-region
```
------
#### [ Terraform ]
**Um Terraform zur Installation des Amazon CloudWatch Observability EKS-Add-ons zu verwenden**
Ersetzen Sie `my-cluster-name` mit dem Namen Ihres Clusters. Weitere Informationen finden Sie unter [Resource: aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_ad).
```
resource "aws_eks_addon" "example" {
addon_name = "amazon-cloudwatch-observability"
cluster_name = "my-cluster-name"
}
```
------
## Option 3: Installation mithilfe der IAM-Servicekonto-Rolle (gilt nur für die Verwendung des Add-ons)
Diese Methode ist nur gültig, wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden. Vor dem Verwenden dieser Methode, überprüfen Sie die folgenden Voraussetzungen:
+ Sie besitzen einen funktionsfähigen Amazon-EKS-Cluster mit angefügten Knoten in einer der AWS-Regionen , von denen Container Insights unterstützt wird. Eine Liste der unterstützten Regionen finden Sie unter [Container Insights](ContainerInsights.md).
+ Sie haben `kubectl` für den Cluster installiert und konfiguriert. Weitere Informationen finden Sie unter [Installieren von `kubectl`](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) im *Amazon-EKS-Benutzerhandbuch*.
+ Sie haben `eksctl` installiert. Weitere Informationen finden Sie unter [Installieren oder Aktualisieren von `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) im *Amazon-EKS-Benutzerhandbuch*.
------
#### [ AWS CLI ]
**AWS CLI Um das Amazon CloudWatch Observability EKS-Add-on mithilfe der IAM-Servicekontorolle zu installieren**
1. Geben Sie den folgenden Befehl ein, um einen OpenID-Connect-Anbieter (OIDC) zu erstellen, falls der Cluster noch keinen hat. Weitere Informationen finden Sie unter [Konfigurieren eines Kubernetes-Servicekontos zur Übernahme einer IAM-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) im *Amazon-EKS-Benutzerhandbuch*.
```
eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve
```
1. Geben Sie den folgenden Befehl ein, um die IAM-Rolle mit der angehängten **CloudWatchAgentServerPolicy**Richtlinie zu erstellen, und konfigurieren Sie das Agent-Servicekonto so, dass es diese Rolle mithilfe von OIDC übernimmt. *my-cluster-name*Ersetzen Sie es durch den Namen Ihres Clusters und *my-service-account-role* ersetzen Sie es durch den Namen der Rolle, der Sie das Dienstkonto zuordnen möchten. Wenn diese Rolle noch nicht vorhanden ist, erstellt `eksctl` sie für Sie.
```
eksctl create iamserviceaccount \
--name cloudwatch-agent \
--namespace amazon-cloudwatch --cluster my-cluster-name \
--role-name my-service-account-role \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-only \
--approve
```
1. Installieren Sie das Add-On indem Sie den folgenden Befehl eingeben. *my-cluster-name*Ersetzen Sie es durch den Namen Ihres Clusters, *111122223333* ersetzen Sie es durch Ihre Konto-ID und *my-service-account-role* ersetzen Sie es durch die IAM-Rolle, die im vorherigen Schritt erstellt wurde.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name --service-account-role-arn arn:aws:iam::111122223333:role/my-service-account-role
```
------
#### [ Amazon EKS console ]
**So verwenden Sie die Konsole zur Installation des Amazon CloudWatch Observability EKS-Add-ons mithilfe der IAM-Servicekontorolle**
1. Öffnen Sie die Amazon EKS-Konsole unter [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** aus.
1. Wählen Sie den Namen des Clusters, für den Sie das Amazon CloudWatch Observability EKS-Add-on konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie **Weitere Add-Ons erhalten**.
1. Führen Sie auf der Seite **Add-Ons auswählen** die folgenden Schritte aus:
1. Aktivieren Sie im Bereich **Amazon EKS-Addons** das Kontrollkästchen **Amazon CloudWatch Observability**.
1. Wählen Sie **Weiter** aus.
1. Gehen Sie auf der Seite **Konfigurieren ausgewählter Add-Ons-Einstellungen** wie folgt vor:
1. Wählen Sie die **Version** aus, die Sie verwenden möchten.
1. Wählen Sie für **Add-on-Zugriff** die Option **IAM-Rollen für Servicekonten (IRSA)** aus
1. Wählen Sie im Feld **Add-on-Zugriff** die IAM-Rolle aus.
1. (Optional) Sie können **Optionale Konfigurationseinstellungen** erweitern. Wenn Sie **Überschreiben** für **Methode zur Konfliktlösung** auswählen, können eine oder mehrere der Einstellungen für das vorhandene Add-on mit den Einstellungen des Amazon-EKS-Add-ons überschrieben werden. Wenn Sie diese Option nicht aktivieren und ein Konflikt mit Ihren vorhandenen Einstellungen vorliegt, schlägt der Vorgang fehl. Sie können die sich daraus ergebende Fehlermeldung heranziehen, um den Konflikt zu beheben. Stellen Sie vor der Auswahl dieser Option sicher, dass das Amazon-EKS-Add-on keine Einstellungen verwaltet, die Sie selbst verwalten müssen.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie auf der Seite **Überprüfen und hinzufügen** die Option **Erstellen** aus. Nachdem die Installation der Add-Ons abgeschlossen ist, wird Ihr installiertes Add-On angezeigt.
------
## Hinweise zu Amazon EKS Hybrid Nodes
Für Hybridknoten sind keine Metriken auf Knotenebene verfügbar, da [Container Insights](ContainerInsights.md) für Metriken auf Knotenebene von der Verfügbarkeit des [EX2 Instance Metadata Service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) (IMDS) abhängt. Für Hybridknoten sind Metriken auf Cluster-, Workload-, Pod- und Container-Ebene verfügbar.
Nachdem Sie das Add-on gemäß den Schritten in den vorherigen Abschnitten installiert haben, müssen Sie das Add-on-Manifest aktualisieren, damit der Agent erfolgreich auf Hybridknoten ausgeführt werden kann. Bearbeiten Sie die `amazoncloudwatchagents`-Ressource im Cluster, um die Umgebungsvariable `RUN_WITH_IRSA` hinzuzufügen, die den folgenden Werten entspricht.
```
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
```
```
apiVersion: v1
items:
- apiVersion: cloudwatch.aws.amazon.com/v1alpha1
kind: AmazonCloudWatchAgent
metadata:
...
name: cloudwatch-agent
namespace: amazon-cloudwatch
...
spec:
...
env:
- name: RUN_WITH_IRSA # <-- Add this
value: "True" # <-- Add this
- name: K8S_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
...
```
## (Optional) Zusätzliche Konfiguration
**Topics**
+ [Die Erfassung von Container-Protokollen deaktivieren](#CloudWatch-Observability-EKS-addon-OptOutContainerLogs)
+ [Eine benutzerdefinierte Fluent Bit-Konfiguration verwenden](#CloudWatch-Observability-EKS-addon-CustomFluentBit)
+ [Verwalten von Kubernetes-Toleranzen für die installierten Pod-Workloads](#CloudWatch-Observability-EKS-addon-Tolerations)
+ [Deaktivieren der Erfassung von Accelerated Compute-Metriken](#CloudWatch-Observability-EKS-addon-OptOutAccelerated)
+ [Verwenden Sie eine benutzerdefinierte CloudWatch Agentenkonfiguration](#CloudWatch-Observability-EKS-addon-CustomAgentConfig)
+ [Webhook-TLS-Zulassungszertifikate verwalten](#CloudWatch-Observability-EKS-addon-Webhook)
+ [Amazon EBS-Volume sammeln IDs](#CloudWatch-Observability-EKS-addon-VolumeIDs)
### Die Erfassung von Container-Protokollen deaktivieren
Standardmäßig verwendet das Add-on Fluent Bit, um Container-Protokolle von allen Pods zu sammeln, und sendet die Protokolle dann an Logs. CloudWatch Informationen darüber, welche Protokolle gesammelt werden, finden Sie unter [Einrichten von Fluent Bit](Container-Insights-setup-logs-FluentBit.md#Container-Insights-FluentBit-setup).
**Anmerkung**
Weder das Add-on noch das Helm-Chart verwalten vorhandene Fluentd- oder Fluent Bit-Ressourcen in einem Cluster. Sie können die vorhandenen Fluentd- oder Fluent-Bit-Ressourcen löschen, bevor Sie das Add-on oder das Helm-Chart installieren. Alternativ können Sie Fluent Bit deaktivieren, indem Sie den Anweisungen in diesem Abschnitt folgen, um das vorhandene Setup beizubehalten und zu verhindern, dass das Add-on oder das Helm-Chart ebenfalls installiert werden.
Um die Erfassung von Container-Protokollen zu deaktivieren, wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden, übergeben Sie bei der Erstellung oder Aktualisierung des Add-ons die folgende Option:
```
--configuration-values '{ "containerLogs": { "enabled": false } }'
```
Um die Erfassung von Container-Protokollen zu deaktivieren, wenn Sie das Helm-Chart verwenden, übergeben Sie bei der Erstellung oder Aktualisierung des Add-ons die folgende Option:
```
--set containerLogs.enabled=false
```
### Eine benutzerdefinierte Fluent Bit-Konfiguration verwenden
Ab Version 1.7.0 des Amazon CloudWatch Observability EKS-Add-ons können Sie die Fluent Bit-Konfiguration ändern, wenn Sie das Add-on oder das Helm-Diagramm erstellen oder aktualisieren. Sie geben die benutzerdefinierte Fluent Bit-Konfiguration im Abschnitt auf `containerLogs` Stammebene der erweiterten Konfiguration des Add-ons oder die Wertüberschreibungen im Helm-Chart an. In diesem Abschnitt geben Sie die benutzerdefinierte Fluent-Bit-Konfiguration im Abschnitt `config` (für Linux) oder im Abschnitt `configWindows` (für Windows) an. Die `config` ist in die folgenden Unterabschnitte unterteilt:
+ `service`: Dieser Abschnitt stellt die `SERVICE`-Konfiguration zur Definition des globalen Verhaltens der Fluent Bit-Engine dar.
+ `customParsers`: Dieser Abschnitt stellt alle globalen `PARSER` dar, die Sie einbeziehen möchten und die in der Lage sind, unstrukturierte Protokolleinträge zu verarbeiten und ihnen eine Struktur zu geben, um sie einfacher zu verarbeiten und weiter zu filtern.
+ `extraFiles`: Dieser Abschnitt kann verwendet werden, um zusätzliche Fluent-Bit `conf`-Dateien hinzuzufügen. Standardmäßig sind die folgenden 3 `conf`-Dateien enthalten:
+ `application-log.conf`— Eine `conf` Datei zum Senden von Anwendungsprotokollen von Ihrem Cluster an die Protokollgruppe `/aws/containerinsights/my-cluster-name/application` in Logs. CloudWatch
+ `dataplane-log.conf`— Eine `conf` Datei zum Senden von Protokollen, die den Datenebenenkomponenten Ihres Clusters entsprechen, einschließlich der CRI-Protokolle, Kubelet-Protokolle, Kube-Proxy-Protokolle und Amazon VPC-CNI-Protokolle, an die Protokollgruppe in Logs. `/aws/containerinsights/my-cluster-name/dataplane` CloudWatch
+ `host-log.conf`— A `conf` zum Senden von Protokollen von `/var/log/dmesg``/var/log/messages`, und unter Linux und System unter Windows `/var/log/secure` `winlogs` an die Protokollgruppe in. `/aws/containerinsights/my-cluster-name/host` CloudWatch
**Anmerkung**
Geben Sie die vollständige Konfiguration für jeden dieser einzelnen Abschnitte an, auch wenn Sie nur ein Feld innerhalb eines Unterabschnitts ändern. Wir empfehlen, die unten angegebene Standardkonfiguration als Grundlage zu verwenden und sie dann zu ändern, damit Sie die standardmäßig aktivierten Funktionen nicht deaktivieren. Sie können die folgende YAML-Konfiguration verwenden, wenn Sie die erweiterte Konfiguration für das Amazon-EKS-Add-on ändern oder wenn Sie Wertüberschreibungen für das Helm-Chart angeben.
Den `config` Abschnitt für Ihren Cluster finden Sie unter [aws-observability /helm-charts](https://github.com/aws-observability/helm-charts/releases). Dort finden Sie die Version, die der Version des Add-ons oder Helm-Charts entspricht, das Sie installieren. GitHub Navigieren Sie dann zu `/charts/amazon-cloudwatch-observability/values.yaml` und zum Abschnitt `config` (für Linux) bzw. zum Abschnitt `configWindows` (für Windows) im Abschnitt `fluentBit` unter `containerLogs`.
Als Beispiel finden Sie [hier](https://github.com/aws-observability/helm-charts/blob/v1.7.0/charts/amazon-cloudwatch-observability/values.yaml#L44)) die Standardkonfiguration für Fluent Bit für Version 1.7.0.
Wir empfehlen, dass Sie die `config` als YAML angeben, wenn Sie es mit der erweiterten Konfiguration des Amazon-EKS-Add-ons bereitstellen oder wenn Sie es als Wertüberschreibungen für Ihre Helm-Installation angeben. Stellen Sie sicher, dass das YAML die folgende Struktur hat.
```
containerLogs:
fluentBit:
config:
service: |
...
customParsers: |
...
extraFiles:
application-log.conf: |
...
dataplane-log.conf: |
...
host-log.conf: |
...
```
Im folgenden Beispiel `config` wird die globale Einstellung für das Bereinigungsintervall auf 45 Sekunden geändert. Auch wenn die einzige Änderung das Feld `Flush` betrifft, müssen Sie dennoch die vollständige `SERVICE`-Definition für den Service-Unterabschnitt angeben. Da in diesem Beispiel keine Überschreibungen für die anderen Unterabschnitte angegeben wurden, werden für sie die Standardwerte verwendet.
```
containerLogs:
fluentBit:
config:
service: |
[SERVICE]
Flush 45
Grace 30
Log_Level error
Daemon off
Parsers_File parsers.conf
storage.path /var/fluent-bit/state/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
```
Die folgende Beispielkonfiguration beinhaltet eine zusätzliche Fluent-Bit `conf`-Datei. In diesem Beispiel fügen wir eine benutzerdefinierte `my-service.conf` unter `extraFiles` hinzu, zusätzlich zu den drei bestehenden standardmäßigen `extraFiles`.
```
containerLogs:
fluentBit:
config:
extraFiles:
my-service.conf: |
[INPUT]
Name tail
Tag myservice.*
Path /var/log/containers/*myservice*.log
DB /var/fluent-bit/state/flb_myservice.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Ignore_Older 1d
Refresh_Interval 10
[OUTPUT]
Name cloudwatch_logs
Match myservice.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice
log_stream_prefix ${HOST_NAME}-
auto_create_group true
```
Im nächsten Beispiel wird eine bestehende `conf`-Datei vollständig von `extraFiles` entfernt. Die `application-log.conf` wird vollständig ausgeschlossen, indem sie mit einer leeren Zeichenfolge überschrieben wird. Würden Sie einfach `application-log.conf` in `extraFiles` weglassen, würde die Standardeinstellung verwendet, was wir in diesem Beispiel nicht wollen. Das Gleiche gilt für das Entfernen von benutzerdefinierten `conf`-Dateien, die Sie möglicherweise zuvor zu `extraFiles` hinzugefügt haben.
```
containerLogs:
fluentBit:
config:
extraFiles:
application-log.conf: ""
```
### Verwalten von Kubernetes-Toleranzen für die installierten Pod-Workloads
Ab Version 1.7.0 des Amazon CloudWatch Observability EKS-Add-ons legen das Add-on und das Helm-Diagramm standardmäßig *Kubernetes-Toleranzen* fest, um alle Fehler in den Pod-Workloads zu tolerieren, die durch das Add-on oder das Helm-Diagramm installiert werden. Dadurch wird sichergestellt, dass Daemonsets wie der CloudWatch Agent und Fluent Bit standardmäßig Pods auf allen Knoten in Ihrem Cluster planen können. Weitere Informationen zu Taints und Toleranzen finden Sie unter [Taints und Toleranzen](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) in der Kubernetes-Dokumentation.
Die vom Add-on oder dem Helm-Chart festgelegten Standardtoleranzen lauten wie folgt:
```
tolerations:
- operator: Exists
```
Sie können die Standardtoleranzen überschreiben, indem Sie das Feld `tolerations` auf der Stammebene festlegen, wenn Sie die erweiterte Konfiguration des Add-ons verwenden oder wenn Sie das Helm-Chart mit Wertüberschreibungen installieren oder aktualisieren. Ein Beispiel könnte folgendermaßen aussehen:
```
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
```
Um Toleranzen vollständig auszulassen, können Sie eine Konfiguration verwenden, die wie die folgende aussieht:
```
tolerations: []
```
Alle Änderungen an den Toleranzen gelten für alle Pod-Workloads, die durch das Add-on oder das Helm-Chart installiert werden.
### Deaktivieren der Erfassung von Accelerated Compute-Metriken
Standardmäßig erfasst Container Insights mit verbesserter Observability Metriken für die Accelerated Compute-Überwachung, darunter NVIDIA-GPU-Metriken, AWS Neuron-Metriken für AWS Trainium und AWS Inferentia sowie AWS Elastic Fabric Adapter (EFA) -Metriken.
NVIDIA-GPU-Metriken von Amazon EKS-Workloads werden standardmäßig erfasst, beginnend mit `v1.3.0-eksbuild.1` der Version des EKS-Add-ons oder des Helm-Diagramms und `1.300034.0` der Version des CloudWatch Agenten. Eine Liste der erfassten Metriken und der Voraussetzungen finden Sie unter [NVIDIA-GPU-Metriken](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-GPU).
AWS Neuron-Metriken für AWS Trainium- und AWS Inferentia-Beschleuniger werden standardmäßig erfasst, beginnend mit `v1.5.0-eksbuild.1` der Version des EKS-Add-ons oder des Helm-Diagramms und der Version des Agenten. `1.300036.0` CloudWatch Eine Liste der erfassten Metriken und der Voraussetzungen finden Sie unter [AWS Neuronenmetriken für AWS Trainium und Inferentia AWS](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-Neuron).
AWS Elastic Fabric Adapter (EFA) -Metriken von Linux-Knoten auf Amazon EKS-Clustern werden standardmäßig erfasst, beginnend mit `v1.5.2-eksbuild.1` der Version des EKS-Add-ons oder des Helm-Diagramms und `1.300037.0` der Version des CloudWatch Agenten. Eine Liste der erfassten Metriken und der Voraussetzungen finden Sie unter [AWS Metriken für Elastic Fabric Adapter (EFA)](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EFA).
Sie können die Erfassung dieser Metriken deaktivieren, indem Sie das `accelerated_compute_metrics` Feld in der CloudWatch Agenten-Konfigurationsdatei auf `false` setzen. Dieses Feld befindet sich im `kubernetes` Abschnitt des `metrics_collected` Abschnitts in der CloudWatch Konfigurationsdatei. Im Folgenden finden Sie eine Opt-out-Beispielkonfiguration. Weitere Informationen zur Verwendung benutzerdefinierter CloudWatch Agentenkonfigurationen finden Sie im folgenden Abschnitt,[Verwenden Sie eine benutzerdefinierte CloudWatch Agentenkonfiguration](#CloudWatch-Observability-EKS-addon-CustomAgentConfig).
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true,
"accelerated_compute_metrics": false
}
}
}
}
```
### Verwenden Sie eine benutzerdefinierte CloudWatch Agentenkonfiguration
Um andere Metriken, Logs oder Traces mithilfe des CloudWatch Agenten zu erfassen, können Sie eine benutzerdefinierte Konfiguration angeben und gleichzeitig Container Insights und CloudWatch Application Signals aktiviert lassen. Betten Sie dazu die CloudWatch Agentenkonfigurationsdatei in den Konfigurationsschlüssel unter dem Agentenschlüssel der erweiterten Konfiguration ein, den Sie bei der Erstellung oder Aktualisierung des EKS-Add-ons oder des Helm-Diagramms verwenden können. Im Folgenden wird die standardmäßige Agentenkonfiguration dargestellt, wenn Sie keine zusätzliche Konfiguration angeben.
**Wichtig**
Jede benutzerdefinierte Konfiguration, die Sie mithilfe zusätzlicher Konfigurationseinstellungen angeben, hat Vorrang vor der vom Agenten verwendeten Standardkonfiguration. Achten Sie darauf, standardmäßig aktivierte Funktionen wie Container Insights mit verbesserter Beobachtbarkeit und CloudWatch Application Signals nicht ungewollt zu deaktivieren. In dem Szenario, bei dem Sie eine benutzerdefinierte Agentenkonfiguration bereitstellen müssen, empfehlen wir, die folgende Standardkonfiguration als Basiskonfiguration zu verwenden und sie dann entsprechend zu ändern.
+ Für die Verwendung des Amazon CloudWatch Observability EKS-Add-ons
```
--configuration-values '{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
}'
```
+ Zur Verwendung des Helm-Charts
```
--set agent.config='{
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}'
```
Das folgende Beispiel zeigt die Standard-Agentenkonfiguration für den CloudWatch Agenten unter Windows. Der CloudWatch Agent unter Windows unterstützt keine benutzerdefinierte Konfiguration.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
},
}
}
}
```
### Webhook-TLS-Zulassungszertifikate verwalten
Das Amazon CloudWatch Observability EKS-Add-on und das Helm-Diagramm nutzen [Kubernetes-Zulassungswebhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) zur Validierung und Mutation sowie `Instrumentation` benutzerdefinierte Ressourcenanfragen (CR) `AmazonCloudWatchAgent` und optional Kubernetes-Pod-Anfragen auf dem Cluster, wenn Application Signals aktiviert ist. CloudWatch In Kubernetes benötigen Webhooks ein TLS-Zertifikat, dem der API-Server vertraut, um die sichere Kommunikation zu gewährleisten.
Standardmäßig generieren das Amazon CloudWatch Observability EKS-Add-on und das Helm-Diagramm automatisch eine selbstsignierte CA und ein von dieser CA signiertes TLS-Zertifikat, um die Kommunikation zwischen dem API-Server und dem Webhook-Server zu sichern. Dieses automatisch generierte Zertifikat hat eine Standardablaufzeit von 10 Jahren und wird nach Ablauf nicht automatisch verlängert. Darüber hinaus werden das CA-Paket und das Zertifikat jedes Mal neu generiert, wenn das Add-on oder das Helm-Chart aktualisiert oder neu installiert wird, wodurch der Ablauf zurückgesetzt wird. Wenn Sie den Standardablauf des automatisch generierten Zertifikats ändern möchten, können Sie beim Erstellen oder Aktualisieren des Add-Ons die folgenden zusätzlichen Konfigurationen verwenden. Ersetzen Sie es *expiry-in-days* durch die gewünschte Ablaufdauer in Tagen.
+ Verwenden Sie dies für das Amazon CloudWatch Observability EKS-Add-on
```
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": expiry-in-days } } }'
```
+ Verwenden Sie dies für das Helm-Chart
```
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
```
Für eine sicherere und featurereichere Zertifizierungsstellen-Lösung bietet das Add-On optionale Unterstützung für [cert-manager](https://cert-manager.io/docs/), eine weit verbreitete Lösung für die Verwaltung von TLS-Zertifikaten in Kubernetes, die den Prozess der Beschaffung, Verlängerung, Verwaltung und Verwendung dieser Zertifikate vereinfacht. Dies stellt sicher, dass Zertifikate gültig und aktuell sind, und versucht, Zertifikate zu einem konfigurierten Zeitpunkt vor Ablauf zu erneuern. cert-manager erleichtert auch die Ausstellung von Zertifikaten aus einer Vielzahl unterstützter Quellen, einschließlich [AWS Certificate Manager Private Certificate Authority](https://aws.amazon.com/private-ca/).
Wir empfehlen Ihnen, sich mit den bewährten Methoden für die Verwaltung von TLS-Zertifikaten auf Ihren Clustern vertraut zu machen und sich für Produktionsumgebungen für cert-manager zu entscheiden. Beachten Sie, dass Sie, wenn Sie sich dafür entscheiden, den Cert-Manager für die Verwaltung der Zulassungs-Webhook-TLS-Zertifikate zu aktivieren, cert-manager auf Ihrem Amazon EKS-Cluster vorinstallieren müssen, bevor Sie das Amazon CloudWatch Observability EKS-Add-on oder das Helm-Diagramm installieren. Weitere Informationen zu den verfügbaren Installationsoptionen finden Sie in der [cert-manager-Dokumentation](https://cert-manager.io/docs/installation/). Nach der Installation können Sie sich dafür entscheiden, cert-manager für die Verwaltung der Webhook-TLS-Zugangszertifikate zu verwenden. Verwenden Sie dazu die folgende zusätzliche Konfiguration.
+ Wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
+ Wenn Sie das Helm-Chart verwenden
```
--set admissionWebhooks.certManager.enabled=true
```
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
Die in diesem Abschnitt beschriebene erweiterte Konfiguration verwendet standardmäßig einen [ SelfSigned](https://cert-manager.io/docs/configuration/selfsigned/)Emittenten.
### Amazon EBS-Volume sammeln IDs
Wenn Sie das Amazon EBS-Volume IDs in den Leistungsprotokollen erfassen möchten, müssen Sie der IAM-Rolle, die den Worker-Knoten oder dem Servicekonto zugeordnet ist, eine weitere Richtlinie hinzufügen. Fügen Sie Folgendes als eingebundenen Richtlinie hinzu. Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
## Erfassung von Java Management Extensions (JMX)-Metriken
Der CloudWatch Agent unterstützt die Erfassung von Java Management Extensions (JMX) -Metriken auf Amazon EKS. Sie können damit zusätzliche Metriken von Java-Anwendungen erfassen, die auf Amazon-EKS-Clustern ausgeführt werden, und Einblicke in Leistung, Speicherverbrauch, Datenverkehr und andere wichtige Metriken erhalten. Weitere Informationen finden Sie unter [Erfassung von Java Management Extensions (JMX)-Metriken](CloudWatch-Agent-JMX-metrics.md).
## Aktivieren von Kueue-Metriken
Ab `v2.4.0-eksbuild.1` der Version des CloudWatch Observability EKS-Add-ons unterstützt Container Insights for Amazon EKS die Erfassung von Kueue-Metriken aus Amazon EKS-Clustern. Weitere Informationen zu diesen Metriken finden Sie unter [Kueue-Metriken](Container-Insights-metrics-EKS.md#Container-Insights-metrics-Kueue).
Wenn Sie das Amazon SageMaker AI Hyperpod Task Governance EKS-Add-on verwenden, können Sie die Schritte im Abschnitt **Voraussetzungen** überspringen und einfach den Schritten unter folgen. [Das Konfigurations-Flag aktivieren](#enable-Kueue-metrics-flag)
### Voraussetzungen
Bevor Sie Kueue in Ihrem Amazon-EKS-Cluster installieren, nehmen Sie die folgenden Aktualisierungen in der Manifestdatei vor:
1. Aktivieren Sie die optionalen Cluster-Warteschlangenressourcen-Metriken für Kueue. Ändern Sie dazu die Inline `controller_manager_config.yaml` in der. `kueue-system` ConfigMap Fügen Sie im Abschnitt `metrics` die Zeile `enableClusterQueueResources: true` hinzu oder entfernen Sie sie.
```
apiVersion: v1
data:
controller_manager_config.yaml: |
apiVersion: config.kueue.x-k8s.io/v1beta1
kind: Configuration
health:
healthProbeBindAddress: :8081
metrics:
bindAddress: :8080
enableClusterQueueResources: true <-- ADD/UNCOMMENT THIS LINE
```
1. Standardmäßig sind alle `k8s`-Services clusterweit verfügbar. Kueue erstellt den Service `kueue-controller-manager-metrics-service` zum Bereitstellen der Metriken. Um doppelte Beobachtungen für Metriken zu vermeiden, ändern Sie diesen Service so, dass nur der Zugriff auf den Metrik-Service von demselben Knoten aus möglich ist. Fügen Sie dazu die Zeile `internalTrafficPolicy: Local` zur Definition `kueue-controller-manager-metrics-service` hinzu.
```
apiVersion: v1
kind: Service
metadata:
labels:
...
name: kueue-controller-manager-metrics-service
namespace: kueue-system
spec:
ports:
- name: https
port: 8443
protocol: TCP
targetPort: https
internalTrafficPolicy: Local <-- ADD THIS LINE
selector:
control-plane: controller-manager
```
1. Schließlich erstellt der Pod `kueue-controller-manager` einen Container `kube-rbac-proxy`. Dieser Container wird derzeit ausführlich protokolliert, was dazu führt, dass das Bearer-Token des Clusters von diesem Container erfasst wird, wenn der Metrik-Scraper auf `kueue-controller-manager-metrics-service` zugreift. Es wird empfohlen, die Ausführlichkeit der Protokollierung zu verringern. Der Standardwert im von Kueue verteilten Manifest ist 10. Wir empfehlen, ihn auf 0 zu ändern.
```
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
...
name: kueue-controller-manager
namespace: kueue-system
spec:
...
template:
...
spec:
containers:
...
- args:
- --secure-listen-address=0.0.0.0:8443
- --upstream=http://127.0.0.1:8080/
- --logtostderr=true
- --v=0 <-- CHANGE v=10 TO v=0
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
name: kube-rbac-proxy
...
```
### Das Konfigurations-Flag aktivieren
Um die Kueue-Metriken zu aktivieren, müssen Sie `kueue_container_insights` im Add-on aktivieren. Sie können dies entweder mit dem AWS CLI zur Einrichtung des EKS Observability Add-ons oder mit der Amazon EKS-Konsole tun.
Nachdem Sie das EKS Observability-Add-on mit einer der folgenden Methoden erfolgreich installiert haben, können Sie Ihre Amazon EKS-Cluster-Metriken auf der Registerkarte **Dashboard** der HyperPod Konsole einsehen.
------
#### [ AWS CLI ]
**Um Kueue-Metriken zu aktivieren, verwenden Sie AWS CLI**
+ Geben Sie den folgenden AWS CLI Befehl ein, um das Add-on zu installieren.
```
aws eks create-addon --cluster-name cluster-name --addon-name amazon-cloudwatch-observability --configuration-values "configuration_json_file"
```
Im Folgenden finden Sie ein Beispiel für die JSON-Datei mit den Konfigurationswerten.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
#### [ Amazon EKS console ]
**So aktivieren Sie Kueue-Metriken mithilfe der Amazon-EKS-Konsole**
1. Öffnen Sie die Amazon EKS-Konsole unter [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen Ihres Clusters aus.
1. Wählen Sie **Add-ons** aus.
1. Suchen Sie das **Amazon CloudWatch Observability-Add-on** in der Liste und installieren Sie es. Wählen Sie **Optionale Konfiguration** aus und geben Sie die folgenden JSON-Konfigurationswerte an.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
## OpenTelemetry Collector-Konfigurationsdateien anhängen
Der CloudWatch Agent unterstützt neben seinen eigenen Konfigurationsdateien auch zusätzliche OpenTelemetry Collector-Konfigurationsdateien. Mit dieser Funktion können Sie CloudWatch Agentenfunktionen wie CloudWatch Application Signals oder Container Insights über die CloudWatch Agentenkonfiguration nutzen und Ihre bestehende OpenTelemetry Collector-Konfiguration mit einem einzigen Agenten integrieren.
Um Zusammenführungskonflikte mit automatisch vom CloudWatch Agenten erstellten Pipelines zu vermeiden, empfehlen wir, dass Sie jeder Komponente und Pipelines in Ihrer OpenTelemetry Collector-Konfiguration ein benutzerdefiniertes Suffix hinzufügen. Dadurch werden Komplikationen und Merge-Konflikte vermieden.
+ Wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden
```
--configuration-values file://values.yaml
```
oder
```
--configuration-values '
agent:
otelConfig:
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
+ Wenn Sie das Helm-Chart verwenden
```
--set agent.otelConfig='
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
## Aktivierung von APM über Application Signals für Ihren Amazon EKS-Cluster
Standardmäßig wird die OpenTelemetry (OTEL) -basierte Überwachung der Anwendungsleistung (APM) über Application Signals aktiviert, wenn entweder das CloudWatch Observability EKS-Add-on (V5.0.0 oder höher) oder das Helm-Diagramm installiert wird. Sie können spezifische Einstellungen mithilfe der erweiterten Konfiguration für das Amazon-EKS-Add-on weiter anpassen oder indem Sie Werte mit dem Helm-Chart überschreiben.
**Anmerkung**
Wenn Sie eine OpenTelemetry (OTEL) -basierte APM-Lösung verwenden, wirkt sich die Aktivierung von Application Signals auf Ihr bestehendes Observability-Setup aus. Überprüfen Sie Ihre aktuelle Implementierung, bevor Sie fortfahren. Informationen zur Beibehaltung Ihres vorhandenen APM-Setups nach dem Upgrade auf Version 5.0.0 oder höher finden Sie unter. [Melden Sie sich von Application Signals ab](#Opting-out-App-Signals)
**Automatische Überwachung für Application Signals**
Version 5.0.0 des Amazon EKS-Add-ons CloudWatch Observability und des Helm-Diagramms bietet neue Funktionen. Sie können Application Signals jetzt automatisch für alle oder bestimmte Service-Workloads in Ihrem EKS-Cluster über die Auto-Monitor-Konfiguration aktivieren. Die folgenden `autoMonitor`-Einstellungen können im Abschnitt `applicationSignals` unter dem Abschnitt `manager` der erweiterten Konfiguration angegeben werden.
+ *monitorAllServices*— Ein boolesches Flag, um die Überwachung aller Service-Workloads durch Auto Monitor zu aktivieren (true) oder zu deaktivieren (false). Standardwert ist „true“. Durch die Aktivierung dieses Flags wird sichergestellt, dass alle Kubernetes-Workloads (Deployments DaemonSets, und StatefulSets) im Cluster, die einem Kubernetes-Dienst zugeordnet sind, für die automatische Aktivierung von Application Signals gelten, wenn sie zum ersten Mal gestartet werden (oder wenn sie für bestehende Workloads neu gestartet werden). Das System schließt standardmäßig Workloads in den Namespaces `kube-system` und `amazon-cloudwatch` aus.
+ *languages*: Eine String-Liste, die angibt, mit welchen Sprachen Application Signals versuchen wird, Ihre Services automatisch zu instrumentieren, wenn `monitorAllServices` aktiviert ist. Standardmäßig werden alle [unterstützten Sprachen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) verwendet.
+ *restartPods*: Ein boolesches Flag steuert, ob Workloads nach Konfigurationsänderungen neu gestartet werden. Standardwert "false". Durch die Aktivierung dieses Flags mit `true` wird gesteuert, ob Kubernetes-Workloads im Auto-Monitor-Bereich beim Speichern von Konfigurationsänderungen automatisch neu gestartet werden. Alle Einstellungen in Ihren Kubernetes-Workloads, die sich auf den Neustart der Pods auswirken, wie `updateStrategy`, werden berücksichtigt. Bedenken Sie, dass ein Neustart zu Serviceausfällen führen kann.
+ *customSelector*: Einstellungen zur Auswahl bestimmter Kubernetes-Namespaces oder Workloads für Auto-Monitor.
+ *java*: Geben Sie Workloads an, die automatisch mit Java instrumentiert werden sollen
+ *python*: Geben Sie Workloads an, die automatisch mit Python instrumentiert werden sollen
+ *nodejs*: Geben Sie Workloads an, die automatisch mit Node.js instrumentiert werden sollen
+ *dotnet*: Geben Sie Workloads an, die automatisch mit .NET instrumentiert werden sollen
Für jede der oben genannten Sprachen können die folgenden Felder konfiguriert werden.
+ *namespaces*: Eine String-Liste der Namespaces, die ausgewählt werden können. Standardmäßig ist die Liste leer, also []
+ *deployment*: Eine String-Liste der Bereitstellungen, die ausgewählt werden können. Im Format `namespace/deployment` angeben. Standardmäßig ist die Liste leer, also []
+ *daemonsets*: Eine String-Liste der daemonsets, die ausgewählt werden können. Im Format `namespace/daemonset` angeben. Standardmäßig ist die Liste leer, also []
+ *statefulsets*: Eine String-Liste der statefulsets, die ausgewählt werden können. Im Format `namespace/statefulset` angeben. Standardmäßig ist die Liste leer, also []
+ *exclude*: Einstellungen zum Ausschluss bestimmter Kubernetes-Namespaces oder Workloads von Auto-Monitor. Das Ausschließen eines Workloads hat Vorrang, wenn derselbe Workload auch im Geltungsbereich von `monitorAllServices` oder `customSelector` liegt.
+ *java*: Geben Sie Workloads an, die nicht automatisch mit Java instrumentiert werden sollen
+ *python*: Geben Sie Workloads an, die nicht automatisch mit Python instrumentiert werden sollen
+ *nodejs*: Geben Sie Workloads an, die nicht automatisch mit Node.js instrumentiert werden sollen
+ *dotnet*: Geben Sie Workloads an, die nicht automatisch mit .NET instrumentiert werden sollen
Für jede der oben genannten Sprachen können die folgenden Felder konfiguriert werden.
+ *namespaces*: Eine String-Liste der Namespaces, die ausgeschlossen werden sollen. Standardmäßig ist die Liste leer, also []
+ *deployment*: Eine String-Liste der Bereitstellungen, die ausgeschlossen werden sollen. Im Format `namespace/deployment` angeben. Standardmäßig ist die Liste leer, also []
+ *daemonsets*: Eine String-Liste der daemonsets, die ausgeschlossen werden sollen. Im Format `namespace/daemonset` angeben. Standardmäßig ist die Liste leer, also []
+ *statefulsets*: Eine String-Liste der statefulsets, die ausgeschlossen werden sollen. Im Format `namespace/statefulset` angeben. Standardmäßig ist die Liste leer, also []
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals automatisch für alle vorhandenen und neuen Service-Workloads auf dem Cluster aktiviert.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
restartPods: true
```
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals automatisch für jeden neuen Service-Workload aktiviert, der gestartet wird, und für jeden vorhandenen Service-Workload, der explizit auf dem Cluster neu gestartet wird.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
```
Die folgende Beispielkonfiguration aktiviert automatisch Application Signals mit Java für alle vorhandenen und neuen Pods, die einem Workload im Namespace `pet-warehouse` entsprechen.
```
manager:
applicationSignals:
autoMonitor:
restartPods: true
customSelector:
java:
namespaces: ["pet-warehouse"]
```
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals with Python automatisch für alle vorhandenen und neuen Service-Workloads im Cluster mit Ausnahme der Bereitstellung `pet-clinic` aktiviert.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["python"]
restartPods: true
exclude:
python:
deployments: ["pet-warehouse/pet-clinic"]
```
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals mit Java automatisch für alle Service-Workloads im Cluster mit Ausnahme der Workloads im Namespace `python-apps` aktiviert und außerdem Application Signals mit Python speziell für die Bereitstellung `sample-python-app` im Namespace `python-apps` aktiviert.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["java"]
restartPods: true
customSelector:
python:
deployments: ["python-apps/sample-python-app"]
exclude:
java:
namespaces: ["python-apps"]
```
## Fehlerbehebung beim Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm
Verwenden Sie die folgenden Informationen, um Probleme mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm zu beheben
**Topics**
+ [Aktualisieren und Löschen des Amazon CloudWatch Observability EKS-Add-ons oder des Helm-Diagramms](#EKS-addon-troubleshoot-update)
+ [Überprüfen Sie die Version des CloudWatch Agenten, die vom Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm verwendet wird](#EKS-addon-troubleshoot-version)
+ [Umgang mit a ConfigurationConflict bei der Verwaltung des Add-ons oder des Helm-Charts](#EKS-addon-troubleshoot-conflict)
### Aktualisieren und Löschen des Amazon CloudWatch Observability EKS-Add-ons oder des Helm-Diagramms
Anweisungen zum Aktualisieren oder Löschen des Amazon CloudWatch Observability EKS-Add-ons finden Sie unter [Amazon EKS-Add-Ons verwalten](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html). Verwenden Sie als `amazon-cloudwatch-observability` Name des Add-Ons.
Geben Sie den folgenden Befehl ein, um das Helm-Chart in einem Cluster zu löschen:
```
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
```
### Überprüfen Sie die Version des CloudWatch Agenten, die vom Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm verwendet wird
Das Amazon CloudWatch Observability EKS-Add-on und das Helm-Diagramm installieren eine benutzerdefinierte Art von Ressource`AmazonCloudWatchAgent`, die das Verhalten des CloudWatch Agenten-Daemonsets auf dem Cluster steuert, einschließlich der Version des verwendeten CloudWatch Agenten. Sie können eine Liste aller auf Ihrem Cluster installierten, benutzerdefinierten `AmazonCloudWatchAgent`-Ressourcen abrufen, indem Sie den folgenden Befehl eingeben:
```
kubectl get amazoncloudwatchagent -A
```
In der Ausgabe dieses Befehls sollten Sie in der Lage sein, die Version des Agenten zu überprüfen. CloudWatch Alternativ können Sie auch die `amazoncloudwatchagent`-Ressource oder einen der `cloudwatch-agent-*`-Pods beschreiben, die auf Ihrem Cluster ausgeführt werden, um das verwendete Image zu überprüfen.
### Umgang mit a ConfigurationConflict bei der Verwaltung des Add-ons oder des Helm-Charts
Wenn Sie bei der Installation oder Aktualisierung des Amazon CloudWatch Observability EKS-Add-ons oder des Helm-Diagramms einen Fehler feststellen, der durch vorhandene Ressourcen verursacht wird, liegt dies wahrscheinlich daran, dass Sie den CloudWatch Agenten und die zugehörigen Komponenten wie den ServiceAccount, den ClusterRole und den bereits auf dem Cluster ClusterRoleBinding installiert haben.
Der vom Add-on angezeigte Fehler beinhaltet: `Conflicts found when trying to apply. Will not continue due to resolve conflicts mode`
Der im Helm-Chart angezeigte Fehler wird ähnlich sein wie `Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.`.
Wenn das Add-on oder das Helm-Diagramm versucht, den CloudWatch Agenten und die zugehörigen Komponenten zu installieren, und wenn es eine Änderung des Inhalts feststellt, schlägt die Installation oder Aktualisierung standardmäßig fehl, um zu verhindern, dass der Status der Ressourcen auf dem Cluster überschrieben wird.
Wenn Sie versuchen, das Amazon CloudWatch Observability EKS-Add-on zu integrieren und dieser Fehler auftritt, empfehlen wir, ein vorhandenes CloudWatch Agenten-Setup zu löschen, das Sie zuvor auf dem Cluster installiert hatten, und dann das EKS-Add-on oder das Helm-Diagramm zu installieren. Stellen Sie sicher, dass Sie alle Anpassungen, die Sie möglicherweise am ursprünglichen CloudWatch Agenten-Setup vorgenommen haben, wie z. B. eine benutzerdefinierte Agentenkonfiguration, sichern und diese bei der nächsten Installation oder Aktualisierung in das Add-on oder das Helm-Diagramm übernehmen. Wenn Sie den CloudWatch Agenten für das Onboarding in Container Insights bereits installiert hatten, finden Sie [Der CloudWatch Agent und Fluent Bit für Container Insights werden gelöscht](ContainerInsights-delete-agent.md) weitere Informationen unter.
Alternativ unterstützt das Add-On eine Konfigurationsoption zur Konfliktlösung, die `OVERWRITE` spezifizieren kann. Sie können diese Option verwenden, um mit der Installation oder Aktualisierung des Add-Ons fortzufahren, indem Sie die Konflikte auf dem Cluster überschreiben. Wenn Sie die Amazon-EKS-Konsole verwenden, finden Sie die **Methode zur Konfliktlösung**, wenn Sie beim Erstellen oder Aktualisieren des Add-Ons die **optionalen Konfigurationseinstellungen** auswählen. Wenn Sie den verwenden AWS CLI, können Sie den in Ihren Befehl eingeben, `--resolve-conflicts OVERWRITE` um das Add-on zu erstellen oder zu aktualisieren.
## Melden Sie sich von Application Signals ab
Passen Sie Ihre Einstellungen für die Dienstüberwachung in der CloudWatch Konsole oder mit dem SDK an.
Gehen Sie für Versionen vor 5.0.0 wie folgt vor, um die automatische Überwachung von Application Signals zu deaktivieren:
**CLI oder SDK verwenden**
Die folgende Konfiguration kann entweder als erweiterte Konfiguration für das EKS-Add-On oder als Werteüberschreibung bei Verwendung des Helmdiagramms angewendet werden.
```
{
"manager": {
"applicationSignals": {
"autoMonitor": {
"monitorAllServices": false
}
}
}
}
```
Starten Sie Ihre Dienste neu, damit die Änderungen wirksam werden.
**Verwenden der Konsole**
Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich unter **Application Signals (APM)** die Option **Services** aus.
1. Wählen Sie **Enable Application Signals** aus, um die Aktivierungsseite aufzurufen.
1. Deaktivieren Sie das Kontrollkästchen **Automatische Überwachung** für jeden Dienst, den Sie nicht überwachen möchten.
1. Starten Sie Ihre Dienste neu, damit die Änderungen wirksam werden.
# Richten Sie den CloudWatch Agenten mit Linux mit verbesserter Sicherheit ein () SELinux
Wenn auf Ihrem System das sicherheitserweiterte Linux (SELinux) aktiviert ist, müssen Sie die entsprechenden Sicherheitsrichtlinien anwenden, um sicherzustellen, dass der CloudWatch Agent in einer begrenzten Domäne ausgeführt wird.
## Voraussetzungen
**Bevor Sie den Agenten konfigurieren SELinux können, überprüfen Sie die folgenden Voraussetzungen:**
**Um die Voraussetzungen für die Verwendung des CloudWatch Agenten mit zu erfüllen SELinux**
1. Falls Sie dies noch nicht getan haben, installieren Sie die folgenden Entwicklungspakete SELinux für Richtlinien:
```
sudo yum update
sudo yum install -y selinux-policy-devel policycoreutils-devel rpm-build git
```
1. Führen Sie den folgenden Befehl aus, um den SELinux Status Ihres Systems zu überprüfen:
```
sestatus
```
Beispielausgabe:
```
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
```
Wenn Sie feststellen, dass dies derzeit deaktiviert SELinux ist, gehen Sie wie folgt vor:
1. Öffnen Sie die SELinux Datei, indem Sie den folgenden Befehl eingeben:
```
sudo vi /etc/selinux/config
```
1. Setzen Sie den `SELINUX`-Parameter auf `permissive` oder `enforcing`. Beispiel:
```
SELINUX=enforcing
```
1. Speichern Sie die Datei und starten Sie das System neu, um die Änderungen zu übernehmen.
```
sudo reboot
```
1. Stellen Sie sicher, dass der CloudWatch Agent als `systemd` Dienst ausgeführt wird. Dies ist erforderlich, um ihn innerhalb einer begrenzten SELinux Domäne zu verwenden.
```
sudo systemctl status amazon-cloudwatch-agent
```
Wenn der Agent korrekt konfiguriert ist, sollte beim Start `active (running)` und `enabled` ausgegeben werden.
## SELinux Für den Agenten konfigurieren
Nachdem Sie die Voraussetzungen erfüllt haben, können Sie konfigurieren SELinux.
**Um SELinux für den CloudWatch Agenten zu konfigurieren**
1. Klonen Sie die SELinux Richtlinie für den CloudWatch Agenten, indem Sie den folgenden Befehl eingeben:
```
git clone https://github.com/aws/amazon-cloudwatch-agent-selinux.git
```
1. Navigieren Sie zum geklonten Repository und aktualisieren Sie dann die Skriptberechtigungen, indem Sie die folgenden Befehle eingeben:
```
cd amazon-cloudwatch-agent-selinux
chmod +x amazon_cloudwatch_agent.sh
```
1. Dient `sudo` zum Ausführen des SELinux Richtlinien-Installationsskripts, indem Sie den folgenden Befehl eingeben. Während der Ausführung fordert Sie das Skript auf, `y` oder `n` einzugeben, um den automatischen Neustart zu ermöglichen. Durch diesen Neustart wird sichergestellt, dass der Agent in die richtige SELinux Domäne wechselt.
```
sudo ./amazon_cloudwatch_agent.sh
```
1. Wenn der CloudWatch Agent noch nicht neu gestartet wurde, starten Sie ihn neu, um sicherzustellen, dass er zur richtigen SELinux Domäne wechselt:
```
sudo systemctl restart amazon-cloudwatch-agent
```
1. Stellen Sie sicher, dass der CloudWatch Agent in der begrenzten Domäne ausgeführt wird, indem Sie den folgenden Befehl eingeben:
```
ps -efZ | grep amazon-cloudwatch-agent
```
Wenn der Agent korrekt eingeschränkt ist, sollte in der Ausgabe anstelle von `unconfined_service_t` eine SELinux -eingeschränkte Domäne angezeigt werden.
Nachstehend finden Sie ein Beispiel für eine Ausgabe, wenn der Agent korrekt eingeschränkt wurde.
```
system_u:system_r:confined_t:s0 root 1234 1 0 12:00 ? 00:00:10 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent
```
Nach SELinux der Konfiguration können Sie mit der Konfiguration des Agenten fortfahren, um Metriken, Protokolle und Traces zu sammeln. Weitere Informationen finden Sie unter [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md).
# Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei
Bevor Sie den CloudWatch Agenten auf einem beliebigen Server ausführen, müssen Sie eine oder mehrere CloudWatch Agenten-Konfigurationsdateien erstellen.
Die Konfigurationsdatei des Agenten ist eine JSON-Datei, in der die Metriken, Protokolle und Ablaufverfolgungen angegeben sind, die der Agent erfassen soll, einschließlich benutzerdefinierter Metriken. Sie können sie mithilfe des Assistenten oder selbst von Grund auf erstellen. Sie können die Konfigurationsdatei auch mit dem Assistenten erstellen und dann manuell anpassen. Wenn Sie die Datei manuell erstellen oder bearbeiten, ist der Prozess komplizierter. Sie haben jedoch mehr Kontrolle über die erfassten Metriken und können Metriken angeben, die im Assistenten nicht verfügbar sind.
Bei jeder Änderung der Agent-Konfigurationsdatei müssen Sie den Agent neu starten, damit die Änderungen wirksam werden. Um den Agent neu zu starten, befolgen Sie die Anweisungen in [(Optional) Ändern Sie die allgemeine Konfiguration und das benannte Profil für den CloudWatch Agenten](installing-cloudwatch-agent-ssm.md#CloudWatch-Agent-profile-instance-fleet).
Sie können die erstellte Konfigurationsdatei als JSON-Datei speichern und später für die Installation des Agenten auf Ihren Servern verwenden. Alternativ können Sie die Datei in Systems Manager Parameter Store speichern, wenn Sie für die Agenteninstallation auf den Servern Systems Manager verwenden möchten.
Der CloudWatch Agent unterstützt die Verwendung mehrerer Konfigurationsdateien. Weitere Informationen finden Sie unter [Erstellen mehrerer CloudWatch Agenten-Konfigurationsdateien](#CloudWatch-Agent-multiple-config-files).
Für die vom CloudWatch Agenten gesammelten Metriken, Protokolle und Traces fallen Gebühren an. Weitere Informationen zur Preisgestaltung finden Sie unter [ CloudWatchAmazon-Preise](https://aws.amazon.com/cloudwatch/pricing).
**Topics**
+ [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei mit dem Assistenten](create-cloudwatch-agent-configuration-file-wizard.md)
+ [Erstellen mehrerer CloudWatch Agenten-Konfigurationsdateien](#CloudWatch-Agent-multiple-config-files)
+ [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md)
# Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei mit dem Assistenten
Der Assistent für die Agentenkonfigurationsdatei`amazon-cloudwatch-agent-config-wizard`,, stellt eine Reihe von Fragen, um Ihnen bei der Konfiguration des CloudWatch Agenten für Ihre Bedürfnisse zu helfen. In diesem Abschnitt werden die für die Konfigurationsdatei erforderlichen Anmeldeinformationen beschrieben. Es wird beschrieben, wie der Assistent für die CloudWatch Agentenkonfiguration ausgeführt wird. Außerdem werden die Metriken beschrieben, die im Assistenten vordefiniert sind.
## Erforderliche Anmeldeinformationen
Der Assistent kann die zu verwendenden Anmeldeinformationen und die AWS Region automatisch erkennen, wenn Sie die AWS Anmeldeinformationen und die Konfigurationsdateien vor dem Start des Assistenten eingerichtet haben. Weitere Informationen zu diesen Dateien finden Sie unter [ Konfigurations- und Anmeldeinformationsdateien](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html) im *AWS Systems Manager -Benutzerhandbuch*.
In der AWS Anmeldeinformationsdatei sucht der Assistent nach Standardanmeldedaten und sucht auch nach einem `AmazonCloudWatchAgent` Abschnitt wie dem folgenden:
```
[AmazonCloudWatchAgent]
aws_access_key_id = my_access_key
aws_secret_access_key = my_secret_key
```
Der Assistent zeigt die Standard-Anmeldeinformationen, die Anmeldeinformationen aus `AmazonCloudWatchAgent` und die Option `Others` an. Sie können auswählen, welche Anmeldeinformationen verwendet werden sollen. Bei Wahl von `Others` (Andere), können Sie Anmeldeinformationen eingeben.
Verwenden Sie für *my\$1access\$1key* und *my\$1secret\$1key* die Schlüssel des IAM-Benutzers, der über Schreibberechtigungen für den Systems Manager Parameter Store verfügt.
In der AWS Konfigurationsdatei können Sie die Region angeben, an die der Agent Metriken sendet, falls es sich um eine andere Region als den `[default]` Abschnitt handelt. Die Voreinstellung ist, die Metriken in der Region zu veröffentlichen, in der sich die Amazon-EC2-Instance befindet. Wenn die Metriken in einer anderen Region veröffentlicht werden sollen, geben Sie hier die Region an. Im folgenden Beispiel werden die Metriken in der Region `us-west-1` veröffentlicht.
```
[AmazonCloudWatchAgent]
region = us-west-1
```
## Führen Sie den Assistenten zur CloudWatch Agentenkonfiguration aus
**Um die CloudWatch Agenten-Konfigurationsdatei zu erstellen**
1. Starten Sie den Assistenten zur CloudWatch Agentenkonfiguration, indem Sie Folgendes eingeben:
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
```
Führen Sie auf einem Server mit Windows Server die folgenden Befehle aus, um den Assistenten zu starten:
```
cd "C:\Program Files\Amazon\AmazonCloudWatchAgent"
```
```
.\amazon-cloudwatch-agent-config-wizard.exe
```
1. Beantworten Sie die Fragen zum Anpassen der Konfigurationsdatei für Ihren Server.
1. Wenn Sie die Konfigurationsdatei lokal speichern, wird die Konfigurationsdatei `config.json` in `/opt/aws/amazon-cloudwatch-agent/bin/` auf Linux-Servern und in `C:\Program Files\Amazon\AmazonCloudWatchAgent` auf Windows Server-Servern gespeichert. Anschließend können Sie diese Datei auf andere Server kopieren, auf denen der Agent installiert werden soll.
Wenn Sie Systems Manager zum Installieren und Konfigurieren des Agenten verwenden, müssen Sie mit **Yes (Ja)** antworten, wenn Sie gefragt werden, ob Sie die Datei in Systems Manager Parameter Store speichern möchten. Sie können sich auch dafür entscheiden, die Datei im Parameter Store zu speichern, auch wenn Sie den SSM-Agent nicht zur Installation des CloudWatch Agenten verwenden. Zum Speichern der Datei in Parameter Store müssen Sie eine IAM-Rolle mit ausreichenden Berechtigungen verwenden.
## CloudWatch Vordefinierte Metriksätze für Agenten
Der Assistent ist mit vordefinierten Metrikkategorien mit unterschiedlichen Detailebenen konfiguriert. Diese Metrikkategorien werden in den folgenden Tabellen dargestellt. Weitere Informationen zu diesen Metriken finden Sie unter [Vom CloudWatch Agenten gesammelte Metriken](metrics-collected-by-CloudWatch-agent.md).
**Anmerkung**
Parameter Store unterstützt Parameter in den Stufen „Standard“ und „Advanced“. Diese Parameterebenen beziehen sich nicht auf die Ebenen „Basic“, „Standard“ und „Advanced“ der Metrikdetails, die in diesen Tabellen beschrieben werden.
**Amazon-EC2-Instances mit Linux**
| Detailstufe | Enthaltene Metriken |
| --- | --- |
| **Basic** | **Mem:** mem\$1used\$1percent **Disk:** disk\$1used\$1percent Die `disk`-Metriken wie `disk_used_percent` haben eine Dimension für `Partition`, was bedeutet, dass die Anzahl der generierten benutzerdefinierten Metriken von der Anzahl der Partitionen abhängt, die Ihrer Instance zugeordnet sind. Die Anzahl der Festplattenpartitionen hängt davon ab, welches AMI Sie verwenden, und wie viele Amazon-EBS-Volumes Sie an den Server anfügen. |
| **Standard** | **CPU:** `cpu_usage_idle`, `cpu_usage_iowait`, `cpu_usage_user`, `cpu_usage_system` **Disk:** `disk_used_percent`, `disk_inodes_free` **Diskio:** `diskio_io_time` **Mem:** `mem_used_percent` **Swap:** `swap_used_percent` |
| **Advanced** | **CPU:** `cpu_usage_idle`, `cpu_usage_iowait`, `cpu_usage_user`, `cpu_usage_system` **Disk:** `disk_used_percent`, `disk_inodes_free` **Diskio:** `diskio_io_time`, `diskio_write_bytes`, `diskio_read_bytes`, `diskio_writes`, `diskio_reads` **Mem:** `mem_used_percent` **Netstat:** `netstat_tcp_established`, `netstat_tcp_time_wait` **Swap:** `swap_used_percent` |
**On-Premises-Server mit Linux**
| Detailstufe | Enthaltene Metriken |
| --- | --- |
| **Basic** | **Disk:** `disk_used_percent` **Diskio:** `diskio_write_bytes`, `diskio_read_bytes`, `diskio_writes`, `diskio_reads` **Mem:** `mem_used_percent` **Net:** `net_bytes_sent`, `net_bytes_recv`, `net_packets_sent`, `net_packets_recv` **Swap:** `swap_used_percent` |
| **Standard** | **CPU:** `cpu_usage_idle`, `cpu_usage_iowait` **Disk:** `disk_used_percent`, `disk_inodes_free` **Diskio:** `diskio_io_time`, `diskio_write_bytes`, `diskio_read_bytes`, `diskio_writes`, `diskio_reads` **Mem:** `mem_used_percent` **Net:** `net_bytes_sent`, `net_bytes_recv`, `net_packets_sent`, `net_packets_recv` **Swap:** `swap_used_percent` |
| **Advanced** | **CPU:** `cpu_usage_guest`, `cpu_usage_idle`, `cpu_usage_iowait`, `cpu_usage_steal`, `cpu_usage_user`, `cpu_usage_system` **Disk:** `disk_used_percent`, `disk_inodes_free` **Diskio:** `diskio_io_time`, `diskio_write_bytes`, `diskio_read_bytes`, `diskio_writes`, `diskio_reads` **Mem:** `mem_used_percent` **Net:** `net_bytes_sent`, `net_bytes_recv`, `net_packets_sent`, `net_packets_recv` **Netstat:** `netstat_tcp_established`, `netstat_tcp_time_wait` **Swap:** `swap_used_percent` |
**Amazon-EC2-Instances mit Windows Server**
**Anmerkung**
Die in dieser Tabelle aufgeführten Metriknamen zeigen an, wie die Metrik in der Konsole angezeigt wird. Der tatsächliche Name der Metrik enthält möglicherweise nicht das erste Wort. Der tatsächliche Metrikname für `LogicalDisk % Free Space` lautet beispielsweise nur `% Free Space`.
| Detailstufe | Enthaltene Metriken |
| --- | --- |
| **Basic** | **Memory:** `Memory % Committed Bytes In Use` **LogicalDisk:** `LogicalDisk % Free Space` |
| **Standard** | **Memory:** `Memory % Committed Bytes In Use` **Paging:** `Paging File % Usage` **Processor:** `Processor % Idle Time`, `Processor % Interrupt Time`, `Processor % User Time` **PhysicalDisk:** `PhysicalDisk % Disk Time` **LogicalDisk:** `LogicalDisk % Free Space` |
| **Advanced** | **Memory:** `Memory % Committed Bytes In Use` **Paging:** `Paging File % Usage` **Processor:** `Processor % Idle Time`, `Processor % Interrupt Time`, `Processor % User Time` **LogicalDisk:** `LogicalDisk % Free Space` **PhysicalDisk:** `PhysicalDisk % Disk Time`, `PhysicalDisk Disk Write Bytes/sec`, `PhysicalDisk Disk Read Bytes/sec`, `PhysicalDisk Disk Writes/sec`, `PhysicalDisk Disk Reads/sec` **TCP:** `TCPv4 Connections Established`, `TCPv6 Connections Established` |
**On-Premises-Server mit Windows Server**
**Anmerkung**
Die in dieser Tabelle aufgeführten Metriknamen zeigen an, wie die Metrik in der Konsole angezeigt wird. Der tatsächliche Name der Metrik enthält möglicherweise nicht das erste Wort. Der tatsächliche Metrikname für `LogicalDisk % Free Space` lautet beispielsweise nur `% Free Space`.
| Detailstufe | Enthaltene Metriken |
| --- | --- |
| **Basic** | **Paging: **`Paging File % Usage` **Processor:** `Processor % Processor Time` **LogicalDisk:**`LogicalDisk % Free Space` **PhysicalDisk:** `PhysicalDisk Disk Write Bytes/sec`, `PhysicalDisk Disk Read Bytes/sec`, `PhysicalDisk Disk Writes/sec`, `PhysicalDisk Disk Reads/sec` **Memory:** `Memory % Committed Bytes In Use` **Network Interface:** `Network Interface Bytes Sent/sec`, `Network Interface Bytes Received/sec`, `Network Interface Packets Sent/sec`, `Network Interface Packets Received/sec` |
| **Standard** | **Paging:** `Paging File % Usage` **Processor:** `Processor % Processor Time`, `Processor % Idle Time`, `Processor % Interrupt Time` **LogicalDisk:** `LogicalDisk % Free Space` **PhysicalDisk:** `PhysicalDisk % Disk Time`, `PhysicalDisk Disk Write Bytes/sec`, `PhysicalDisk Disk Read Bytes/sec`, `PhysicalDisk Disk Writes/sec`, `PhysicalDisk Disk Reads/sec` **Memory:** `Memory % Committed Bytes In Use` **Network Interface:** `Network Interface Bytes Sent/sec`, `Network Interface Bytes Received/sec`, `Network Interface Packets Sent/sec`, `Network Interface Packets Received/sec` |
| **Advanced** | **Paging:**`Paging File % Usage` **Processor:** `Processor % Processor Time`, `Processor % Idle Time`, `Processor % Interrupt Time`, `Processor % User Time` **LogicalDisk:** `LogicalDisk % Free Space` **PhysicalDisk:** `PhysicalDisk % Disk Time`, `PhysicalDisk Disk Write Bytes/sec`, `PhysicalDisk Disk Read Bytes/sec`, `PhysicalDisk Disk Writes/sec`, `PhysicalDisk Disk Reads/sec` **Memory:** `Memory % Committed Bytes In Use` **Network Interface:** `Network Interface Bytes Sent/sec`, `Network Interface Bytes Received/sec`, `Network Interface Packets Sent/sec`, `Network Interface Packets Received/sec` **TCP:** `TCPv4 Connections Established`, `TCPv6 Connections Established` |
# Beispiele für Konfigurationsdateien
**Grundlegende Konfiguration der Systemmetriken**
```
{
"agent": {
"metrics_collection_interval": 60,
"region": "us-east-1"
},
"metrics": {
"namespace": "MySystem",
"metrics_collected": {
"cpu": {
"resources": ["*"],
"measurement": ["usage_active", "usage_system", "usage_user"]
},
"mem": {
"measurement": ["used_percent"]
},
"disk": {
"resources": ["/"],
"measurement": ["used_percent"]
}
},
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
}
}
}
```
**Konfiguration der Webserver-Überwachung**
```
{
"agent": {
"metrics_collection_interval": 60,
"region": "us-east-1"
},
"metrics": {
"namespace": "WebServer",
"metrics_collected": {
"cpu": {
"resources": ["*"],
"measurement": ["usage_active"]
},
"mem": {
"measurement": ["used_percent"]
},
"net": {
"resources": ["eth0"],
"measurement": ["bytes_sent", "bytes_recv"]
}
}
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/apache2/access.log",
"log_group_name": "apache-access-logs",
"log_stream_name": "{instance_id}-access"
},
{
"file_path": "/var/log/apache2/error.log",
"log_group_name": "apache-error-logs",
"log_stream_name": "{instance_id}-error"
}
]
}
}
}
}
```
**Konfiguration des Datenbankservers**
```
{
"agent": {
"metrics_collection_interval": 30,
"region": "us-east-1"
},
"metrics": {
"namespace": "DatabaseServer",
"metrics_collected": {
"cpu": {
"resources": ["*"],
"measurement": ["usage_active", "usage_iowait"]
},
"mem": {
"measurement": ["used_percent", "available_percent"]
},
"disk": {
"resources": ["/", "/data"],
"measurement": ["used_percent", "inodes_free"]
},
"diskio": {
"resources": ["*"],
"measurement": ["read_bytes", "write_bytes", "io_time"]
}
},
"append_dimensions": {
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
}
}
}
```
## Erstellen mehrerer CloudWatch Agenten-Konfigurationsdateien
Sowohl auf Linux- als auch auf Windows-Servern können Sie den CloudWatch Agenten so einrichten, dass er mehrere Konfigurationsdateien verwendet. Sie können zum Beispiel eine gemeinsame Konfigurationsdatei verwenden, die eine Reihe von Metriken, Protokollen und Ablaufverfolgungen sammelt, die Sie immer von allen Servern in Ihrer Infrastruktur sammeln möchten. Anschließend können Sie zusätzliche Konfigurationsdateien verwenden, die Metriken aus bestimmten Anwendungen oder in bestimmten Situationen erfassen.
Um dies einzurichten, erstellen Sie zunächst die Konfigurationsdateien, die Sie verwenden möchten. Alle Konfigurationsdateien, die gemeinsam auf demselben Server benutzt werden, müssen unterschiedliche Dateinamen haben. Sie können die Konfigurationsdateien auf Servern oder in Parameter Store speichern.
Starten Sie den CloudWatch Agenten mit der `fetch-config` Option und geben Sie die erste Konfigurationsdatei an. Um die zweite Konfigurationsdatei an den ausgeführten Agent anzufügen, verwenden Sie denselben Befehl, aber mit der `append-config`-Option. Alle Metriken, Protokolle und Ablaufverfolgungen, die in einer der beiden Konfigurationsdateien aufgeführt sind, werden gesammelt. Die folgenden Beispielbefehle veranschaulichen dieses Szenario mit Konfigurationen, die als Dateien gespeichert sind. Die erste Zeile startet den Agent mithilfe der `infrastructure.json`-Konfigurationsdatei und die zweite Zeile fügt die `app.json`-Konfigurationsdatei an.
Die folgenden Beispielbefehle sind für Linux.
```
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/tmp/infrastructure.json
```
```
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -m ec2 -s -c file:/tmp/app.json
```
Die folgenden Beispielbefehle sind für Windows Server.
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\infrastructure.json"
```
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a append-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\app.json"
```
Die folgenden Beispiel-Konfigurationsdateien veranschaulichen eine Nutzung für dieses Feature. Die erste Konfigurationsdatei wird für alle Server in der Infrastruktur verwendet, und die zweite erfasst nur Protokolle von einer bestimmten Anwendung und wird an Server angehängt, die die Anwendung ausführen.
**infrastructure.json**
```
{
"metrics": {
"metrics_collected": {
"cpu": {
"resources": [
"*"
],
"measurement": [
"usage_active"
],
"totalcpu": true
},
"mem": {
"measurement": [
"used_percent"
]
}
}
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log"
},
{
"file_path": "/var/log/messages",
"log_group_name": "/var/log/messages"
}
]
}
}
}
}
```
**app.json**
```
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/app/app.log*",
"log_group_name": "/app/app.log"
}
]
}
}
}
}
```
Die Dateinamen aller Konfigurationsdateien, die an die Konfiguration angehängt werden, müssen sich voneinander und vom Namen der anfänglichen Konfigurationsdatei unterscheiden. Wenn Sie `append-config` mit einer Konfigurationsdatei mit dem selben Dateinamen wie eine Konfigurationsdatei verwenden, die der Agent bereits verwendet, überschreibt der Append-Befehl die Informationen aus der ersten Konfigurationsdatei, anstatt Inhalte anzuhängen. Dies gilt auch, wenn sich zwei Konfigurationsdateien mit demselben Dateinamen in verschiedenen Dateipfaden befinden.
Das vorstehende Beispiel zeigt die Verwendung von zwei Konfigurationsdateien. Es gibt jedoch keine Beschränkungen hinsichtlich der Anzahl der Konfigurationsdateien, die Sie an die Agentenkonfiguration anhängen können. Sie können auch die Nutzung von Konfigurationsdateien auf Servern und Konfigurationen in Parameter Store kombinieren.
# Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell
Die CloudWatch Agenten-Konfigurationsdatei ist eine JSON-Datei mit vier Abschnitten: `agent``metrics`,`logs`, und`traces`.
+ Der Abschnitt `agent` enthält Felder für die allgemeine Konfiguration des Agenten.
+ `metrics`In diesem Abschnitt werden die benutzerdefinierten Metriken für die Erfassung und Veröffentlichung angegeben CloudWatch. Wenn Sie den Agenten nur verwenden, um Protokolle zu erfassen, können Sie den Abschnitt `metrics` in der Datei weglassen.
+ `logs`In diesem Abschnitt wird angegeben, welche Protokolldateien in CloudWatch Logs veröffentlicht werden. Hierbei kann es sich u. a. um Ereignisse aus dem Windows-Ereignisprotokoll handeln, wenn auf dem Server Windows Server ausgeführt wird.
+ `traces`In diesem Abschnitt werden die Quellen für Traces angegeben, die gesammelt und an sie gesendet werden AWS X-Ray.
In diesem Abschnitt werden die Struktur und die Felder der CloudWatch Agentenkonfigurationsdatei erläutert. Sie können die Schemadefinition für diese Konfigurationsdatei anzeigen. Die Schemadefinition befindet sich auf Linux-Servern unter `installation-directory/doc/amazon-cloudwatch-agent-schema.json` und auf Servern mit Windows Server unter `installation-directory/amazon-cloudwatch-agent-schema.json`.
Wenn Sie die -Agentenkonfigurationsdatei manuell erstellen oder bearbeiten, können Sie ihr einen beliebigen Namen geben. Zur Vereinfachung der Fehlerbehebung wird empfohlen, ihr auf Linux-Servern den Namen `/opt/aws/amazon-cloudwatch-agent/etc/cloudwatch-agent.json` und auf Servern, auf denen Windows Server ausgeführt wird, den Namen `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json` zu geben. Anschließend können Sie die Datei auf andere Server kopieren, auf denen der Agent installiert werden soll.
Wenn der Agent gestartet wird, erstellt er eine Kopie jeder Konfigurationsdatei im Verzeichnis `/opt/aws/amazon-cloudwatch/etc/amazon-cloudwatch-agent.d`, wobei dem Dateinamen entweder `file_` (für lokale Dateiquellen) oder `ssm_` (für Systems Manager Manager-Parameterspeicherquellen) vorangestellt wird, um den Ursprung der Konfiguration anzugeben.
**Anmerkung**
Für die vom CloudWatch Agenten gesammelten Metriken, Protokolle und Traces fallen Gebühren an. Weitere Informationen zur Preisgestaltung finden Sie unter [ CloudWatchAmazon-Preise](https://aws.amazon.com/cloudwatch/pricing).
## CloudWatch Agenten-Konfigurationsdatei: Abschnitt Agent
Der Abschnitt `agent` kann die folgenden Felder enthalten: Der Assistent erstellt keinen Abschnitt `agent`. Stattdessen lässt der Assistent diesen weg und verwendet die Standardwerte für alle Felder in diesem Abschnitt.
+ `metrics_collection_interval` – Optional. Gibt an, wie oft alle in dieser Konfigurationsdatei angegebenen Metriken erfasst werden. Sie können den Wert für bestimmte Arten von Metriken überschreiben.
Der Wert wird in Sekunden angegeben. Beispiel: Angeben, dass 10 Metriken alle 10 Sekunden und 300 Metriken alle 5 Minuten gesammelt werden sollen.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen zu hochauflösenden Metriken finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
Der Standardwert lautet 60.
+ `region`— Gibt die Region an, die für den CloudWatch Endpunkt verwendet werden soll, wenn eine Amazon EC2 EC2-Instance überwacht wird. Die gesammelten Metriken werden an diese Region gesendet, wie z. B. `us-west-1`. Wenn Sie dieses Feld weglassen, sendet der Agent Metriken an die Region, in der sich die Amazon-EC2-Instance befindet.
Wenn Sie einen On-Premises-Server überwachen, wird dieses Feld nicht verwendet, und der Agent liest die Region aus dem `AmazonCloudWatchAgent`-Profil der AWS -Konfigurationsdatei.
+ `credentials`— Gibt eine IAM-Rolle an, die beim Senden von Metriken, Protokollen und Traces an ein anderes AWS Konto verwendet werden soll. Sofern angegeben, enthält dieses Feld einen Parameter, `role_arn`.
+ `role_arn`— Gibt den Amazon-Ressourcennamen (ARN) einer IAM-Rolle an, der für die Authentifizierung verwendet werden soll, wenn Metriken, Logs und Traces an ein anderes AWS Konto gesendet werden. Weitere Informationen finden Sie unter [Metriken, Protokolle und Ablaufverfolgungen an ein anderes Konto senden](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account).
+ `debug` – Optional. Gibt an, dass der CloudWatch Agent mit Debug-Protokollmeldungen ausgeführt wird. Der Standardwert ist `false`.
+ `aws_sdk_log_level` – Optional. Wird nur in den Versionen 1.247350.0 und höher des Agenten unterstützt. CloudWatch
Sie können dieses Feld angeben, damit der Agent die Protokollierung für AWS SDK-Endpunkte durchführt. Der Wert für dieses Feld kann eine oder mehrere der folgenden Optionen enthalten. Trennen Sie mehrere Optionen mit dem `|`-Zeichen.
+ `LogDebug`
+ `LogDebugWithSigning`
+ `LogDebugWithHTTPBody`
+ `LogDebugRequestRetries`
+ `LogDebugWithEventStreamBody`
Weitere Informationen zu diesen Optionen finden Sie unter [LogLevelType](https://docs.aws.amazon.com/sdk-for-go/api/aws/#LogLevelType).
+ `logfile`— Gibt den Ort an, an dem der CloudWatch Agent Protokollnachrichten schreibt. Wenn Sie eine leere Zeichenfolge angeben, wird das Protokoll in stderr abgelegt. Wenn Sie diese Option nicht angeben, lauten die Standardspeicherorte folgendermaßen:
+ Linux: `/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log`
+ Windows Server: `c:\\ProgramData\\Amazon\\CloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log`
Der CloudWatch Agent rotiert die von ihm erstellte Protokolldatei automatisch. Eine Protokolldatei wird rotiert, wenn sie eine Größe von 100 MB erreicht. Der Agent bewahrt die rotierten Protokolldateien bis zu sieben Tage lang auf, und er behält bis zu fünf Backup-Protokolldateien, die ausgelagert werden. Die Dateinamen der Sicherungen von Protokolldateien werden um einen Zeitstempel ergänzt. Der Zeitstempel gibt das Datum und die Uhrzeit der Rotation an, z. B. `amazon-cloudwatch-agent-2018-06-08T21-01-50.247.log.gz`.
+ `omit_hostname` – Optional. Standardmäßig wird der Hostname als Dimension von Metriken veröffentlicht, die vom Agenten erfasst werden, es sei denn, Sie verwenden das `append_dimensions`-Feld im `metrics`-Abschnitt. Setzen Sie `omit_hostname ` auf `true`, um zu verhindern, dass der Hostname als Dimension veröffentlicht wird, auch wenn Sie `append_dimensions` nicht verwenden. Der Standardwert ist `false`.
+ `run_as_user` – Optional. Gibt einen Benutzer an, der zum Ausführen des CloudWatch -Agenten verwendet werden soll. Wenn Sie diesen Parameter nicht angeben, wird der Root-Benutzer verwendet. Diese Option ist nur auf Linux-Servern gültig.
Wenn Sie diese Option angeben, muss der Benutzer vorhanden sein, bevor Sie den CloudWatch Agenten starten. Weitere Informationen finden Sie unter [Den CloudWatch Agenten als anderer Benutzer ausführen](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-run-as-user).
+ `user_agent` – Optional. Gibt die `user-agent` Zeichenfolge an, die vom CloudWatch Agenten verwendet wird, wenn er API-Aufrufe an das CloudWatch Backend tätigt. Der Standardwert ist eine Zeichenfolge, die aus der Agentenversion, der Version der Go-Programmiersprache, die zum Kompilieren des Agenten verwendet wurde, dem Laufzeitbetriebssystem und der Architektur, der Buildzeit und den aktivierten Plugins besteht.
+ `usage_data` – Optional. Standardmäßig sendet der CloudWatch Agent Integritäts- und Leistungsdaten über sich selbst an, CloudWatch wann immer er Metriken oder Protokolle veröffentlicht. CloudWatch Für diese Daten entstehen Ihnen keine Kosten. Sie können verhindern, dass der Agent diese Daten sendet, indem Sie `false` für `usage_data` angeben. Wenn Sie diesen Parameter weglassen, wird der Standard von `true` verwendet, und der Agent sendet die Zustands- und Leistungsdaten.
Wenn Sie diesen Wert auf `false` setzen, müssen Sie den Agenten beenden und neu starten, damit die Änderung wirksam wird.
+ `service.name` – Optional. Gibt den Servicenamen an, der verwendet werden soll, um die Entität für die [Suche nach zugehöriger Telemetrie](ExploreRelated.md) mit Werten zu befüllen.
+ `deployment.environment` – Optional. Gibt den Umgebungsnamen an, der verwendet werden soll, um die Entität für die [Suche nach zugehöriger Telemetrie](ExploreRelated.md) mit Werten zu befüllen.
+ `use_dualstack_endpoint` – Optional. Wenn dies der Fall ist`true`, verwendet der CloudWatch Agent [Dual-Stack-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#dual-stack-endpoints) für alle API-Aufrufe.
Es folgt ein Beispiel für den Abschnitt `agent`.
```
"agent": {
"metrics_collection_interval": 60,
"region": "us-west-1",
"logfile": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
"debug": false,
"run_as_user": "cwagent"
}
```
## CloudWatch Agenten-Konfigurationsdatei: Abschnitt „Metriken“
### Gemeinsame Felder für Linux und Windows
Auf Servern mit Linux oder Windows Server enthält der Abschnitt `metrics` die folgenden Felder:
+ `namespace` – Optional. Der Namespace für die vom Agent zu erfassenden Metriken. Der Standardwert ist `CWAgent`. Die maximale Länge beträgt 255 Zeichen. Im Folgenden wird ein Beispiel gezeigt:
```
{
"metrics": {
"namespace": "Development/Product1Metrics",
......
},
}
```
+ `append_dimensions` – Optional. Fügt Amazon-EC2-Metrik-Dimensionen zu allen vom Agent erfassten Metriken hinzu. Dies bewirkt auch, dass der Agent den Hostnamen nicht als Dimension veröffentlicht.
Die einzigen unterstützten Schlüssel-Wert-Paare für `append_dimensions` werden in der folgenden Liste angezeigt. Alle anderen Schlüssel-Wert-Paare werden ignoriert. Der Agent unterstützt diese Schlüssel-Wert-Paare genau so, wie sie in der folgenden Liste aufgeführt sind. Sie können die Schlüsselwerte nicht ändern, um unterschiedliche Dimensionsnamen für sie zu veröffentlichen.
+ `"ImageId":"${aws:ImageId}"` legt die AMI-ID der Instance als Wert der `ImageId`-Dimension fest.
+ `"InstanceId":"${aws:InstanceId}"` legt die Instance-ID der Instance als Wert der `InstanceId`-Dimension fest.
+ `"InstanceType":"${aws:InstanceType}"` legt den Instance-Typ der Instance als Wert der `InstanceType`-Dimension fest.
+ `"AutoScalingGroupName":"${aws:AutoScalingGroupName}"` legt den Namen der Auto Scaling-Gruppe der Instance als Wert der `AutoScalingGroupName`-Dimension fest.
Wenn Sie Dimensionen an Metriken mit beliebigen Schlüssel-Wert-Paaren anfügen möchten, verwenden Sie den Parameter `append_dimensions` im Feld für diesen bestimmten Metriktyp.
Wenn Sie einen Wert angeben, der von Amazon-EC2-Metadaten abhängt, und Sie Proxys verwenden, müssen Sie sicherstellen, dass der Server auf den Endpunkt für Amazon EC2 zugreifen kann. Weitere Informationen zu diesen Endpunkten finden Sie unter [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/general/latest/gr/rande.html#ec2_region) in der *Allgemeine Amazon Web Services-Referenz*.
+ `aggregation_dimensions` – Optional. Gibt die Dimensionen an, in denen erfasste Metriken aggregiert werden sollen. Beispiel: Wenn Sie Metriken in der `AutoScalingGroupName`-Dimension zusammenführen, werden die Metriken aus allen Instances in der jeweiligen Auto-Scaling-Gruppe aggregiert und können als Ganzes angezeigt werden.
Sie können Metriken in einer einzelnen oder in mehreren Dimensionen zusammenfassen. Beispiel: Wenn Sie `[["InstanceId"], ["InstanceType"], ["InstanceId","InstanceType"]]` festlegen, werden Metriken für die Instance-ID einzeln, den Instance-Typ einzeln und für die Kombination der beiden Dimensionen aggregiert.
Sie können auch `[]` angeben, um alle Metriken in einer Sammlung ungeachtet jeglicher Dimensionen zusammenzufassen.
+ `endpoint_override` – Gibt einen FIPS-Endpunkt oder einen privaten Link an, der als Endpunkt verwendet wird, an den der Agent Metriken sendet. Wenn Sie dies angeben und einen privaten Link einrichten, können Sie die Metriken an eine Amazon-VPC-Endpunkt senden. Weitere Informationen finden Sie unter [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
Der Wert von `endpoint_override` muss eine Zeichenkette sein, die eine URL ist.
Beispielsweise legt der folgende Teil des Metrikabschnitts der Konfigurationsdatei fest, dass der Agent beim Senden von Metriken einen VPC-Endpunkt verwendet.
```
{
"metrics": {
"endpoint_override": "vpce-XXXXXXXXXXXXXXXXXXXXXXXXX.monitoring.us-east-1.vpce.amazonaws.com",
......
},
}
```
+ `metrics_collected` – Erforderlich. Gibt an, welche Metriken erfasst werden sollen, einschließlich benutzerdefinierter Metriken, die mit `StatsD` oder `collectd` erfasst werden. Dieser Abschnitt enthält mehrere Unterabschnitte.
Der Inhalt des `metrics_collected`-Abschnitts hängt davon ab, ob diese Konfigurationsdatei für einen Server mit Linux oder Windows Server vorgesehen ist.
+ `metrics_destinations` – Optional. Gibt ein oder mehrere Ziele für alle in `metrics_collected` definierten Metriken an. Wenn dies hier angegeben wird, überschreibt es das Standardziel von `cloudwatch`.
+ `cloudwatch`— Amazon CloudWatch.
+ `amp`: Amazon Managed Service für Prometheus
+ `workspace_id`: Die ID, die dem Workspace in Amazon Managed Service für Prometheus entspricht.
```
{
"metrics": {
"metrics_destinations": {
"cloudwatch": {},
"amp": {
"workspace_id": "ws-abcd1234-ef56-7890-ab12-example"
}
}
}
}
```
+ `force_flush_interval` – Gibt die maximale Zeitspanne in Sekunden an, in der Metriken im Speicherpuffer verbleiben, bevor sie an den Server gesendet werden. Unabhängig von dieser Einstellung werden die Metriken sofort an den Server gesendet, sobald die Größe der Metriken im Puffer 1 MB oder 1 000 verschiedene Metriken erreicht.
Der Standardwert lautet 60.
+ `credentials` – Gibt eine IAM-Rolle an, die beim Senden von Metriken an ein anderes Konto verwendet werden soll. Sofern angegeben, enthält dieses Feld einen Parameter, `role_arn`.
+ `role_arn` – Gibt den ARN einer IAM-Rolle für die Authentifizierung beim Senden von Metriken an ein anderes Konto an. Weitere Informationen finden Sie unter [Metriken, Protokolle und Ablaufverfolgungen an ein anderes Konto senden](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account). Wenn dieser Wert hier angegeben wird, überschreibt er den `role_arn` im Abschnitt `agent` der Konfigurationsdatei, sofern vorhanden.
+ `service.name` – Optional. Gibt den Servicenamen an, der verwendet werden soll, um die Entität für die [Suche nach zugehöriger Telemetrie](ExploreRelated.md) mit Werten zu befüllen.
+ `deployment.environment` – Optional. Gibt den Umgebungsnamen an, der verwendet werden soll, um die Entität für die [Suche nach zugehöriger Telemetrie](ExploreRelated.md) mit Werten zu befüllen.
### Linux-Abschnitt
Auf Servern mit Linux kann der Abschnitt `metrics_collected` der Konfigurationsdatei auch die folgenden Felder enthalten.
Viele dieser Felder können `measurement`-Bereiche enthalten, in denen die Metriken aufgelistet werden, die Sie für diese Ressource erfassen möchten. In diesen `measurement`-Abschnitten können Sie entweder den vollständigen Metriknamen, wie z. B. `swap_used`, oder nur den Teil des Metriknamens, der an die Typ der Ressource angehängt wird. Beispiel: Die Angabe von `reads` im Abschnitt `measurement` des Abschnitts `diskio` bewirkt, dass die Metrik `diskio_reads` erfasst wird.
+ `collectd` – Optional. Gibt an, dass Sie benutzerdefinierte Metriken mithilfe des Protokolls `collectd` abrufen möchten. Sie verwenden `collectd` Software, um die Metriken an den CloudWatch Agenten zu senden. Weitere Informationen zu den Konfigurationsoptionen, die für collectd verfügbar sind, finden Sie unter [Abrufen benutzerdefinierter Metriken mit collectd](CloudWatch-Agent-custom-metrics-collectd.md).
+ `cpu` – Optional. Gibt an, dass CPU-Metriken erfasst werden sollen. Dieser Abschnitt gilt nur für Linux-Instances. Sie müssen mindestens eines der `resources`- und `totalcpu`-Felder für alle zu erfassenden CPU-Metriken einschließen. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Metriken an gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `resources` – Optional. Geben Sie dieses Feld mit dem Wert `*` an, um zu bewirken, dass pro CPU-Metriken erfasst werden. Der einzige zulässige Wert ist `*`.
+ `totalcpu` – Optional. Gibt an, ob CPU-Metriken gesammelt über alle CPU-Kerne hinweg gemeldet werden sollen. Der Standardwert ist true.
+ `measurement` – Gibt das Array der zu erfassenden CPU-Metriken an. Mögliche Werte sind `time_active`, `time_guest`, `time_guest_nice`, `time_idle`, `time_iowait`, `time_irq`, `time_nice`, `time_softirq`, `time_steal`, `time_system`, `time_user`, `usage_active`, `usage_guest`, `usage_guest_nice`, `usage_idle`, `usage_iowait`, `usage_irq`, `usage_nice`, `usage_softirq`, `usage_steal`, `usage_system` und `usage_user`. Dieses Feld muss angegeben werden, wenn Sie `cpu` einbeziehen.
Standardmäßig ist die Einheit für `cpu_usage_*`-Metriken `Percent`; `cpu_time_*`-Metriken sind einheitenlos.
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die CPU-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben. Beispiel: Angeben, dass 10 Metriken alle 10 Sekunden und 300 Metriken alle 5 Minuten gesammelt werden sollen.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen zu hochauflösenden Metriken finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Zusätzliche Dimensionen, die nur für die CPU-Metriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im globalen Feld `append_dimensions` angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agenten erfasst werden.
+ `disk` – Optional. Gibt an, dass Datenträger-Metriken erfasst werden sollen. Erfasst Metriken nur für bereitgestellte Volumes. Dieser Abschnitt gilt nur für Linux-Instances. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Messwerte gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `resources` – Optional. Gibt ein Array von Datenträger-Mountingpunkten an. Dieses Feld beschränkt CloudWatch sich darauf, nur Metriken von den aufgelisteten Einhängepunkten zu sammeln. Sie können `*` als Wert festlegen, um Metriken von allen Mountingpunkten zu erfassen. Standardmäßig werden Metriken von allen Mountingpunkten erfasst.
+ `measurement` – Gibt das Array der zu erfassenden Disk-Metriken an. Mögliche Werte sind `free`, `total`, `used`, `used_percent`, `inodes_free`, `inodes_used` und `inodes_total`. Dieses Feld muss angegeben werden, wenn Sie `disk` einbeziehen.
**Anmerkung**
Die `disk`-Metriken haben eine Dimension für `Partition`, was bedeutet, dass die Anzahl der generierten benutzerdefinierten Metriken von der Anzahl der Partitionen abhängt, die Ihrer Instance zugeordnet sind. Die Anzahl der Festplattenpartitionen hängt davon ab, welches AMI Sie verwenden, und wie viele Amazon-EBS-Volumes Sie an den Server anfügen.
Informationen zum Anzeigen der Standardeinheiten für jede `disk`-Metrik finden Sie unter [Vom CloudWatch Agenten auf Linux- und macOS-Instances gesammelte Metriken](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None` von `None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `ignore_file_system_types` – Gibt Dateisystemtypen an, die beim Erfassen von Datenträgermetriken ausgeschlossen werden sollen. Gültige Werte sind `sysfs`, `devtmpfs` usw.
+ `drop_device` – Wenn Sie dies auf `true` setzen, wird `Device` nicht als Dimension für Datenträgermetriken aufgenommen.
Verhindern, dass `Device` als Dimension verwendet wird, kann auf Instances nützlich sein, die das Nitro-System verwenden, da sich die Gerätenamen auf diesen Instances bei jedem Datenträger-Mount ändern, wenn die Instance neu gestartet wird. Dies kann dazu führen, dass inkonsistente Daten in Ihren -Metriken und dazu führen, dass Alarme, die auf diesen Metriken basieren, in den Status `INSUFFICIENT DATA` übergehen.
Der Standardwert ist `false`.
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die Datenträger-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Geben Sie Schlüssel-Wert-Paare an, die als zusätzliche Dimensionen nur für die Festplattenmetriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im `append_dimensions`-Feld angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agent erfasst werden.
Ein Schlüssel-Wert-Paar, das Sie verwenden können, ist das Folgende. Sie können auch andere benutzerdefinierte Schlüssel-Wert-Paare festlegen.
+ `"VolumeId":"${aws:VolumeId}"` fügt den Festplattenmetriken des Blockgeräts eine `VolumeId`-Dimension hinzu. Für Amazon-EBS-Volumes ist dies die Amazon-EBS-Volume-ID. Für den EC2-Instance-Speicher ist dies die Seriennummer des Geräts. Um dies zu verwenden, muss der Parameter `drop_device` auf `false` gesetzt sein.
+ `diskio` – Optional. Gibt an, dass i/o Festplattenmetriken erfasst werden sollen. Dieser Abschnitt gilt nur für Linux-Instances. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Metriken an gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `resources` – Optional. Wenn Sie eine Reihe von Geräten angeben, werden nur Messwerte von diesen Geräten CloudWatch erfasst. Andernfalls werden Metriken für alle Geräte erfasst. Sie können auch \$1 als Wert festlegen, um Metriken von allen Geräten zu erfassen.
+ `measurement`— Gibt das Array von Diskio- und AWS NVMe-Treibermetriken an, die für Amazon EBS-Volumes und Instance-Speicher-Volumes erfasst werden sollen, die an Amazon EC2 EC2-Instances angehängt sind. Mögliche diskio-Werte sind `reads`, `writes`, `read_bytes`, `write_bytes`, `read_time`, `write_time`, `io_time` und `iops_in_progress`. Eine Liste der NVMe-Treibermetriken für Amazon-EBS-Volumes und Amazon-EC2-Instance-Speicher-Volumes finden Sie unter [Erfassen Sie Amazon NVMe EBS-Treibermetriken](Container-Insights-metrics-EBS-Collect.md) und [Erfassung von NVMe Volumen-Treibermetriken für Amazon EC2 EC2-Instance-Speicher](Container-Insights-metrics-instance-store-Collect.md). Dieses Feld muss angegeben werden, wenn Sie `diskio` einbeziehen.
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None` von `None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der Beschreibung unter aufgeführt. `Unit` [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)
Informationen zu Standardeinheiten und eine Beschreibung der Metriken finden Sie unter [Erfassen Sie Amazon NVMe EBS-Treibermetriken](Container-Insights-metrics-EBS-Collect.md).
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die diskio-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen zu hochauflösenden Metriken finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Zusätzliche Dimensionen, die nur für die diskio-Metriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im `append_dimensions`-Feld angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agent erfasst werden.
+ `swap` – Optional. Gibt an, dass Swap-Arbeitsspeicher-Metriken erfasst werden sollen. Dieser Abschnitt gilt nur für Linux-Instances. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Messwerte gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `measurement` – Gibt das Array der zu erfassenden Swap-Metriken an. Mögliche Werte sind `free`, `used` und `used_percent`. Dieses Feld muss angegeben werden, wenn Sie `swap` einbeziehen.
Informationen zum Anzeigen der Standardeinheiten für jede `swap`-Metrik finden Sie unter [Vom CloudWatch Agenten auf Linux- und macOS-Instances gesammelte Metriken](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None` von `None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die Swap-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen zu hochauflösenden Metriken finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Zusätzliche Dimensionen, die nur für die Swap-Metriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im globalen `append_dimensions`-Feld angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agent erfasst werden. Der Wert wird als hochauflösende Metrik erfasst.
+ `mem` – Optional. Gibt an, dass Arbeitsspeicher-Metriken erfasst werden sollen. Dieser Abschnitt gilt nur für Linux-Instances. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Messwerte gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `measurement` – Gibt das Array der zu erfassenden Arbeitsspeicher-Metriken an. Mögliche Werte sind `active`, `available`, `available_percent`, `buffered`, `cached`, `free`, `inactive`, `shared`, `total`, `used` und `used_percent`. Dieses Feld muss angegeben werden, wenn Sie `mem` einbeziehen.
Informationen zum Anzeigen der Standardeinheiten für jede `mem`-Metrik finden Sie unter [Vom CloudWatch Agenten auf Linux- und macOS-Instances gesammelte Metriken](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die mem-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen zu hochauflösenden Metriken finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Zusätzliche Dimensionen, die nur für die mem-Metriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im Feld `append_dimensions` angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agenten erfasst werden.
+ `net` – Optional. Gibt an, dass Netzwerk-Metriken erfasst werden sollen. Dieser Abschnitt gilt nur für Linux-Instances. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Messwerte gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `resources` – Optional. Wenn Sie ein Array von Netzwerkschnittstellen angeben, werden nur Metriken von diesen Schnittstellen CloudWatch erfasst. Andernfalls werden Metriken für alle Geräte erfasst. Sie können auch `*` als Wert festlegen, um Metriken von allen Schnittstellen zu erfassen.
+ `measurement` – Gibt das Array der zu erfassenden Netzwerk-Metriken an. Mögliche Werte sind `bytes_sent`, `bytes_recv`, `drop_in`, `drop_out`, `err_in`, `err_out`, `packets_sent` und `packets_recv`. Dieses Feld muss angegeben werden, wenn Sie `net` einbeziehen.
Informationen zum Anzeigen der Standardeinheiten für jede `net`-Metrik finden Sie unter [Vom CloudWatch Agenten auf Linux- und macOS-Instances gesammelte Metriken](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die net-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben. Beispiel: Angeben, dass 10 Metriken alle 10 Sekunden und 300 Metriken alle 5 Minuten gesammelt werden sollen.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen zu hochauflösenden Metriken finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Zusätzliche Dimensionen, die nur für die net-Metriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im Feld `append_dimensions` angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agent erfasst werden.
+ `netstat` – Optional. Gibt an, dass TCP-Verbindungsstatus und UDP-Verbindungsmetriken gesammelt werden sollen. Dieser Abschnitt gilt nur für Linux-Instances. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Messwerte gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `measurement` – Gibt das Array der zu erfassenden Netstat-Metriken an. Mögliche Werte sind `tcp_close`, `tcp_close_wait`, `tcp_closing`, `tcp_established`, `tcp_fin_wait1`, `tcp_fin_wait2`, `tcp_last_ack`, `tcp_listen`, `tcp_none`, `tcp_syn_sent`, `tcp_syn_recv`, `tcp_time_wait` und `udp_socket`. Dieses Feld muss angegeben werden, wenn Sie `netstat` einbeziehen.
Informationen zum Anzeigen der Standardeinheiten für jede `netstat`-Metrik finden Sie unter [Vom CloudWatch Agenten auf Linux- und macOS-Instances gesammelte Metriken](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die netstat-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen zu hochauflösenden Metriken finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Zusätzliche Dimensionen, die nur für die netstat-Metriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im Feld `append_dimensions` angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agent erfasst werden.
+ `processes` – Optional. Gibt an, dass Prozess-Metriken erfasst werden sollen. Dieser Abschnitt gilt nur für Linux-Instances. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Messwerte gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `measurement` – Gibt das Array der zu erfassenden Prozess-Metriken an. Mögliche Werte sind `blocked`, `dead`, `idle`, `paging`, `running`, `sleeping`, `stopped`, `total`, `total_threads`, `wait` und `zombies`. Dieses Feld muss angegeben werden, wenn Sie `processes` einbeziehen.
Für alle `processes`-Metriken lautet die Standardeinheit `None`.
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die Prozess-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben. Beispiel: Angeben, dass 10 Metriken alle 10 Sekunden und 300 Metriken alle 5 Minuten gesammelt werden sollen.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Zusätzliche Dimensionen, die nur für die Prozess-Metriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im Feld `append_dimensions` angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agent erfasst werden.
+ `nvidia_gpu` – Optional. Gibt an, dass NVIDIA GPU-Metriken erfasst werden sollen. Dieser Abschnitt gilt nur für Linux-Instances auf Hosts, die mit einem NVIDIA GPU-Accelerator konfiguriert sind und auf denen das NVIDIA System Management Interface (nvidia-smi) installiert ist.
Den erfassten NVIDIA GPU-Metriken wird die Zeichenfolge `nvidia_smi_` vorangestellt, um sie von den Metriken zu unterscheiden, die für andere Accelerator-Typen erfasst wurden. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Messwerte gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
+ `measurement` – Gibt das Array der zu erfassenden NVIDIA GPU-Metriken an. Eine Liste der möglichen Werte, die Sie hier verwenden können, finden Sie in der Spalte **Metric** (Metrik) in der Tabelle unter [Erfassen von NVIDIA GPU-Metriken](CloudWatch-Agent-NVIDIA-GPU.md).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik (`None`). Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die NVIDIA GPU-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
+ `jmx` – Optional. Gibt an, dass Sie Java Management Extensions (JMX)-Metriken von der Instance abrufen möchten. Weitere Informationen zu den Parametern, die in diesem Abschnitt verwendet werden können, und den Metriken, die erfasst werden können, finden Sie unter [Erfassung von Java Management Extensions (JMX)-Metriken](CloudWatch-Agent-JMX-metrics.md).
+ `otlp` – Optional. Gibt an, dass Sie Metriken aus dem OpenTelemetry SDK sammeln möchten. Weitere Informationen über die Felder, die Sie in diesem Abschnitt verwenden können, finden Sie unter [Erfassen Sie Metriken und Traces mit OpenTelemetry](CloudWatch-Agent-OpenTelemetry-metrics.md).
+ `procstat` – Optional. Gibt an, dass Sie Metriken aus einzelnen Prozessen abrufen möchten. Weitere Informationen zu den Konfigurationsoptionen, die für procstat verfügbar sind, finden Sie unter [Erfassen von Prozessmetriken mit dem procstat-Plugin](CloudWatch-Agent-procstat-process-metrics.md).
+ `statsd` – Optional. Gibt an, dass Sie benutzerdefinierte Metriken mithilfe des Protokolls `StatsD` abrufen möchten. Der CloudWatch Agent fungiert als Daemon für das Protokoll. Sie verwenden einen beliebigen `StatsD` Standard-Client, um die Metriken an den CloudWatch Agenten zu senden. Weitere Informationen zu den Konfigurationsoptionen, die für StatsD verfügbar sind, finden Sie unter [Abrufen benutzerdefinierter Metriken mit StatsD](CloudWatch-Agent-custom-metrics-statsd.md).
+ `ethtool` – Optional. Gibt an, dass Sie Netzwerkmetriken mithilfe des `ethtool`-Plug-Ins abrufen möchten. Dieses Plugin kann sowohl die vom Standard-Dienstprogramm ethtool gesammelten Metriken als auch die Metriken zur Netzwerkleistung von Amazon-EC2-Instances importieren. Weitere Informationen zu den Konfigurationsoptionen, die für ethtool verfügbar sind, finden Sie unter [Netzwerkleistungsmetriken sammeln](CloudWatch-Agent-network-performance.md).
Es folgt das Beispiel eines `metrics`-Abschnitts für einen Linux-Server. In diesem Beispiel werden drei CPU-Metriken, drei netstat-Metriken, drei Prozessmetriken und eine Datenträgermetrik erfasst und der Agent ist zum Empfang zusätzlicher Metriken von einem `collectd`-Client eingerichtet.
```
"metrics": {
"aggregation_dimensions" : [["AutoScalingGroupName"], ["InstanceId", "InstanceType"],[]],
"metrics_collected": {
"collectd": {},
"cpu": {
"resources": [
"*"
],
"measurement": [
{"name": "cpu_usage_idle", "rename": "CPU_USAGE_IDLE", "unit": "Percent"},
{"name": "cpu_usage_nice", "unit": "Percent"},
"cpu_usage_guest"
],
"totalcpu": false,
"drop_original_metrics": [ "cpu_usage_guest" ],
"metrics_collection_interval": 10,
"append_dimensions": {
"test": "test1",
"date": "2017-10-01"
}
},
"netstat": {
"measurement": [
"tcp_established",
"tcp_syn_sent",
"tcp_close"
],
"metrics_collection_interval": 60
},
"disk": {
"measurement": [
"used_percent"
],
"resources": [
"*"
],
"drop_device": true
},
"processes": {
"measurement": [
"running",
"sleeping",
"dead"
]
}
},
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
}
}
```
### Windows Server
Im Abschnitt `metrics_collected` für Windows Server können Sie für jedes Windows-Leistungsobjekt Unterabschnitte anlegen, beispielsweise `Memory`, `Processor` und `LogicalDisk`. Informationen darüber, welche Objekte und Zähler verfügbar sind, finden Sie unter [Leistungszähler](https://learn.microsoft.com/en-us/windows/win32/perfctrs/performance-counters-portal) in der Microsoft Windows-Dokumentation.
Innerhalb des Unterabschnitts für jedes Objekt geben Sie ein `measurement`-Array der zu erfassenden Zähler an. Das `measurement`-Array ist für jedes Objekt erforderlich, das Sie in der Konfigurationsdatei angeben. Sie können auch ein `resources`-Feld angeben, um die Instances zu benennen, aus denen Sie Metriken erfassen. Sie können auch `*` für `resources` angeben, um separate Metriken für alle Instances zu erfassen. Wenn Sie `resources` bei Zählern mit Instances weglassen, werden die Daten für alle Instances in einem Satz zusammengefasst. Wenn Sie `resources` bei Zählern, die keine Instanzen haben, auslassen, werden die Zähler nicht vom Agenten erfasst. CloudWatch Um festzustellen, ob Zähler über Instances verfügen, können Sie einen der folgenden Befehle verwenden.
Powershell:
```
Get-Counter -ListSet *
```
Befehlszeile (nicht Powershell):
```
TypePerf.exe –q
```
Innerhalb des jeweiligen Objektabschnitts können Sie auch die folgenden optionalen Felder angeben:
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die Metriken für dieses Objekt erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben. Beispiel: Angeben, dass 10 Metriken alle 10 Sekunden und 300 Metriken alle 5 Minuten gesammelt werden sollen.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
+ `append_dimensions` – Optional. Gibt zusätzliche Dimensionen an, die nur für die Metriken für dieses Objekt verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im globalen Feld `append_dimensions` angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agent erfasst werden.
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Metriken an gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
Innerhalb des jeweiligen Zählerabschnitts können Sie auch die folgenden optionalen Felder angeben:
+ `rename`— Gibt einen anderen Namen an, der CloudWatch für diese Metrik verwendet werden soll.
+ `unit` – Gibt die für diese Metrik zu verwendende Einheit an. Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
Es gibt zwei weitere optionale Abschnitte, die Sie in `metrics_collected` aufnehmen können:
+ `statsd` – Ermöglicht den Abruf benutzerdefinierter Metriken mittels `StatsD`-Protokoll. Der CloudWatch Agent fungiert als Daemon für das Protokoll. Sie können die Metriken mit einem beliebigen `StatsD`-Standardclient an den CloudWatch-Agenten senden. Weitere Informationen finden Sie unter [Abrufen benutzerdefinierter Metriken mit StatsD](CloudWatch-Agent-custom-metrics-statsd.md).
+ `procstat` – Ermöglicht den Abruf von Metriken aus einzelnen Prozessen. Weitere Informationen finden Sie unter [Erfassen von Prozessmetriken mit dem procstat-Plugin](CloudWatch-Agent-procstat-process-metrics.md).
+ `jmx` – Optional. Gibt an, dass Sie Java Management Extensions (JMX)-Metriken von der Instance abrufen möchten. Weitere Informationen zu den Feldern, die in diesem Abschnitt verwendet werden können, und den Metriken, die erfasst werden können, finden Sie unter [Erfassung von Java Management Extensions (JMX)-Metriken](CloudWatch-Agent-JMX-metrics.md).
+ `otlp` – Optional. Gibt an, dass Sie Metriken aus dem OpenTelemetry SDK sammeln möchten. Weitere Informationen über die Felder, die Sie in diesem Abschnitt verwenden können, finden Sie unter [Erfassen Sie Metriken und Traces mit OpenTelemetry](CloudWatch-Agent-OpenTelemetry-metrics.md).
Es folgt das Beispiel eines `metrics`-Abschnitts zur Verwendung unter Windows Server. In diesem Beispiel werden viele Windows-Metriken erfasst, und der Computer ist zusätzlich für das Empfangen weiterer Metriken von einem `StatsD`-Client eingerichtet.
```
"metrics": {
"metrics_collected": {
"statsd": {},
"Processor": {
"measurement": [
{"name": "% Idle Time", "rename": "CPU_IDLE", "unit": "Percent"},
"% Interrupt Time",
"% User Time",
"% Processor Time"
],
"resources": [
"*"
],
"append_dimensions": {
"d1": "win_foo",
"d2": "win_bar"
}
},
"LogicalDisk": {
"measurement": [
{"name": "% Idle Time", "unit": "Percent"},
{"name": "% Disk Read Time", "rename": "DISK_READ"},
"% Disk Write Time"
],
"resources": [
"*"
]
},
"Memory": {
"metrics_collection_interval": 5,
"measurement": [
"Available Bytes",
"Cache Faults/sec",
"Page Faults/sec",
"Pages/sec"
],
"append_dimensions": {
"d3": "win_bo"
}
},
"Network Interface": {
"metrics_collection_interval": 5,
"measurement": [
"Bytes Received/sec",
"Bytes Sent/sec",
"Packets Received/sec",
"Packets Sent/sec"
],
"resources": [
"*"
],
"append_dimensions": {
"d3": "win_bo"
}
},
"System": {
"measurement": [
"Context Switches/sec",
"System Calls/sec",
"Processor Queue Length"
],
"append_dimensions": {
"d1": "win_foo",
"d2": "win_bar"
}
}
},
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
"aggregation_dimensions" : [["ImageId"], ["InstanceId", "InstanceType"], ["d1"],[]]
}
}
```
## CloudWatch Agenten-Konfigurationsdatei: Abschnitt „Protokolle“
Der Abschnitt `logs` enthält die folgenden Felder:
+ `service.name` – Optional. Gibt den Servicenamen an, der verwendet werden soll, um die Entität für die [Suche nach zugehöriger Telemetrie](ExploreRelated.md) mit Werten zu befüllen.
+ `deployment.environment` – Optional. Gibt den Umgebungsnamen an, der verwendet werden soll, um die Entität für die [Suche nach zugehöriger Telemetrie](ExploreRelated.md) mit Werten zu befüllen.
+ `backpressure_mode` – Optional. Gibt das Verhalten an, wenn der CloudWatch Agent Logs schneller aufnimmt, als er an CloudWatch Logs senden kann, was zu Gegendruck führt. Gegendruck kann durch Netzwerkprobleme, API-Drosselung oder hohes Protokollvolumen entstehen.
Der Agent unterstützt die folgenden Werte:
+ `fd_release`— Gibt Dateideskriptoren für gelöschte Dateien bei Gegendruck frei. Mit dieser Option kann verhindert werden, dass Festplattenspeicher erschöpft wird, wenn externe Protokollrotations- oder Säuberungsprozesse Dateien entfernen, während der Agent offene Dateideskriptoren beibehält. Die `auto_removal` Option hat Vorrang vor der Option, die auf gesetzt ist`backpressure_mode`. `fd_release` Wenn diese Option aktiviert `auto_removal` ist, verarbeitet der CloudWatch Agent die Datei bis zum Abschluss, ohne den Dateideskriptor freizugeben.
**Wichtig**
Die Verwendung `fd_release` kann dazu führen, dass der CloudWatch Agent die Protokolldateien nicht vollständig lesen kann, was zu Protokollverlust führen kann.
+ `concurrency` – Optional. Gibt die Anzahl der gemeinsam genutzten Protokollherausgeber an, die für die gleichzeitige Veröffentlichung von Protokolldateien in CloudWatch Logs verwendet werden.
Wenn Sie dieses Feld weglassen, hat jedes Protokolldateiziel (Protokollgruppe, Stream-Kombination) einen einzigen gemeinsam genutzten Protokollherausgeber, was zu Engpässen bei großen Dateien oder beim Schreiben mehrerer Dateien an dasselbe Ziel führen kann. Die Aktivierung der Parallelität kann den Durchsatz verbessern.
+ `logs_collected` – Erforderlich, sofern der Abschnitt `logs` enthalten ist. Gibt an, welche Protokolldateien und Windows-Ereignisprotokolle vom Server erfasst werden sollen. Kann zwei Felder enthalten: `files` und `windows_events`.
+ `files`— Gibt an, welche regulären Protokolldateien der CloudWatch Agent sammeln soll. Enthält das Feld `collect_list`, das diese Dateien genauer definiert.
+ `collect_list` – Erforderlich, wenn `files` enthalten ist. Enthält ein Array von Einträgen, die jeweils eine zu erfassende Protokolldatei angeben. Jeder dieser Einträge kann die folgenden Felder enthalten:
+ `file_path`— Gibt den Pfad der Protokolldatei an, die in CloudWatch Logs hochgeladen werden soll. Globale standardmäßige Unixabgleichsregeln werden akzeptiert. `**` muss als *super asterisk* hinzugefügt werden. Beispiel: Angeben von `/var/log/**.log` bewirkt, dass alle `.log`-Dateien in der `/var/log`-Verzeichnisstruktur erfasst werden. Weitere Beispiele finden Sie in der [globalen Bibliothek](https://github.com/gobwas/glob).
Sie können das Standardsternchen auch als Standardplatzhalter verwenden. Beispiel: `/var/log/system.log*` findet Dateien wie `system.log_1111`, `system.log_2222` usw. in `/var/log`.
Nur die neueste Datei wird basierend auf der Änderungszeit der Datei in die CloudWatch Logs übertragen. Wir empfehlen, dass Sie eine Reihe von Platzhaltern angeben, z. B. Dateien desselben Typs, `access_log.2018-06-01-01` und `access_log.2018-06-01-02`, aber nicht mehrere Arten von Dateien, wie z. B. `access_log_80` und `access_log_443`. Wenn Sie mehrere Arten von Dateien angeben möchten, fügen Sie der Agentenkonfigurationsdatei einen anderen Protokoll-Stream-Eintrag hinzu, damit jede Art von Protokolldatei in einen anderen Protokoll-Stream gestellt wird.
+ `auto_removal` – Optional. Wenn dies der Fall ist`true`, löscht der CloudWatch Agent diese Protokolldatei nach dem Lesen automatisch und sie wurde rotiert. Normalerweise werden die Protokolldateien gelöscht, nachdem ihr gesamter Inhalt in CloudWatch Logs hochgeladen wurde. Wenn der Agent jedoch das EOF (Dateiende) erreicht und auch eine andere neuere Protokolldatei entdeckt, die dieser entspricht`file_path`, löscht der Agent die ALTE Datei. Sie müssen also sicherstellen, dass Sie mit dem Schreiben in die ALTE Datei fertig sind, bevor Sie die NEUE Datei erstellen. Die [RUST-Ablaufverfolgungsbibliothek](https://docs.rs/tracing/latest/tracing/) ist bekanntermaßen nicht kompatibel, da sie möglicherweise eine NEUE Protokolldatei erstellt und dann trotzdem versucht, in die ALTE Protokolldatei zu schreiben.
Der Agent entfernt aus Protokollen, die mehrere Dateien erstellen, nur vollständige Dateien. Dies sind z. B. Protokolle, die für jedes Datum separate Dateien erstellen. Wenn ein Protokoll kontinuierlich in eine einzige Datei schreibt, wird es nicht entfernt.
Wenn Sie bereits eine Rotations- oder Entfernungsmethode für Protokolldateien eingerichtet haben, sollten Sie dieses Feld auslassen oder auf `false` festlegen.
Wenn Sie dieses Feld auslassen, wird der Standardwert `false` verwendet.
+ `log_group_name` – Optional. Gibt an, was als Protokollgruppenname in CloudWatch Logs verwendet werden soll.
Wir empfehlen, in diesem Feld einen Protokollgruppen-Namen festzulegen, um Verwirrungen zu vermeiden. Wenn Sie `log_group_name` auslassen, wird der Wert von `file_path` bis zu dem letzten Punkt als Name der Protokollgruppe verwendet. Beispiel: Falls der Dateipfad `/tmp/TestLogFile.log.2017-07-11-14` ist, lautet der Name der Protokollgruppe `/tmp/TestLogFile.log`.
Wenn Sie einen Protokollgruppen-Namen angeben, können Sie `{instance_id}`, `{hostname}`, `{local_hostname}` und `{ip_address}` als Variablen im Namen verwenden. `{hostname}` ruft den Hostnamen aus den EC2-Metadaten ab und `{local_hostname}` verwendet den Hostnamen aus der Netzwerkkonfigurationsdatei.
Wenn Sie diese Variablen verwenden, um viele verschiedene Loggruppen zu erstellen, beachten Sie die Begrenzung auf 1.000.000 Loggruppen pro Region und Konto.
Zulässige Zeichen sind a – z, A – Z, 0 – 9, „\$1“ (Unterstrich), „-“ (Bindestrich), „/“ (Schrägstrich) und „.“ (Punkt).
+ `log_group_class` – Optional. Gibt an, welche Protokollgruppen-Klasse für die neue Protokollgruppe verwendet werden soll. Weitere Hinweise zu Protokollgruppen-Klassen finden Sie unter [Protokollklassen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch_Logs_Log_Classes.html).
Gültige Werte sind `STANDARD` und `INFREQUENT_ACCESS`. Wenn Sie dieses Feld auslassen, wird der Standard `STANDARD` verwendet.
**Wichtig**
Nachdem eine Protokollgruppe erstellt wurde, kann ihre Klasse nicht mehr geändert werden.
+ `log_stream_name` – Optional. Gibt an, was als Name des Protokolldatenstroms in CloudWatch Logs verwendet werden soll. Sie können die Variablen `{instance_id}`, `{hostname}`, `{local_hostname}` und `{ip_address}` im Namen verwenden. `{hostname}` ruft den Hostnamen aus den EC2-Metadaten ab, `{local_hostname}` verwendet den Hostnamen aus der Netzwerkkonfigurationsdatei.
Wenn Sie dieses Feld auslassen, wird der Wert des Parameters `log_stream_name` im globalen `logs`-Abschnitt verwendet. Wird dies ebenfalls weggelassen, wird der Standardwert von `{instance_id}` verwendet.
Wenn ein Protokoll-Stream noch nicht vorhanden ist, wird er automatisch erstellt.
+ `retention_in_days` – Optional. Gibt an, wie viele Tage lang die Protokollereignisse in der festgelegten Protokollgruppe aufbewahrt werden.
+ Wenn der Agent diese Protokollgruppe jetzt erstellt und Sie dieses Feld auslassen, wird die Aufbewahrung dieser neuen Protokollgruppe auf niemals ablaufend gesetzt.
+ Wenn diese Protokollgruppe bereits vorhanden ist und Sie dieses Feld angeben, wird die von Ihnen angegebene neue Aufbewahrung verwendet. Wenn Sie dieses Feld für eine bereits vorhandene Protokollgruppe weglassen, wird die Aufbewahrung der Protokollgruppe nicht geändert.
Der CloudWatch Agent-Assistent verwendet `-1` als Standardwert für dieses Feld, wenn es zur Erstellung der Agent-Konfigurationsdatei verwendet wird und Sie keinen Wert für die Protokollaufbewahrung angeben. Dieser vom Assistenten festgelegte `-1`-Wert legt fest, dass die Ereignisse in der Protokollgruppe nie ablaufen. Das manuelle Ändern dieses Werts auf `-1` hat jedoch keine Auswirkung.
Mögliche Werte sind 1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1827, 2192, 2557, 2922, 3288 und 3653.
Wenn Sie den Agenten so konfigurieren, dass er mehrere Protokollstreams in dieselbe Protokollgruppe schreibt, und Sie `retention_in_days` an einer Stelle angeben, wird damit die Protokollaufbewahrung für die gesamte Protokollgruppe festgelegt. Wenn Sie `retention_in_days` an mehreren Stellen für dieselbe Protokollgruppe angeben und alle diese Werte gleich sind, wird die Aufbewahrung festgelegt. Werden jedoch für dieselbe Protokollgruppe an mehreren Stellen unterschiedliche `retention_in_days`-Werte angegeben, wird die Protokollaufbewahrung nicht festgelegt und der Agent wird gestoppt und gibt einen Fehler zurück.
**Anmerkung**
Die IAM-Rolle oder der IAM-Benutzer des Agenten muss über `logs:PutRetentionPolicy` verfügen, damit sie bzw. er Aufbewahrungsrichtlinien festlegen kann.
**Warnung**
Wenn Sie für eine bereits vorhandene Protokollgruppe `retention_in_days` festlegen, werden alle Protokolle in dieser Protokollgruppe, die vor der von Ihnen angegebenen Anzahl von Tagen veröffentlicht wurden, gelöscht. Wenn Sie beispielsweise den Wert 3 festlegen, werden alle Protokolle gelöscht, die 3 oder mehr Tage alt sind.
+ `filters` – Optional. Kann ein Array von Einträgen enthalten, von denen jeder einen regulären Ausdruck und einen Filtertyp angibt, um anzugeben, ob Protokolleinträge, die dem Filter entsprechen, veröffentlicht oder gelöscht werden sollen. Wenn Sie dieses Feld weglassen, werden alle Protokolle in der Protokolldatei in CloudWatch Logs veröffentlicht. Wenn Sie dieses Feld angeben, verarbeitet der Agent jede Protokollnachricht mit allen von Ihnen angegebenen Filtern, und nur die Protokollereignisse, die alle Filter bestehen, werden in CloudWatch Logs veröffentlicht. Die Protokolleinträge, die nicht alle Filter bestehen, verbleiben weiterhin in der Protokolldatei des Hosts, werden aber nicht an CloudWatch Logs gesendet.
Jeder Eintrag im Filter-Array kann die folgenden Felder enthalten:
+ `type` – Gibt den Filtertyp an. Gültige Werte sind `include` und `exclude`. Bei `include` muss der Protokolleintrag mit dem Ausdruck übereinstimmen, der in CloudWatch Logs veröffentlicht werden soll. Bei `exclude` wird nicht jeder Protokolleintrag, der dem Filter entspricht, an CloudWatch Logs gesendet.
+ `expression`— Eine Zeichenfolge für reguläre Ausdrücke, die der [RE2 Syntax](https://github.com/google/re2/wiki/Syntax) folgt.
**Anmerkung**
Der CloudWatch Agent überprüft nicht die Leistung eines von Ihnen angegebenen regulären Ausdrucks und schränkt auch nicht die Laufzeit der Auswertung der regulären Ausdrücke ein. Wir empfehlen, darauf zu achten, keinen Ausdruck zu erstellen, dessen Auswertung hohe Kosten verursacht. Weitere Informationen zu möglichen Problemen finden Sie unter [Denial of Service für reguläre Ausdrücke — ReDo](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) S
Der folgende Auszug aus der CloudWatch Agentenkonfigurationsdatei veröffentlicht beispielsweise Protokolle, bei denen es sich um PUT- und POST-Anfragen handelt, in CloudWatch Logs, jedoch keine Protokolle, die von Firefox stammen.
```
"collect_list": [
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/test.log",
"log_group_name": "test.log",
"log_stream_name": "test.log",
"filters": [
{
"type": "exclude",
"expression": "Firefox"
},
{
"type": "include",
"expression": "P(UT|OST)"
}
]
},
.....
]
```
**Anmerkung**
Die Reihenfolge der Filter in der Konfigurationsdatei ist für die Leistung wichtig. Im vorherigen Beispiel löscht der Agent alle Protokolle, die mit `Firefox` übereinstimmen, bevor er mit der Auswertung des zweiten Filters beginnt. Wenn weniger Protokolleinträge mit mehreren Filtern ausgewertet werden sollen, platzieren Sie den Filter, der voraussichtlich mehr Protokolle ausschließt, an der ersten Stelle in der Konfigurationsdatei.
+ `timezone` – Optional. Gibt die Zeitzone an, die verwendet werden soll, wenn Zeitstempel auf Protokollereignisse angewendet werden. Die gültigen Werte sind `UTC` und `Local`. Der Standardwert ist `Local`.
Dieser Parameter wird ignoriert, wenn Sie keinen Wert für `timestamp_format` angeben.
+ `timestamp_format` – Optional. Gibt das Zeitstempelformat an, wobei Klartext und spezielle Symbole verwendet werden, die mit % beginnen. Wenn Sie dieses Feld nicht ausfüllen, wird die aktuelle Zeit verwendet. Wenn Sie dieses Feld verwenden, können Sie die Symbole aus der folgenden Liste als Teil des Formats verwenden.
**Anmerkung**
Dieser Parameter wird nicht berücksichtigt, wenn der `file_path` auf `amazon-cloudwatch-agent.log` gesetzt ist.
Wenn ein einzelner Protokolleintrag zwei Zeitstempel enthält, die dem Format entsprechen, wird der erste Zeitstempel verwendet.
Diese Liste von Symbolen unterscheidet sich von der Liste, die vom älteren CloudWatch Logs-Agenten verwendet wurde. Eine Zusammenfassung der Unterschiede finden Sie unter [Zeitstempelunterschiede zwischen dem CloudWatch Agenten und dem früheren CloudWatch Logs-Agenten](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-logs-timestamp-differences).
`%y`
Jahr ohne Jahrhundert als mit Nullen aufgefüllte Dezimalzahl Zum Beispiel, `19` um 2019 darzustellen.
`%Y`
Jahr mit Jahrhundert als Dezimalzahl Beispiel, `2019`.
`%b`
Monat als Abkürzung des Namens des Gebietsschemas
`%B`
Monat als vollständiger Name des Gebietsschemas
`%m`
Monat als mit Nullen aufgefüllte Dezimalzahl
`%-m`
Monat als Dezimalzahl (nicht mit Nullen aufgefüllt)
`%d`
Tag des Monats als mit Nullen aufgefüllte Dezimalzahl
`%-d`
Tag des Monats als Dezimalzahl (nicht mit Nullen aufgefüllt)
`%A`
Vollständiger Name des Wochentags, wie z. B. `Monday`
`%a`
Abkürzung des Wochentags, wie z. B. `Mon`
`%H`
Stunde (24-Stunden-Format) als mit Nullen aufgefüllte Dezimalzahl
`%I`
Stunde (12-Stunden-Format) als mit Nullen aufgefüllte Dezimalzahl
`%-I`
Stunde (12-Stunden-Format) als Dezimalzahl (nicht mit Nullen aufgefüllt)
`%p`
AM oder PM
`%M`
Minuten als mit Nullen aufgefüllte Dezimalzahl
`%-M`
Minuten als Dezimalzahl (nicht mit Nullen aufgefüllt)
`%S`
Sekunden als mit Nullen aufgefüllte Dezimalzahl
`%-S`
Sekunden als Dezimalzahl (nicht mit Nullen aufgefüllt)
`%f`
Sekundenbruchteile als Dezimalzahl (1 bis 9 Ziffern), links mit Nullen aufgefüllt.
`%Z`
Zeitzone, z. B. `PST`
`%z`
Zeitzone, ausgedrückt als der Abstand zwischen der lokalen Zeitzone und der Koordinierten Weltzeit (UTC). Beispiel, `-0700`. Es wird nur das dieses Format unterstützt. Beispiel: `-07:00` ist kein gültiges Format.
+ `multi_line_start_pattern` – Gibt das Muster an, anhand dessen der Beginn einer Protokollmeldung identifiziert wird. Eine Protokollmeldung besteht aus einer Zeile, die mit dem angegebenen Muster übereinstimmt, und allen folgenden Zeilen, die nicht dem Muster entsprechen.
Wenn Sie dieses Feld leer lassen, wird der Mehrzeilenmodus deaktiviert und bei jeder Zeile, die mit einem Zeichen beginnt, das kein Leerzeichen ist, wird der vorherige Protokolleintrag abgeschlossen und ein neuer Protokolleintrag gestartet.
Wenn Sie dieses Feld aufnehmen, können Sie `{timestamp_format}` angeben, um den gleichen regulären Ausdruck wie Ihr Zeitstempelformat zu verwenden. Andernfalls können Sie für CloudWatch Logs einen anderen regulären Ausdruck angeben, anhand dessen die Startzeilen von mehrzeiligen Einträgen bestimmt werden.
+ `encoding` – Gibt die Codierung der Protokolldatei an, damit sie korrekt gelesen werden kann. Wenn Sie eine falsche Codierung angeben, kann dies zu Datenverlust führen, weil Zeichen, die nicht decodiert werden können, durch andere Zeichen ersetzt werden.
Der Standardwert ist `utf-8`. Die folgenden Werte sind möglich:
`ascii, big5, euc-jp, euc-kr, gbk, gb18030, ibm866, iso2022-jp, iso8859-2, iso8859-3, iso8859-4, iso8859-5, iso8859-6, iso8859-7, iso8859-8, iso8859-8-i, iso8859-10, iso8859-13, iso8859-14, iso8859-15, iso8859-16, koi8-r, koi8-u, macintosh, shift_jis, utf-8, utf-16, utf-16le, UTF-16, UTF-16LE, windows-874, windows-1250, windows-1251, windows-1252, windows-1253, windows-1254, windows-1255, windows-1256, windows-1257, windows-1258, x-mac-cyrillic`
+ `service.name` – Optional. Gibt den Servicenamen an, der verwendet werden soll, um die Entität für die [Suche nach zugehöriger Telemetrie](ExploreRelated.md) mit Werten zu befüllen.
+ `deployment.environment` – Optional. Gibt den Umgebungsnamen an, der verwendet werden soll, um die Entität für die [Suche nach zugehöriger Telemetrie](ExploreRelated.md) mit Werten zu befüllen.
+ `trim_timestamp` – Optional. Wenn dies zutrifft, entfernt der CloudWatch Agent den entsprechenden Zeitstempel `timestamp_format` aus der Zeile, bevor er ihn an CloudWatch Logs sendet. Das LogEvent wird das `timestamp` Feld immer noch enthalten.
Wenn Sie dieses Feld auslassen, wird der Standardwert `false` verwendet.
+ Im Abschnitt `windows_events` ist der Typ der Windows-Ereignisse angegeben, der von Servern mit Windows Server erfasst wird. Er enthält folgende Felder:
+ `collect_list` – Erforderlich, wenn `windows_events` enthalten ist. Gibt die Typen und Stufen von zu erfassenden Windows-Ereignissen an. Jedes zu erfassende Protokoll hat einen Eintrag in diesem Abschnitt, der folgende Felder enthalten kann:
+ `event_name` – Gibt den Typ der zu protokollierenden Windows-Ereignisse an. Dies entspricht dem Kanalnamen des Windows-Ereignisprotokolls, z. B. `System`, `Security`, `Application` usw. Dieses Feld ist für jeden Typ eines zu protokollierenden Windows-Ereignisses ein Pflichtfeld.
**Anmerkung**
Beim CloudWatch Abrufen von Nachrichten aus einem Windows-Protokollkanal wird der Protokollkanal anhand seiner `Full Name` Eigenschaft gesucht. Währenddessen zeigt der Navigationsbereich der Windows Event Viewer die `Log Name`-Eigenschaft von Protokollkanälen an. `Full Name` und `Log Name` stimmen nicht immer überein. Um den `Full Name` eines Kanals zu bestätigen, klicken Sie in der Windows Event Viewer mit der rechten Maustaste darauf und öffnen Sie **Eigenschaften**.
+ `event_levels` – Optional. Gibt die Ebenen des zu protokollierenden Ereignisses an. Sie müssen jede zu protokollierende Ebene angeben. Mögliche Werte sind `INFORMATION`, `WARNING`, `ERROR`, `CRITICAL` und `VERBOSE`. Dieses Feld ist für jede Art von Windows-Ereignis, das protokolliert werden soll, optional und kann mit anderen Filteroptionen wie `event_ids` und `filters` verwendet werden.
+ `event_ids` – Optional. Enthält eine Reihe von Windows-Ereignissen IDs , mit denen angegeben wird, welche Ereignisse aus dem Windows-Ereignisprotokoll erfasst werden sollen. Wenn dieses Feld ausgeschlossen wird, werden alle Ereignisse aus dem angegebenen Ereignisprotokoll erfasst. Wenn dieses Feld enthalten ist, sammelt der Agent nur Ereignisse, die dem angegebenen Ereignis entsprechen IDs.
Jeder Eintrag im `event_ids`-Array sollte ein numerischer Ereignis-ID-Wert sein und kann mit anderen Filteroptionen verwendet werden. Beachten Sie den dritten Eintrag im folgenden Konfigurationsbeispiel.
**Anmerkung**
Wenn Sie nach Ereignis-ID filtern müssen, wird die Verwendung von `event_ids` gegenüber regulären Ausdrücken empfohlen, da dies eine bessere Leistung bietet.
+ `filters` – Optional. Enthält einen Array von Einträgen. Jeder Eintrag gibt einen regulären Ausdruck und einen Filtertyp an, um anzugeben, ob Protokolleinträge, die dem Filter entsprechen, veröffentlicht oder gelöscht werden sollen. Wenn das Feld enthalten ist, verarbeitet der Agent jede Protokollnachricht mit allen von Ihnen angegebenen Filtern, und nur die Protokollereignisse, die alle Filter bestehen, werden in CloudWatch Logs veröffentlicht. Die Windows-Ereignisprotokolle, die nicht alle Filter bestehen, werden gelöscht und nicht an CloudWatch Logs gesendet. Der Filterbereich kann auch zusammen mit anderen Filtermechanismen wie Ereignis-IDs [4624, 4625] und Systemebenen (Information, Fehler oder Kritisch) verwendet werden, um Protokolle effektiv zu filtern und an sie weiterzuleiten. CloudWatch
Jeder Eintrag im Filter-Array kann die folgenden Felder enthalten:
+ `type`: Gibt den Filtertyp an. Gültige Werte sind `include` und `exclude`. Bei Include muss der Windows-Ereigniseintrag mit dem Ausdruck übereinstimmen, der in Logs veröffentlicht werden soll. CloudWatch Mit exclude wird jeder Eintrag im Windows-Ereignisprotokoll, der dem Filter entspricht, nicht an CloudWatch Logs gesendet.
+ `expression`— Eine Zeichenfolge für reguläre Ausdrücke, die der RE2 Syntax folgt.
**Anmerkung**
Der CloudWatch Agent validiert keine regulären Ausdrücke, die Sie angeben. Er begrenzt auch nicht die Evaluierungszeit. Schreiben Sie Ihre Ausdrücke sorgfältig, um Leistungsprobleme zu vermeiden. Weitere Informationen zu Sicherheitstricks finden Sie unter [Denial of Service mit regulären Ausdrücken — S. ReDo](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)
In der folgenden Beispielkonfiguration für Agenten:
Für den ersten Eintrag überträgt der Agent Protokolle, die Datenbankfehlermeldungen, alle authentifizierungsbezogenen Aktivitäten und alle Anmeldeereignisse (sowohl erfolgreiche als auch fehlgeschlagene Versuche) enthalten. CloudWatch Protokolle, die diesem Muster nicht entsprechen, werden gelöscht.
Beim zweiten Eintrag erfolgt die anfängliche Filterung auf der Grundlage von Ereignis-IDs für das Windows-Ereignisabonnement. Der Agent erfasst alle Protokolle, die die Zeichenfolge „user“ enthalten, und verwirft Protokolle, die diesen Mustern nicht entsprechen. Der Agent löscht dann die Protokolle, die Folgendes enthalten, `successful` bevor er die verbleibenden CloudWatch Protokolle an Logs sendet. Jeder Filtertyp wird auf jedes Windows-Ereignisprotokoll angewendet, bevor es an gesendet wird CloudWatch.
```
"collect_list": [
{
"event_name": "Application",
"log_group_name": "ApplicationEvents",
"log_stream_name": "ApplicationEvents",
"filters": [
{
"type": "include",
"expression": "Database.*failed|Authentication.*|login.*"
}
]
},
{
"event_name": "System",
"log_group_name": "SystemEvents",
"log_stream_name": "Logon-events",
"event_ids": [
4624,
4625
],
"filters": [
{
"type": "include",
"expression": ".*user.*"
},
{
"type": "exclude",
"expression": ".*successful.*"
}
]
}
.....
]
```
**Anmerkung**
Die Reihenfolge der Filter in der Konfiguration ist für die Leistung wichtig. Im zweiten Eintrag verwirft der Agent alle Protokolle, die nicht mit dem Benutzer übereinstimmen, bevor er mit der Auswertung des zweiten Filterausdrucks beginnt. Für optimale Leistung ordnen Sie die Filter von der höchsten zur niedrigsten Ausschlussrate.
Sie können zwar Protokolle nach Ereignis-IDs und Systemebene im Filterausdruck herausfiltern, es wird jedoch empfohlen, `event_ids` und `log_level` zu verwenden, wie im zweiten Eintrag gezeigt, um die Leistung zu verbessern.
**Warnung**
Obwohl alle Filtermechanismen (event\$1levels, event\$1ids, filters) optional sind, ist während der Agentenkonfiguration mindestens einer erforderlich, um Protokolle zu filtern.
+ `log_group_name` – Erforderlich. Gibt an, was als Protokollgruppenname in CloudWatch Logs verwendet werden soll.
+ `log_stream_name` – Optional. Gibt an, was als Name des Protokolldatenstroms in CloudWatch Logs verwendet werden soll. Sie können die Variablen `{instance_id}`, `{hostname}`, `{local_hostname}` und `{ip_address}` im Namen verwenden. `{hostname}` ruft den Hostnamen aus den EC2-Metadaten ab, `{local_hostname}` verwendet den Hostnamen aus der Netzwerkkonfigurationsdatei.
Wenn Sie dieses Feld auslassen, wird der Wert des Parameters `log_stream_name` im globalen `logs`-Abschnitt verwendet. Wird dies ebenfalls weggelassen, wird der Standardwert von `{instance_id}` verwendet.
Wenn ein Protokoll-Stream noch nicht vorhanden ist, wird er automatisch erstellt.
+ `event_format` – Optional. Gibt das Format an, das beim Speichern von Windows-Ereignissen in CloudWatch Protokollen verwendet werden soll. `xml`verwendet das XML-Format wie in der Windows-Ereignisanzeige. `text`verwendet das CloudWatch Legacy-Logs-Agent-Format.
+ `retention_in_days` – Optional. Gibt an, wie viele Tage lang die Windows-Ereignisse in der festgelegten Protokollgruppe aufbewahrt werden.
+ Wenn der Agent diese Protokollgruppe jetzt erstellt und Sie dieses Feld auslassen, wird die Aufbewahrung dieser neuen Protokollgruppe auf niemals ablaufend gesetzt.
+ Wenn diese Protokollgruppe bereits vorhanden ist und Sie dieses Feld angeben, wird die von Ihnen angegebene neue Aufbewahrung verwendet. Wenn Sie dieses Feld für eine bereits vorhandene Protokollgruppe weglassen, wird die Aufbewahrung der Protokollgruppe nicht geändert.
Der CloudWatch Agent-Assistent verwendet `-1` als Standardwert für dieses Feld, wenn es zur Erstellung der Agent-Konfigurationsdatei verwendet wird und Sie keinen Wert für die Aufbewahrung von Protokollen angeben. Dieser vom Assistenten festgelegte `-1`-Wert legt fest, dass die Ereignisse in der Protokollgruppe nicht ablaufen. Das manuelle Ändern dieses Werts auf `-1` hat jedoch keine Auswirkung.
Mögliche Werte sind 1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1827, 2192, 2557, 2922, 3288 und 3653.
Wenn Sie den Agenten so konfigurieren, dass er mehrere Protokollstreams in dieselbe Protokollgruppe schreibt, und Sie `retention_in_days` an einer Stelle angeben, wird damit die Protokollaufbewahrung für die gesamte Protokollgruppe festgelegt. Wenn Sie `retention_in_days` an mehreren Stellen für dieselbe Protokollgruppe angeben und alle diese Werte gleich sind, wird die Aufbewahrung festgelegt. Werden jedoch für dieselbe Protokollgruppe an mehreren Stellen unterschiedliche `retention_in_days`-Werte angegeben, wird die Protokollaufbewahrung nicht festgelegt und der Agent wird gestoppt und gibt einen Fehler zurück.
**Anmerkung**
Die IAM-Rolle oder der IAM-Benutzer des Agenten muss über `logs:PutRetentionPolicy` verfügen, damit sie bzw. er Aufbewahrungsrichtlinien festlegen kann.
**Warnung**
Wenn Sie für eine bereits vorhandene Protokollgruppe `retention_in_days` festlegen, werden alle Protokolle in dieser Protokollgruppe, die vor der von Ihnen angegebenen Anzahl von Tagen veröffentlicht wurden, gelöscht. Wenn Sie beispielsweise den Wert 3 festlegen, werden alle Protokolle gelöscht, die 3 oder mehr Tage alt sind.
+ `log_stream_name` – Optional. Gibt den Namen des standardmäßigen Protokoll-Streams an, der für alle Protokolle oder Windows-Ereignisse verwendet werden soll, für die kein Name eines Protokoll-Streams im Parameter `log_stream_name` des zugehörigen Eintrags in `collect_list` definiert ist.
+ `endpoint_override` – Gibt einen FIPS-Endpunkt oder einen privaten Link an, der als Endpunkt verwendet wird, an den der Agent Protokolle sendet. Wenn Sie dieses Feld angeben und einen privaten Link setzen, können Sie die Protokolle an einen Amazon-VPC-Endpunkt senden. Weitere Informationen finden Sie unter [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
Der Wert von `endpoint_override` muss eine Zeichenkette sein, die eine URL ist.
Beispielsweise legt der folgende Teil des Protokollabschnitts der Konfigurationsdatei fest, dass der Agent beim Senden von Protokollen einen VPC-Endpunkt verwendet.
```
{
"logs": {
"endpoint_override": "vpce-XXXXXXXXXXXXXXXXXXXXXXXXX.logs.us-east-1.vpce.amazonaws.com",
......
},
}
```
+ `force_flush_interval` – Gibt die maximale Zeitspanne in Sekunden an, in der Protokolle im Speicherpuffer verbleiben, bevor sie an den Server gesendet werden. Unabhängig von der Einstellung für dieses Feld werden die Protokolle an den Server gesendet, sobald die Größe der Protokolle im Puffer 1 MB erreicht. Der Standardwert ist 5.
Wenn Sie den Agenten verwenden, um hochauflösende Metriken im eingebetteten Metrikformat zu melden, und Sie Alarme für diese Metriken einstellen, belassen Sie diesen Parameter auf dem Standardwert von 5. Andernfalls werden die Metriken mit einer Verzögerung gemeldet, die bei unvollständigen oder unvollständigen Daten zu einer Alarmierung führen kann.
+ `credentials`— Gibt eine IAM-Rolle an, die beim Senden von Protokollen an ein anderes AWS Konto verwendet werden soll. Sofern angegeben, enthält dieses Feld einen Parameter, `role_arn`.
+ `role_arn`— Gibt den ARN einer IAM-Rolle an, der für die Authentifizierung verwendet werden soll, wenn Logs an ein anderes AWS Konto gesendet werden. Weitere Informationen finden Sie unter [Metriken, Protokolle und Ablaufverfolgungen an ein anderes Konto senden](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account). Wenn dieser Parameter hier angegeben wird, überschreibt er den Wert für `role_arn` im Abschnitt `agent` der Konfigurationsdatei, sofern vorhanden.
+ `metrics_collected`— Dieses Feld kann Abschnitte enthalten, in denen angegeben wird, dass der Agent Protokolle sammeln soll, um Anwendungsfälle wie CloudWatch Application Signals und Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS zu ermöglichen.
+ `application_signals`(Optional) Gibt an, dass Sie [CloudWatchApplication Signals](CloudWatch-Application-Monitoring-Sections.md) aktivieren möchten. Weitere Informationen zu dieser Konfiguration finden Sie unter[CloudWatch Anwendungssignale aktivieren](CloudWatch-Agent-Application_Signals.md).
+ `kubernetes` – Dieses Feld kann einen `enhanced_container_insights`-Parameter enthalten, mit dem Sie Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS aktivieren können.
+ `enhanced_container_insights` – Stellen Sie dies auf `true` ein, um Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS zu aktivieren. Weitere Informationen finden Sie unter [Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS](container-insights-detailed-metrics.md).
+ `accelerated_compute_metrics`: Setzen Sie dies auf `false`, um die Erfassung von Nvidia-GPU-Metriken auf Amazon-EKS-Clustern zu deaktivieren. Weitere Informationen finden Sie unter [NVIDIA-GPU-Metriken](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-GPU).
+ `emf` – Um in Protokollen eingebettete Metriken zu erfassen, ist es nicht mehr erforderlich, dieses `emf`-Feld hinzuzufügen. Dies ist ein Legacy-Feld, das angibt, dass der Agent Protokolle im eingebetteten Metrikformat erfassen soll. Sie können Metrikdaten aus diesen Protokollen generieren. Weitere Informationen finden Sie unter [Einbetten von Metriken in Protokollen](CloudWatch_Embedded_Metric_Format.md).
+ `otlp` – Optional. Gibt an, dass Sie Metriken aus dem OpenTelemetry SDK sammeln möchten. Weitere Informationen über die Felder, die Sie in diesem Abschnitt verwenden können, finden Sie unter [Erfassen Sie Metriken und Traces mit OpenTelemetry](CloudWatch-Agent-OpenTelemetry-metrics.md).
Es folgt ein Beispiel für den Abschnitt `logs`.
```
"logs":{
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log",
"log_stream_name": "my_log_stream_name_1"
},
{
"file_path": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\test.log",
"log_group_name": "test.log",
"log_stream_name": "my_log_stream_name_2"
}
]
},
"windows_events": {
"collect_list": [
{
"event_name": "System",
"event_ids": [
1001,
1008
],
"log_group_name": "System",
"log_stream_name": "System"
},
{
"event_name": "CustomizedName",
"event_levels": [
"INFORMATION",
"ERROR"
],
"log_group_name": "CustomizedLogGroup",
"log_stream_name": "CustomizedLogStream"
},
{
"event_name": "Application",
"event_levels": [
"INFORMATION",
"ERROR"
],
"event_ids":[
7369,
5624
],
"log_group_name": "CustomizedLogGroup",
"log_stream_name": "CustomizedLogStream"
}
]
}
},
"log_stream_name": "my_log_stream_name",
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
}
}
}
```
## CloudWatch Agenten-Konfigurationsdatei: Abschnitt Traces
Indem Sie der CloudWatch Agentenkonfigurationsdatei einen `traces` Abschnitt hinzufügen, können Sie CloudWatch Application Signals aktivieren oder Traces von X-Ray und dem OpenTelemetry Instrumentierungs-SDK sammeln und an X-Ray senden.
**Wichtig**
Die IAM-Rolle oder der IAM-Benutzer des Agenten müssen über die **AWSXrayWriteOnlyAccess**Richtlinie verfügen, um Trace-Daten an X-Ray zu senden.
Für einen schnellen Start mit der Erfassung von Traces können Sie der CloudWatch Agenten-Konfigurationsdatei einfach Folgendes hinzufügen.
```
"traces_collected": {
"xray": {
},
"otlp": {
}
}
```
Wenn Sie den vorherigen Abschnitt zur CloudWatch Agentenkonfigurationsdatei hinzufügen und den Agenten neu starten, beginnt der Agent mit der Erfassung von Traces mit den folgenden Standardoptionen und -werten. Weitere Informationen zu diesen Parametern finden Sie in den Parameterdefinitionen weiter unten in diesem Abschnitt.
```
"traces_collected": {
"xray": {
"bind_address": "127.0.0.1:2000",
"tcp_proxy": {
"bind_address": "127.0.0.1:2000"
}
},
"otlp": {
"grpc_endpoint": "127.0.0.1:4317",
"http_endpoint": "127.0.0.1:4318"
}
}
```
Der Abschnitt `traces` kann die folgenden Felder enthalten:
+ `traces_collected` – Erforderlich, sofern der Abschnitt `traces` enthalten ist. Gibt SDKs an, von welchem Traces erfasst werden sollen. Dies kann die folgenden Felder umfassen:
+ `application_signals` – Optional. Gibt an, dass Sie [CloudWatchApplication Signals](CloudWatch-Application-Monitoring-Sections.md) aktivieren möchten. Weitere Informationen zu dieser Konfiguration finden Sie unter[CloudWatch Anwendungssignale aktivieren](CloudWatch-Agent-Application_Signals.md).
+ `xray` – Optional. Gibt an, dass Sie Ablaufverfolgungen aus dem X-Ray-SDK sammeln möchten. Dieser Abschnitt kann die folgenden Felder enthalten:
+ `bind_address` – Optional. Gibt die UDP-Adresse an, die der CloudWatch Agent verwenden soll, um auf Röntgen-Traces zu warten. Das Format ist `ip:port`. Diese Adresse muss mit der im X-Ray SDK eingestellten Adresse übereinstimmen.
Wenn Sie dieses Feld auslassen, wird der Standard `127.0.0.1:2000` verwendet.
+ `tcp_proxy` – Optional. Konfiguriert die Adresse für einen Proxy, der für die Unterstützung von X-Ray Remote Sampling verwendet wird. Weitere Informationen finden Sie unter [Konfigurieren von Samplingregeln](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-sampling.html) in der X-Ray-Dokumentation.
Dieser Abschnitt kann das folgende Feld enthalten.
+ `bind_address` – Optional. Gibt die TCP-Adresse an, für die der CloudWatch Agent den Proxy einrichten soll. Das Format ist `ip:port`. Diese Adresse muss mit der im X-Ray SDK eingestellten Adresse übereinstimmen.
Wenn Sie dieses Feld auslassen, wird der Standard `127.0.0.1:2000` verwendet.
+ `otlp` – Optional. Gibt an, dass Sie Traces vom OpenTelemetry SDK sammeln möchten. Weitere Informationen über die Felder, die Sie in diesem Abschnitt verwenden können, finden Sie unter [Erfassen Sie Metriken und Traces mit OpenTelemetry](CloudWatch-Agent-OpenTelemetry-metrics.md).) Weitere Informationen zur Distribution für finden Sie unter AWS [AWS Distro](https://aws.amazon.com/otel/) for OpenTelemetry. OpenTelemetry [Weitere Informationen zur AWS Distribution für OpenTelemetry SDKs finden Sie unter Einführung.](https://aws-otel.github.io/docs/introduction)
Dieser Abschnitt kann die folgenden Felder enthalten:
+ `grpc_endpoint` – Optional. Gibt die Adresse an, die der CloudWatch Agent verwenden soll, um auf OpenTelemetry Traces zu warten, die mit gRPC Remote Procedure Calls gesendet wurden. Das Format ist `ip:port`. Diese Adresse muss mit der Adresse übereinstimmen, die für den gRPC-Exporter im OpenTelemetry SDK festgelegt wurde.
Wenn Sie dieses Feld auslassen, wird der Standard `127.0.0.1:4317` verwendet.
+ `http_endpoint` – Optional. Gibt die Adresse an, die der CloudWatch Agent verwenden soll, um auf OTLP-Traces zu warten, die über HTTP gesendet wurden. Das Format ist `ip:port`. Diese Adresse muss mit der Adresse übereinstimmen, die für den HTTP-Exporter im OpenTelemetry SDK festgelegt wurde.
Wenn Sie dieses Feld auslassen, wird der Standard `127.0.0.1:4318` verwendet.
+ `concurrency` – Optional. Gibt die maximale Anzahl der gleichzeitigen Aufrufe von X-Ray an, die zum Hochladen von Ablaufverfolgungen verwendet werden können. Der Standardwert ist `8`
+ `local_mode` – Optional. Wenn `true`, erfasst der Agent keine Amazon-EC2-Instance-Metadaten. Der Standardwert ist `false`
+ `endpoint_override` – Optional. Gibt einen FIPS-Endpunkt oder einen privaten Link an, der als Endpunkt verwendet werden soll, an den der CloudWatch Agent Traces sendet. Wenn Sie dieses Feld angeben und einen privaten Link setzen, können Sie die Ablaufverfolgung an einen Amazon-VPC-Endpunkt senden. Weitere Informationen finden Sie unter [Was ist Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
Der Wert von `endpoint_override` muss eine Zeichenkette sein, die eine URL ist.
+ `region_override` – Optional. Gibt die Region an, die für den X-Ray-Endpunkt verwendet werden soll. Der CloudWatch Agent sendet die Spuren in der angegebenen Region an X-Ray. Wenn Sie dieses Feld auslassen, sendet der Agent die Ablaufverfolgung an die Region, in der sich die Amazon-EC2-Instance befindet.
Wenn Sie hier eine Region angeben, hat diese Vorrang vor der Einstellung des `region`-Parameters im `agent`-Abschnitt der Konfigurationsdatei.
+ `proxy_override` – Optional. Gibt die Proxy-Serveradresse an, die der CloudWatch Agent beim Senden von Anfragen an X-Ray verwenden soll. Das Protokoll des Proxyservers muss als Teil dieser Adresse angegeben werden.
+ `credentials`— Gibt eine IAM-Rolle an, die beim Senden von Traces an ein anderes AWS Konto verwendet werden soll. Sofern angegeben, enthält dieses Feld einen Parameter, `role_arn`.
+ `role_arn`— Gibt den ARN einer IAM-Rolle an, der für die Authentifizierung verwendet werden soll, wenn Traces an ein anderes AWS Konto gesendet werden. Weitere Informationen finden Sie unter [Metriken, Protokolle und Ablaufverfolgungen an ein anderes Konto senden](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account). Wenn dieser Parameter hier angegeben wird, überschreibt er den Wert für `role_arn` im Abschnitt `agent` der Konfigurationsdatei, sofern vorhanden.
+ `transit_spans_in_otlp_format` – Optional. Wenn`true`, sendet Traces im OpenTelemetry Protokollformat an X-Ray, das Span-Ereignisse in der Transaktionssuche unterstützt. Weitere Informationen finden Sie unter [Hinzufügen benutzerdefinierter Attribute](CloudWatch-Transaction-Search-add-custom-attributes.md). Der Standardwert ist `false`.
## CloudWatch Agenten-Konfigurationsdatei: Vollständige Beispiele
Im Folgenden finden Sie ein Beispiel für eine vollständige CloudWatch Agentenkonfigurationsdatei für einen Linux-Server.
Die Elemente, die in den `measurement`-Abschnitten für die zu sammelnden Metriken aufgelistet werden, können entweder den vollständigen Namen angeben oder nur den Teil des Metriknamens, der an den Typ der Ressource angehängt wird. Beispiel: Die Angabe von entweder `reads` oder `diskio_reads` im Abschnitt `measurement` des Abschnitts `diskio` bewirkt, dass die Metrik `diskio_reads` erfasst wird.
Dieses Beispiel enthält beide Möglichkeiten zur Angabe von Metriken im Bereich `measurement`.
```
{
"agent": {
"metrics_collection_interval": 10,
"logfile": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log"
},
"metrics": {
"namespace": "MyCustomNamespace",
"metrics_collected": {
"cpu": {
"resources": [
"*"
],
"measurement": [
{"name": "cpu_usage_idle", "rename": "CPU_USAGE_IDLE", "unit": "Percent"},
{"name": "cpu_usage_nice", "unit": "Percent"},
"cpu_usage_guest"
],
"totalcpu": false,
"metrics_collection_interval": 10,
"append_dimensions": {
"customized_dimension_key_1": "customized_dimension_value_1",
"customized_dimension_key_2": "customized_dimension_value_2"
}
},
"disk": {
"resources": [
"/",
"/tmp"
],
"measurement": [
{"name": "free", "rename": "DISK_FREE", "unit": "Gigabytes"},
"total",
"used"
],
"ignore_file_system_types": [
"sysfs", "devtmpfs"
],
"metrics_collection_interval": 60,
"append_dimensions": {
"customized_dimension_key_3": "customized_dimension_value_3",
"customized_dimension_key_4": "customized_dimension_value_4"
}
},
"diskio": {
"resources": [
"*"
],
"measurement": [
"reads",
"writes",
"read_time",
"write_time",
"io_time"
],
"metrics_collection_interval": 60
},
"swap": {
"measurement": [
"swap_used",
"swap_free",
"swap_used_percent"
]
},
"mem": {
"measurement": [
"mem_used",
"mem_cached",
"mem_total"
],
"metrics_collection_interval": 1
},
"net": {
"resources": [
"eth0"
],
"measurement": [
"bytes_sent",
"bytes_recv",
"drop_in",
"drop_out"
]
},
"netstat": {
"measurement": [
"tcp_established",
"tcp_syn_sent",
"tcp_close"
],
"metrics_collection_interval": 60
},
"processes": {
"measurement": [
"running",
"sleeping",
"dead"
]
}
},
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
"aggregation_dimensions" : [["ImageId"], ["InstanceId", "InstanceType"], ["d1"],[]],
"force_flush_interval" : 30
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log",
"log_stream_name": "amazon-cloudwatch-agent.log",
"timezone": "UTC"
},
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/test.log",
"log_group_name": "test.log",
"log_stream_name": "test.log",
"timezone": "Local"
}
]
}
},
"log_stream_name": "my_log_stream_name",
"force_flush_interval" : 15,
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
}
}
}
}
```
Im Folgenden finden Sie ein Beispiel für eine vollständige CloudWatch Agentenkonfigurationsdatei für einen Server, auf dem Windows Server ausgeführt wird.
```
{
"agent": {
"metrics_collection_interval": 60,
"logfile": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log"
},
"metrics": {
"namespace": "MyCustomNamespace",
"metrics_collected": {
"Processor": {
"measurement": [
{"name": "% Idle Time", "rename": "CPU_IDLE", "unit": "Percent"},
"% Interrupt Time",
"% User Time",
"% Processor Time"
],
"resources": [
"*"
],
"append_dimensions": {
"customized_dimension_key_1": "customized_dimension_value_1",
"customized_dimension_key_2": "customized_dimension_value_2"
}
},
"LogicalDisk": {
"measurement": [
{"name": "% Idle Time", "unit": "Percent"},
{"name": "% Disk Read Time", "rename": "DISK_READ"},
"% Disk Write Time"
],
"resources": [
"*"
]
},
"customizedObjectName": {
"metrics_collection_interval": 60,
"customizedCounterName": [
"metric1",
"metric2"
],
"resources": [
"customizedInstances"
]
},
"Memory": {
"metrics_collection_interval": 5,
"measurement": [
"Available Bytes",
"Cache Faults/sec",
"Page Faults/sec",
"Pages/sec"
]
},
"Network Interface": {
"metrics_collection_interval": 5,
"measurement": [
"Bytes Received/sec",
"Bytes Sent/sec",
"Packets Received/sec",
"Packets Sent/sec"
],
"resources": [
"*"
],
"append_dimensions": {
"customized_dimension_key_3": "customized_dimension_value_3"
}
},
"System": {
"measurement": [
"Context Switches/sec",
"System Calls/sec",
"Processor Queue Length"
]
}
},
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
"aggregation_dimensions" : [["ImageId"], ["InstanceId", "InstanceType"], ["d1"],[]]
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log",
"timezone": "UTC"
},
{
"file_path": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\test.log",
"log_group_name": "test.log",
"timezone": "Local"
}
]
},
"windows_events": {
"collect_list": [
{
"event_name": "System",
"event_levels": [
"INFORMATION",
"ERROR"
],
"log_group_name": "System",
"log_stream_name": "System",
"event_format": "xml"
},
{
"event_name": "CustomizedName",
"event_levels": [
"WARNING",
"ERROR"
],
"log_group_name": "CustomizedLogGroup",
"log_stream_name": "CustomizedLogStream",
"event_format": "xml"
}
]
}
},
"log_stream_name": "example_log_stream_name"
}
}
```
## Speichern Sie die CloudWatch Agent-Konfigurationsdatei manuell
Wenn Sie die CloudWatch Agentenkonfigurationsdatei manuell erstellen oder bearbeiten, können Sie ihr einen beliebigen Namen geben. Anschließend können Sie die Datei auf andere Server kopieren, auf denen der Agent ausgeführt werden soll.
## Die CloudWatch Agentenkonfigurationsdatei in den Systems Manager Parameter Store hochladen
Wenn Sie den SSM-Agent verwenden möchten, um den CloudWatch Agenten auf Servern zu installieren, können Sie die CloudWatch Agentenkonfigurationsdatei nach der manuellen Bearbeitung in den Systems Manager Parameter Store hochladen. Verwenden Sie dazu den Systems Manager `put-parameter`-Befehl.
Zum Speichern der Datei in Parameter Store müssen Sie eine IAM-Rolle mit ausreichenden Berechtigungen verwenden.
Verwenden Sie den folgenden Befehl. Dabei *parameter name* handelt es sich um den Namen, der für diese Datei im Parameter Store verwendet werden soll, sowie *configuration\$1file\$1pathname* um den Pfad und den Dateinamen der Konfigurationsdatei, die Sie bearbeitet haben.
```
aws ssm put-parameter --name "parameter name" --type "String" --value file://configuration_file_pathname
```
# CloudWatch Anwendungssignale aktivieren
Verwenden Sie CloudWatch Application Signals, um Ihre Anwendungen automatisch zu nutzen, AWS sodass Sie die Anwendungsleistung anhand Ihrer Geschäftsziele verfolgen können. Application Signals bietet Ihnen eine einheitliche, anwendungsorientierte Ansicht Ihrer Java-Anwendungen, ihrer Abhängigkeiten und ihrer Edges. Weitere Informationen finden Sie unter [Anwendungssignale](CloudWatch-Application-Monitoring-Sections.md).
CloudWatch Application Signals nutzt den CloudWatch Agenten, um Metriken und Traces von Ihren automatisch instrumentierten Anwendungen zu empfangen, optional Regeln anzuwenden, um die hohe Kardinalität zu reduzieren, und dann die verarbeitete Telemetrie zu veröffentlichen. CloudWatch Mithilfe der Agenten-Konfigurationsdatei können Sie dem CloudWatch Agenten eine benutzerdefinierte Konfiguration speziell für Application Signals bereitstellen. Zunächst gibt das Vorhandensein eines `application_signals` Abschnitts unter dem Abschnitt innerhalb des `metrics_collected` `logs` Abschnitts der Agentenkonfigurationsdatei an, dass der CloudWatch Agent Metriken von Ihren automatisch instrumentierten Anwendungen empfängt. In ähnlicher Weise gibt das Vorhandensein eines `application_signals` Abschnitts unter dem `traces_collected` Abschnitt innerhalb des `traces` Abschnitts der Agentenkonfigurationsdatei an, dass der CloudWatch Agent für den Empfang von Traces von Ihren automatisch instrumentierten Anwendungen aktiviert ist. Darüber hinaus können Sie optional benutzerdefinierte Konfigurationsregeln angeben, um die Veröffentlichung von Telemetriedaten mit hoher Kardinalität zu reduzieren, wie in diesem Abschnitt beschrieben.
+ Wenn Sie das Amazon [ CloudWatchObservability EKS-Add-on für Amazon](install-CloudWatch-Observability-EKS-addon.md) EKS-Cluster installieren, ist der CloudWatch Agent standardmäßig aktiviert, um sowohl Metriken als auch Traces von Ihren automatisch instrumentierten Anwendungen zu empfangen. Wenn Sie optional benutzerdefinierte Konfigurationsregeln übergeben möchten, können Sie dies tun, indem Sie eine benutzerdefinierte Agentenkonfiguration an das Amazon-EKS-Add-On übergeben, wenn Sie es erstellen oder aktualisieren, indem Sie zusätzliche Konfigurationen verwenden, wie unter [(Optional) Zusätzliche Konfiguration](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration) beschrieben.
+ Wenn Sie RedHat für OpenShift on AWS (ROSA) den CloudWatch Agent-Operator mithilfe von Helm-Charts installieren, ist der CloudWatch Agent standardmäßig so aktiviert, dass er sowohl Metriken als auch Traces von Ihren automatisch instrumentierten Anwendungen empfängt. Wenn Sie optional benutzerdefinierte Konfigurationsregeln übergeben möchten, können Sie dazu eine benutzerdefinierte Agentenkonfiguration übergeben, indem Sie das Helm-Chart nutzen, wie unter [(Optional) Zusätzliche Konfiguration](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration) beschrieben.
+ Für andere unterstützte Plattformen, einschließlich Amazon EC2, müssen Sie den CloudWatch Agenten mit einer Agentenkonfiguration starten, die Application Signals aktiviert, indem Sie die `application_signals` Abschnitte und optional alle benutzerdefinierten Konfigurationsregeln angeben, wie später in diesem Abschnitt beschrieben.
Im Folgenden finden Sie eine Übersicht über die Felder in der CloudWatch Agenten-Konfigurationsdatei, die sich auf CloudWatch Application Signals beziehen.
+ `logs`
+ `metrics_collected`— Dieses Feld kann Abschnitte enthalten, in denen angegeben wird, dass der Agent Protokolle sammeln soll, um Anwendungsfälle wie CloudWatch Application Signals und Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS zu ermöglichen.
**Anmerkung**
Bisher wurde dieser Abschnitt auch verwendet, um anzugeben, dass der Agent Protokolle im eingebetteten Metrikformat sammeln soll. Diese Einstellungen werden nicht mehr benötigt.
+ `application_signals`(Optional) Gibt an, dass Sie CloudWatch Application Signals ermöglichen möchten, Metriken von Ihren automatisch instrumentierten Anwendungen zu empfangen, um CloudWatch Application Signals zu unterstützen.
+ `rules` (Optional) Eine Reihe von Regeln zur bedingten Auswahl von Metriken und Traces und zur Anwendung von Aktionen für Szenarien mit hoher Kardinalität. Jede Regel kann die folgenden Felder enthalten:
+ `rule_name` (Optional) Der Name der Regel.
+ `selectors` (Optional) Eine Reihe von Metriken und Traces mit Dimensionsabgleichungen. Jede Auswahl muss folgende Felder angeben:
+ `dimension` Erforderlich, wenn `selectors` nicht leer ist. Dies gibt die Dimension der Metriken und Ablaufverfolgungen an, die als Filter verwendet werden sollen.
+ `match` Erforderlich, wenn `selectors` nicht leer ist. Ein Platzhaltermuster, das zum Abgleichen von Werten der angegebenen Dimension verwendet wird.
+ `action` (Optional) Die Aktion, die auf Metriken und Traces angewendet werden soll, die den angegebenen Selektoren entsprechen. Der Wert von `action` muss eines der folgenden Schlüsselwörter sein:
+ `keep`Gibt an, dass nur die Metriken und Traces gesendet werden sollen, CloudWatch wenn sie mit den übereinstimmen. `selectors`
+ `drop` Gibt an, dass die Metrik und die Traces, die dem `selectors` entsprechen, verworfen werden sollen.
+ `replace` Gibt an, dass die Dimensionen der Metriken und Traces, die dem `selectors` entsprechen, ersetzt werden sollen. Sie werden entsprechend dem `replacements`-Abschnitt ersetzt.
+ `replacements`Erforderlich, wenn `action` ein `replace` ist. Eine Reihe von Dimensions- und Wertepaaren, die auf Metriken und Traces angewendet werden, die mit den angegebenen `selectors` übereinstimmen, wenn die `action` gleich `replace` ist. Jeder Ersatz muss folgende Felder angeben:
+ `target_dimension` Erforderlich, wenn `replacements` nicht leer ist. Gibt die Dimension an, die ersetzt werden muss.
+ `value` Erforderlich, wenn `replacements` nicht leer ist. Der Wert, durch den der ursprüngliche Wert von `target_dimension` ersetzt werden soll.
+ `limiter`(Optional) Verwenden Sie diesen Abschnitt, um einzuschränken, an wie viele Metriken und Dimensionen Application Signals sendet CloudWatch, um Ihre Kosten zu optimieren.
+ `disabled` (Optional) Wenn `true`, ist das Feature zur Metrikbegrenzung deaktiviert. Der Standardwert ist `false`
+ `drop_threshold`(Optional) Die maximale Anzahl unterschiedlicher Metriken pro Service in einem Rotationsintervall, die von einem CloudWatch Agenten exportiert werden können. Die Standardeinstellung ist 500.
+ `rotation_interval` (Optional) Das Intervall, in dem der Begrenzer die Metrikdatensätze zur Differenzierung zurücksetzt. Dies wird als Zeichenfolge mit einer Zahlenfolge und einem Einheitensuffix ausgedrückt. Brüche werden unterstützt. Die unterstützten Einheitensuffixe sind`s`,`m`,, `h` `ms``us`, und. `ns` Der Standard ist `1h` für 1 Stunde.
+ `log_dropped_metrics`(Optional) Gibt an, ob der Agent Protokolle in die CloudWatch Agentenprotokolle schreiben soll, wenn Application Signals-Metriken gelöscht werden. Der Standardwert ist `false`.
**Anmerkung**
Um diese Protokollierung zu aktivieren, muss der Parameter `debug` im Abschnitt `agent` ebenfalls auf `true` gesetzt sein.
+ `traces`
+ `traces_collected`
+ `application_signals` Optional. Geben Sie dies an, damit der CloudWatch Agent zur Unterstützung von CloudWatch Anwendungssignalen Traces von Ihren automatisch instrumentierten Anwendungen empfangen kann.
**Anmerkung**
Obwohl die benutzerdefinierten `application_signals`-Regeln in dem `metrics_collected`-Abschnitt angegeben sind, der im `logs`-Abschnitt enthalten ist, gelten sie auch implizit für den `traces_collected`-Abschnitt. Das gleiche Regelwerk gilt sowohl für Metriken als auch für Traces.
Wenn es mehrere Regeln mit unterschiedlichen Aktionen gibt, gelten sie in der folgenden Reihenfolge: `keep`, dann `drop`, dann `replace`.
Im Folgenden finden Sie ein Beispiel für eine vollständige CloudWatch Agentenkonfigurationsdatei, die benutzerdefinierte Regeln anwendet.
```
{
"logs": {
"metrics_collected": {
"application_signals": {
"rules": [
{
"rule_name": "keep01",
"selectors": [
{
"dimension": "Service",
"match": "pet-clinic-frontend"
},
{
"dimension": "RemoteService",
"match": "customers-service"
}
],
"action": "keep"
},
{
"rule_name": "drop01",
"selectors": [
{
"dimension": "Operation",
"match": "GET /api/customer/owners/*"
}
],
"action": "drop"
},
{
"rule_name": "replace01",
"selectors": [
{
"dimension": "Operation",
"match": "PUT /api/customer/owners/*/pets/*"
},
{
"dimension": "RemoteOperation",
"match": "PUT /owners"
}
],
"replacements": [
{
"target_dimension": "Operation",
"value": "PUT /api/customer/owners/{ownerId}/pets{petId}"
}
],
"action": "replace"
}
]
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
```
In der vorherigen Beispiel-Konfigurationsdatei werden die `rules` wie folgt verarbeitet:
1. Die Regel `keep01` stellt sicher, dass alle Metriken und Traces mit der Dimension `Service` als `pet-clinic-frontend` und der Dimension `RemoteService` als `customers-service` beibehalten werden.
1. Für die verarbeiteten Metriken und Traces nach der Anwendung von `keep01` stellt die `drop01`-Regel sicher, dass Metriken und Traces mit der Dimension `Operation` als `GET /api/customer/owners/*` verworfen werden.
1. Für die verarbeiteten Metriken und Traces nach der Anwendung von `drop01` aktualisiert die `replace01`-Regel Metriken und Traces, die die Dimension `Operation` als `PUT /api/customer/owners/*/pets/*` und die Dimension `RemoteOperation` als `PUT /owners` haben, sodass ihre `Operation`-Dimension jetzt durch `PUT /api/customer/owners/{ownerId}/pets{petId}` ersetzt wurde.
Im Folgenden finden Sie ein vollständiges Beispiel für eine CloudWatch Konfigurationsdatei, die die Kardinalität in Application Signals verwaltet, indem sie das Metriklimit auf 100 ändert, die Protokollierung gelöschter Metriken aktiviert und das Rotationsintervall auf zwei Stunden festlegt.
```
{
"logs": {
"metrics_collected": {
"application_signals": {
"limiter": {
"disabled": false,
"drop_threshold": 100,
"rotation_interval": "2h",
"log_dropped_metrics": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
```
# Netzwerkleistungsmetriken sammeln
EC2-Instances, die unter Linux ausgeführt werden, die den Elastic Network Adapter (ENA) verwenden, veröffentlichen Netzwerkleistungsmetriken. Version 1.246396.0 und höher des CloudWatch Agenten ermöglichen es Ihnen, diese Netzwerkleistungskennzahlen in zu importieren. CloudWatch Wenn Sie diese Netzwerkleistungsmetriken in importieren CloudWatch, werden sie als benutzerdefinierte Messwerte berechnet. CloudWatch
Weitere Informationen zum ENA-Treiber finden Sie unter [Erweiterte Netzwerke mit dem Elastic Network Adapter (ENA) auf Linux-Instances aktivieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) und [Erweiterte Netzwerke mit dem Elastic Network Adapter (ENA) auf Windows-Instances aktivieren](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking-ena.html).
Wie Sie die Sammlung von Netzwerkleistungsmetriken einrichten, unterscheidet sich von Linux-Servern und Windows-Servern.
In der folgenden Tabelle sind die vom ENA-Adapter aktivierten Netzwerkleistungsmetriken aufgeführt. Wenn der CloudWatch Agent diese Metriken CloudWatch aus Linux-Instances importiert, wird jeder dieser Metriknamen `ethtool_` am Anfang vorangestellt.
| Metrik | Description |
| --- | --- |
| Name auf Linux-Servern: `bw_in_allowance_exceeded` Name auf Windows-Servern: `Aggregate inbound BW allowance exceeded` | Die Anzahl der Pakete, die in die Warteschlange gestellt wurden and/or , weil die Gesamtbandbreite für eingehende Nachrichten das Maximum für die Instance überschritten hat. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](#CloudWatch-Agent-network-performance). Einheit: keine |
| Name auf Linux-Servern: `bw_out_allowance_exceeded` Name auf Windows-Servern: `Aggregate outbound BW allowance exceeded` | Die Anzahl der Pakete, die in der Warteschlange and/or verworfen wurden, weil die Gesamtbandbreite für ausgehende Nachrichten das Maximum für die Instance überschritten hat. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](#CloudWatch-Agent-network-performance). Einheit: keine |
| Name auf Linux-Servern: `conntrack_allowance_available` Name auf Windows-Servern: `Available connection tracking allowance` | Zeigt die Anzahl der nachverfolgten Verbindungen an, die von der Instance hergestellt werden können, bevor die zulässige Anzahl der nachverfolgten Verbindungen für diesen Instance-Typ erreicht wird. Diese Metrik ist ab Version 2.8.1 nur auf Nitro-basierten EC2-Instances verfügbar, die den Linux-Treiber für Elastic Network Adapter (ENA) verwenden, und auf Computern, die den Windows-Treiber für Elastic Network Adapter (ENA) ab Version 2.6.0 verwenden. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](#CloudWatch-Agent-network-performance). Einheit: keine |
| Name auf Linux-Servern: `ena_srd_mode` Name auf Windows-Servern: `ena srd mode` | Beschreibt, welche ENA-Express-Features aktiviert sind. Weitere Informationen zu ENA Express finden Sie unter [Verbessern der Netzwerkleistung mit ENA Express auf Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ena-express.html). Die Werte lauten wie folgt: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-network-performance.html) |
| Name auf Linux-Servern: `ena_srd_eligible_tx_pkts` Name auf Windows-Servern: `ena srd eligible tx pkts` | Die Anzahl der innerhalb eines bestimmten Zeitraums gesendeten Netzwerkpakete, die die AWS Scalable Reliable Datagram (SRD)-Anforderungen für die Zulassung erfüllen, wie folgt: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-network-performance.html) |
| Name auf Linux-Servern: `ena_srd_tx_pkts` Name auf Windows-Servern: `ena srd tx pkts` | Die Anzahl der SRD-Pakete, die innerhalb eines bestimmten Zeitraums übertragen wurden. |
| Name auf Linux-Servern: `ena_srd_rx_pkts` Name auf Windows-Servern: `ena srd rx pkts` | Die Anzahl der SRD-Pakete, die innerhalb eines bestimmten Zeitraums empfangen wurden. |
| Name auf Linux-Servern: `ena_srd_resource_utilization` Name auf Windows-Servern: `ena srd resource utilization` | Der Prozentsatz der maximal zulässigen Arbeitsspeichernutzung für gleichzeitige SRD-Verbindungen, den die Instance verbraucht hat. |
| Name auf Linux-Servern: `linklocal_allowance_exceeded` Name auf Windows-Servern: `Link local packet rate allowance exceeded` | Die Anzahl der verworfenen Pakete, weil das PPS des Datenverkehrs zu lokalen Proxy-Diensten das Maximum für die Netzwerkschnittstelle überschritten hat. Dies wirkt sich auf den Datenverkehr zum DNS-Service, zum Instance Metadata Service und zum Amazon Time Sync Service aus, hat jedoch keine Auswirkung auf den Datenverkehr an benutzerdefinierte DNS-Resolver. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](#CloudWatch-Agent-network-performance). Einheit: keine |
| Name auf Linux-Servern: `pps_allowance_exceeded` Name auf Windows-Servern: `PPS allowance exceeded` | Die Anzahl der Pakete, die in die Warteschlange gestellt wurden and/or , weil das bidirektionale PPS das Maximum für die Instanz überschritten hat. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](#CloudWatch-Agent-network-performance). Einheit: keine |
## Linux-Einrichtung
Auf Linux-Servern können Sie mit dem *Ethtool-Plug-in* die Netzwerkleistungsmetriken importieren. CloudWatch
ethtool ist ein Standard-Linux-Dienstprogramm, das Statistiken über Ethernet-Geräte auf Linux-Servern sammeln kann. Die erfassten Statistiken hängen vom Netzwerkgerät und vom Treiber ab. Beispiele für diese Statistiken sind`tx_cnt`, `rx_bytes`, `tx_errors` und `align_errors`. Wenn Sie das Ethtool-Plugin mit dem CloudWatch Agenten verwenden, können Sie diese Statistiken zusammen mit den weiter oben in CloudWatch diesem Abschnitt aufgeführten EC2-Netzwerkleistungskennzahlen auch in dieses importieren.
**Tipp**
Verwenden Sie den Befehl `ethtool –S`, um die auf unserem Betriebssystem und Netzwerkgerät verfügbaren Statistiken zu finden.
Wenn der CloudWatch Agent Metriken importiert CloudWatch, fügt er den Namen aller importierten Metriken ein `ethtool_` Präfix hinzu. Also `rx_bytes` wird die standardmäßige Ethtool-Statistik aufgerufen `ethtool_rx_bytes` und die EC2-Netzwerkleistungsmetrik `bw_in_allowance_exceeded` wird aufgerufen. CloudWatch `ethtool_bw_in_allowance_exceeded` CloudWatch
Um Ethtool-Metriken auf Linux-Servern zu importieren, fügen Sie dem `ethtool` Abschnitt der Agenten-Konfigurationsdatei einen `metrics_collected` Abschnitt hinzu. CloudWatch Der Abschnitt `ethtool` kann die folgenden Unterabschnitte enthalten:
+ **interface\$1include** – Einschließen dieses Abschnitts bewirkt, dass der Agent Metriken nur von den Schnittstellen sammelt, deren Namen in diesem Abschnitt aufgeführt sind. Wenn Sie diesen Abschnitt auslassen, werden Metriken von allen Ethernet-Schnittstellen gesammelt, die nicht in `interface_exclude` aufgeführt sind.
Die Standard-Ethernet-Schnittstelle ist `eth0`a.
+ **interface\$1exclude** – Wenn Sie diesen Abschnitt einschließen, listen Sie die Ethernet-Schnittstellen auf, von denen Sie keine Metriken sammeln möchten.
Das ethtool-Plug-In ignoriert immer Loopback-Schnittstellen.
+ **metrics\$1include** — Dieser Abschnitt listet die Metriken auf, in die importiert werden soll. CloudWatch Es kann sowohl von ethtool gesammelte Standardstatistiken als auch hochauflösende Amazon-EC2-Netzwerkmetriken enthalten.
Im folgenden Beispiel wird ein Teil der Agenten-Konfigurationsdatei angezeigt. CloudWatch Diese Konfiguration erfasst die standardmäßigen Ethtool-Metriken `rx_packets` und `tx_packets` sowie die Amazon-EC2-Netzwerkleistungsmetriken nur von der `eth1`-Schnittstelle.
Weitere Informationen zur CloudWatch Agenten-Konfigurationsdatei finden Sie unter[Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md).
```
{
"metrics": {
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"ethtool": {
"interface_include": [
"eth1"
],
"metrics_include": [
"bw_in_allowance_exceeded",
"bw_out_allowance_exceeded",
"conntrack_allowance_exceeded",
"linklocal_allowance_exceeded",
"pps_allowance_exceeded"
]
}
}
}
}
```
## Windows-Einrichtung
Auf Windows-Servern sind die Netzwerkleistungsmesswerte über die Windows-Leistungsindikatoren verfügbar, von denen der CloudWatch Agent bereits Messwerte erfasst. Sie benötigen also kein Plugin, um diese Metriken von Windows-Servern zu sammeln.
Nachfolgend finden Sie eine Beispielkonfigurationsdatei zur Erfassung von Netzwerkleistungsmetriken von Windows. Weitere Informationen zum Bearbeiten der CloudWatch Agent-Konfigurationsdatei finden Sie unter[Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md).
```
{
"metrics": {
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"ENA Packets Shaping": {
"measurement": [
"Aggregate inbound BW allowance exceeded",
"Aggregate outbound BW allowance exceeded",
"Connection tracking allowance exceeded",
"Link local packet rate allowance exceeded",
"PPS allowance exceeded"
],
"metrics_collection_interval": 60,
"resources": [
"*"
]
}
}
}
}
```
## Netzwerkleistungsmetriken anzeigen
Nachdem Sie die Netzwerkleistungsmetriken in importiert haben CloudWatch, können Sie sich diese Metriken als Zeitreihendiagramme ansehen und Alarme erstellen, die diese Metriken überwachen und Sie benachrichtigen, wenn sie einen von Ihnen festgelegten Schwellenwert überschreiten. Das folgende Verfahren zeigt, wie Sie ethtool-Metriken als Zeitreihendiagramm anzeigen. Weitere Informationen zum Einrichten eines -Alarms finden Sie unter [CloudWatch Amazon-Alarme verwenden](CloudWatch_Alarms.md).
Da es sich bei all diesen Metriken um aggregierte Zähler handelt, können Sie mathematische Funktionen verwenden CloudWatch , `RATE(METRICS())` um z. B. die Rate dieser Metriken in Diagrammen zu berechnen oder sie zum Einstellen von Alarmen zu verwenden. Weitere Informationen zu Metrikberechnungsfunktionen finden Sie unter [Verwenden von mathematischen Ausdrücken mit CloudWatch Metriken](using-metric-math.md)
**Um Netzwerkleistungsmetriken in der CloudWatch Konsole anzuzeigen**
1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie den Namespace für die vom Agent zu erfassenden Metriken. Standardmäßig ist dies der Fall **CWAgent**, aber Sie haben möglicherweise einen anderen Namespace in der CloudWatch Agentenkonfigurationsdatei angegeben.
1. Wählen Sie eine Metrikdimension aus (z. B. **Per-Instance Metrics (Metriken pro Instance)**).
1. Die Registerkarte **All metrics** zeigt alle Metriken für diese Dimension im Namespace an. Sie haben die folgenden Möglichkeiten:
1. Um eine Metrik grafisch darzustellen, müssen Sie das Kontrollkästchen neben der Metrik aktivieren. Um alle Metriken auszuwählen, aktivieren Sie das Kontrollkästchen in der Kopfzeile der Tabelle.
1. Um die Tabelle sortieren, verwenden Sie die Spaltenüberschrift.
1. Um nach Ressource zu filtern, müssen Sie zunächst die Ressourcen-ID und dann die Option **Add to search (Zu Suche hinzufügen)** wählen.
1. Um nach Metrik zu filtern, müssen Sie den Metriknamen und anschließend **Add to search (Zu Suche hinzufügen)** wählen.
1. (Optional) Um dieses Diagramm zu einem CloudWatch Dashboard hinzuzufügen, wählen Sie **Aktionen** und dann Zum **Dashboard hinzufügen** aus.
# Erfassen Sie Amazon NVMe EBS-Treibermetriken
Damit der CloudWatch Agent AWS NVMe-Treibermetriken für Amazon EBS-Volumes sammeln kann, die an eine Amazon EC2 EC2-Instance angehängt sind, fügen Sie den `diskio` Abschnitt innerhalb des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei hinzu.
Darüber hinaus erfordert die CloudWatch Agent-Binärdatei `ioctl` Berechtigungen für NVMe Treibergeräte, um Metriken von angehängten Amazon EBS-Volumes zu sammeln.
Die folgenden Metriken können erfasst werden.
| Metrik | Name der Metrik in CloudWatch | Description |
| --- | --- | --- |
| `ebs_total_read_ops` | `diskio_ebs_total_read_ops` | Die Gesamtzahl der abgeschlossenen Lesevorgänge. |
| `ebs_total_write_ops` | `diskio_ebs_total_write_ops` | Die Gesamtzahl der abgeschlossenen Schreibvorgänge. |
| `ebs_total_read_bytes` | `diskio_ebs_total_read_bytes` | Die Gesamtzahl der übertragenen und gelesenen Bytes. |
| `ebs_total_write_bytes` | `diskio_ebs_total_write_bytes` | Die Gesamtzahl der übertragenen und geschriebenen Bytes. |
| `ebs_total_read_time` | `diskio_ebs_total_read_time` | Die Gesamtzeit für alle abgeschlossenen Lesevorgänge in Mikrosekunden. |
| `ebs_total_write_time` | `diskio_ebs_total_write_time` | Die Gesamtzeit für alle abgeschlossenen Schreibvorgänge in Mikrosekunden. |
| `ebs_volume_performance_exceeded_iops` | `diskio_ebs_volume_performance_exceeded_iops` | Die Gesamtzeit in Mikrosekunden, in welcher der IOPS-Bedarf die vom Volume bereitgestellte IOPS-Leistung überstiegen hat. |
| `ebs_volume_performance_exceeded_tp` | `diskio_ebs_volume_performance_exceeded_tp` | Die Gesamtzeit in Mikrosekunden, in welcher der Durchsatzbedarf die vom Volume bereitgestellte Durchsatzleistung überstiegen hat. |
| `ebs_ec2_instance_performance_exceeded_iops` | `diskio_ebs_ec2_instance_performance_exceeded_iops` | Die Gesamtzeit in Mikrosekunden, in der das EBS-Volume die maximale IOPS-Leistung der angeschlossenen Amazon-EC2-Instance überschritten hat. |
| `ebs_ec2_instance_performance_exceeded_tp` | `diskio_ebs_ec2_instance_performance_exceeded_tp` | Die Gesamtzeit in Mikrosekunden, in der das EBS-Volume die maximale Durchsatzleistung der angeschlossenen Amazon-EC2-Instance überschritten hat. |
| `ebs_volume_queue_length` | `diskio_ebs_volume_queue_length` | Die Anzahl der Lese- und Schreibvorgänge, die auf Abschluss warten. |
# Erfassung von NVMe Volumen-Treibermetriken für Amazon EC2 EC2-Instance-Speicher
Damit der CloudWatch Agent AWS NVMe-Treibermetriken für Instance-Speicher-Volumes sammeln kann, die an eine Amazon EC2 EC2-Instance angehängt sind, fügen Sie den `diskio` Abschnitt innerhalb des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei hinzu.
Darüber hinaus erfordert die CloudWatch Agent-Binärdatei `ioctl` Berechtigungen für NVMe Treibergeräte, um Metriken von angehängten Instance-Speicher-Volumes zu sammeln.
Die folgenden Metriken können erfasst werden.
| Metrik | Name der Metrik in CloudWatch | Description |
| --- | --- | --- |
| `instance_store_total_read_ops` | `diskio_instance_store_total_read_ops` | Die Gesamtzahl der abgeschlossenen Lesevorgänge. |
| `instance_store_total_write_ops` | `diskio_instance_store_total_write_ops` | Die Gesamtzahl der abgeschlossenen Schreibvorgänge. |
| `instance_store_total_read_bytes` | `diskio_instance_store_total_read_bytes` | Die Gesamtzahl der übertragenen und gelesenen Bytes. |
| `instance_store_total_write_bytes` | `diskio_instance_store_total_write_bytes` | Die Gesamtzahl der übertragenen und geschriebenen Bytes. |
| `instance_store_total_read_time` | `diskio_instance_store_total_read_time` | Die Gesamtzeit für alle abgeschlossenen Lesevorgänge in Mikrosekunden. |
| `instance_store_total_write_time` | `diskio_instance_store_total_write_time` | Die Gesamtzeit für alle abgeschlossenen Schreibvorgänge in Mikrosekunden. |
| `instance_store_performance_exceeded_iops` | `diskio_instance_store_performance_exceeded_iops` | Die Gesamtzeit in Mikrosekunden, in welcher der IOPS-Bedarf die maximale IOPS-Leistung des Volumes überstiegen hat. |
| `instance_store_performance_exceeded_tp` | `diskio_instance_store_performance_exceeded_tp` | Die Gesamtzeit in Mikrosekunden, in welcher der Durchsatzbedarf die maximale Durchsatzleistung des Volumes überstiegen hat. |
| `instance_store_volume_queue_length` | `diskio_instance_store_volume_queue_length` | Die Anzahl der Lese- und Schreibvorgänge, die auf Abschluss warten. |
# Erfassen von NVIDIA GPU-Metriken
Sie können den CloudWatch Agenten verwenden, um NVIDIA-GPU-Metriken von Linux-Servern zu sammeln. Um dies einzurichten, fügen Sie dem `nvidia_gpu` `metrics_collected` Abschnitt der CloudWatch Agenten-Konfigurationsdatei einen Abschnitt hinzu. Weitere Informationen finden Sie unter [Linux-Abschnitt](CloudWatch-Agent-Configuration-File-Details.md#CloudWatch-Agent-Linux-section).
Darüber hinaus muss auf der Instance ein NVIDIA-Treiber installiert sein. NVIDIA-Treiber sind auf einigen Amazon Machine Images vorinstalliert (AMIs). Andernfalls können Sie den Treiber manuell installieren. Weitere Informationen finden Sie unter [Installieren von NVIDIA-Treibern auf Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-nvidia-driver.html).
Die folgenden Metriken können erfasst werden. Alle diese Metriken werden ohne Angabe erfasst CloudWatch `Unit`, aber Sie können für jede Metrik eine Einheit angeben, indem Sie der CloudWatch Agentenkonfigurationsdatei einen Parameter hinzufügen. Weitere Informationen finden Sie unter [Linux-Abschnitt](CloudWatch-Agent-Configuration-File-Details.md#CloudWatch-Agent-Linux-section).
| Metrik | Name der Metrik in CloudWatch | Description |
| --- | --- | --- |
| `utilization_gpu` | `nvidia_smi_utilization_gpu` | Der Prozentsatz der Zeit im vergangenen Erfassungszeitraum, während dessen ein oder mehrere Kernel der GPU aktiv waren. |
| `temperature_gpu` | `nvidia_smi_temperature_gpu` | Die GPU-Kerntemperatur in Grad Celsius. |
| `power_draw` | `nvidia_smi_power_draw` | Die letzte gemessene Leistungsaufnahme des gesamten Boards in Watt. |
| `utilization_memory` | `nvidia_smi_utilization_memory` | Der Prozentsatz der Zeit im vergangenen Erfassungszeitraum, während dessen der globale Speicher (Gerätespeicher) gelesen oder geschrieben wurde. |
| `fan_speed` | `nvidia_smi_fan_speed` | Der Prozentsatz der maximalen Lüfterdrehzahl, mit der der Lüfter des Geräts derzeit laufen soll. |
| `memory_total` | `nvidia_smi_memory_total` | Der gemeldete Gesamtspeicher in MB. |
| `memory_used` | `nvidia_smi_memory_used` | Der verwendete Speicher in MB. |
| `memory_free` | `nvidia_smi_memory_free` | Der freie Speicher in MB. |
| `pcie_link_gen_current` | `nvidia_smi_pcie_link_gen_current` | Die aktuelle Link-Generation. |
| `pcie_link_width_current` | `nvidia_smi_pcie_link_width_current` | Die aktuelle Link-Breite. |
| `encoder_stats_session_count` | `nvidia_smi_encoder_stats_session_count` | Aktuelle Anzahl von Encoder-Sitzungen. |
| `encoder_stats_average_fps` | `nvidia_smi_encoder_stats_average_fps` | Der gleitende Durchschnitt der Codierungs-Frames pro Sekunde. |
| `encoder_stats_average_latency` | `nvidia_smi_encoder_stats_average_latency` | Der gleitende Durchschnitt der Codier-Latenz in Mikrosekunden. |
| `clocks_current_graphics` | `nvidia_smi_clocks_current_graphics` | Die aktuelle Frequenz der Grafikuhr (Shader). |
| `clocks_current_sm` | `nvidia_smi_clocks_current_sm` | Die aktuelle Frequenz der SM-Uhr (Streaming Multiprozessor). |
| `clocks_current_memory` | `nvidia_smi_clocks_current_memory` | Die aktuelle Frequenz der Speicheruhr. |
| `clocks_current_video` | `nvidia_smi_clocks_current_video` | Die aktuelle Frequenz der Videouhr (Encoder plus Decoder). |
Alle diese Metriken werden mit den folgenden Dimensionen erfasst:
| Dimension | Description |
| --- | --- |
| `index` | Ein eindeutiger Bezeichner für die GPU dieses Servers. Stellt den NVML-Index (NVIDIA Management Library) des Geräts dar. |
| `name` | Die Art der GPU. Beispiel: `NVIDIA Tesla A100` |
| `arch` | Die Serverarchitektur. |
# Erfassung von Java Management Extensions (JMX)-Metriken
Sie können den CloudWatch Agenten verwenden, um Java Management Extensions (JMX) -Metriken aus Ihren Java-Anwendungen zu sammeln.
Der CloudWatch Agent unterstützt das Sammeln dieser Metriken aus den folgenden Versionen:
+ JVM 8 und höher
+ Kafka 0.8.2.x und höher
+ Tomcat 9, 10.1 und 11 (Beta)
------
#### [ Amazon EC2 ]
**So aktivieren Sie JMX in Ihrer JVM-Instance**
Damit der CloudWatch Agent JMX-Metriken sammeln kann, muss sich die JVM Ihrer Anwendung mithilfe der `com.sun.management.jmxremote.port` Systemeigenschaft an einen Port binden.
```
java -Dcom.sun.management.jmxremote.port=port-number -jar example.jar
```
Weitere Informationen und andere Konfigurationen finden Sie in der [JMX-Dokumentation](https://docs.oracle.com/en/java/javase/17/management/monitoring-and-management-using-jmx-technology.html).
------
#### [ Amazon EKS ]
**So aktivieren Sie JMX auf Ihren Java-Anwendungs-Pods**
Wenn Sie das CloudWatch Observability EKS-Add-on verwenden, können Sie mithilfe von Anmerkungen verwalten, wie JMX-Metriken aktiviert werden. Weitere Informationen finden Sie unter [Installieren Sie den CloudWatch Agenten mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm](install-CloudWatch-Observability-EKS-addon.md). Um die Erfassung von JMX-Metriken aus einem Workload zu aktivieren, fügen Sie der Workload-Manifestdatei im Abschnitt `PodTemplate` die folgenden Anmerkungen hinzu:
+ `instrumentation.opentelemetry.io/inject-java: "true"`
+ Eine oder mehrere der Folgenden:
+ Für JVM-Metriken: `cloudwatch.aws.amazon.com/inject-jmx-jvm: "true"`
+ Für Kafka-Broker-Metriken: `cloudwatch.aws.amazon.com/inject-jmx-kafka: "true"`
+ Für Kafka-Consumer-Metriken: `cloudwatch.aws.amazon.com/inject-jmx-kafka-consumer: "true"`
+ Für Kafka-Producer-Metriken: `cloudwatch.aws.amazon.com/inject-jmx-kafka-producer: "true"`
+ Für Tomcat-Metriken: `cloudwatch.aws.amazon.com/inject-jmx-tomcat: "true"`
------
Um mit der Erfassung von JMX-Metriken zu beginnen, fügen Sie dem `jmx` Abschnitt der `metrics_collected` Agenten-Konfigurationsdatei einen Abschnitt hinzu. CloudWatch Der Abschnitt `jmx` kann die folgenden Felder enthalten.
+ `jvm` – Optional. Gibt an, dass Sie Java Management Extensions (JMX)-Metriken von der Instance abrufen möchten. Weitere Informationen finden Sie unter [Erfassen von JVM-Metriken](#CloudWatch-Agent-JVM-metrics).
Dieser Abschnitt kann die folgenden Felder enthalten:
+ `measurement`: Gibt das Array der zu erfassenden JVM-Metriken an. Eine Liste der möglichen Werte, die Sie hier verwenden können, finden Sie in der Spalte **Metric** (Metrik) in der Tabelle unter [Erfassen von JVM-Metriken](#CloudWatch-Agent-JVM-metrics).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik. Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt. [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)
+ `kafka` – Optional. Gibt an, dass Sie Apache Kafka-Broker-Metriken von der Instance abrufen möchten. Weitere Informationen finden Sie unter [Erfassen von Kafka-Metriken](#CloudWatch-Agent-Kafka-metrics).
Dieser Abschnitt kann die folgenden Felder enthalten:
+ `measurement`: Gibt das Array der zu erfassenden Kafka Broker-Metriken an. Eine Liste der möglichen Werte, die Sie hier verwenden können, finden Sie in der Spalte **Metrik** in der ersten Tabelle unter [Erfassen von Kafka-Metriken](#CloudWatch-Agent-Kafka-metrics).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik. Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `kafka-consumer` – Optional. Gibt an, dass Sie Apache Kafka-Consumer-Metriken von der Instance abrufen möchten. Weitere Informationen finden Sie unter [Erfassen von Kafka-Metriken](#CloudWatch-Agent-Kafka-metrics).
Dieser Abschnitt kann die folgenden Felder enthalten:
+ `measurement`: Gibt das Array der zu erfassenden Kafka Broker-Metriken an. Eine Liste der möglichen Werte, die Sie hier verwenden können, finden Sie in der Spalte **Metrik** in der zweiten Metriktabelle unter [Erfassen von Kafka-Metriken](#CloudWatch-Agent-Kafka-metrics).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik. Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `kafka-producer` – Optional. Gibt an, dass Sie Apache Kafka-Producer-Metriken von der Instance abrufen möchten. Weitere Informationen finden Sie unter [Erfassen von Kafka-Metriken](#CloudWatch-Agent-Kafka-metrics).
Dieser Abschnitt kann die folgenden Felder enthalten:
+ `measurement`: Gibt das Array der zu erfassenden Kafka Broker-Metriken an. Eine Liste der möglichen Werte, die Sie hier verwenden können, finden Sie in der Spalte **Metrik** in der dritten Metriktabelle unter [Erfassen von Kafka-Metriken](#CloudWatch-Agent-Kafka-metrics).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik. Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
+ `tomcat` – Optional. Gibt an, dass Sie Tomcat-Metriken von der Instance abrufen möchten. Weitere Informationen finden Sie unter [Erfassen von Tomcat-Metriken](#CloudWatch-Agent-Tomcat-metrics).
Dieser Abschnitt kann die folgenden Felder enthalten:
+ `measurement`: Gibt das Array der zu erfassenden Tomcat-Metriken an. Eine Liste der möglichen Werte, die Sie hier verwenden können, finden Sie in der Spalte **Metric** (Metrik) in der Tabelle unter [Erfassen von Tomcat-Metriken](#CloudWatch-Agent-Tomcat-metrics).
Im Eintrag für jede einzelne Metrik können Sie optional einen oder beide der folgenden Werte angeben:
+ `rename` – Legt einen anderen Namen für diese Metrik fest.
+ `unit` – Gibt die zu verwendende Einheit für diese Metrik an und überschreibt die Standardeinheit für die Metrik. Bei der von Ihnen angegebenen Einheit muss es sich um eine gültige CloudWatch metrische Einheit handeln, wie in der `Unit` Beschreibung unter aufgeführt [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html).
Der Abschnitt `jmx` kann auch das optionale Feld `append_dimensions` enthalten:
+ `append_dimensions` – Optional. Zusätzliche Dimensionen, die nur für die Prozess-Metriken verwendet werden sollen. Falls Sie dieses Feld angeben, wird es zusätzlich zu den im Feld `append_dimensions` angegebenen Dimensionen verwendet, das für alle Typen von Metriken verwendet wird, die vom Agent erfasst werden.
**Die folgenden Felder gelten nur für Amazon EC2.**
+ `endpoint`: Die Adresse, zu der der JMX-Client eine Verbindung herstellen soll. Das Format ist `ip:port`. Wenn der Endpunkt nicht der localhost ist und die Passwortauthentifizierung und SSL aktiviert sein müssen.
+ `metrics_collection_interval` – Optional. Gibt an, wie oft die Prozess-Metriken erfasst werden und das globale `metrics_collection_interval` im Abschnitt `agent` der Konfigurationsdatei überschrieben wird.
Der Wert wird in Sekunden angegeben. Beispiel: Angeben, dass 10 Metriken alle 10 Sekunden und 300 Metriken alle 5 Minuten gesammelt werden sollen.
Wenn Sie diesen Wert auf weniger als 60 Sekunden festlegen, wird die jeweilige Metrik als hochauflösende Metrik erfasst. Weitere Informationen finden Sie unter [Hochauflösende Metriken](publishingMetrics.md#high-resolution-metrics).
Wenn JMX mit Passwortauthentifizierung oder SSL für den Fernzugriff aktiviert wurde, können Sie die folgenden Felder verwenden.
+ `password_file` – Optional. Gibt eine Java-Eigenschaftendatei mit Schlüsseln für Passwörter an. Die Datei muss schreibgeschützt und auf den Benutzer beschränkt sein, der den Agenten ausführt. CloudWatch Wenn die Passwortauthentifizierung aktiviert ist, ist dafür dasselbe Benutzername/Passwort-Paar erforderlich wie für den Eintrag in der JMX-Passwortdatei, die in der Eigenschaft `com.sun.management.jmxremote.password.file` bereitgestellt wird. Wenn SSL aktiviert ist, sind Einträge für `keystore` erforderlich und `truststore` entspricht jeweils dem `javax.net.ssl.keyStorePassword` und `javax.net.ssl.trustStorePassword`.
+ `username`: Wenn die Passwortauthentifizierung aktiviert ist, geben Sie den Benutzernamen an, der dem Benutzernamen in der bereitgestellten Passwortdatei entspricht.
+ `keystore_path`: Wenn SSL aktiviert ist, geben Sie den vollständigen Pfad zum Java-Keystore an, der aus einem privaten Schlüssel und einem Zertifikat für den öffentlichen Schlüssel besteht. Entspricht der Eigenschaft `javax.net.ssl.keyStore`.
+ `keystore_type`: Wenn SSL aktiviert ist, geben Sie den Typ des verwendeten Keystores an. Entspricht der Eigenschaft `javax.net.ssl.keyStoreType`.
+ `truststore_path`: Wenn SSL aktiviert ist, geben Sie den vollständigen Pfad zum Java-Truststore an, der das öffentliche Zertifikat des Remote-JMX-Servers enthalten muss. Entspricht der Eigenschaft `javax.net.ssl.trustStore`.
+ `truststore_type`: Wenn SSL aktiviert ist, geben Sie den Typ des verwendeten Truststores an. Entspricht der Eigenschaft `javax.net.ssl.trustStoreType`.
+ `remote_profile` – Optional. Unterstützte JMX-Remoteprofile sind TLS in Kombination mit den SASL-Profilen: `SASL/PLAIN`, `SASL/DIGEST-MD5` und `SASL/CRAM-MD5`. Sollte einer der folgenden sein: `SASL/PLAIN`, `SASL/DIGEST-MD5`, `SASL/CRAM-MD5`, `TLS SASL/PLAIN`, `TLS SASL/DIGEST-MD5` oder `TLS SASL/CRAM-MD5`
+ `realm` – Optional. Der vom Remote-Profil `SASL/DIGEST-MD5` geforderte Realm.
+ `registry_ssl_enabled`: Wenn die RMI-Registrierungsauthentifizierung aktiviert ist. Auf „true“ gesetzt, wenn die JVM mit `com.sun.management.jmxremote.registry.ssl=true` konfiguriert wurde.
+ `insecure` Auf `true` gesetzt, um die Überprüfung zu deaktivieren, die erforderlich ist, wenn der Agent für einen anderen Endpunkt als localhost konfiguriert ist.
Im Folgenden finden Sie ein Beispiel für den `jmx` Abschnitt der CloudWatch Agenten-Konfigurationsdatei.
```
{
"metrics": {
"metrics_collected": {
"jmx": [
{
"endpoint": "remotehost:1314",
"jvm": {
"measurement": [
"jvm.memory.heap.init",
"jvm.memory.nonheap.used"
]
},
"kafka": {
"measurement": [
"kafka.request.count",
{
"name": "kafka.message.count",
"rename": "KAFKA_MESSAGE_COUNT",
"unit": "Count"
}
]
},
"username": "cwagent",
"keystore_path": "/path/to/keystore",
"keystore_type": "PKCS12",
"truststore_path": "/path/to/truststore",
"truststore_type": "PKCS12"
},
{
"endpoint": "localhost:1315",
"kafka-producer": {
"measurement": [
"kafka.producer.request-rate"
]
},
"append_dimensions": {
"service.name": "kafka/1"
}
}
]
}
}
}
```
## Erfassen von JVM-Metriken
Sie können den CloudWatch Agenten verwenden, um Metriken für Java Virtual Machine (JVM) zu sammeln. Um dies einzurichten, fügen Sie dem `jvm` Abschnitt der CloudWatch Agenten-Konfigurationsdatei einen `jmx` Abschnitt hinzu.
Die folgenden Metriken können erfasst werden.
| Metrik | Dimensionen | Description |
| --- | --- | --- |
| `jvm.classes.loaded` | [STANDARD] | Die Gesamtzahl der geladenen Klassen. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.gc.collections.count` | [STANDARD], `name` | Die Gesamtzahl der durchgeführten Garbage Collections. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.gc.collections.elapsed` | [STANDARD], `name` | Die ungefähre Gesamtdauer der bisherigen Garbage Collection. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.heap.init` | [STANDARD] | Die anfängliche Speichermenge, die die JVM vom Betriebssystem für den Heap anfordert. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.heap.max` | [STANDARD] | Die maximale Speichermenge, die für den Heap verwendet werden kann. **Einheit:** Byte **Aussagekräftige Statistiken:** Maximum |
| `jvm.memory.heap.used` | [STANDARD] | Die aktuelle Auslastung des Heap-Speichers. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.heap.committed` | [STANDARD] | Die Menge an Speicher, die garantiert für den Heap verfügbar ist. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.nonheap.init` | [STANDARD] | Die anfängliche Speichermenge, die die JVM vom Betriebssystem für Nicht-Heap-Zwecke anfordert. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.nonheap.max` | [STANDARD] | Die maximale Speichermenge, die für Non-Heap-Zwecke verwendet werden kann. **Einheit:** Byte **Aussagekräftige Statistiken:** Maximum |
| `jvm.memory.nonheap.used` | [STANDARD] | Die aktuelle Nicht-Heap-Speichernutzung. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.nonheap.committed` | [STANDARD] | Die Menge an Speicher, die garantiert für Nicht-Heap-Zwecke verfügbar ist. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.pool.init` | [STANDARD], `name` | Die anfängliche Speichermenge, die die JVM vom Betriebssystem für den Speicherpool anfordert. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.pool.max` | [STANDARD], `name` | Die maximale Speichermenge, die für den Speicherpool verwendet werden kann. **Einheit:** Byte **Aussagekräftige Statistiken:** Maximum |
| `jvm.memory.pool.used` | [STANDARD], `name` | Die aktuelle Speichernutzung des Speicherpools. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.memory.pool.committed` | [STANDARD], `name` | Die Menge an Speicher, die garantiert für den Speicherpool verfügbar ist. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `jvm.threads.count` | [STANDARD] | Die aktuelle Anzahl von Threads. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
Die JVM-Metriken werden mit den folgenden Dimensionen erfasst:
| Dimension | Description |
| --- | --- |
| [STANDARD] | In Amazon EC2 wird der Host standardmäßig auch als Dimension von Metriken veröffentlicht, die vom CloudWatch Agenten erfasst werden, es sei denn, Sie verwenden das `append_dimensions` Feld im `metrics` Abschnitt. Sehen Sie sich `omit_hostname` im Agenten-Abschnitt von [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md) für weitere Informationen an. In Amazon EKS wird der k8s-bezogene Kontext standardmäßig auch als Dimensionen von Metriken (`k8s.container.name`, `k8s.deployment.name`, `k8s.namespace.name`, `k8s.node.name`, `k8s.pod.name` und `k8s.replicaset.name`) veröffentlicht. Diese können mithilfe des Felds `aggregation_dimensions` gefiltert werden. |
| `name` | Bei `jvm.gc.collections`-Metriken ist der Wert der Name des Garbage-Collectors. Bei `jvm.memory.pool`-Metriken ist der Wert der Name des Speicherpools. |
## Erfassen von Kafka-Metriken
Sie können den CloudWatch Agenten verwenden, um Apache Kafka-Metriken zu sammeln. Um dies einzurichten, fügen Sie dem `jmx` Abschnitt der CloudWatch Agenten-Konfigurationsdatei einen oder mehrere der folgenden Unterabschnitte hinzu.
+ Verwenden Sie einen `kafka`-Abschnitt, um Kafka-Broker-Metriken zu erfassen.
+ Verwenden Sie einen `kafka-consumer`-Abschnitt, um Kafka-Consumer-Metriken zu erfassen.
+ Verwenden Sie einen `kafka-producer`-Abschnitt, um Kafka-Producer-Metriken zu erfassen.
**Kafka-Broker-Metriken**
Die folgenden Metriken können für Kafka-Broker erfasst werden.
| Metrik | Dimensionen | Description |
| --- | --- | --- |
| `kafka.message.count` | [STANDARD] | Die Anzahl der vom Kafka-Broker empfangenen Meldungen. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.request.count` | [STANDARD], `type` | Die Anzahl der vom Kafka-Broker empfangenen Anforderungen. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.request.failed` | [STANDARD], `type` | Die Anzahl der Anforderungen an den Kafka-Broker, die zu einem Fehler geführt haben. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.request.time.total` | [STANDARD], `type` | Die Gesamtzeit, die der Kafka-Broker für die Bearbeitung von Anforderungen benötigt hat. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.request.time.50p` | [STANDARD], `type` | Die 50. Perzentilzeit, die der Kafka-Broker für die Bearbeitung von Anforderungen benötigt hat. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.request.time.99p` | [STANDARD], `type` | Die 99. Perzentilzeit, die der Kafka-Broker für die Bearbeitung von Anforderungen benötigt hat. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.request.time.avg` | [STANDARD], `type` | Die durchschnittliche Zeit, die der Kafka-Broker für die Bearbeitung von Anforderungen benötigt hat. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.network.io` | [STANDARD], `state` | Die Anzahl der Bytes, die von dem Kafka-Broker empfangen oder gesendet wurden. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.purgatory.size` | [STANDARD], `type` | Die Anzahl der Anforderungen in der Purgatory-Warteschlange. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.partition.count` | [STANDARD] | Die Anzahl der Partitionen für den Kafka-Broker. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.partition.offline` | [STANDARD] | Die Gesamtzahl der Partitionen, die offline sind. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.partition.under_replicated` | [STANDARD] | Die Anzahl der unter-replizierten Partitionen. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.isr.operation.count` | [STANDARD], `operation` | Die Anzahl der synchronisierten Replikat-Verkleinerungs- und Vergrößerungsvorgänge. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.max.lag` | [STANDARD] | Die maximale Verzögerung bei Nachrichten zwischen Follower- und Leader-Replikaten. **Einheit:** keine **Aussagekräftige Statistiken:** Maximum |
| `kafka.controller.active.count` | [STANDARD] | Die Anzahl der aktiven Verbindungen auf dem Broker. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.leader.election.rate` | [STANDARD] | Leader-Wahlquote. Wenn dieser Wert zunimmt, deutet dies auf Broker-Ausfälle hin. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.unclean.election.rate` | [STANDARD] | Unclean-Leader-Wahlquote. Wenn dieser Wert zunimmt, deutet dies auf Broker-Ausfälle hin. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.request.queue` | [STANDARD] | Die Größe der Anforderungswarteschlange. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.logs.flush.time.count` | [STANDARD] | Die Anzahl der gelöschten Protokolle. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.logs.flush.time.median` | [STANDARD] | Der 50. Perzentilwert der Protokoll-Löschungsanzahl. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.logs.flush.time.99p` | [STANDARD] | Der 99. Perzentilwert der Protokoll-Löschungsanzahl. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
Die Kafka–Broker-Metriken werden mit den folgenden Dimensionen erfasst:
| Dimension | Description |
| --- | --- |
| [STANDARD] | In Amazon EC2 wird der Host standardmäßig auch als Dimension von Metriken veröffentlicht, die vom CloudWatch Agenten erfasst werden, es sei denn, Sie verwenden das `append_dimensions` Feld im `metrics` Abschnitt. Sehen Sie sich `omit_hostname` im Agenten-Abschnitt von [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md) für weitere Informationen an. In Amazon EKS wird der k8s-bezogene Kontext standardmäßig auch als Dimensionen von Metriken (`k8s.container.name`, `k8s.deployment.name`, `k8s.namespace.name`, `k8s.node.name`, `k8s.pod.name` und `k8s.replicaset.name`) veröffentlicht. Diese können mithilfe des Felds `aggregation_dimensions` gefiltert werden. |
| `type` | Der Anforderungstyp. Mögliche Werte sind `produce`, `fetch`, `fetchconsumer` und `fetchfollower`. |
| `state` | Die Richtung des Netzwerkverkehrs. Mögliche Werte sind `in` und `out`. |
| `operation` | Der Vorgangstyp für das synchrone Replikat. Mögliche Werte sind `shrink` und `expand`. |
**Kafka-Consumer-Metriken**
Die folgenden Metriken können für Kafka-Consumer erfasst werden.
| Metrik | Dimensionen | Description |
| --- | --- | --- |
| `kafka.consumer.fetch-rate` | [STANDARD], `client-id` | Die Anzahl der Abrufanforderungen für alle Themen pro Sekunde. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.consumer.records-lag-max` | [STANDARD], `client-id` | Die Anzahl der Nachrichten, bei denen der Consumer dem Producer hinterherhinkt. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.consumer.total.bytes-consumed-rate` | [STANDARD], `client-id` | Die durchschnittliche Anzahl von Bytes, die pro Sekunde für alle Themen verbraucht werden. **Einheit:** Byte **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.consumer.total.fetch-size-avg` | [STANDARD], `client-id` | Die Anzahl der pro Anforderung abgerufenen Bytes für alle Themen. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.consumer.total.records-consumed-rate` | [STANDARD], `client-id` | Die durchschnittliche Anzahl der Datensätze, die pro Sekunde für alle Themen verbraucht werden. **Einheit:** keine **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.consumer.bytes-consumed-rate` | [STANDARD], `client-id`, `topic` | Die durchschnittliche Anzahl von Bytes, die pro Sekunde verbraucht werden. **Einheit:** Byte **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.consumer.fetch-size-avg` | [STANDARD], `client-id`, `topic` | Die Anzahl der pro Anforderung abgerufenen Bytes. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.consumer.records-consumed-rate` | [STANDARD], `client-id`, `topic` | Die durchschnittliche Anzahl von Datensätzen, die pro Sekunde verbraucht werden. **Einheit:** keine **Aussagekräftige Statistiken:** Durchschnitt |
Die Kafka–Consumer-Metriken werden mit den folgenden Dimensionen erfasst:
| Dimension | Description |
| --- | --- |
| [STANDARD] | In Amazon EC2 wird der Host standardmäßig auch als Dimension von Metriken veröffentlicht, die vom CloudWatch Agenten erfasst werden, es sei denn, Sie verwenden das `append_dimensions` Feld im `metrics` Abschnitt. Sehen Sie sich `omit_hostname` im Agenten-Abschnitt von [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md) für weitere Informationen an. In Amazon EKS wird der k8s-bezogene Kontext standardmäßig auch als Dimensionen von Metriken (`k8s.container.name`, `k8s.deployment.name`, `k8s.namespace.name`, `k8s.node.name`, `k8s.pod.name` und `k8s.replicaset.name`) veröffentlicht. Diese können mithilfe des Felds `aggregation_dimensions` gefiltert werden. |
| `client-id` | Die Client-ID |
| `topic` | Das Kafka-Thema. |
**Kafka-Producer-Metriken**
Die folgenden Metriken können für Kafka-Producer erfasst werden.
| Metrik | Dimensionen | Description |
| --- | --- | --- |
| `kafka.producer.io-wait-time-ns-avg` | [STANDARD], `client-id` | Die durchschnittliche Zeit, die der I/O Thread damit verbracht hat, auf einen Socket zu warten, der für Lese- oder Schreibvorgänge bereit ist. **Einheit:** keine **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.producer.outgoing-byte-rate` | [STANDARD], `client-id` | Die durchschnittliche Anzahl ausgehender Byte, die pro Sekunde an alle Server gesendet werden. **Einheit:** Byte **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.producer.request-latency-avg` | [STANDARD], `client-id` | Die durchschnittliche Latenz bei Anforderungen. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.producer.request-rate` | [STANDARD], `client-id` | Die durchschnittliche Anzahl an Anforderungen pro Sekunde. **Einheit:** keine **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.producer.response-rate` | [STANDARD], `client-id` | Die Anzahl der pro Sekunde empfangenen Antworten. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `kafka.producer.byte-rate` | [STANDARD], `client-id`, `topic` | Die durchschnittliche Anzahl von Bytes, die pro Sekunde für ein Thema gesendet werden. **Einheit:** Byte **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.producer.compression-rate` | [STANDARD], `client-id`, `topic` | Die durchschnittliche Komprimierungsrate von Datensatz-Batches für ein Thema. **Einheit:** keine **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.producer.record-error-rate` | [STANDARD], `client-id`, `topic` | Die durchschnittliche Anzahl der pro Sekunde gesendeten Datensätze, die für ein Thema zu Fehlern geführt haben. **Einheit:** keine **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.producer.record-retry-rate` | [STANDARD], `client-id`, `topic` | Die durchschnittliche Anzahl der pro Sekunde wiederholten Datensatzsendungen für ein Thema. **Einheit:** keine **Aussagekräftige Statistiken:** Durchschnitt |
| `kafka.producer.record-send-rate` | [STANDARD], `client-id`, `topic` | Die durchschnittliche Anzahl der Datensätze, die pro Sekunde für ein Thema gesendet werden. **Einheit:** keine **Aussagekräftige Statistiken:** Durchschnitt |
Die Kafka-Producer-Metriken werden mit den folgenden Dimensionen erfasst:
| Dimension | Description |
| --- | --- |
| [STANDARD] | In Amazon EC2 wird der Host standardmäßig auch als Dimension von Metriken veröffentlicht, die vom CloudWatch Agenten erfasst werden, es sei denn, Sie verwenden das `append_dimensions` Feld im `metrics` Abschnitt. Sehen Sie sich `omit_hostname` im Agenten-Abschnitt von [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md) für weitere Informationen an. In Amazon EKS wird der k8s-bezogene Kontext standardmäßig auch als Dimensionen von Metriken (`k8s.container.name`, `k8s.deployment.name`, `k8s.namespace.name`, `k8s.node.name`, `k8s.pod.name` und `k8s.replicaset.name`) veröffentlicht. Diese können mithilfe des Felds `aggregation_dimensions` gefiltert werden. |
| `client-id` | Die Client-ID |
| `topic` | Das Kafka-Thema. |
## Erfassen von Tomcat-Metriken
Sie können den CloudWatch Agenten verwenden, um Apache Tomcat-Metriken zu sammeln. Um dies einzurichten, fügen Sie dem `tomcat` Abschnitt der CloudWatch Agenten-Konfigurationsdatei einen `metrics_collected` Abschnitt hinzu.
Die folgenden Metriken können erfasst werden.
| Metrik | Dimensionen | Description |
| --- | --- | --- |
| `tomcat.sessions` | [STANDARD] | Die Anzahl der aktiven Sitzungen. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `tomcat.errors` | [STANDARD], `proto_handler` | Die Anzahl der angetroffenen Fehler. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `tomcat.processing_time` | [STANDARD], `proto_handler` | Die gesamte Verarbeitungszeit. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `tomcat.traffic` | [STANDARD], `proto_handler` | Die Anzahl der empfangenen und gesendeten Bytes. **Einheit:** Byte **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `tomcat.threads` | [STANDARD], `proto_handler` | Die Anzahl von Threads. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
| `tomcat.max_time` | [STANDARD], `proto_handler`, `direction` | Maximale Zeit für die Bearbeitung einer Anforderung. **Einheit:** Millisekunden **Aussagekräftige Statistiken:** Maximum |
| `tomcat.request_count` | [STANDARD], `proto_handler` | Die Gesamtzahl der Anforderungen. **Einheit:** keine **Aussagekräftige Statistiken:** Minimum, Maximum, Durchschnitt |
Die Tomcat-Metriken werden mit den folgenden Dimensionen erfasst:
| Dimension | Description |
| --- | --- |
| [STANDARD] | In Amazon EC2 wird der Host standardmäßig auch als Dimension von Metriken veröffentlicht, die vom CloudWatch Agenten erfasst werden, es sei denn, Sie verwenden das `append_dimensions` Feld im `metrics` Abschnitt. Sehen Sie sich `omit_hostname` im Agenten-Abschnitt von [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md) für weitere Informationen an. In Amazon EKS wird der k8s-bezogene Kontext standardmäßig auch als Dimensionen von Metriken (`k8s.container.name`, `k8s.deployment.name`, `k8s.namespace.name`, `k8s.node.name`, `k8s.pod.name` und `k8s.replicaset.name`) veröffentlicht. Diese können mithilfe des Felds `aggregation_dimensions` gefiltert werden. |
| `proto_handler` | Der `proto_handler` ist ein Bezeichner für einen Konnektor, der im `--`-Format bereitgestellt wird (z. B. `http-nio-8080`). |
| `direction` | Die Verkehrsrichtung. Mögliche Werte sind `received` und `sent`. |
# Erfassen Sie Metriken und Traces mit OpenTelemetry
Mit dem CloudWatch Agent with the OpenTelemetry Protocol (OTLP), einer beliebten Open-Source-Lösung, können Sie Metriken und Traces aus Ihren Anwendungen oder Diensten sammeln. Sie können jedes OpenTelemetry SDK verwenden, um Metriken und Traces an den CloudWatch Agenten zu senden. Weitere Informationen zu den verfügbaren OpenTelemetry SDKs Sprachen finden Sie unter [ OpenTelemetry Unterstützte Sprache APIs & SDKs.](https://opentelemetry.io/docs/languages/) .
Um OpenTelemetry Metriken und Traces zu sammeln, fügen Sie der CloudWatch Agenten-Konfigurationsdatei einen `otlp` Abschnitt hinzu. Der Abschnitt hat die folgenden Felder:
+ `grpc_endpoint` – Optional. Gibt die Adresse an, die der CloudWatch Agent verwenden soll, um auf OpenTelemetry Metriken oder Traces zu warten, die mit gRPC Remote Procedure Calls gesendet wurden. Das Format ist `ip:port`. Diese Adresse muss mit der Adresse übereinstimmen, die für den gRPC-Exporter im OpenTelemetry SDK festgelegt wurde. Wenn Sie dieses Feld auslassen, wird der Standard `127.0.0.1:4317` verwendet.
+ `http_endpoint` – Optional. Gibt die Adresse an, die der CloudWatch Agent verwenden soll, um auf OpenTelemetry Metriken oder Traces zu warten, die über HTTP gesendet wurden. Das Format ist `ip:port`. Diese Adresse muss mit der Adresse übereinstimmen, die für den HTTP-Exporter im OpenTelemetry SDK festgelegt wurde. Wenn Sie dieses Feld auslassen, wird der Standard `127.0.0.1:4318` verwendet.
+ `tls` – Optional. Gibt an, dass der Server mit TLS konfiguriert werden sollte.
+ `cert_file`: Pfad zum TLS-Zertifikat, das für die erforderlichen TLS-Verbindungen verwendet werden soll.
+ `key_file`: Pfad zum TLS-Schlüssel, der für die erforderlichen TLS-Verbindungen verwendet werden soll.
Der `otlp` Abschnitt kann in der CloudWatch Agentenkonfigurationsdatei in mehreren Abschnitten platziert werden, je nachdem, wie und wohin Sie die Metriken und Traces senden möchten.
**Wichtig**
Jeder `otlp`-Abschnitt erfordert einen eindeutigen Endpunkt und Port. Ausführliche Informationen zur Aufteilung der Metriken- und Traces-Endpunkte finden Sie in der [SDK-Dokumentation unter OTLP Exporter Configuration](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/). OpenTelemetry
Um Messwerte an CloudWatch oder Amazon Managed Service for Prometheus zu senden, fügen Sie den `otlp` Abschnitt unten `metrics_collected` innerhalb des `metrics` Abschnitts hinzu. Weitere Informationen zum Senden von Metriken an verschiedene Ziele finden Sie unter [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md). Das folgende Beispiel zeigt eine Konfiguration, die Metriken sendet an: CloudWatch
**Anmerkung**
Wenn Sie den Agenten in containerisierten Umgebungen ausführen und Telemetriedaten von außerhalb des Netzwerks des Agenten-Containers senden, stellen Sie sicher, dass Sie den Endpunkt als `0.0.0.0` anstelle des Standardendpunkts `127.0.0.1` angeben.
```
{
"metrics": {
"metrics_collected": {
"otlp": {
"grpc_endpoint": "127.0.0.1:4317",
"http_endpoint": "127.0.0.1:4318"
}
}
}
}
```
Um Metriken mit dem Embedded Metric Format (EMF) an Amazon CloudWatch Logs zu senden, fügen Sie den `otlp` Abschnitt unten `metrics_collected` innerhalb des `logs` Abschnitts hinzu. Dadurch werden die EMF-Protokolle standardmäßig an die `/aws/cwagent`-Protokollgruppe und ein generierter Protokollstream gesendet. Die Metriken werden standardmäßig in den Namespace `CWAgent` extrahiert. Das folgende Beispiel zeigt eine Konfiguration, die Metriken als EMF-Protokolle an CloudWatch Logs sendet:
```
{
"logs": {
"metrics_collected": {
"otlp": {
"grpc_endpoint": "127.0.0.1:4317",
"http_endpoint": "127.0.0.1:4318"
}
}
}
}
```
Um Traces an zu senden AWS X-Ray, fügen Sie `traces_collected` innerhalb des `otlp` Abschnitts den `traces` Abschnitt unter hinzu. Das folgende Beispiel zeigt eine Konfiguration, die Ablaufverfolgungen an X-Ray sendet:
```
{
"traces": {
"traces_collected": {
"otlp": {
"grpc_endpoint": "127.0.0.1:4317",
"http_endpoint": "127.0.0.1:4318"
}
}
}
}
```
# Erfassen von Prozessmetriken mit dem procstat-Plugin
Das *procstat*-Plugin ermöglicht es Ihnen, Metriken aus einzelnen Prozessen zu erfassen. Das Plug-in wird auf Linux-Servern und auf Servern mit einer unterstützten Version von Windows Server unterstützt. In diesem Abschnitt wird beschrieben, wie Sie den CloudWatch Agenten für procstat konfigurieren und die Metriken anzeigen, die der CloudWatch Agent importiert. Er listet auch die Metriken auf, die procstat erfasst.
**Anmerkung**
Das `procstat`-Plug-in wird für den Fargate-Starttyp in Amazon-ECS-Umgebungen nicht unterstützt.
**Topics**
+ [Konfigurieren Sie den CloudWatch Agenten für procstat](#CloudWatch-Agent-procstat-configuration)
+ [Von Procstat erfasste Metriken](#CloudWatch-Agent-procstat-process-metrics-collected)
+ [Vom CloudWatch Agenten importierte Prozessmetriken anzeigen](#CloudWatch-view-procstat-metrics)
## Konfigurieren Sie den CloudWatch Agenten für procstat
Um das procstat-Plug-In zu verwenden, fügen Sie dem `procstat` Abschnitt der CloudWatch Agenten-Konfigurationsdatei einen `metrics_collected` Abschnitt hinzu. Es gibt drei Möglichkeiten, die zu überwachenden Prozesse festzulegen. Sie können nur eine dieser Methoden verwenden, aber Sie können diese Methode verwenden, um einen oder mehrere Prozesse zur Überwachung anzugeben.
+ `pid_file`: Wählt Prozesse anhand der Namen der von ihnen erstellten PID-Dateien (Process Identification Number) aus.
+ `exe`: Wählt die Prozesse mit Prozessnamen aus, die mit der von Ihnen angegebenen Zeichenkette übereinstimmen, unter Verwendung von Abgleichsregeln für reguläre Ausdrücke. Die Übereinstimmung ist eine „enthält“ -Übereinstimmung, d. h., wenn Sie `agent` als übereinstimmender Begriff angeben, werden Prozesse mit Namen wie `cloudwatchagent` mit der Angabe übereinstimmen. Weitere Informationen finden Sie unter [Syntax](https://github.com/google/re2/wiki/Syntax).
+ `pattern`: Wählt Prozesse über die Befehlszeilen aus, die zum Starten der Prozesse verwendet werden. Es werden alle Prozesse ausgewählt, deren Befehlszeilen mit Hilfe von Regeln für den Abgleich mit regulären Ausdrücken mit der angegebenen Zeichenkette übereinstimmen. Die gesamte Befehlszeile wird überprüft, einschließlich der Parameter und Optionen, die mit dem Befehl verwendet werden.
Die Übereinstimmung ist eine „enthält“ -Übereinstimmung, d. h., wenn Sie `-c` als abzugleichenden Ausdruck angeben, werden Prozesse mit Parametern wie `-config` als Übereinstimmung interpretiert.
Der CloudWatch Agent verwendet nur eine dieser Methoden, auch wenn Sie mehr als einen der obigen Abschnitte angeben. Wenn Sie mehr als einen Abschnitt angeben, verwendet der CloudWatch Agent den `pid_file` Abschnitt, sofern er vorhanden ist. Wenn nicht, verwendet er den `exe`-Abschnitt.
Auf Linux-Servern werden die Zeichenfolgen, die Sie in einem `exe`- oder `pattern`-Abschnitt angeben, als reguläre Ausdrücke ausgewertet. Auf Servern mit Windows Server werden diese Zeichenketten als WMI-Abfragen ausgewertet. Ein Beispiel wäre `pattern: "%apache%"`. Weitere Informationen finden Sie unter [LIKE Operator (LIKE-Operator)](https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/like-operator).
Welche Methode Sie auch immer verwenden, Sie können einen optionalen `metrics_collection_interval`-Parameter einschließen, der angibt, wie oft diese Metriken in Sekunden erfasst werden sollen. Wenn Sie diesen Parameter weglassen, wird der Standardwert von 60 Sekunden verwendet.
In den Beispielen in den folgenden Abschnitten ist der `procstat`-Abschnitt der einzige Abschnitt, der im `metrics_collected`-Abschnitt der Agent-Konfigurationsdatei enthalten ist. Tatsächliche Konfigurationsdateien können auch andere Abschnitte in `metrics_collected` enthalten. Weitere Informationen finden Sie unter [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md).
### Konfigurieren mit pid\$1file
Das folgende Beispiel eines `procstat`-Abschnitts überwacht die Prozesse, die die PID-Dateien `example1.pid` und `example2.pid` erstellen. Von jedem Prozess werden unterschiedliche Metriken erfasst. Metriken, die aus dem Prozess erfasst wurden, der `example2.pid` erstellt, werden alle 10 Sekunden erfasst, während die Metriken aus dem Prozess `example1.pid` alle 60 Sekunden (Standardwert) erfasst werden.
```
{
"metrics": {
"metrics_collected": {
"procstat": [
{
"pid_file": "/var/run/example1.pid",
"measurement": [
"cpu_usage",
"memory_rss"
]
},
{
"pid_file": "/var/run/example2.pid",
"measurement": [
"read_bytes",
"read_count",
"write_bytes"
],
"metrics_collection_interval": 10
}
]
}
}
}
```
### Konfigurieren mit exe
Das folgende Beispiel eines `procstat`-Abschnitts überwacht alle Prozesse mit Namen, die mit den Zeichenfolgen `agent` oder `plugin` übereinstimmen. Von jedem Prozess werden die gleichen Metriken gesammelt.
```
{
"metrics": {
"metrics_collected": {
"procstat": [
{
"exe": "agent",
"measurement": [
"cpu_time",
"cpu_time_system",
"cpu_time_user"
]
},
{
"exe": "plugin",
"measurement": [
"cpu_time",
"cpu_time_system",
"cpu_time_user"
]
}
]
}
}
}
```
### Konfigurieren mit Muster
Das folgende Beispiel eines `procstat`-Abschnitts überwacht alle Prozesse mit Befehlszeilen, die den Zeichenfolgen `config` oder `-c` entsprechen. Von jedem Prozess werden die gleichen Metriken gesammelt.
```
{
"metrics": {
"metrics_collected": {
"procstat": [
{
"pattern": "config",
"measurement": [
"rlimit_memory_data_hard",
"rlimit_memory_data_soft",
"rlimit_memory_stack_hard",
"rlimit_memory_stack_soft"
]
},
{
"pattern": "-c",
"measurement": [
"rlimit_memory_data_hard",
"rlimit_memory_data_soft",
"rlimit_memory_stack_hard",
"rlimit_memory_stack_soft"
]
}
]
}
}
}
```
## Von Procstat erfasste Metriken
Die folgende Tabelle listet die Metriken auf, die Sie mit dem `procstat`-Plug-in erfassen können.
Der CloudWatch Agent fügt `procstat` am Anfang der folgenden Metriknamen hinzu. Es gibt eine unterschiedliche Syntax, je nachdem, ob sie von einem Linux-Server oder einem Server mit Windows-Server erfasst wurde. Zum Beispiel erscheint die `cpu_time`-Metrik als `procstat_cpu_time`, wenn sie unter Linux erfasst wurde, aber als `procstat cpu_time`, wenn sie unter Windows Server erfasst wurde.
| Metrikname | Verfügbar am | Description |
| --- | --- | --- |
| `cpu_time` | Linux | Die Zeit, die der Prozess die CPU nutzt. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: Anzahl |
| `cpu_time_guest` | Linux | Die Zeitspanne, die der Vorgang im Gastmodus ist. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_guest_nice` | Linux | Die Zeitspanne, die der Prozess in einem Nice Guest läuft. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_idle` | Linux | Die Zeitspanne, die der Prozess im Ruhezustand ist. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_iowait` | Linux | Die Zeitspanne, in der der Prozess auf den Abschluss von I/O Vorgängen wartet. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_irq` | Linux | Die Zeitspanne, in der der Prozess Unterbrechungen behandelt. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_nice` | Linux | Die Zeitspanne, in der sich der Prozess im Nice Mode befindet. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_soft_irq` | Linux | Die Zeitspanne, in der der Prozess Software-Unterbrechungen behandelt. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_steal` | Linux | Die Zeitspanne, die in anderen Betriebssystemen verbracht wird, wenn das Programm in einer virtualisierten Umgebung läuft. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_stolen` | Linux, Windows Server | Die Zeitspanne, in der sich der Prozess in *gestohlener Zeit* befindet, also die Zeit, die in anderen Betriebssystemen in einer virtualisierten Umgebung verbracht wird. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: keine |
| `cpu_time_system` | Linux, Windows Server, macOS | Die Zeit, die sich der Prozess im Systemmodus befindet. Diese Metrik wird in Hundertstelsekunden gemessen. Typ: Float Einheit: Anzahl |
| `cpu_time_user` | Linux, Windows Server, macOS | Die Zeit, die sich der Prozess im Benutzermodus befindet. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: Anzahl |
| `cpu_usage` | Linux, Windows Server, macOS | Der Prozentsatz der Zeit, in der der Prozess in beliebiger Funktion aktiv ist. Einheit: Prozent |
| `memory_data` | Linux, macOS | Die Menge an Speicher, die der Prozess für Daten benötigt. Einheit: Byte |
| `memory_locked` | Linux, macOS | Die Menge an Speicher, die der Prozess gesperrt hat. Einheit: Byte |
| `memory_rss` | Linux, Windows Server, macOS | Die Menge des realen Speichers (resident set), die der Prozess verwendet. Einheit: Byte |
| `memory_stack` | Linux, macOS | Die Menge an Stackspeicher, die der Prozess verwendet. Einheit: Byte |
| `memory_swap` | Linux, macOS | Die Menge an Auslagerungsspeicher, die der Prozess verwendet. Einheit: Byte |
| `memory_vms` | Linux, Windows Server, macOS | Die Menge an virtuellem Speicher, die der Prozess verwendet. Einheit: Byte |
| `num_fds` | Linux | Die Anzahl der Dateideskriptoren, die dieser Prozess geöffnet hat. Einheit: keine |
| `num_threads` | Linux, Windows, MacOS | Die Anzahl der Threads in diesem Prozess. Einheit: keine |
| `pid` | Linux, Windows Server, macOS | Prozesskennung (ID). Einheit: keine |
| `pid_count` | Linux, Windows Server, macOS | Die Anzahl der Prozesse, die dem Prozess IDs zugeordnet sind. Auf Linux-Servern und macOS-Computern lautet der volle Name dieser Metrik `procstat_lookup_pid_count` und auf Windows-Servern `procstat_lookup pid_count`. Einheit: keine |
| `read_bytes` | Linux, Windows Server | Die Anzahl der Bytes, die der Prozess von Datenträgern gelesen hat. Einheit: Byte |
| `write_bytes` | Linux, Windows Server | Die Anzahl der Bytes, die der Prozess auf Datenträger geschrieben hat. Einheit: Byte |
| `read_count` | Linux, Windows Server | Die Anzahl der Datenträgerlesevorgänge, die der Prozess ausgeführt hat. Einheit: keine |
| `rlimit_realtime_priority_hard` | Linux | Das feste Limit für die Echtzeitpriorität, die für diesen Prozess festgelegt werden kann. Einheit: keine |
| `rlimit_realtime_priority_soft` | Linux | Das weiche Limit für die Echtzeitpriorität, die für diesen Prozess festgelegt werden kann. Einheit: keine |
| `rlimit_signals_pending_hard` | Linux | Das feste Limit für die maximale Anzahl von Signalen, die von diesem Prozess in die Warteschlange gestellt werden können. Einheit: keine |
| `rlimit_signals_pending_soft` | Linux | Das weiche Limit für die maximale Anzahl von Signalen, die von diesem Prozess in die Warteschlange gestellt werden können. Einheit: keine |
| `rlimit_nice_priority_hard` | Linux | Das feste Limit für die maximale Nice-Priorität, die von diesem Prozess festgelegt werden kann. Einheit: keine |
| `rlimit_nice_priority_soft` | Linux | Das weiche Limit für die maximale Nice-Priorität, die von diesem Prozess festgelegt werden kann. Einheit: keine |
| `rlimit_num_fds_hard` | Linux | Das feste Limit für die maximale Anzahl von Dateideskriptoren, die dieser Prozess geöffnet haben kann. Einheit: keine |
| `rlimit_num_fds_soft` | Linux | Das weiche Limit für die maximale Anzahl von Dateideskriptoren, die dieser Prozess geöffnet haben kann. Einheit: keine |
| `write_count` | Linux, Windows Server | Die Anzahl der Festplattenschreibvorgänge, die der Prozess ausgeführt hat. Einheit: keine |
| `involuntary_context_switches` | Linux | Die Anzahl der unfreiwilligen Kontextwechsel des Prozesses. Einheit: keine |
| `voluntary_context_switches` | Linux | Die Anzahl der freiwilligen Kontextwechsel des Prozesses. Einheit: keine |
| `realtime_priority` | Linux | Die aktuelle Nutzung der Echtzeit-Priorität für den Prozess. Einheit: keine |
| `nice_priority` | Linux | Die aktuelle Verwendung angenehmer Priorität für den Prozess. Einheit: keine |
| `signals_pending` | Linux | Die Anzahl der Signale, die noch ausstehen, um vom Prozess verarbeitet zu werden. Einheit: keine |
| `rlimit_cpu_time_hard` | Linux | Die harte CPU-Zeitressourcenbegrenzung für den Prozess. Einheit: keine |
| `rlimit_cpu_time_soft` | Linux | Die weiche CPU-Zeitressourcenbegrenzung für den Prozess. Einheit: keine |
| `rlimit_file_locks_hard` | Linux | Die harte Dateisperren-Ressourcenbegrenzung für den Prozess. Einheit: keine |
| `rlimit_file_locks_soft` | Linux | Die weiche Dateisperren-Ressourcenbegrenzung für den Prozess. Einheit: keine |
| `rlimit_memory_data_hard` | Linux | Die harte Ressourcenbegrenzung im Prozess für den Speicher, der für Daten verwendet wird. Einheit: Byte |
| `rlimit_memory_data_soft` | Linux | Die weiche Ressourcenbegrenzung im Prozess für den Speicher, der für Daten verwendet wird. Einheit: Byte |
| `rlimit_memory_locked_hard` | Linux | Die harte Ressourcenbegrenzung im Prozess für gesperrten Speicher. Einheit: Byte |
| `rlimit_memory_locked_soft` | Linux | Die weiche Ressourcenbegrenzung im Prozess für gesperrten Speicher. Einheit: Byte |
| `rlimit_memory_rss_hard` | Linux | Die harte Ressourcenbegrenzung im Prozess für physischen Speicher. Einheit: Byte |
| `rlimit_memory_rss_soft` | Linux | Die weiche Ressourcenbegrenzung im Prozess für physischen Speicher. Einheit: Byte |
| `rlimit_memory_stack_hard` | Linux | Die harte Ressourcenbegrenzung im Prozessstapel. Einheit: Byte |
| `rlimit_memory_stack_soft` | Linux | Die weiche Ressourcenbegrenzung im Prozessstapel. Einheit: Byte |
| `rlimit_memory_vms_hard` | Linux | Die harte Ressourcenbegrenzung im Prozess für virtuellen Speicher. Einheit: Byte |
| `rlimit_memory_vms_soft` | Linux | Die weiche Ressourcenbegrenzung im Prozess für virtuellen Speicher. Einheit: Byte |
## Vom CloudWatch Agenten importierte Prozessmetriken anzeigen
Nachdem Sie Prozessmetriken in importiert haben CloudWatch, können Sie diese Metriken als Zeitreihendiagramme anzeigen und Alarme erstellen, die diese Metriken überwachen und Sie benachrichtigen, wenn sie einen von Ihnen angegebenen Schwellenwert überschreiten. Das folgende Verfahren zeigt, wie Sie Prozess-Metriken als Zeitreihendiagramm anzeigen. Weitere Informationen zum Einrichten eines -Alarms finden Sie unter [CloudWatch Amazon-Alarme verwenden](CloudWatch_Alarms.md).
**Um Prozessmetriken in der CloudWatch Konsole anzuzeigen**
1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie den Namespace für die vom Agent zu erfassenden Metriken. Standardmäßig ist dies der Fall **CWAgent**, aber Sie haben möglicherweise einen anderen Namespace in der CloudWatch Agentenkonfigurationsdatei angegeben.
1. Wählen Sie eine Metrikdimension aus (z. B. **Per-Instance Metrics (Metriken pro Instance)**).
1. Die Registerkarte **All metrics** zeigt alle Metriken für diese Dimension im Namespace an. Sie haben die folgenden Möglichkeiten:
1. Um eine Metrik grafisch darzustellen, müssen Sie das Kontrollkästchen neben der Metrik aktivieren. Um alle Metriken auszuwählen, aktivieren Sie das Kontrollkästchen in der Kopfzeile der Tabelle.
1. Um die Tabelle sortieren, verwenden Sie die Spaltenüberschrift.
1. Um nach Ressource zu filtern, müssen Sie zunächst die Ressourcen-ID und dann die Option **Zu Suche hinzufügen** auswählen.
1. Um nach Metrik zu filtern, müssen Sie den Metriknamen und anschließend **Add to search (Zur Suche hinzufügen)** auswählen.
1. (Optional) Um dieses Diagramm zu einem CloudWatch Dashboard hinzuzufügen, wählen Sie **Aktionen**, **Zum Dashboard hinzufügen** aus.
# Abrufen benutzerdefinierter Metriken mit StatsD
Sie können zusätzliche benutzerdefinierte Messwerte aus Ihren Anwendungen oder Diensten abrufen, indem Sie den CloudWatch Agenten mit dem `StatsD` Protokoll verwenden. StatSD ist eine beliebte Open-Source-Lösung, mit der Metriken aus einer Vielzahl von Anwendungen gesammelt werden können. StatSD ist besonders nützlich für das Instrumentieren eigener Metriken. Ein Beispiel für die gemeinsame Verwendung von CloudWatch Agent und StatsD finden Sie unter [So überwachen Sie Ihre benutzerdefinierten Anwendungsmetriken mithilfe von Amazon CloudWatch Agent besser](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/).
`StatsD`wird sowohl auf Linux-Servern als auch auf Servern unterstützt, auf denen Windows Server ausgeführt wird. CloudWatch unterstützt das folgende `StatsD` Format:
```
MetricName:value|type|@sample_rate|#tag1:
value,tag1...
```
+ `MetricName` – Eine Zeichenfolge ohne Doppelpunkte, Balken, \$1-Zeichen oder @-Zeichen.
+ `value` – Dies kann eine Ganzzahl oder Gleitkommazahl sein.
+ `type` – Geben Sie `c` für Zähler, `g` für Anzeige, `ms` für Timer, `h` für Histogramm oder `s` für Set an.
+ `sample_rate` – (Optional) Eine Gleitkommazahl zwischen 0 und 1. Wird nur für Zähler-, Histogramm- und Timer-Metriken verwendet. Der Standardwert lautet "1" (Erfassung über die gesamte Zeit hinweg).
+ `tags`— (Optional) Eine durch Kommas getrennte Liste von Tags. `StatsD`Tags ähneln den Dimensionen in. CloudWatch Verwenden Sie für Schlüssel/Wert-Tags Doppelpunkte, z. B. `env:prod`.
Sie können jeden `StatsD` Client verwenden, der dieses Format verwendet, um die Metriken an den CloudWatch Agenten zu senden. Weitere Informationen zu einigen der verfügbaren `StatsD` Clients finden Sie auf der [StatsD-Client-Seite unter GitHub](https://github.com/etsy/statsd/wiki#client-implementations).
Um diese benutzerdefinierten Metriken zu erfassen, fügen Sie die Zeile `"statsd": {}` zum Abschnitt `metrics_collected` der Agentenkonfigurationsdatei hinzu. Sie können diese Zeile manuell hinzufügen. Wenn Sie zum Erstellen der Konfigurationsdatei den Assistenten verwenden, geschieht dies automatisch. Weitere Informationen finden Sie unter [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md).
Die `StatsD`-Standardkonfiguration eignet sich für die meisten Benutzer. Es gibt optionale Felder, die Sie ganz nach Bedarf zum Abschnitt **statsd** der Agentenkonfigurationsdatei hinzufügen können:
+ `service_address`— Die Dienstadresse, auf die der CloudWatch Agent hören soll. Das Format ist `ip:port`. Wenn Sie die IP-Adresse weglassen, überwacht der Agent alle verfügbaren Schnittstellen. Da nur das UDP-Format unterstützt wird, müssen Sie kein UDP-Präfix anzugeben.
Der Standardwert ist `:8125`.
+ `metrics_collection_interval` – Wie oft (in Sekunden) das `StatsD`-Plug-in ausgeführt wird und Metriken erfasst. Der Standardwert liegt bei 10 Sekunden. Der Bereich liegt zwischen 1 und 172.000.
+ `metrics_aggregation_interval`— Wie oft (in Sekunden) werden CloudWatch Metriken zu einzelnen Datenpunkten zusammengefasst. Der Standardwert liegt bei 60 Sekunden.
Wenn beispielsweise 10 und 60 `metrics_collection_interval` `metrics_aggregation_interval` ist, werden alle 10 Sekunden Daten CloudWatch erfasst. Nach jeder Minute werden die sechs Datenmessungen der ersten Minute in einen einzelnen Datenpunkt aggregiert, der zu CloudWatch gesendet wird.
Der Bereich liegt zwischen 0 und 172.000. Wenn für `metrics_aggregation_interval` "0" festgelegt wird, ist die Aggregation von `StatsD`-Metriken deaktiviert.
+ `allowed_pending_messages` – Die Anzahl der UDP-Nachrichten, die in die Warteschlange aufgenommen werden dürfen. Wenn die Warteschlange voll ist, beginnt der StatsD-Server, Pakete zu verwerfen. Der Standardwert lautet 10.000.
+ `drop_original_metrics` – Optional. Wenn Sie das `aggregation_dimensions`-Feld im `metrics`-Abschnitt verwenden, um Metriken zu aggregierten Ergebnissen zusammenzufassen, dann sendet der Agent standardmäßig sowohl die aggregierten Metriken als auch die ursprünglichen Metriken, die für jeden Wert der Dimension getrennt sind. Wenn Sie nicht möchten, dass die ursprünglichen Metriken an gesendet werden CloudWatch, können Sie diesen Parameter mit einer Liste von Metriken angeben. Für die zusammen mit diesem Parameter angegebenen Metriken werden keine Kennzahlen nach Dimension gemeldet CloudWatch. Stattdessen werden nur die aggregierten Metriken gemeldet. Dadurch verringert sich die Anzahl der Metriken, die der Agent erfasst, was Ihre Kosten senkt.
Im Folgenden finden Sie ein Beispiel für den Abschnitt **statsd** der Agent-Konfigurationsdatei unter Verwendung des Standard-Ports und von benutzerdefinierten Sammlungs- und Aggregationsintervallen.
```
{
"metrics":{
"metrics_collected":{
"statsd":{
"service_address":":8125",
"metrics_collection_interval":60,
"metrics_aggregation_interval":300
}
}
}
}
```
## Vom Agenten importierte StatsD-Metriken anzeigen CloudWatch
Nach dem Import von StatsD-Metriken in CloudWatch können Sie diese Metriken als Zeitreihendiagramme anzeigen und Alarme erstellen, die diese Metriken überwachen und Sie benachrichtigen können, wenn sie einen von Ihnen angegebenen Schwellenwert überschreiten. Das folgende Verfahren zeigt, wie Sie StatsD-Metriken als Zeitreihendiagramm anzeigen. Weitere Informationen zum Einrichten eines -Alarms finden Sie unter [CloudWatch Amazon-Alarme verwenden](CloudWatch_Alarms.md).
**So zeigen Sie StatsD-Metriken in der Konsole an CloudWatch**
1. Öffnen Sie die CloudWatch Konsole unter. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie den Namespace für die vom Agent zu erfassenden Metriken. Standardmäßig ist dies der Fall **CWAgent**, aber Sie haben möglicherweise einen anderen Namespace in der CloudWatch Agentenkonfigurationsdatei angegeben.
1. Wählen Sie eine Metrikdimension aus (z. B. **Per-Instance Metrics (Metriken pro Instance)**).
1. Die Registerkarte **All metrics** zeigt alle Metriken für diese Dimension im Namespace an. Sie haben die folgenden Möglichkeiten:
1. Um eine Metrik grafisch darzustellen, müssen Sie das Kontrollkästchen neben der Metrik aktivieren. Um alle Metriken auszuwählen, aktivieren Sie das Kontrollkästchen in der Kopfzeile der Tabelle.
1. Um die Tabelle sortieren, verwenden Sie die Spaltenüberschrift.
1. Um nach Ressource zu filtern, müssen Sie zunächst die Ressourcen-ID und dann die Option **Zu Suche hinzufügen** auswählen.
1. Um nach Metrik zu filtern, müssen Sie den Metriknamen und anschließend **Add to search (Zur Suche hinzufügen)** auswählen.
1. (Optional) Um dieses Diagramm zu einem CloudWatch Dashboard hinzuzufügen, wählen Sie **Aktionen**, **Zum Dashboard hinzufügen** aus.
# Abrufen benutzerdefinierter Metriken mit collectd
Mithilfe des CloudWatch Agenten mit dem Collectd-Protokoll, das nur auf Linux-Servern unterstützt wird, können Sie zusätzliche Messwerte aus Ihren Anwendungen oder Diensten abrufen. collectd ist eine beliebte Open-Source-Lösung mit Plugins, die Systemstatistiken für eine Vielzahl von Anwendungen sammeln können. Durch die Kombination der Systemmetriken, die der CloudWatch Agent bereits erfassen kann, mit den zusätzlichen Metriken von collectd können Sie Ihre Systeme und Anwendungen besser überwachen, analysieren und Fehler beheben. Weitere Informationen zu collectd finden Sie unter [collectd – Daemon für die Systemstatistikerfassung](https://collectd.org/).
Sie verwenden die gesammelte Software, um die Metriken an den Agenten zu senden. CloudWatch Bei den gesammelten Metriken fungiert der CloudWatch Agent als Server, während das Collectd-Plugin als Client fungiert.
Die collectd-Software wird nicht auf jedem Server automatisch installiert. Führen Sie auf einem Server mit Amazon Linux 2 die folgenden Schritte aus, um collectd zu installieren.
```
sudo amazon-linux-extras install collectd
```
Informationen zum Installieren von collectd auf anderen Systemen finden Sie auf der [Download-Seite für collectd.](https://www.collectd.org/download.html)
Um diese benutzerdefinierten Metriken zu erfassen, fügen Sie die Zeile **"collectd": \$1\$1** zum Abschnitt **metrics\$1collected** der Agentenkonfigurationsdatei hinzu. Sie können diese Zeile manuell hinzufügen. Wenn Sie zum Erstellen der Konfigurationsdatei den Assistenten verwenden, geschieht dies automatisch. Weitere Informationen finden Sie unter [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md).
Optionale Parameter sind ebenfalls verfügbar. Wenn Sie bei Einsatz des collectd-Protokolls nicht `/etc/collectd/auth_file` als Wert für **collectd\$1auth\$1file** verwenden, müssen Sie einige dieser Optionen selbst festlegen.
+ **service\$1address: Die** Dienstadresse, auf die der CloudWatch Agent hören soll. Das Format ist `"udp://ip:port`. Der Standardwert ist `udp://127.0.0.1:25826`.
+ **name\$1prefix:** Ein Präfix zum Anfügen an den Anfang des Namens einer jeden collectd-Metrik. Der Standardwert ist `collectd_`. Die maximale Länge beträgt 255 Zeichen.
+ **collectd\$1security\$1level:** Legt die Sicherheitsstufe für die Netzwerkkommunikation fest. Der Standardwert lautet **encrypt (Verschlüsseln)**.
**encrypt (Verschlüsseln)** gibt an, dass nur verschlüsselte Daten akzeptiert werden. **sign (Signieren)** gibt an, dass nur signierte und verschlüsselte Daten akzeptiert werden. **none (Keine)** gibt an, dass alle Daten akzeptiert werden. Wenn Sie einen Wert für **collectd\$1auth\$1file** angeben, werden verschlüsselte Daten, falls möglich, entschlüsselt.
Weitere Informationen finden Sie unter [Client-Einrichtung](https://collectd.org/wiki/index.php/Networking_introduction#Client_setup) und [Mögliche Interaktionen](https://collectd.org/wiki/index.php/Networking_introduction#Possible_interactions) in der collectd Wiki.
+ **collectd\$1auth\$1file** Legt eine Datei fest, in der Benutzernamen Passwörtern zugeordnet sind. Diese Passwörter werden verwendet, um Signaturen zu verifizieren und verschlüsselte Netzwerkpakete zu entschlüsseln. Sofern angegeben, werden signierte Daten verifiziert und verschlüsselte Pakete entschlüsselt. Andernfalls werden signierte Daten ohne Überprüfung der Signatur akzeptiert und verschlüsselte Daten können nicht entschlüsselt werden.
Der Standardwert ist `/etc/collectd/auth_file`.
Wenn **collectd\$1security\$1level** auf **none (Keine)** gesetzt ist, ist dies optional. Wenn Sie **collectd\$1security\$1level** auf `encrypt` oder **sign (Signieren)** einstellen, müssen Sie einen Wert für **collectd\$1auth\$1file** angeben.
Bei dem Format der auth-Datei ist jede Zeile ein Benutzernamen, gefolgt von einem Doppelpunkt und einer beliebigen Anzahl von Leerzeichen, gefolgt von dem Passwort. Zum Beispiel:
`user1: user1_password`
`user2: user2_password`
+ **collectd\$1typesdb:** Eine Liste von einer oder mehreren Dateien, die die Beschreibungen der Datensätze enthalten. Die Liste muss in eckigen Klammern stehen, auch wenn sie nur einen Eintrag enthält. Jeder Eintrag in der Liste muss in Anführungszeichen stehen. Wenn mehrere Einträge vorhanden sind, trennen Sie sie durch Kommas voneinander. Der Standardwert auf Linux-Servern ist `["/usr/share/collectd/types.db"]`. Die Standardeinstellung auf macOs Computern hängt von der Version von collectd ab. Beispiel, `["/usr/local/Cellar/collectd/5.12.0/share/collectd/types.db"]`.
Weitere Informationen finden Sie unter [https://www.collectd.org/documentation/manpages/types.db.html](https://www.collectd.org/documentation/manpages/types.db.html).
+ **metrics\$1aggregation\$1interval:** Wie oft (in Sekunden) CloudWatch Metriken in einzelne Datenpunkte aggregiert. Standardmäßig ist ein Zeitraum von 60 Sekunden festgelegt. Der Bereich liegt zwischen 0 und 172.000. Wenn für ihn "0" festgelegt wird, ist die Aggregation von collectd-Metriken deaktiviert.
Es folgt ein Beispiel des collectd-Abschnitts der Agenten-Konfigurationsdatei.
```
{
"metrics":{
"metrics_collected":{
"collectd":{
"name_prefix":"My_collectd_metrics_",
"metrics_aggregation_interval":120
}
}
}
}
```
## Gesammelte Metriken anzeigen, die vom Agenten importiert wurden CloudWatch
Nachdem Sie die gesammelten Metriken in importiert haben CloudWatch, können Sie diese Metriken als Zeitreihendiagramme anzeigen und Alarme erstellen, die diese Metriken überwachen und Sie benachrichtigen, wenn sie einen von Ihnen festgelegten Schwellenwert überschreiten. Das folgende Verfahren zeigt, wie Sie Collectd-Metriken als Zeitreihendiagramm anzeigen. Weitere Informationen zum Einrichten eines -Alarms finden Sie unter [CloudWatch Amazon-Alarme verwenden](CloudWatch_Alarms.md).
**Um gesammelte Metriken in der Konsole anzuzeigen CloudWatch**
1. Öffnen Sie die CloudWatch Konsole unter. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie den Namespace für die vom Agent zu erfassenden Metriken. Standardmäßig ist dies der Fall **CWAgent**, aber Sie haben möglicherweise einen anderen Namespace in der CloudWatch Agentenkonfigurationsdatei angegeben.
1. Wählen Sie eine Metrikdimension aus (z. B. **Per-Instance Metrics (Metriken pro Instance)**).
1. Die Registerkarte **All metrics** zeigt alle Metriken für diese Dimension im Namespace an. Sie haben die folgenden Möglichkeiten:
1. Um eine Metrik grafisch darzustellen, müssen Sie das Kontrollkästchen neben der Metrik aktivieren. Um alle Metriken auszuwählen, aktivieren Sie das Kontrollkästchen in der Kopfzeile der Tabelle.
1. Um die Tabelle sortieren, verwenden Sie die Spaltenüberschrift.
1. Um nach Ressource zu filtern, müssen Sie zunächst die Ressourcen-ID und dann die Option **Zu Suche hinzufügen** auswählen.
1. Um nach Metrik zu filtern, müssen Sie den Metriknamen und anschließend **Add to search (Zur Suche hinzufügen)** auswählen.
1. (Optional) Um dieses Diagramm zu einem CloudWatch Dashboard hinzuzufügen, wählen Sie **Aktionen**, **Zum Dashboard hinzufügen** aus.
# Einrichten und Konfigurieren der Prometheus-Metrikensammlung in Amazon-EC2-Instances
In den folgenden Abschnitten wird erklärt, wie der CloudWatch Agent mit Prometheus-Überwachung auf EC2-Instances installiert wird und wie der Agent so konfiguriert wird, dass er zusätzliche Ziele scannt. Es bietet auch Tutorials zum Einrichten von Beispiel-Workloads für die Verwendung von Tests mit Prometheus-Überwachung.
Sowohl Linux- als auch Windows-Instances werden unterstützt.
Informationen zu den vom Agenten unterstützten Betriebssystemen finden Sie unter CloudWatch [Erfassen Sie Metriken, Logs und Traces mithilfe des CloudWatch Agenten](Install-CloudWatch-Agent.md)
**Anforderungen an VPC-Sicherheitsgruppen**
Wenn Sie eine VPC verwenden, gelten folgende Anforderungen.
+ Die Eingangsregeln der Sicherheitsgruppen für die Prometheus-Workloads müssen die Prometheus-Ports für den CloudWatch Agenten öffnen, damit er die Prometheus-Metriken über die private IP scrapen kann.
+ Die Ausgangsregeln der Sicherheitsgruppe für den CloudWatch Agenten müssen es dem CloudWatch Agenten ermöglichen, über eine private IP eine Verbindung zum Port der Prometheus-Workloads herzustellen.
**Topics**
+ [Schritt 1: Installieren Sie den Agenten CloudWatch](#CloudWatch-Agent-PrometheusEC2-install)
+ [Schritt 2: Prometheus-Quellen scrapen und Metriken importieren](#CloudWatch-Agent-PrometheusEC2-configure)
+ [Beispiel: Java/JMX Beispiel-Workloads für Prometheus-Metriktests einrichten](#CloudWatch-Agent-Prometheus-Java)
## Schritt 1: Installieren Sie den Agenten CloudWatch
Der erste Schritt besteht darin, den CloudWatch Agenten auf der EC2-Instance zu installieren. Detaillierte Anweisungen finden Sie unter [Den CloudWatch Agenten installieren](install-CloudWatch-Agent-on-EC2-Instance.md).
## Schritt 2: Prometheus-Quellen scrapen und Metriken importieren
Der CloudWatch Agent mit Prometheus-Überwachung benötigt zwei Konfigurationen, um die Prometheus-Metriken zu erfassen. Er folgt der standardmäßigen Prometheus-Konfiguration, wie in [](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) in der Prometheus-Dokumentation erläutert. Die andere ist für die Agentenkonfiguration vorgesehen. CloudWatch
### Prometheus-Scrape-Konfiguration
Der CloudWatch Agent unterstützt die standardmäßigen Prometheus-Scrape-Konfigurationen, wie[https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) in der Prometheus-Dokumentation dokumentiert. Sie können diesen Abschnitt bearbeiten, um die Konfigurationen zu aktualisieren, die sich bereits in dieser Datei befinden, und zusätzliche Prometheus-Scraping-Ziele hinzufügen. Eine Beispielkonfigurationsdatei enthält die folgenden globalen Konfigurationszeilen:
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: MY_JOB
sample_limit: 10000
file_sd_configs:
- files: ["C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus_sd_1.yaml", "C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus_sd_2.yaml"]
```
Der Abschnitt `global` gibt Parameter an, die in allen Konfigurationskontexten gültig sind. Sie fungieren auch als Standardwerte für andere Konfigurationsabschnitte. Es enthält die folgenden Parameter:
+ `scrape_interval` – Definiert, wie oft das Scraping von zielen durchgeführt werden soll.
+ `scrape_timeout` – Definiert, wie lange gewartet werden soll, bis für eine Scrape-Anforderung eine Zeitüberschreitung eintritt.
`scrape_configs` gibt einen Satz von Zielen und Parametern an, mit denen festgelegt wird, wie sie das Scraping durchführen sollen. Es enthält die folgenden Parameter:
+ `job_name`— Der Auftragsname, der standardmäßig gescrapten Metriken zugewiesen ist.
+ `sample_limit` – Pro-Scrape-Limit für die Anzahl der Scraping-Proben, die akzeptiert werden.
+ `file_sd_configs` – Liste der Konfigurationen für die Dateiserviceerkennung. Es liest eine Reihe von Dateien, die eine Liste von null oder mehr statischen Konfigurationen enthalten. Der Abschnitt `file_sd_configs` enthält einen Parameter `files`, der Muster für Dateien definiert, aus denen Zielgruppen extrahiert werden.
Der CloudWatch Agent unterstützt die folgenden Service Discovery-Konfigurationstypen.
**`static_config`** Ermöglicht die Angabe einer Liste von Zielen und eines gemeinsamen Beschriftungssatzes für diese. Es ist der kanonische Weg, statische Ziele in einer Scrape-Konfiguration anzugeben.
Im Folgenden finden Sie eine statische Beispielkonfiguration, um Prometheus Metriken von einem lokalen Host zu scrapen. Metriken können auch von anderen Servern gescrapet werden, wenn der Prometheus-Port für den Server geöffnet ist, auf dem der Agent ausgeführt wird.
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus_sd_1.yaml
- targets:
- 127.0.0.1:9404
labels:
key1: value1
key2: value2
```
Dieses Beispiel enthält die folgenden Parameter:
+ `targets` – Die Ziele, die von der statischen Konfiguration gescrapet werden.
+ `labels` – Beschriftungen, die allen Metriken zugewiesen sind, die von den Zielen gescrapet werden.
**`ec2_sd_config`** Ermöglicht das Abrufen von Scrape-Zielen von Amazon-EC2-Instances. Im Folgenden finden Sie ein `ec2_sd_config`-Beispiel zum Scrapen von Prometheus-Metriken aus einer Liste von EC2-Instances. Die Prometheus-Ports dieser Instanzen müssen für den Server geöffnet werden, auf dem der CloudWatch Agent ausgeführt wird. Die IAM-Rolle für die EC2-Instance, auf der der CloudWatch Agent ausgeführt wird, muss die Berechtigung enthalten. `ec2:DescribeInstance` Sie könnten beispielsweise die verwaltete Richtlinie **Amazon** an die Instance anhängen EC2ReadOnlyAccess, auf der der CloudWatch Agent ausgeführt wird.
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: MY_JOB
sample_limit: 10000
ec2_sd_configs:
- region: us-east-1
port: 9404
filters:
- name: instance-id
values:
- i-98765432109876543
- i-12345678901234567
```
Dieses Beispiel enthält die folgenden Parameter:
+ `region`— Die AWS Region, in der sich die EC2-Zielinstanz befindet. Wenn Sie dieses Feld leer lassen, wird die Region aus den Instance-Metadaten verwendet.
+ `port` – Der Port, von dem Metriken gescrapet werden.
+ `filters` – Optionale Filter zum Filtern der Instanceliste. In diesem Beispiel werden Filter basierend auf der EC2-Instance gefiltert. IDs Weitere Kriterien, nach denen Sie filtern können, finden Sie unter [ DescribeInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html).
### CloudWatch Agentenkonfiguration für Prometheus
Die CloudWatch Agenten-Konfigurationsdatei enthält `prometheus` Abschnitte sowohl unter als auch`logs`. `metrics_collected` Es enthält die folgenden Parameter.
+ **Clustername** – Gibt den Clusternamen an, der als Bezeichnung im Protokollereignis hinzugefügt werden soll. Dies ist ein optionales Feld.
+ **log\$1group\$1name** – Gibt den Namen der Protokollgruppe für die Prometheus-Scrape-Metriken an.
+ **prometheus\$1config\$1path** – gibt den Pfad der Prometheus-Scrape-Konfigurationsdatei an.
+ **emf\$1processor** – Gibt die Prozessorkonfiguration im eingebetteten Metrikformat an. Weitere Hinweise zum eingebetteten Metrik-Format finden Sie unter [Einbetten von Metriken in Protokollen](CloudWatch_Embedded_Metric_Format.md).
Der Abschnitt `emf_processor` kann die folgenden Parameter enthalten:
+ **metric\$1declaration\$1dedup** – Wenn es auf „true“ gesetzt ist, wird die Deduplizierungsfunktion für die eingebetteten Metrikformatmetriken aktiviert.
+ **metric\$1namespace — Gibt den Metrik-Namespace** für die ausgegebenen Metriken an. CloudWatch
+ **metric\$1unit** – Gibt die Metrikname:Metrikeinheitszuordnung an. Hinweise zu unterstützten metrischen Einheiten finden Sie unter. [ MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)
+ **metric\$1declaration** – sind Abschnitte, die das Array von Protokollen mit eingebettetem Metrikformat angeben, das generiert werden soll. Für jede Prometheus-Quelle, aus der der CloudWatch Agent standardmäßig importiert, gibt es `metric_declaration` Abschnitte. Diese Abschnitte enthalten jeweils die folgenden Felder:
+ `source_labels` gibt den Wert der Beschriftungen an, die von der `label_matcher`-Zeile überprüft werden.
+ `label_matcher` ist ein regulärer Ausdruck, der den Wert der in `source_labels` aufgelisteten Beschriftungen überprüft. Die übereinstimmenden Metriken werden für die Aufnahme in das eingebettete Metrikformat aktiviert, an das gesendet wird. CloudWatch
+ `metric_selectors` ist ein regulärer Ausdruck, der die Metriken angibt, die erfasst und an CloudWatch gesendet werden sollen.
+ `dimensions` ist die Liste der Beschriftungen, die als CloudWatch-Dimensionen für jede ausgewählte Metrik verwendet werden sollen.
Im Folgenden finden Sie ein Beispiel für eine CloudWatch Agentenkonfiguration für Prometheus.
```
{
"logs":{
"metrics_collected":{
"prometheus":{
"cluster_name":"prometheus-cluster",
"log_group_name":"Prometheus",
"prometheus_config_path":"C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus.yaml",
"emf_processor":{
"metric_declaration_dedup":true,
"metric_namespace":"CWAgent-Prometheus",
"metric_unit":{
"jvm_threads_current": "Count",
"jvm_gc_collection_seconds_sum": "Milliseconds"
},
"metric_declaration":[
{
"source_labels":[
"job", "key2"
],
"label_matcher":"MY_JOB;^value2",
"dimensions":[
[
"key1", "key2"
],
[
"key2"
]
],
"metric_selectors":[
"^jvm_threads_current$",
"^jvm_gc_collection_seconds_sum$"
]
}
]
}
}
}
}
}
```
Im vorherigen Beispiel wird ein eingebetteter Metrikformatabschnitt konfiguriert, der als Protokollereignis gesendet wird, wenn die folgenden Bedingungen erfüllt sind:
+ Der Wert der Beschriftung `job` ist `MY_JOB`
+ Der Wert der Beschriftung `key2` ist `value2`
+ Die Prometheus-Metriken `jvm_threads_current` und `jvm_gc_collection_seconds_sum` enthalten sowohl `job`-als auch `key2`-Beschriftungen.
Das Protokollereignis, das gesendet wird, enthält den folgenden hervorgehobenen Abschnitt.
```
{
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Count",
"Name": "jvm_threads_current"
},
{
"Unit": "Milliseconds",
"Name": "jvm_gc_collection_seconds_sum"
}
],
"Dimensions": [
[
"key1",
"key2"
],
[
"key2"
]
],
"Namespace": "CWAgent-Prometheus"
}
],
"ClusterName": "prometheus-cluster",
"InstanceId": "i-0e45bd06f196096c8",
"Timestamp": "1607966368109",
"Version": "0",
"host": "EC2AMAZ-PDDOIUM",
"instance": "127.0.0.1:9404",
"jvm_threads_current": 2,
"jvm_gc_collection_seconds_sum": 0.006000000000000002,
"prom_metric_type": "gauge",
...
}
```
## Beispiel: Java/JMX Beispiel-Workloads für Prometheus-Metriktests einrichten
JMX Exporter ist ein offizieller Prometheus-Exporter, der JMX mBeans als Prometheus-Metriken erfassen und verfügbar machen kann. Weitere Informationen finden Sie unter [prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter).
Der CloudWatch Agent kann vordefinierte Prometheus-Metriken von Java Virtual Machine (JVM), Hjava und Tomcat (Catalina) von einem JMX-Exporter auf EC2-Instances sammeln.
### CloudWatch Schritt 1: Installieren Sie den Agenten
Der erste Schritt besteht darin, den CloudWatch Agenten auf der EC2-Instance zu installieren. Detaillierte Anweisungen finden Sie unter [Den CloudWatch Agenten installieren](install-CloudWatch-Agent-on-EC2-Instance.md).
### Schritt 2: Starten Sie den Workload Java/JMX
Der nächste Schritt besteht darin, den Java/JMX Workload zu starten.
Laden Sie zunächst die neueste JMX-Exporter-JAR-Datei vom folgenden Speicherort herunter: [prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter).
**Verwenden des .jar für Ihre Beispielanwendung**
Die Beispielbefehle in den folgenden Abschnitten verwenden `SampleJavaApplication-1.0-SNAPSHOT.jar` als JAR-Datei. Ersetzen Sie diese Teile der Befehle durch die JAR-Datei für Ihre Anwendung.
#### Vorbereiten der JMX-Exporter-Konfiguration
Die `config.yaml`-Datei ist die JMX-Exporter-Konfigurationsdatei. Weitere Informationen finden Sie unter [Konfiguration](https://github.com/prometheus/jmx_exporter#Configuration) in der JMX-Exporter-Dokumentation.
Hier ist eine Beispielkonfiguration für Java und Tomcat.
```
---
lowercaseOutputName: true
lowercaseOutputLabelNames: true
rules:
- pattern: 'java.lang<>(FreePhysicalMemorySize|TotalPhysicalMemorySize|FreeSwapSpaceSize|TotalSwapSpaceSize|SystemCpuLoad|ProcessCpuLoad|OpenFileDescriptorCount|AvailableProcessors)'
name: java_lang_OperatingSystem_$1
type: GAUGE
- pattern: 'java.lang<>(TotalStartedThreadCount|ThreadCount)'
name: java_lang_threading_$1
type: GAUGE
- pattern: 'Catalina<>(\w+)'
name: catalina_globalrequestprocessor_$3_total
labels:
port: "$2"
protocol: "$1"
help: Catalina global $3
type: COUNTER
- pattern: 'Catalina<>(requestCount|maxTime|processingTime|errorCount)'
name: catalina_servlet_$3_total
labels:
module: "$1"
servlet: "$2"
help: Catalina servlet $3 total
type: COUNTER
- pattern: 'Catalina<>(currentThreadCount|currentThreadsBusy|keepAliveCount|pollerThreadCount|connectionCount)'
name: catalina_threadpool_$3
labels:
port: "$2"
protocol: "$1"
help: Catalina threadpool $3
type: GAUGE
- pattern: 'Catalina<>(processingTime|sessionCounter|rejectedSessions|expiredSessions)'
name: catalina_session_$3_total
labels:
context: "$2"
host: "$1"
help: Catalina session $3 total
type: COUNTER
- pattern: ".*"
```
#### Starten Sie die Java-Anwendung mit dem Prometheus-Exporter
Starten der Beispielanwendung Dadurch werden Prometheus-Metriken an Port 9404 ausgegeben. Stellen Sie sicher, dass Sie den Einstiegspunkt `com.gubupt.sample.app.App` durch die richtigen Informationen für Ihre Java-Beispielanwendung ersetzen.
Geben Sie unter Linux den folgenden Befehl ein.
```
$ nohup java -javaagent:./jmx_prometheus_javaagent-0.14.0.jar=9404:./config.yaml -cp ./SampleJavaApplication-1.0-SNAPSHOT.jar com.gubupt.sample.app.App &
```
Geben Sie unter Windows den folgenden Befehl ein.
```
PS C:\> java -javaagent:.\jmx_prometheus_javaagent-0.14.0.jar=9404:.\config.yaml -cp .\SampleJavaApplication-1.0-SNAPSHOT.jar com.gubupt.sample.app.App
```
#### Überprüfen der Prometheus-Metriken
Stellen Sie sicher, dass Prometheus-Metriken ausgegeben werden.
Geben Sie unter Linux den folgenden Befehl ein.
```
$ curl localhost:9404
```
Geben Sie unter Windows den folgenden Befehl ein.
```
PS C:\> curl http://localhost:9404
```
Beispielausgabe unter Linux:
```
StatusCode : 200
StatusDescription : OK
Content : # HELP jvm_classes_loaded The number of classes that are currently loaded in the JVM
# TYPE jvm_classes_loaded gauge
jvm_classes_loaded 2526.0
# HELP jvm_classes_loaded_total The total number of class...
RawContent : HTTP/1.1 200 OK
Content-Length: 71908
Content-Type: text/plain; version=0.0.4; charset=utf-8
Date: Fri, 18 Dec 2020 16:38:10 GMT
# HELP jvm_classes_loaded The number of classes that are currentl...
Forms : {}
Headers : {[Content-Length, 71908], [Content-Type, text/plain; version=0.0.4; charset=utf-8], [Date, Fri, 18
Dec 2020 16:38:10 GMT]}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : System.__ComObject
RawContentLength : 71908
```
### Schritt 3: Den CloudWatch Agenten so konfigurieren, dass er Prometheus-Metriken scannt
Richten Sie als Nächstes die Prometheus-Scrape-Konfiguration in der CloudWatch Agentenkonfigurationsdatei ein.
**Um die Prometheus-Scrape-Konfiguration für das Beispiel einzurichten Java/JMX**
1. Richten Sie die Konfiguration für `file_sd_config`und `static_config` ein.
Geben Sie unter Linux den folgenden Befehl ein.
```
$ cat /opt/aws/amazon-cloudwatch-agent/var/prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: jmx
sample_limit: 10000
file_sd_configs:
- files: [ "/opt/aws/amazon-cloudwatch-agent/var/prometheus_file_sd.yaml" ]
```
Geben Sie unter Windows den folgenden Befehl ein.
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: jmx
sample_limit: 10000
file_sd_configs:
- files: [ "C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus_file_sd.yaml" ]
```
1. Richten Sie die Konfiguration der Scrape-Ziele ein.
Geben Sie unter Linux den folgenden Befehl ein.
```
$ cat /opt/aws/amazon-cloudwatch-agent/var/prometheus_file_sd.yaml
- targets:
- 127.0.0.1:9404
labels:
application: sample_java_app
os: linux
```
Geben Sie unter Windows den folgenden Befehl ein.
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus_file_sd.yaml
- targets:
- 127.0.0.1:9404
labels:
application: sample_java_app
os: windows
```
1. Richten Sie die Scrape-Konfiguration von Prometheus mit `ec2_sc_config` ein. Ersetzen Sie *your-ec2-instance-id* durch die richtige EC2-Instanz-ID.
Geben Sie unter Linux den folgenden Befehl ein.
```
$ cat .\prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: jmx
sample_limit: 10000
ec2_sd_configs:
- region: us-east-1
port: 9404
filters:
- name: instance-id
values:
- your-ec2-instance-id
```
Geben Sie unter Windows den folgenden Befehl ein.
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus_file_sd.yaml
- targets:
- 127.0.0.1:9404
labels:
application: sample_java_app
os: windows
```
1. Richten Sie die CloudWatch Agentenkonfiguration ein. Wechseln Sie zunächst in das richtige Verzeichnis. Unter Linux ist es `/opt/aws/amazon-cloudwatch-agent/var/cwagent-config.json`. Unter Windows ist es `C:\ProgramData\Amazon\AmazonCloudWatchAgent\cwagent-config.json`.
Im Folgenden finden Sie eine Beispielkonfiguration mit definierten Java/JHX Prometheus-Metriken. Achten Sie darauf, durch den richtigen Pfad zu *path-to-Prometheus-Scrape-Configuration-file* ersetzen.
```
{
"agent": {
"region": "us-east-1"
},
"logs": {
"metrics_collected": {
"prometheus": {
"cluster_name": "my-cluster",
"log_group_name": "prometheus-test",
"prometheus_config_path": "path-to-Prometheus-Scrape-Configuration-file",
"emf_processor": {
"metric_declaration_dedup": true,
"metric_namespace": "PrometheusTest",
"metric_unit":{
"jvm_threads_current": "Count",
"jvm_classes_loaded": "Count",
"java_lang_operatingsystem_freephysicalmemorysize": "Bytes",
"catalina_manager_activesessions": "Count",
"jvm_gc_collection_seconds_sum": "Seconds",
"catalina_globalrequestprocessor_bytesreceived": "Bytes",
"jvm_memory_bytes_used": "Bytes",
"jvm_memory_pool_bytes_used": "Bytes"
},
"metric_declaration": [
{
"source_labels": ["job"],
"label_matcher": "^jmx$",
"dimensions": [["instance"]],
"metric_selectors": [
"^jvm_threads_current$",
"^jvm_classes_loaded$",
"^java_lang_operatingsystem_freephysicalmemorysize$",
"^catalina_manager_activesessions$",
"^jvm_gc_collection_seconds_sum$",
"^catalina_globalrequestprocessor_bytesreceived$"
]
},
{
"source_labels": ["job"],
"label_matcher": "^jmx$",
"dimensions": [["area"]],
"metric_selectors": [
"^jvm_memory_bytes_used$"
]
},
{
"source_labels": ["job"],
"label_matcher": "^jmx$",
"dimensions": [["pool"]],
"metric_selectors": [
"^jvm_memory_pool_bytes_used$"
]
}
]
}
}
},
"force_flush_interval": 5
}
}
```
1. Starten Sie den CloudWatch Agenten neu, indem Sie einen der folgenden Befehle eingeben.
Geben Sie unter Linux den folgenden Befehl ein.
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/var/cwagent-config.json
```
Geben Sie unter Windows den folgenden Befehl ein.
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:C:\ProgramData\Amazon\AmazonCloudWatchAgent\cwagent-config.json
```
### Anzeigen der Prometheus-Metriken und Protokolle
Sie können jetzt die gesammelten Java/JMX Metriken einsehen.
**Um die Metriken für Ihren Java/JMX Beispiel-Workload anzuzeigen**
1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie in der Region, in der Ihr Cluster ausgeführt wird, im linken Navigationsbereich **Metriken** aus. Suchen Sie den **PrometheusTest**Namespace, um die Metriken zu sehen.
1. Um die CloudWatch Protokollereignisse anzuzeigen, wählen Sie im Navigationsbereich **Protokollgruppen** aus. Die Ereignisse befinden sich in der Protokollgruppe **prometheus-test**.
# Konfigurieren Sie CloudWatch Agentendienst- und Umgebungsnamen für verwandte Entitäten
Der CloudWatch Agent kann Metriken und Protokolle mit Entitätsdaten senden, um den [Themenbereich Erkunden](ExploreRelated.md) in der CloudWatch Konsole zu unterstützen. Der Dienstname oder der Umgebungsname kann in der [JSON-Konfiguration des CloudWatch Agenten](CloudWatch-Agent-Configuration-File-Details.md) konfiguriert werden.
**Anmerkung**
Die Agentenkonfiguration kann überschrieben werden. Einzelheiten dazu, wie der Agent entscheidet, welche Daten für verwandte Entitäten gesendet werden sollen, finden Sie unter [Verwenden des Agenten mit zugehöriger Telemetrie CloudWatch](CloudWatch-Agent-RelatedEntities.md).
Metriken können auf Agenten-, Metrik- oder Plug-in-Ebene konfiguriert werden. Protokolle können auf Agenten-, Protokoll- oder Dateiebene konfiguriert werden. Es wird immer die spezifischste Konfiguration verwendet. Wenn die Konfiguration beispielsweise auf Agentenebene und Metrikebene existiert, verwenden die Metriken die Metrikkonfiguration und alles andere (Protokolle) verwendet die Agentenkonfiguration. Das folgende Beispiel zeigt verschiedene Möglichkeiten, den Service- und Umgebungsnamen zu konfigurieren.
```
{
"agent": {
"service.name": "agent-level-service",
"deployment.environment": "agent-level-environment"
},
"metrics": {
"service.name": "metric-level-service",
"deployment.environment": "metric-level-environment",
"metrics_collected": {
"statsd": {
"service.name": "statsd-level-service",
"deployment.environment": "statsd-level-environment",
},
"collectd": {
"service.name": "collectdd-level-service",
"deployment.environment": "collectd-level-environment",
}
}
},
"logs": {
"service.name": "log-level-service",
"deployment.environment": "log-level-environment",
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log",
"log_stream_name": "amazon-cloudwatch-agent.log",
"service.name": "file-level-service",
"deployment.environment": "file-level-environment"
}
]
}
}
}
}
```
# Der CloudWatch Agent wird gestartet
Sie können den CloudWatch Agenten entweder mit Systems Manager Run Command oder der Befehlszeile starten.
Hinweise zum Einrichten des Agenten auf einem System, auf dem die erweiterte Sicherheit von Linux (SELinux) aktiviert ist, finden Sie unter. [Richten Sie den CloudWatch Agenten mit Linux mit verbesserter Sicherheit ein () SELinux](CloudWatch-Agent-SELinux.md)
## Starten Sie den CloudWatch Agenten über die Befehlszeile in Amazon EC2
Gehen Sie wie folgt vor, um den CloudWatch Agenten über die Befehlszeile auf Amazon EC2 zu starten.
Informationen zum Einrichten des Agenten auf einem System, auf dem das sicherheitserweiterte Linux (SELinux) aktiviert ist, finden Sie unter. [Richten Sie den CloudWatch Agenten mit Linux mit verbesserter Sicherheit ein () SELinux](CloudWatch-Agent-SELinux.md)
**So verwenden Sie die Befehlszeile, um den CloudWatch Agenten auf Amazon EC2 zu starten**
1. Kopieren Sie die gewünschte Agentenkonfigurationsdatei auf den Server, auf dem der Agent ausgeführt werden soll. Merken Sie sich den Pfadnamen, in den Sie die Datei kopiert haben.
1. Dieser Befehl `-a fetch-config` veranlasst den Agenten, die neueste Version der CloudWatch Agenten-Konfigurationsdatei zu laden, und `-s` startet den Agenten.
Geben Sie einen der folgenden Befehle ein. *configuration-file-path*Ersetzen Sie durch den Pfad zur Agenten-Konfigurationsdatei. Diese Datei heißt `config.json`, wenn Sie sie mit dem Assistenten erstellt haben, und `amazon-cloudwatch-agent.json`, wenn Sie sie manuell erstellt haben.
Geben Sie in einer EC2-Instance mit Linux den folgenden Befehl ein:
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
```
Geben Sie auf einem On-Premises-Server mit Linux Folgendes ein:
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c file:configuration-file-path
```
Geben Sie auf einer EC2-Instance, auf der Windows Server ausgeführt wird, Folgendes von der PowerShell Konsole aus ein:
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:configuration-file-path
```
Geben Sie auf einem lokalen Server, auf dem Windows Server ausgeführt wird, Folgendes von der PowerShell Konsole aus ein:
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m onPremise -s -c file:configuration-file-path
```
## Starten Sie den CloudWatch Agenten auf einem lokalen Server
Gehen Sie wie folgt vor, um den CloudWatch Agenten auf einem lokalen Server zu starten.
**Um den Agenten mit SSM CloudWatch Agent auf einem lokalen Server zu starten**
1. Öffnen Sie die Systems Manager Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
–oder–
Wenn die AWS Systems Manager Startseite geöffnet wird, scrollen Sie nach unten und wählen Sie **Explore Run Command**.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste der **Befehlsdokumente** die Schaltfläche neben **AmazonCloudWatch-** ausManageAgent.
1. Wählen Sie im Bereich **Targets** die Instance aus, auf der Sie den Agent installiert haben.
1. Klicken Sie in der Liste **Action** auf **Configure**.
1. Wählen Sie in der Liste **Mode** **onPremise**.
1. Geben Sie im Feld **Optional Configuration Location** (Optionaler Konfigurationsstandort) den Namen der Agentenkonfigurationsdatei ein, die Sie mit dem Assistenten erstellt und in Parameter Store gespeichert haben.
1. Klicken Sie auf **Ausführen**.
Der Agent beginnt mit der Konfiguration, die Sie in der Konfigurationsdatei angegeben haben.
**Um den CloudWatch Agenten über die Befehlszeile auf einem lokalen Server zu starten**
+ Dieser Befehl `-a fetch-config` veranlasst den Agenten, die neueste Version der CloudWatch Agenten-Konfigurationsdatei zu laden, und `-s` startet den Agenten.
Linux: Wenn Sie die Konfigurationsdatei in Systems Manager Parameter Store gespeichert haben, geben Sie Folgendes ein:
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c ssm:configuration-parameter-store-name
```
Linux: Wenn Sie die Konfigurationsdatei auf dem lokalen Computer gespeichert haben, geben Sie den folgenden Befehl ein: *configuration-file-path*Ersetzen Sie durch den Pfad zur Agenten-Konfigurationsdatei. Diese Datei heißt `config.json`, wenn Sie sie mit dem Assistenten erstellt haben, und `amazon-cloudwatch-agent.json`, wenn Sie sie manuell erstellt haben.
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c file:configuration-file-path
```
Windows Server: Wenn Sie die Agent-Konfigurationsdatei im Systems Manager Parameter Store gespeichert haben, geben Sie in der PowerShell Konsole Folgendes ein:
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m onPremise -s -c ssm:configuration-parameter-store-name
```
Windows Server: Wenn Sie die Agent-Konfigurationsdatei auf dem lokalen Computer gespeichert haben, geben Sie in der PowerShell Konsole Folgendes ein. *configuration-file-path*Ersetzen Sie es durch den Pfad zur Agenten-Konfigurationsdatei. Diese Datei heißt `config.json`, wenn Sie sie mit dem Assistenten erstellt haben, und `amazon-cloudwatch-agent.json`, wenn Sie sie manuell erstellt haben.
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m onPremise -s -c file:configuration-file-path
```
# Vom CloudWatch Agenten gesammelte Metriken
Sie können Messwerte von Servern sammeln, indem Sie den CloudWatch Agenten auf dem Server installieren. Sie können den Agenten auf Amazon-EC2-Instances oder On-Premises-Servern starten. Sie können den Agenten auch auf Computern installieren, die Linux, Windows Server oder macOS ausführen. Wenn Sie den Agenten auf einer Amazon-EC2-Instance installieren, werden die von ihm erfassten Metriken zusätzlich zu den Metriken erfasst, die auf Amazon-EC2-Instances standardmäßig aktiviert sind. Informationen zur Installation des CloudWatch Agenten auf einer Instanz finden Sie unter[Erfassen Sie Metriken, Logs und Traces mithilfe des CloudWatch Agenten](Install-CloudWatch-Agent.md). In diesem Abschnitt erfahren Sie mehr über die Metriken, die der CloudWatch Agent erfasst.
## Vom CloudWatch Agenten auf Windows Server-Instanzen gesammelte Metriken
Auf einem Server, auf dem Windows Server ausgeführt wird, können Sie durch die Installation des CloudWatch Agenten die Messwerte erfassen, die den Leistungsindikatoren im Windows-Leistungsmonitor zugeordnet sind. Die CloudWatch Messobjektnamen für diese Leistungsindikatoren werden erstellt, indem ein Leerzeichen zwischen dem Objektnamen und dem Leistungsindikatornamen eingefügt wird. Beispielsweise erhält der `% Interrupt Time`-Zähler des Objekts `Processor` in CloudWatch den Metriknamen `Processor % Interrupt Time`. Weitere Informationen zu Leistungsindikatoren der Windows-Leistungsüberwachung finden Sie in der Dokumentation von Microsoft Windows Server.
Der Standard-Namespace für vom CloudWatch Agenten gesammelte Metriken ist`CWAgent`, obwohl Sie bei der Konfiguration des Agenten einen anderen Namespace angeben können.
## Vom CloudWatch Agenten auf Linux- und macOS-Instances gesammelte Metriken
In der folgenden Tabelle sind die Metriken aufgeführt, die Sie mit dem CloudWatch Agenten auf Linux-Servern und macOS-Computern sammeln können.
| Metrik | Description |
| --- | --- |
| `cpu_time_active` | Die Zeit, für die die CPU auf beliebige Art und Weise aktiv ist. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_guest` | Die Zeit, für die die CPU eine virtuelle CPU für ein Gastbetriebssystem zur Verfügung stellt. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_guest_nice` | Die Zeitspanne, in der die CPU eine virtuelle CPU für ein Gastbetriebssystem betreibt, die niedrige Priorität hat und durch andere Prozesse unterbrochen werden kann. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_idle` | Die Zeit, für die sich die CPU im Leerlauf befindet. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_iowait` | Die Zeitspanne, in der die CPU auf den Abschluss von I/O Vorgängen wartet. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_irq` | Die Zeit, für die die CPU Unterbrechungen bedient. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_nice` | Die Zeitspanne, in der sich die CPU im Benutzermodus mit Prozessen mit niedriger Priorität befindet, die leicht durch Prozesse mit höherer Priorität unterbrochen werden können. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_softirq` | Die Zeit, für die die CPU Softwareunterbrechungen bedient. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_steal` | Die Zeit, für die sich die CPU in *gestohlener Zeit* befindet. Dies ist die Zeit, die in anderen Betriebssystemen in einer virtualisierten Umgebung verbracht wird. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_system` | Die Zeit, die die CPU im Systemmodus verbringt. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_time_user` | Die Zeit, die die CPU im Benutzermodus verbringt. Diese Metrik wird in Hundertstelsekunden gemessen. Einheit: keine |
| `cpu_usage_active` | Der Prozentsatz der Zeit, für die die CPU auf beliebige Art und Weise aktiv ist. Einheit: Prozent |
| `cpu_usage_guest` | Der Prozentanteil der Zeit, für die die CPU eine virtuelle CPU für ein Gastbetriebssystem zur Verfügung stellt. Einheit: Prozent |
| `cpu_usage_guest_nice` | Der Prozentsatz der Zeit, in der die CPU eine virtuelle CPU für ein Gastbetriebssystem betreibt, der niedrige Priorität hat und durch andere Prozesse unterbrochen werden kann. Einheit: Prozent |
| `cpu_usage_idle` | Der Prozentsatz der Zeit, die sich die CPU im Leerlauf befindet. Einheit: Prozent |
| `cpu_usage_iowait` | Der Prozentsatz der Zeit, in der die CPU auf den Abschluss von I/O Vorgängen wartet. Einheit: Prozent |
| `cpu_usage_irq` | Der Prozentanteil der Zeit, für die die CPU Unterbrechungen bedient. Einheit: Prozent |
| `cpu_usage_nice` | Der Anteil der Zeit, in der sich die CPU im Benutzermodus mit Prozessen mit niedriger Priorität befindet, die leicht durch Prozesse mit höherer Priorität unterbrochen werden können. Einheit: Prozent |
| `cpu_usage_softirq` | Der Prozentanteil der Zeit, für die die CPU Softwareunterbrechungen bedient. Einheit: Prozent |
| `cpu_usage_steal` | Der Anteil der Zeit, für den sich die CPU in *gestohlener Zeit* oder Zeit, die in anderen Betriebssystemen in einer virtualisierten Umgebung verbracht wird, befindet. Einheit: Prozent |
| `cpu_usage_system` | Der Prozentanteil der Zeit, die die CPU im Systemmodus verbringt. Einheit: Prozent |
| `cpu_usage_user` | Der Prozentanteil der Zeit, die die CPU im Benutzermodus verbringt. Einheit: Prozent |
| `disk_free` | Freier Speicherplatz auf den Festplatten. Einheit: Byte |
| `disk_inodes_free` | Die Anzahl der verfügbaren Index-Knoten auf der Festplatte. Einheit: Anzahl |
| `disk_inodes_total` | Die Gesamtanzahl der reservierten Index-Knoten auf der Festplatte. Einheit: Anzahl |
| `disk_inodes_used` | Die Anzahl der verwendeten Index-Knoten auf der Festplatte. Einheit: Anzahl |
| `disk_total` | Der Gesamtspeicherplatz auf den Festplatten, sowohl verwendet als auch frei. Einheit: Byte |
| `disk_used` | Verwendeter Speicherplatz auf den Festplatten. Einheit: Byte |
| `disk_used_percent` | Der Prozentanteil des verwendeten Gesamtspeicherplatzes. Einheit: Prozent |
| `diskio_iops_in_progress` | Die Anzahl der I/O Anfragen, die an den Gerätetreiber gesendet, aber noch nicht abgeschlossen wurden. Einheit: Anzahl |
| `diskio_io_time` | Der Zeitraum, in dem I/O Anfragen auf der Festplatte in die Warteschlange gestellt wurden. Einheit: Millisekunden Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `diskio_reads` | Die Anzahl der Festplattenlesevorgänge. Einheit: Anzahl Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `diskio_read_bytes` | Die Anzahl der von den Festplatten gelesenen Bytes. Einheit: Byte Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `diskio_read_time` | Die Zeit, für die Leseanforderungen auf den Festplatten gewartet haben. Mehrere gleichzeitig wartende Leseanforderungen erhöhen die Anzahl. Wenn beispielsweise 5 Anforderungen im Mittel 100 Millisekunden lang warten, wird 500 gemeldet. Einheit: Millisekunden Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `diskio_writes` | Die Anzahl der Festplattenschreibvorgänge. Einheit: Anzahl Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `diskio_write_bytes` | Anzahl der auf die Festplatten geschriebenen Bytes. Einheit: Byte Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `diskio_write_time` | Die Zeit, für die Schreibanforderungen auf den Festplatten gewartet haben. Mehrere gleichzeitig wartende Schreibanforderungen erhöhen die Anzahl. Wenn beispielsweise 8 Anforderungen im Mittel 1000 Millisekunden lang warten, wird 8000 gemeldet. Einheit: Millisekunden Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `ethtool_bw_in_allowance_exceeded` | Die Anzahl der Pakete, die in die Warteschlange gestellt and/or wurden, weil die Gesamtbandbreite für eingehende Nachrichten das Maximum für die Instanz überschritten hat. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](CloudWatch-Agent-network-performance.md). Einheit: keine |
| `ethtool_bw_out_allowance_exceeded` | Die Anzahl der Pakete, die in der Warteschlange and/or verworfen wurden, weil die Gesamtbandbreite für ausgehende Nachrichten das Maximum für die Instance überschritten hat. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](CloudWatch-Agent-network-performance.md). Einheit: keine |
| `ethtool_conntrack_allowance_exceeded` | Die Anzahl der verworfenen Pakete, weil die Verbindungsverfolgung das Maximum für die Instance überschritten hat und keine neuen Verbindungen hergestellt werden konnten. Dies kann zu einem Paketverlust für den Datenverkehr zur oder von der Instance führen. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](CloudWatch-Agent-network-performance.md). Einheit: keine |
| `ethtool_linklocal_allowance_exceeded` | Die Anzahl der verworfenen Pakete, weil das PPS des Datenverkehrs zu lokalen Proxy-Diensten das Maximum für die Netzwerkschnittstelle überschritten hat. Dies wirkt sich auf den Datenverkehr zum DNS-Dienst, zum Instance Metadata Service und zum Amazon Time Sync Service aus. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](CloudWatch-Agent-network-performance.md). Einheit: keine |
| `ethtool_pps_allowance_exceeded` | Die Anzahl der Pakete, die in die Warteschlange gestellt wurden and/or , weil das bidirektionale PPS das Maximum für die Instanz überschritten hat. Diese Metrik wird nur erfasst, wenn Sie sie im `ethtool` Unterabschnitt des `metrics_collected` Abschnitts der CloudWatch Agenten-Konfigurationsdatei aufgeführt haben. Weitere Informationen finden Sie unter [Netzwerkleistungsmetriken sammeln](CloudWatch-Agent-network-performance.md). Einheit: keine |
| `mem_active` | Die Speichermenge, die während des letzten Stichprobenzeitraums auf beliebige Art und Weise verwendet wurde. Einheit: Byte |
| `mem_available` | Die Speichermenge, die verfügbar ist und sofort Prozessen zugewiesen werden kann. Einheit: Byte |
| `mem_available_percent` | Der Prozentanteil des Speichers, der verfügbar ist und sofort Prozessen zugewiesen werden kann. Einheit: Prozent |
| `mem_buffered` | Die Speichermenge, die für Puffer verwendet wird. Einheit: Byte |
| `mem_cached` | Die Speichermenge, die für Datei-Caches verwendet wird. Einheit: Byte |
| `mem_free` | Die Speichermenge, die nicht verwendet wird. Einheit: Byte |
| `mem_inactive` | Die Speichermenge, die während des letzten Stichprobenzeitraums nicht verwendet wurde. Einheit: Byte |
| `mem_shared` | Die Menge an Arbeitsspeicher, die von Prozessen gemeinsam genutzt wird. Einheit: Byte |
| `mem_total` | Die Gesamtgröße des Speichers. Einheit: Byte |
| `mem_used` | Die derzeit verwendete Speichermenge. Einheit: Byte |
| `mem_used_percent` | Der derzeit verwendete Anteil des Speicherplatzes in Prozent. Einheit: Prozent |
| `net_bytes_recv` | Die Anzahl der von der Netzwerkschnittstelle empfangenen Bytes. Einheit: Byte Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `net_bytes_sent` | Die Anzahl der von der Netzwerkschnittstelle gesendeten Bytes. Einheit: Byte Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `net_drop_in` | Die Anzahl der von dieser Netzwerkschnittstelle empfangenen Pakete, die gelöscht wurden. Einheit: Anzahl Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `net_drop_out` | Die Anzahl der von dieser Netzwerkschnittstelle übertragenen Pakete, die gelöscht wurden. Einheit: Anzahl Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `net_err_in` | Die Anzahl der Empfangsfehler, die diese Netzwerkschnittstelle erkannt hat. Einheit: Anzahl Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `net_err_out` | Die Anzahl der Übertragungsfehler, die diese Netzwerkschnittstelle erkannt hat. Einheit: Anzahl Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `net_packets_sent` | Die Anzahl der von dieser Netzwerkschnittstelle gesendeten Pakete. Einheit: Anzahl Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `net_packets_recv` | Die Anzahl der von dieser Netzwerkschnittstelle empfangenen Pakete. Einheit: Anzahl Die einzige Statistik, die für diese Metrik verwendet werden sollte, ist `Sum`. Verwenden Sie nicht `Average`. |
| `netstat_tcp_close` | Die Anzahl der TCP-Verbindungen ohne Status. Einheit: Anzahl |
| `netstat_tcp_close_wait` | Die Anzahl der TCP-Verbindungen, die auf eine Beendigungsanforderung vom Client warten. Einheit: Anzahl |
| `netstat_tcp_closing` | Die Anzahl der TCP-Verbindungen, die auf eine Beendigungsanforderung mit Bestätigung vom Client warten. Einheit: Anzahl |
| `netstat_tcp_established` | Die Anzahl der eingerichteten TCP-Verbindungen. Einheit: Anzahl |
| `netstat_tcp_fin_wait1` | Die Anzahl der TCP-Verbindungen mit Status `FIN_WAIT1` während des Schließens einer Verbindung. Einheit: Anzahl |
| `netstat_tcp_fin_wait2` | Die Anzahl der TCP-Verbindungen mit Status `FIN_WAIT2` während des Schließens einer Verbindung. Einheit: Anzahl |
| `netstat_tcp_last_ack` | Die Anzahl der TCP-Verbindungen, die darauf warten, dass der Client die Nachricht über die Beendigung der Verbindung bestätigt. Dies ist der letzte Status, bevor die Verbindung geschlossen wird. Einheit: Anzahl |
| `netstat_tcp_listen` | Die Anzahl der TCP-Ports, die derzeit auf eine Verbindung warten. Einheit: Anzahl |
| `netstat_tcp_none` | Die Anzahl der TCP-Verbindungen mit inaktiven Clients. Einheit: Anzahl |
| `netstat_tcp_syn_sent` | Die Anzahl der TCP-Verbindungen, die nach dem Senden einer Verbindungsanforderung auf eine übereinstimmende Verbindungsanforderung warten. Einheit: Anzahl |
| `netstat_tcp_syn_recv` | Die Anzahl der TCP-Verbindungen, die nach dem Senden und Empfangen einer Verbindungsanforderung auf eine Anforderungsbestätigung warten. Einheit: Anzahl |
| `netstat_tcp_time_wait` | Die Anzahl der TCP-Verbindungen, die derzeit darauf warten, dass der Client die Bestätigung seiner Verbindungsabbauanforderung erhält. Einheit: Anzahl |
| `netstat_udp_socket` | Die Anzahl der aktuellen UDP-Verbindungen. Einheit: Anzahl |
| `processes_blocked` | Die Anzahl von blockierten Prozessen. Einheit: Anzahl |
| `processes_dead` | Die Anzahl der „toten“ Prozesse, die unter Linux den Statuscode `X` tragen. Diese Metrik wird auf macOS-Computern nicht erfasst. Einheit: Anzahl |
| `processes_idle` | Anzahl der Prozesse, die sich im Leerlauf befinden, für die also länger als 20 Sekunden keine Aktivitäten stattgefunden hat. Nur auf FreeBSD-Instances verfügbar. Einheit: Anzahl |
| `processes_paging` | Die Anzahl der ausgelagerten Prozesse, die unter Linux den Statuscode `W` tragen. Diese Metrik wird auf macOS-Computern nicht erfasst. Einheit: Anzahl |
| `processes_running` | Die Anzahl der laufenden Prozesse, angezeigt durch den Statuscode `R`. Einheit: Anzahl |
| `processes_sleeping` | Die Anzahl der Prozesse im Standby-Modus, angezeigt durch den Statuscode `S`. Einheit: Anzahl |
| `processes_stopped` | Die Anzahl der angehaltenen Prozesse, angezeigt durch den Statuscode `T`. Einheit: Anzahl |
| `processes_total` | Die Gesamtanzahl der Prozesse auf der Instance. Einheit: Anzahl |
| `processes_total_threads` | Die Gesamtanzahl der Threads der Prozesse. Diese Metrik ist nur für Linux-Instances verfügbar. Diese Metrik wird auf macOS-Computern nicht erfasst. Einheit: Anzahl |
| `processes_wait` | Die Anzahl der ausgelagerten Prozesse, die in FreeBSD-Instances den Statuscode `W` tragen. Diese Metrik ist nur auf FreeBSD-Instances und nicht auf Linux-, Windows Server- oder macOS-Instances verfügbar. Einheit: Anzahl |
| `processes_zombies` | Die Anzahl der Zombieprozesse, angezeigt durch Statuscode `Z`. Einheit: Anzahl |
| `swap_free` | Der Speicherplatz des Auslagerungsbereichs, der nicht verwendet wird. Einheit: Byte |
| `swap_used` | Der Speicherplatz des Auslagerungsbereichs, der derzeit verwendet wird. Einheit: Byte |
| `swap_used_percent` | Der Prozentanteil des Auslagerungsbereichs, der derzeit verwendet wird. Einheit: Prozent |
## Definitionen der vom CloudWatch Agenten gesammelten Speichermetriken
Wenn der CloudWatch Agent Speichermetriken sammelt, ist die Quelle das Speicherverwaltungs-Subsystem des Hosts. Zum Beispiel legt der Linux-Kernel die vom Betriebssystem verwalteten Daten in `/proc` offen. Was den Arbeitsspeicher betrifft, so befinden sich die Daten in `/proc/meminfo`.
Für jedes Betriebssystem und jede Architektur werden die Ressourcen, die von Prozessen verwendet werden, unterschiedlich berechnet. Weitere Informationen finden Sie in den folgenden Abschnitten.
Während jedes Erfassungsintervalls sammelt der CloudWatch Agent auf jeder Instanz die Instanzressourcen und berechnet die Ressourcen, die von allen Prozessen verwendet werden, die in dieser Instanz ausgeführt werden. Diese Informationen werden in CloudWatch Metriken zurückgemeldet. Sie können die Länge des Erfassungsintervalls in der CloudWatch Agent-Konfigurationsdatei konfigurieren. Weitere Informationen finden Sie unter [CloudWatch Agenten-Konfigurationsdatei: Abschnitt Agent](CloudWatch-Agent-Configuration-File-Details.md#CloudWatch-Agent-Configuration-File-Agentsection).
In der folgenden Liste wird erklärt, wie die Speichermetriken definiert sind, die der CloudWatch Agent erfasst.
+ **Aktiver Speicher** – Speicher, der von einem Prozess verwendet wird. Mit anderen Worten, der Speicher, der von aktuell laufenden Anwendungen verwendet wird.
+ **Verfügbarer Speicher** – Der Speicher, der den Prozessen sofort zur Verfügung gestellt werden kann, ohne dass das System in den Swap wechselt (auch als virtueller Speicher bezeichnet).
+ **Pufferspeicher** – Der Datenbereich, der von Hardwaregeräten oder Programmprozessen gemeinsam genutzt wird, die mit unterschiedlichen Geschwindigkeiten und Prioritäten arbeiten.
+ **Zwischenspeicher** – Speichert Programmanweisungen und Daten, die wiederholt bei der Ausführung von Programmen verwendet werden, die die CPU wahrscheinlich als Nächstes benötigt.
+ **Freier Speicher** – Speicher, der überhaupt nicht verwendet wird und sofort verfügbar ist. Es ist völlig kostenlos, dass das System bei Bedarf verwendet werden kann.
+ **Inaktiver Speicher** – Seiten, auf die „kürzlich“ nicht zugegriffen wurde.
+ **Gesamtspeicher** – Die Größe des tatsächlichen physischen RAM-Speichers.
+ **Verwendeter Speicher** – Speicher, der derzeit von Programmen und Prozessen verwendet wird.
**Topics**
+ [Linux: Gesammelte Metriken und verwendete Berechnungen](#CloudWatch-agent-metrics-definitions-calculations)
+ [macOS: Gesammelte Metriken und verwendete Berechnungen](#CloudWatch-agent-metrics-definitions-calculations)
+ [Windows: Gesammelte Metriken](#CloudWatch-agent-metrics-definitions-calculations)
+ [Beispiel: Berechnung von Speichermetriken auf Linux](#CloudWatch-agent-metrics-definitions-LinuxExample)
### Linux: Gesammelte Metriken und verwendete Berechnungen
Gesammelte Metriken und Einheiten:
+ Aktiv (Byte)
+ Verfügbar (Byte)
+ Verfügbarer Prozentsatz (Prozent)
+ Gepuffert (Byte)
+ Zwischengespeichert (Byte)
+ Kostenlos (Byte)
+ Inaktiv (Byte)
+ Gesamt (Byte)
+ Benutzt (Byte)
+ Verwendeter Prozentsatz (Prozent)
**Verwendeter Speicher** = Gesamtspeicher - Freier Speicher - Zwischenspeicher - Pufferspeicher
**Gesamtspeicher** = Verwendeter Speicher \$1 Freier Speicher \$1 Zwischenspeicher \$1 Pufferspeicher
### macOS: Gesammelte Metriken und verwendete Berechnungen
Gesammelte Metriken und Einheiten:
+ Aktiv (Byte)
+ Verfügbar (Byte)
+ Verfügbarer Prozentsatz (Prozent)
+ Kostenlos (Byte)
+ Inaktiv (Byte)
+ Gesamt (Byte)
+ Benutzt (Byte)
+ Verwendeter Prozentsatz (Prozent)
**Verfügbarer Speicher** = Freier Speicher \$1 Inaktiver Speicher
**Verwendeter Speicher** = Gesamtspeicher - Verfügbarer Speicher
**Gesamtspeicher** = Verfügbarer Speicher \$1 Verwendeter Speicher
### Windows: Gesammelte Metriken
Die auf Windows-Hosts erfassten Metriken sind unten aufgeführt. Alle diese Metriken haben `None` für `Unit`.
+ Verfügbare Byte
+ Cache-Fehler/Sekunde
+ Seitenfehler/Sekunde
+ Seiten/Sekunde
Für Windows-Metriken werden keine Berechnungen verwendet, da der CloudWatch Agent Ereignisse anhand von Leistungsindikatoren analysiert.
### Beispiel: Berechnung von Speichermetriken auf Linux
Nehmen wir als Beispiel an, dass die Eingabe des **cat /proc/meminfo**-Befehls auf einem Linux-Host zu folgenden Ergebnissen führt:
```
MemTotal: 3824388 kB
MemFree: 462704 kB
MemAvailable: 2157328 kB
Buffers: 126268 kB
Cached: 1560520 kB
SReclaimable: 289080 kB>
```
In diesem Beispiel erfasst der CloudWatch Agent die folgenden Werte. Alle Werte, die der CloudWatch Agent sammelt und meldet, sind in Byte angegeben.
+ `mem_total`: 3916173312 Byte
+ `mem_available`: 2209103872 Byte (\$1 zwischengespeichert) MemFree
+ `mem_free`: 473808896 Byte
+ `mem_cached`: 1893990400 Byte (`cached` \$1 `SReclaimable`
+ `mem_used`: 1419075584 Byte (`MemTotal` – (`MemFree` \$1 `Buffers` \$1 (`Cached` \$1 `SReclaimable`)))
+ `mem_buffered`: 129667072 Byte
+ `mem_available_percent`: 56,41 %
+ `mem_used_percent`: 36,24 % (`mem_used`/`mem_total`) \$1 100
# Verwenden des Agenten mit zugehöriger Telemetrie CloudWatch
Metriken und Protokolle, die an gesendet werden, CloudWatch können eine optionale Entität zur Korrelation der Telemetrie enthalten. Entitäten werden im Bereich [„Verwandte erkunden“](ExploreRelated.md) verwendet. Der CloudWatch Agent sendet Entitäten, in denen ein Dienstname und ein Umgebungsname enthalten sind.
Der Agent wählt den Servicenamen und den Umgebungsnamen aus den folgenden Daten aus.
**Name des Dienstes**
Der Agent wählt den Servicenamen in der Reihenfolge der Priorität aus den folgenden Optionen aus:
+ **Application Signals-Instrumentierung**: Der Agent sendet den von Application Signals verwendeten Servicenamen. Dies kann überschrieben werden, indem die `OTEL_SERVICE_NAME` Umgebungsvariable geändert wird, die von den unterstützten OpenTelemetry Instrumentierungsbibliotheken verwendet wird.
+ **CloudWatch Agentenkonfiguration** — Sie können [den Agenten so konfigurieren](CloudWatch-Agent-configure-related-telemetry.md), dass er einen bestimmten Dienstnamen verwendet. Dies kann auf Agent-, Plug-in-, Metrik-, Protokoll- oder Protokolldateiebene konfiguriert werden.
+ **Name des Kubernetes-Workloads**: Bei Kubernetes-Workloads sendet der Agent den Namen des Workloads für den entsprechenden Pod in der folgenden Prioritätsreihenfolge.
+ Name der Bereitstellung
+ ReplicaSet Name
+ StatefulSet Name
+ DaemonSet Name
+ CronJob Name
+ Job name (Auftragsname)
+ Pod-Name
+ Container-Name
+ **Ressourcen-Tags von Instance-Metadaten**: Für Amazon-EC2-Workloads sendet der Agent den Namen von Tags in der folgenden Reihenfolge.
+ Service nicht zulässig
+ Anwendung
+ App
Sie müssen [Instance-Metadaten einrichten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS), damit der Agent auf Tags zugreifen kann.
+ **Standard**: Wenn kein anderer Servicename gefunden wird, sendet der Agent den Namen `Unknown`.
**Name der Umgebung**
Der Agent wählt den Umgebungsnamen in der Reihenfolge der Priorität aus den folgenden Optionen aus:
+ **Application Signals-Instrumentierung**: Der Agent sendet den von Application Signals verwendeten Umgebungsnamen. Dies kann überschrieben werden, indem eine `deployment.environment` Umgebungsvariable gesetzt wird, die von unterstützten OpenTelemetry Instrumentierungsbibliotheken verwendet wird. Beispielsweise können Anwendungen die Umgebungsvariable `OTEL_RESOURCE_ATTRIBUTES=deployment.environment=MyEnvironment` festlegen.
+ **CloudWatch Agentenkonfiguration** — Sie können [den Agenten so konfigurieren](CloudWatch-Agent-configure-related-telemetry.md), dass er einen bestimmten Umgebungsnamen verwendet. Dies kann auf Agent-, Plug-in-, Metrik-, Protokoll- oder Protokolldateiebene konfiguriert werden.
+ **Clustername und Workspace**: Für Amazon EKS, `eks:cluster-name/Namespace`. Für natives Kubernetes, das auf Amazon EC2 ausgeführt wird, `k8s:cluster-name/Namespace`.
+ **Ressourcen-Tags von Instance-Metadaten**: Für Amazon-EC2-Workloads wird der Agent das Tag `AutoScalingGroup` verwenden.
Sie müssen [Instance-Metadaten einrichten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS), damit der Agent auf Tags zugreifen kann.
+ Standardmäßig erhalten Amazon-EC2-Instances, auf denen Kubernetes nicht ausgeführt wird, den Umgebungsnamen `ec2:default`.
# Allgemeine Szenarien mit dem CloudWatch Agenten
In diesem Abschnitt finden Sie verschiedene Szenarien, in denen beschrieben wird, wie allgemeine Konfigurations- und Anpassungsaufgaben für den CloudWatch Agenten ausgeführt werden.
**Topics**
+ [Den CloudWatch Agenten als anderer Benutzer ausführen](#CloudWatch-Agent-run-as-user)
+ [Wie der CloudWatch Agent mit spärlichen Protokolldateien umgeht](#CloudWatch-Agent-sparse-log-files)
+ [Hinzufügen benutzerdefinierter Dimensionen zu den vom Agenten gesammelten Metriken CloudWatch](#CloudWatch-Agent-adding-custom-dimensions)
+ [Aggregation oder Zusammenfassung der vom Agenten gesammelten Metriken CloudWatch](#CloudWatch-Agent-aggregating-metrics)
+ [Erfassung hochauflösender Metriken mit dem Agenten CloudWatch](#CloudWatch-Agent-collect-high-resolution-metrics)
+ [Metriken, Protokolle und Ablaufverfolgungen an ein anderes Konto senden](#CloudWatch-Agent-send-to-different-AWS-account)
+ [Zeitstempelunterschiede zwischen dem CloudWatch Agenten und dem früheren CloudWatch Logs-Agenten](#CloudWatch-Agent-logs-timestamp-differences)
+ [OpenTelemetry Collector-Konfigurationsdateien anhängen](#CloudWatch-Agent-appending-OpenTelemetry-config-files)
## Den CloudWatch Agenten als anderer Benutzer ausführen
Auf Linux-Servern CloudWatch wird der standardmäßig als Root-Benutzer ausgeführt. Damit der Agent unter einem anderen Benutzer ausgeführt wird, verwenden Sie den `run_as_user` Parameter im `agent` Abschnitt in der CloudWatch Agenten-Konfigurationsdatei. Diese Option ist nur auf Linux-Servern verfügbar.
Wenn Sie den Agenten bereits mit dem Root-Benutzer ausführen und zu einem anderen Benutzer wechseln möchten, gehen Sie wie folgt vor.
**Um den CloudWatch Agenten unter einem anderen Benutzer auf einer EC2-Instance unter Linux auszuführen**
1. Laden Sie ein neues CloudWatch Agentenpaket herunter und installieren Sie es.
1. Erstellen Sie einen neuen Linux-Benutzer oder verwenden Sie den Standardbenutzer `cwagent`, der die RPM- oder DEB-Datei erstellt hat.
1. Geben Sie auf eine der folgenden Arten Anmeldeinformationen für diesen Benutzer an:
+ Wenn die Datei im Home-Verzeichnis des Root-Benutzers `.aws/credentials` vorhanden ist, müssen Sie eine Anmeldeinformationsdatei für den Benutzer erstellen, mit dem Sie den CloudWatch Agenten ausführen möchten. Diese Datei mit den Anmeldeinformationen lautet `/home/username/.aws/credentials`. Setzen Sie dann den Wert des Parameters `shared_credential_file` in `common-config.toml` auf den Pfadnamen der Anmeldedatei. Weitere Informationen finden Sie unter [Installieren Sie den CloudWatch Agenten mit AWS Systems Manager](installing-cloudwatch-agent-ssm.md).
+ Wenn die Datei `.aws/credentials` nicht im Heim-Verzeichnis des Stammbenutzers vorhanden ist, können Sie einen der folgenden Schritte ausführen:
+ Erstellen Sie eine Anmeldeinformationen-Datei für den Benutzer, den Sie verwenden werden, um den CloudWatch-Agenten auszuführen. Diese Datei mit den Anmeldeinformationen lautet `/home/username/.aws/credentials`. Setzen Sie dann den Wert des Parameters `shared_credential_file` in `common-config.toml` auf den Pfadnamen der Anmeldedatei. Weitere Informationen finden Sie unter [Installieren Sie den CloudWatch Agenten mit AWS Systems Manager](installing-cloudwatch-agent-ssm.md).
+ Anstatt eine Datei mit Anmeldeinformationen zu erstellen, fügen Sie der Instance eine IAM-Rolle hinzu. Der Agent verwendet diese Rolle als Anmeldeprovider.
1. Fügen Sie in der CloudWatch Agent-Konfigurationsdatei im `agent` Abschnitt die folgende Zeile hinzu:
```
"run_as_user": "username"
```
Nehmen Sie bei Bedarf weitere Änderungen an der Konfigurationsdatei vor. Weitere Informationen finden Sie unter [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md).
1. Erteilen Sie dem Benutzer die erforderlichen Berechtigungen. Der Benutzer muss über Lese-(r)-Berechtigungen für die zu erfassenden Protokolldateien und über Execute-(x)-Berechtigung für jedes Verzeichnis im Pfad der Protokolldateien verfügen.
1. Starten Sie den Agenten mit der Konfigurationsdatei, die Sie gerade geändert haben.
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
```
**Um den CloudWatch Agenten unter einem anderen Benutzer auf einem lokalen Server unter Linux auszuführen**
1. Laden Sie ein neues CloudWatch Agentenpaket herunter und installieren Sie es.
1. Erstellen Sie einen neuen Linux-Benutzer oder verwenden Sie den Standardbenutzer `cwagent`, der die RPM- oder DEB-Datei erstellt hat.
1. Speichern Sie die Anmeldeinformationen dieses Benutzers in einem Pfad, auf den der Benutzer zugreifen kann, z. B. `/home/username/.aws/credentials`.
1. Setzen Sie den Wert des Parameters `shared_credential_file` in `common-config.toml` auf den Pfadnamen der Anmeldedatei. Weitere Informationen finden Sie unter [Installieren Sie den CloudWatch Agenten mit AWS Systems Manager](installing-cloudwatch-agent-ssm.md).
1. Fügen Sie in der CloudWatch Agent-Konfigurationsdatei die folgende Zeile in den `agent` Abschnitt ein:
```
"run_as_user": "username"
```
Nehmen Sie bei Bedarf weitere Änderungen an der Konfigurationsdatei vor. Weitere Informationen finden Sie unter [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md).
1. Erteilen Sie dem Benutzer erforderliche Berechtigungen. Der Benutzer muss über Lese-(r)-Berechtigungen für die zu erfassenden Protokolldateien und über Execute-(x)-Berechtigung für jedes Verzeichnis im Pfad der Protokolldateien verfügen.
1. Starten Sie den Agenten mit der Konfigurationsdatei, die Sie gerade geändert haben.
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
```
## Wie der CloudWatch Agent mit spärlichen Protokolldateien umgeht
Sparse-Dateien sind Dateien mit leeren Blöcken und echten Inhalten. Eine Sparse-Datei verwendet Speicherplatz effizienter, indem anstelle der tatsächlichen Null-Bytes, aus denen der Block besteht, kurze Informationen, die die leeren Blöcke darstellen, auf die Festplatte geschrieben werden. Dadurch wird die tatsächliche Größe einer Sparse-Datei in der Regel viel kleiner als die scheinbare Größe.
Der CloudWatch Agent behandelt Dateien mit geringer Dichte jedoch nicht anders als normale Dateien. Wenn der Agent eine Sparse-Datei liest, werden die leeren Blöcke als „echte“ Blöcke behandelt, die mit Null-Bytes gefüllt sind. Aus diesem Grund veröffentlicht der CloudWatch Agent so viele Byte, wie die scheinbare Größe einer Datei mit geringer Dichte entspricht. CloudWatch
Wenn der CloudWatch Agent so konfiguriert wird, dass er eine Datei mit geringer Dichte veröffentlicht, kann dies zu höheren CloudWatch Kosten als erwartet führen. Wir empfehlen daher, dies nicht zu tun. Beispielsweise handelt es `/var/logs/lastlog` sich unter Linux normalerweise um eine Datei mit sehr geringer Dichte, und wir empfehlen, sie nicht in zu veröffentlichen. CloudWatch
## Hinzufügen benutzerdefinierter Dimensionen zu den vom Agenten gesammelten Metriken CloudWatch
Um benutzerdefinierte Dimensionen wie Tags zu Metriken hinzuzufügen, die vom Agent erfasst werden, fügen Sie das Feld `append_dimensions` dem Abschnitt der Agent-Konfigurationsdatei hinzu, in dem diese Metriken aufgelistet sind.
Beispiel: Der folgende Beispielabschnitt der Konfigurationsdatei fügt eine benutzerdefinierte Dimension mit dem Namen `stackName` und dem Wert `Prod` zu den vom Agenten gesammelten Metriken `cpu` und `disk` hinzu.
```
"cpu":{
"resources":[
"*"
],
"measurement":[
"cpu_usage_guest",
"cpu_usage_nice",
"cpu_usage_idle"
],
"totalcpu":false,
"append_dimensions":{
"stackName":"Prod"
}
},
"disk":{
"resources":[
"/",
"/tmp"
],
"measurement":[
"total",
"used"
],
"append_dimensions":{
"stackName":"Prod"
}
}
```
Beachten Sie, dass Sie den Agenten bei jeder Änderung der Agentenkonfigurationsdatei neu starten müssen, damit die Änderungen wirksam werden.
## Aggregation oder Zusammenfassung der vom Agenten gesammelten Metriken CloudWatch
Um vom Agenten erfasste Metriken zu aggregieren oder zusammenzufassen, fügen Sie im Abschnitt für die betreffende Metrik in der Agentenkonfigurationsdatei das Feld `aggregation_dimensions` hinzu.
Beispielsweise fasst der folgende Abschnitt der Konfigurationsdatei Metriken in der `AutoScalingGroupName`-Dimension zusammen. Die Metriken aus allen Instances in der jeweiligen Auto-Scaling-Gruppe werden aggregiert und können als Ganzes angezeigt werden.
```
"metrics": {
"cpu":{...}
"disk":{...}
"aggregation_dimensions" : [["AutoScalingGroupName"]]
}
```
Wenn Sie zusätzlich zum Zusammenfassen im Auto-Scaling-Gruppennamen auch die Kombination der einzelnen `InstanceId`- und `InstanceType`-Dimensionen zusammenfassen möchten, können Sie Folgendes hinzufügen.
```
"metrics": {
"cpu":{...}
"disk":{...}
"aggregation_dimensions" : [["AutoScalingGroupName"], ["InstanceId", "InstanceType"]]
}
```
Wenn Sie stattdessen Metriken in einer Sammlung zusammenfassen möchten, verwenden Sie `[]`.
```
"metrics": {
"cpu":{...}
"disk":{...}
"aggregation_dimensions" : [[]]
}
```
Beachten Sie, dass Sie den Agenten bei jeder Änderung der Agentenkonfigurationsdatei neu starten müssen, damit die Änderungen wirksam werden.
## Erfassung hochauflösender Metriken mit dem Agenten CloudWatch
Das `metrics_collection_interval`-Feld gibt das Zeitintervall für die erfassten Metriken in Sekunden an. Durch Angabe eines Werts von weniger als 60 für dieses Feld werden die Metriken als hochauflösende Metriken erfasst.
Beispiel: Wenn Sie möchten, dass alle Ihre Metriken hochauflösend sind und alle 10 Sekunden erfasst werden, geben Sie als Wert für `metrics_collection_interval` im Abschnitt `agent` „10“ als Intervall für die globale Erfassung von Metriken an.
```
"agent": {
"metrics_collection_interval": 10
}
```
Alternativ wird im folgenden Beispiel festgelegt, dass die `cpu`-Metriken jede Sekunde erfasst werden, während andere Metriken jede Minute erfasst werden.
```
"agent":{
"metrics_collection_interval": 60
},
"metrics":{
"metrics_collected":{
"cpu":{
"resources":[
"*"
],
"measurement":[
"cpu_usage_guest"
],
"totalcpu":false,
"metrics_collection_interval": 1
},
"disk":{
"resources":[
"/",
"/tmp"
],
"measurement":[
"total",
"used"
]
}
}
}
```
Beachten Sie, dass Sie den Agenten bei jeder Änderung der Agentenkonfigurationsdatei neu starten müssen, damit die Änderungen wirksam werden.
## Metriken, Protokolle und Ablaufverfolgungen an ein anderes Konto senden
Damit der CloudWatch Agent die Metriken, Logs oder Traces an ein anderes Konto sendet, geben Sie einen `role_arn` Parameter in der Agenten-Konfigurationsdatei auf dem sendenden Server an. Der `role_arn`-Wert legt eine IAM-Rolle im Zielkonto fest, die der Agent beim Senden von Daten an das Zielkonto verwendet. Diese Rolle ermöglicht dem sendenden Konto, eine entsprechende Rolle im Zielkonto anzunehmen, wenn die Metriken oder Protokolle für das Zielkonto bereitgestellt werden.
Sie können in der Konfigurationsdatei des Agenten auch separate `role_arn`-Zeichenfolgen angeben: eine für das Senden von Metriken, eine für das Senden von Protokollen und eine für das Senden von Ablaufverfolgungen.
Das folgende Beispiel für einen Teil des `agent`-Abschnitts in der Konfigurationsdatei legt fest, dass der Agent `CrossAccountAgentRole` verwendet, wenn er Daten an ein anderes Konto sendet.
```
{
"agent": {
"credentials": {
"role_arn": "arn:aws:iam::123456789012:role/CrossAccountAgentRole"
}
},
.....
}
```
Alternativ dazu können Sie im folgenden Beispiel verschiedene Rollen für das sendende Konto festlegen, um Metriken, Protokolle und Ablaufverfolgungen zu senden:
```
"metrics": {
"credentials": {
"role_arn": "RoleToSendMetrics"
},
"metrics_collected": {....
```
```
"logs": {
"credentials": {
"role_arn": "RoleToSendLogs"
},
....
```
**Erforderliche Richtlinien**
Wenn Sie in der Agenten-Konfigurationsdatei einen Wert für `role_arn` festlegen, müssen Sie auch sicherstellen, dass die IAM-Rollen des sendenden Kontos und des Zielkontos über bestimmte Richtlinien verfügen. In den Rollen sowohl im sendenden als auch im Zielkonto muss `CloudWatchAgentServerPolicy` enthalten sein. Weitere Informationen zum Zuweisen dieser Richtlinie zu einer Rolle finden Sie unter [Voraussetzungen](prerequisites.md).
Die Rolle im sendenden Konto muss außerdem die folgende Richtlinie enthalten. Sie fügen diese Richtlinie auf der Registerkarte **Permissions** (Berechtigungen) in der IAM-Konsole hinzu, wenn Sie die Rolle bearbeiten.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/agent-role-in-target-account"
]
}
]
}
```
------
Die Rolle im Zielkonto muss die folgende Richtlinie enthalten, damit es die vom sendenden Konto verwendete IAM-Rolle erkennen kann. Sie fügen diese Richtlinie auf der Registerkarte **Trust relationships (Vertrauensstellungen)** in der IAM-Konsole hinzu, wenn Sie die Rolle bearbeiten. Dabei handelt es sich um die Rolle, die Sie unter `agent-role-in-target-account` in der Richtlinie angegebenen haben, die vom sendenden Konto verwendet wird.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/role-in-sender-account"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
## Zeitstempelunterschiede zwischen dem CloudWatch Agenten und dem früheren CloudWatch Logs-Agenten
Der CloudWatch Agent unterstützt im Vergleich zum früheren CloudWatch Logs-Agent einen anderen Satz von Symbolen für Zeitstempelformate. Diese Unterschiede sind in der folgenden Tabelle aufgeführt.
| Von beiden Agenten unterstützte Symbole | Symbole, die nur vom Agenten unterstützt werden CloudWatch | Symbole, die nur von früheren CloudWatch Logs-Agenten unterstützt wurden |
| --- | --- | --- |
| %A, %a, %b, %B, %d, %f, %H, %l, %m, %M, %p, %S, %y, %Y, %Z, %z | %-d, %-l, %-m, %-M, %-S | %c,%j, %U, %W, %w |
Weitere Informationen zu den Bedeutungen der vom neuen CloudWatch Agenten unterstützten Symbole finden Sie unter [ CloudWatch Agenten-Konfigurationsdatei: Abschnitt Protokolle](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Logssection) im * CloudWatch Amazon-Benutzerhandbuch*. Informationen zu den vom CloudWatch Logs-Agenten unterstützten Symbolen finden Sie in der [Agent-Konfigurationsdatei](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html#agent-configuration-file) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
## OpenTelemetry Collector-Konfigurationsdateien anhängen
Der CloudWatch Agent unterstützt neben seinen eigenen Konfigurationsdateien auch zusätzliche OpenTelemetry Collector-Konfigurationsdateien. Mit dieser Funktion können Sie CloudWatch Agentenfunktionen wie CloudWatch Application Signals oder Container Insights über die CloudWatch Agentenkonfiguration nutzen und Ihre bestehende OpenTelemetry Collector-Konfiguration mit einem einzigen Agenten integrieren.
Um Zusammenführungskonflikte mit automatisch vom CloudWatch Agenten erstellten Pipelines zu vermeiden, empfehlen wir, dass Sie jeder Komponente und Pipelines in Ihrer OpenTelemetry Collector-Konfiguration ein benutzerdefiniertes Suffix hinzufügen.
```
receivers:
otlp/custom-suffix:
protocols:
http:
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
```
Um den CloudWatch Agenten zu konfigurieren, starten Sie den CloudWatch Agenten mit der `fetch-config` Option und geben Sie die Konfigurationsdatei des CloudWatch Agenten an. CloudWatch Der Agent benötigt mindestens eine CloudWatch Agenten-Konfigurationsdatei.
```
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -c file:/tmp/agent.json -s
```
Verwenden Sie als Nächstes die `append-config` Option bei der Angabe der OpenTelemetry Collector-Konfigurationsdatei.
```
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -c file:/tmp/otel.yaml -s
```
Der Agent führt die beiden Konfigurationsdateien beim Start zusammen und protokolliert die endgültige Konfiguration.
# CloudWatch Präferenz für Agenten-Anmeldeinformationen
In diesem Abschnitt wird die Anbieterkette für Anmeldeinformationen beschrieben, die der CloudWatch Agent verwendet, um Anmeldeinformationen zu erhalten, wenn er mit anderen AWS Diensten kommuniziert und APIs. Die Reihenfolge ist wie folgt:
**Anmerkung**
Die in den Ziffern zwei bis fünf aufgeführten Einstellungen entsprechen der im AWS SDK definierten Reihenfolge. Weitere Informationen finden Sie unter [Angeben von Anmeldeinformationen](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) in der SDK-Dokumentation.
1. Gemeinsam genutzte Konfigurations- und Anmeldeinformationsdateien, wie sie in der CloudWatch `common-config.toml` Agentendatei definiert sind. Weitere Informationen finden Sie unter [Installieren Sie den CloudWatch Agenten mit AWS Systems Manager](installing-cloudwatch-agent-ssm.md).
1. AWS SDK-Umgebungsvariablen
**Wichtig**
Wenn Sie unter Linux den CloudWatch Agenten mithilfe des `amazon-cloudwatch-agent-ctl` Skripts ausführen, startet das Skript den Agenten als `systemd` Dienst. In diesem Fall kann der Agent nicht auf Umgebungsvariablen wie `HOME`, `AWS_ACCESS_KEY_ID` und `AWS_SECRET_ACCESS_KEY` zugreifen.
1. Gemeinsame Konfigurations- und Anmeldeinformationen finden Sie in `$HOME/%USERPROFILE%`
**Anmerkung**
Der CloudWatch Agent sucht nach `.aws/credentials` in `$HOME` für Linux und macOS und sucht `%USERPROFILE%` nach Windows. Im Gegensatz zum AWS SDK verfügt der CloudWatch Agent nicht über Fallback-Methoden, um das Home-Verzeichnis zu ermitteln, falls auf die Umgebungsvariablen nicht zugegriffen werden kann. Dieser Unterschied im Verhalten besteht darin, die Abwärtskompatibilität mit früheren Implementierungen des SDK aufrechtzuerhalten. AWS
Wenn die vom AWS SDK abgeleiteten gemeinsamen Anmeldeinformationen ablaufen und rotiert werden`common-config.toml`, werden die erneuerten Anmeldeinformationen im Gegensatz zu den gemeinsamen Anmeldeinformationen in außerdem nicht automatisch vom CloudWatch Agenten übernommen und erfordern dazu einen Neustart des Agenten.
1. Eine AWS Identity and Access Management Rolle für Aufgaben, wenn eine Anwendung vorhanden ist, die eine Amazon Elastic Container Service-Aufgabendefinition oder eine RunTask API-Operation verwendet.
1. Ein einer Amazon EC2-Instance hinzugefügtes Instance-Profil.
Als bewährte Methode empfehlen wir, dass Sie die Anmeldeinformationen in der folgenden Reihenfolge angeben, wenn Sie den CloudWatch Agenten verwenden.
1. Verwenden Sie IAM-Rollen für Aufgaben, wenn Ihre Anwendung eine Amazon Elastic Container Service-Aufgabendefinition oder eine RunTask API-Operation verwendet.
1. Verwenden Sie IAM-Rollen, wenn Ihre Anwendung auf einer Amazon-EC2-Instance ausgeführt wird.
1. Verwenden Sie die CloudWatch `common-config.toml` Agent-Datei, um die Anmeldeinformationsdatei anzugeben. Bei dieser Anmeldeinformationsdatei handelt es sich um dieselbe, die von other AWS SDKs und der verwendet wird AWS CLI. Wenn Sie bereits eine freigegebene Anmeldeinformationsdatei verwenden, können Sie diese Datei auch für diesen Zweck verwenden. Wenn Sie sie mithilfe der CloudWatch `common-config.toml` Agentendatei bereitstellen, stellen Sie sicher, dass der Agent die Anmeldeinformationen nach deren Ablauf rotiert und ersetzt, ohne dass Sie den Agenten neu starten müssen.
1. Umgebungsvariablen verwenden. Das Festlegen von Umgebungsvariablen ist dann sinnvoll, wenn Sie auf einem anderen Computer als einer Amazon-EC2-Instance entwickeln.
**Anmerkung**
Wenn Sie Telemetriedaten an ein anderes Konto senden, wie unter beschrieben[Metriken, Protokolle und Ablaufverfolgungen an ein anderes Konto senden](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account), verwendet der CloudWatch Agent die in diesem Abschnitt beschriebene Anbieterkette für Anmeldeinformationen, um die ersten Anmeldeinformationen abzurufen. Anschließend verwendet er diese Anmeldeinformationen, wenn er die `role_arn` in der CloudWatch Agentenkonfigurationsdatei angegebene IAM-Rolle annimmt.
# Fehlerbehebung beim Agenten CloudWatch
Sie können die Informationen in diesem Abschnitt verwenden, um Probleme zu beheben, die möglicherweise mit dem CloudWatch Agenten auftreten.
Wenn Sie auf Probleme mit dem CloudWatch Agenten stoßen, können Sie das `AWSSupport-TroubleshootCloudWatchAgent` Automatisierungs-Runbook verwenden. Das AWS -Tool zur Fehlerbehebung kann:
+ IAM-Berechtigungen und Instance-Profile prüfen
+ den Agentenstatus prüfen und Protokolle analysieren
+ die Konnektivität des VPC-Endpunkts testen
+ relevante Protokolle automatisch erfassen und in Amazon S3 hochladen
Ausführliche Informationen zum Tool zur AWS Problembehandlung finden Sie unter [Support Automation Workflow (SAW) Runbook — CloudWatch Troubleshooting-Agent](https://repost.aws/articles/ARDFhNRgSMRcahrIbGJaIC4g/support-automation-workflow-saw-runbook-troubleshoot-amazon-cloudwatch-agent).
**Topics**
+ [CloudWatch Befehlszeilenparameter für den Agenten](#CloudWatch-Agent-options-help)
+ [Die Installation des CloudWatch Agenten mithilfe von Run Command schlägt fehl](#CloudWatch-Agent-installation-fails)
+ [Der Agent lässt sich nicht starten CloudWatch](#CloudWatch-Agent-troubleshooting-cannot-start)
+ [Stellen Sie sicher, dass der CloudWatch Agent läuft](#CloudWatch-Agent-troubleshooting-verify-running)
+ [Der CloudWatch Agent startet nicht und der Fehler erwähnt eine Amazon EC2 EC2-Region](#CloudWatch-Agent-troubleshooting-EC2-region)
+ [Der CloudWatch Agent wird auf Windows Server nicht gestartet](#CloudWatch-Agent-troubleshooting-Windows-start)
+ [Wo sind die Metriken?](#CloudWatch-Agent-troubleshooting-no-metrics)
+ [Es dauert lange, bis der CloudWatch Agent in einem Container ausgeführt wird, oder es wird ein Hop-Limit-Fehler protokolliert](#CloudWatch-Agent-container-slow)
+ [Ich habe meine Agentenkonfiguration aktualisiert, sehe aber die neuen Metriken oder Logs nicht in der CloudWatch Konsole](#CloudWatch-Agent-troubleshooting-update-no-new-metrics)
+ [CloudWatch Agentendateien und Speicherorte](#CloudWatch-Agent-files-and-locations)
+ [Suchen Sie nach Informationen zu CloudWatch Agentenversionen](#CloudWatch-Agent-troubleshooting-agent-version)
+ [Vom CloudWatch Agenten generierte Protokolle](#CloudWatch-Agent-troubleshooting-loginfo)
+ [Den Agenten stoppen und neu starten CloudWatch](#CloudWatch-Agent-troubleshooting-stopping-restarting)
## CloudWatch Befehlszeilenparameter für den Agenten
Um die vollständige Liste der vom CloudWatch Agenten unterstützten Parameter zu sehen, geben Sie in der Befehlszeile des Computers, auf dem der Agent installiert ist, Folgendes ein:
```
amazon-cloudwatch-agent-ctl -help
```
## Die Installation des CloudWatch Agenten mithilfe von Run Command schlägt fehl
Um den CloudWatch Agenten mit Systems Manager Run Command zu installieren, muss der SSM-Agent auf dem Zielserver Version 2.2.93.0 oder höher des SSM-Agenten sein. Wenn Ihr SSM Agent nicht die richtige Version aufweist, werden möglicherweise Fehler mit den folgenden Meldungen angezeigt:
```
no latest version found for package AmazonCloudWatchAgent on platform linux
```
```
failed to download installation package reliably
```
Informationen über das Installieren oder Aktualisieren der SSM-Agent-Version finden Sie unter [Installieren und Konfigurieren des SSM-Agents](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) in *AWS Systems Manager -Benutzerhandbuch*.
## Der Agent lässt sich nicht starten CloudWatch
Wenn der CloudWatch Agent nicht gestartet werden kann, liegt möglicherweise ein Problem in Ihrer Konfiguration vor. Konfigurationsinformationen werden in die Datei `configuration-validation.log` geschrieben. Diese Datei befindet sich auf Linux-Servern unter `/opt/aws/amazon-cloudwatch-agent/logs/configuration-validation.log` und auf Servern mit Windows Server unter `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\configuration-validation.log`.
## Stellen Sie sicher, dass der CloudWatch Agent läuft
Sie können den CloudWatch Agenten abfragen, um herauszufinden, ob er läuft oder gestoppt wurde. Sie können AWS Systems Manager verwenden, um dies fernbedient zu erledigen. Sie können auch die Befehlszeile verwenden, aber damit nur den lokalen Server überprüfen.
**Um den Status des CloudWatch Agenten mit Run Command abzufragen**
1. Öffnen Sie die Systems Manager Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
–oder–
Wenn die AWS Systems Manager Startseite geöffnet wird, scrollen Sie nach unten und wählen Sie **Explore Run Command**.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste der **Befehlsdokumente** die Schaltfläche neben **AmazonCloudWatch-** ausManageAgent.
1. Klicken Sie in der Liste **Action** auf **Status**.
1. Wählen Sie für **Optional Configuration Source (Optionale Konfigurationsquelle)** den **Standardwert** aus und lassen Sie **Optional Configuration Location (Optionaler Konfigurationsstandort)** leer.
1. Wählen Sie im Bereich **Target** die Instance, die Sie prüfen möchten.
1. Klicken Sie auf **Ausführen**.
Wenn der Agent ausgeführt wird, sieht die Ausgabe etwa folgendermaßen aus.
```
{
"status": "running",
"starttime": "2017-12-12T18:41:18",
"version": "1.73.4"
}
```
Wenn der Agent angehalten ist, wird im Feld `"status"` `"stopped"` angezeigt.
**Um den Status des CloudWatch Agenten lokal über die Befehlszeile abzufragen**
+ Geben Sie auf einem Linux-Server Folgendes ein:
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
```
Geben Sie auf einem Server, auf dem Windows Server ausgeführt wird, PowerShell als Administrator Folgendes ein:
```
& $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a status
```
## Der CloudWatch Agent startet nicht und der Fehler erwähnt eine Amazon EC2 EC2-Region
Wenn der Agent nicht startet und die Fehlermeldung einen Endpunkt einer Amazon-EC2-Region erwähnt, haben Sie den Agenten möglicherweise so konfiguriert, dass er Zugriff auf den Amazon-EC2-Endpunkt benötigt, ohne diesen Zugriff zu gewähren.
Beispiel: Wenn Sie einen Wert für den Parameter `append_dimensions` in der Agentenkonfigurationsdatei angeben, der von Amazon-EC2-Metadaten abhängt, und Sie Proxys verwenden, müssen Sie sicherstellen, dass der Server auf den Endpunkt für Amazon EC2 zugreifen kann. Weitere Informationen zu diesen Endpunkten finden Sie unter [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/general/latest/gr/rande.html#ec2_region) in der *Allgemeine Amazon Web Services-Referenz*.
## Der CloudWatch Agent wird auf Windows Server nicht gestartet
Unter Windows Server wird möglicherweise der folgende Fehler angezeigt:
```
Start-Service : Service 'Amazon CloudWatch Agent (AmazonCloudWatchAgent)' cannot be started due to the following
error: Cannot start service AmazonCloudWatchAgent on computer '.'.
At C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1:113 char:12
+ $svc | Start-Service
+ ~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
ServiceCommandException
+ FullyQualifiedErrorId : CouldNotStartService,Microsoft.PowerShell.Commands.StartServiceCommand
```
Um dies zu beheben, stellen Sie zunächst sicher, dass der Serverservice ausgeführt wird. Dieser Fehler kann angezeigt werden, wenn der Agent versucht, zu starten, während der Serverservice nicht ausgeführt wird.
Wenn der Serverservice bereits ausgeführt wird, kann Folgendes sein: Bei einigen Windows Server-Installationen benötigt der CloudWatch Agent mehr als 30 Sekunden, um zu starten. Da Windows Server standardmäßig nur 30 Sekunden zum Starten von Services zulässt, führt dies dazu, dass der Agent mit einem Fehler wie dem folgenden fehlschlägt:
Um dieses Problem zu beheben, erhöhen Sie den Zeitüberschreitungswert für Services. Weitere Informationen finden Sie unter [Ein Service wird nicht gestartet und die Ereignisse 7000 und 7011 werden im Windows-Ereignisprotokoll protokolliert](https://support.microsoft.com/en-us/help/922918/a-service-does-not-start-and-events-7000-and-7011-are-logged-in-window).
## Wo sind die Metriken?
Wenn der CloudWatch Agent ausgeführt wurde, Sie aber im AWS-Managementkonsole oder im keine von ihm gesammelten Messwerte finden können, vergewissern Sie sich AWS CLI, dass Sie den richtigen Namespace verwenden. Der Namespace für die vom Agent zu erfassenden Metriken ist standardmäßig `CWAgent`. Sie können diesen Namespace mit dem Feld `namespace` im Abschnitt `metrics` der Agentenkonfigurationsdatei anpassen. Wenn Sie die erwarteten Metriken nicht finden, prüfen Sie die Konfigurationsdatei, um festzustellen, welchen Namespace Sie verwenden.
Wenn Sie das CloudWatch Agentenpaket zum ersten Mal herunterladen, befindet `amazon-cloudwatch-agent.json` sich die Agenten-Konfigurationsdatei. Diese Datei befindet sich in dem Verzeichnis, in dem Sie den Konfigurationsassistenten ausgeführt haben. Möglicherweise haben Sie die Datei in ein anderes Verzeichnis verschoben. Wenn Sie den Konfigurations-Assistenten verwenden, wird die Ausgabe der Agent-Konfigurationsdatei vom Assistenten mit dem Namen `config.json` versehen. Weitere Informationen zur Konfigurationsdatei, einschließlich des Felds `namespace`, finden Sie unter [CloudWatch Agenten-Konfigurationsdatei: Abschnitt „Metriken“](CloudWatch-Agent-Configuration-File-Details.md#CloudWatch-Agent-Configuration-File-Metricssection).
## Es dauert lange, bis der CloudWatch Agent in einem Container ausgeführt wird, oder es wird ein Hop-Limit-Fehler protokolliert
Wenn Sie den CloudWatch Agenten als Container-Service ausführen und Amazon EC2-Metrikdimensionen zu allen vom Agenten gesammelten Metriken hinzufügen möchten, werden in Version v1.247354.0 des Agenten möglicherweise die folgenden Fehler angezeigt:
```
2022-06-07T03:36:11Z E! [processors.ec2tagger] ec2tagger: Unable to retrieve Instance Metadata Tags. This plugin must only be used on an EC2 instance.
2022-06-07T03:36:11Z E! [processors.ec2tagger] ec2tagger: Please increase hop limit to 2 by following this document https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html#configuring-IMDS-existing-instances.
2022-06-07T03:36:11Z E! [telegraf] Error running agent: could not initialize processor ec2tagger: EC2MetadataRequestError: failed to get EC2 instance identity document
caused by: EC2MetadataError: failed to make EC2Metadata request
status code: 401, request id:
caused by:
```
Dieser Fehler wird möglicherweise angezeigt, wenn der Agent versucht, Metadaten aus einem IMDSv2 Container ohne entsprechendes Hop-Limit abzurufen. In Agentenversionen vor v1.247354.0 kann dieses Problem auftreten, ohne dass die Protokollmeldung angezeigt wird.
Erhöhen Sie zur Lösung dieses Problems das Hop-Limit auf „2“. Eine entsprechende Anleitung finden Sie unter [ Konfigurieren der Optionen für Instance-Metadaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html#configuring-IMDS-existing-instances.).
## Ich habe meine Agentenkonfiguration aktualisiert, sehe aber die neuen Metriken oder Logs nicht in der CloudWatch Konsole
Wenn Sie Ihre CloudWatch Agenten-Konfigurationsdatei aktualisieren, müssen Sie beim nächsten Start des Agenten die **fetch-config** Option verwenden. Wenn Sie beispielsweise die aktualisierte Datei auf dem lokalen Computer gespeichert haben, geben Sie den folgenden Befehl ein:
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -s -m ec2 -c file:configuration-file-path
```
## CloudWatch Agentendateien und Speicherorte
In der folgenden Tabelle sind die vom CloudWatch Agenten installierten und mit ihm verwendeten Dateien sowie ihre Speicherorte auf Servern aufgeführt, auf denen Linux oder Windows Server ausgeführt werden.
| Datei | Linux-Speicherort | Windows Server-Speicherort |
| --- | --- | --- |
| Das Steuerskript, das das Starten, Anhalten und Neustarten des Agents kontrolliert. | `/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl` oder `/usr/bin/amazon-cloudwatch-agent-ctl` | `$Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1` |
| Die Protokolldatei, in die der Agent schreibt. Möglicherweise müssen Sie dies bei der Kontaktaufnahme anhängen AWS Support. | `/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log` oder `/var/log/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.log` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log` |
| Datei für die Auswertung der Agentenkonfiguration. | `/opt/aws/amazon-cloudwatch-agent/logs/configuration-validation.log` oder `/var/log/amazon/amazon-cloudwatch-agent/configuration-validation.log` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\configuration-validation.log` |
| Die für die Konfiguration des Agenten verwendete JSON-Datei, sofort nach der Erstellung durch den Assistenten. Weitere Informationen finden Sie unter [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](create-cloudwatch-agent-configuration-file.md). | `/opt/aws/amazon-cloudwatch-agent/bin/config.json` | `$Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\config.json` |
| Die für die Konfiguration des Agenten verwendete JSON-Datei, wenn diese Konfigurationsdatei aus Parameter Store heruntergeladen wurde. | `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json` oder `/etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.json` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json` |
| Die TOML-Datei, mit der Regions- und Anmeldeinformationen angegeben werden, die vom Agenten verwendet werden sollen, wobei die Systemvorgaben überschrieben werden. | `/opt/aws/amazon-cloudwatch-agent/etc/common-config.toml` oder `/etc/amazon/amazon-cloudwatch-agent/common-config.toml` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\common-config.toml` |
| Die TOML-Datei, die den konvertierten Inhalt der JSON-Konfigurationsdatei enthält. Das `amazon-cloudwatch-agent-ctl`-Skript generiert diese Datei. Benutzer sollten diese Datei nicht direkt ändern. Sie kann nützlich sein, um zu überprüfen, ob die Übersetzung von JSON in TOML erfolgreich war. | `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml` oder `/etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.toml` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.toml` |
| Die YAML-Datei, die den konvertierten Inhalt der JSON-Konfigurationsdatei enthält. Das `amazon-cloudwatch-agent-ctl`-Skript generiert diese Datei. Sie sollten diese Datei nicht direkt ändern. Diese Datei kann nützlich sein, um zu überprüfen, ob die Übersetzung von JSON nach YAML erfolgreich war. | `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.yaml or /etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.yaml` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.yaml` |
## Suchen Sie nach Informationen zu CloudWatch Agentenversionen
Geben Sie den folgenden Befehl ein, um die Versionsnummer des CloudWatch Agenten auf einem Linux-Server zu ermitteln:
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status
```
Geben Sie den folgenden Befehl ein, um die Versionsnummer des CloudWatch Agenten auf Windows Server zu ermitteln:
```
& $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a status
```
**Anmerkung**
Die Verwendung dieses Befehls ist der richtige Weg, um die Version des CloudWatch Agenten zu finden. Wenn Sie **Programme und Feature** nutzen, sehen Sie in der Systemsteuerung eine falsche Versionsnummer.
Sie können auch eine README-Datei über die neuesten Änderungen am Agenten sowie eine Datei mit der Versionsnummer herunterladen, die aktuell zum Download verfügbar ist. Diese Dateien befinden sich an den folgenden Speicherorten:
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/info/latest/RELEASE_NOTES` oder `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/info/latest/RELEASE_NOTES`
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/info/latest/CWAGENT_VERSION` oder `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/info/latest/CWAGENT_VERSION`
## Vom CloudWatch Agenten generierte Protokolle
Der Agent generiert ein Protokoll, während es ausgeführt wird. Dieses Protokoll enthält Informationen zur Fehlerbehebung. Das Protokoll ist die Datei `amazon-cloudwatch-agent.log`. Diese Datei befindet sich auf Linux-Servern unter `/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log` und auf Servern mit Windows Server unter `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log`.
Sie können den Agenten so konfigurieren, dass zusätzliche Details in der Datei `amazon-cloudwatch-agent.log` protokolliert werden. Setzen Sie in der Agentenkonfigurationsdatei im `agent` Abschnitt das `debug` Feld auf`true`, konfigurieren Sie den CloudWatch Agenten neu und starten Sie ihn neu. Um die Aufzeichnung dieser zusätzlichen Informationen zu deaktivieren, setzen Sie das Feld `debug` auf `false`. Konfigurieren Sie dann den Agenten neu und starten Sie ihn neu. Weitere Informationen finden Sie unter [Erstellen oder bearbeiten Sie die CloudWatch Agenten-Konfigurationsdatei manuell](CloudWatch-Agent-Configuration-File-Details.md).
In den Versionen 1.247350.0 und höher des CloudWatch Agenten können Sie das `aws_sdk_log_level` Feld im `agent` Abschnitt der Agenten-Konfigurationsdatei optional auf eine oder mehrere der folgenden Optionen festlegen. Trennen Sie mehrere Optionen mit dem `|`-Zeichen.
+ `LogDebug`
+ `LogDebugWithSigning`
+ `LogDebugWithHTTPBody`
+ `LogDebugRequestRetries`
+ `LogDebugWithEventStreamBody`
Weitere Informationen zu diesen Optionen finden Sie unter [LogLevelType](https://docs.aws.amazon.com/sdk-for-go/api/aws/#LogLevelType).
## Den Agenten stoppen und neu starten CloudWatch
Sie können den CloudWatch Agenten manuell entweder über die Befehlszeile AWS Systems Manager oder über die Befehlszeile beenden.
**Um den CloudWatch Agenten mit Run Command zu beenden**
1. Öffnen Sie die Systems Manager Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
–oder–
Wenn die AWS Systems Manager Startseite geöffnet wird, scrollen Sie nach unten und wählen Sie **Explore Run Command**.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der **Command-Dokumentliste** die Option **AmazonCloudWatch- ManageAgent**.
1. Wählen Sie im Bereich **Ziele** die Instanz aus, auf der Sie den CloudWatch Agenten installiert haben.
1. Klicken Sie in der Liste **Action** auf **stop**.
1. Lassen Sie **Optional Configuration Source (Optionale Konfigurationsquelle)** und **Optional Configuration Location (Optionaler Konfigurationsstandort)** leer.
1. Klicken Sie auf **Ausführen**.
**Um den CloudWatch Agenten lokal über die Befehlszeile zu beenden**
+ Geben Sie auf einem Linux-Server Folgendes ein:
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a stop
```
Geben Sie auf einem Server, auf dem Windows Server ausgeführt wird, PowerShell als Administrator Folgendes ein:
```
& $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a stop
```
Um den Agent neu zu starten, befolgen Sie die Anweisungen in [(Optional) Ändern Sie die allgemeine Konfiguration und das benannte Profil für den CloudWatch Agenten](installing-cloudwatch-agent-ssm.md#CloudWatch-Agent-profile-instance-fleet).