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.
# 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"
}
]
}
}
}
}
```