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.
# Protokollierung und Überwachung auf Amazon ECS
Amazon Elastic Container Service (Amazon ECS) bietet [zwei Starttypen](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/launch_types.html) für die Ausführung von Containern, die den Typ der Infrastruktur bestimmen, auf der Aufgaben und Dienste gehostet werden. Diese Starttypen sind AWS Fargate Amazon EC2. Beide Starttypen lassen sich integrieren CloudWatch , Konfigurationen und Support variieren jedoch.
In den folgenden Abschnitten erfahren Sie, wie Sie es CloudWatch für die Protokollierung und Überwachung auf Amazon ECS verwenden.
**Topics**
+ [Konfiguration CloudWatch mit einem EC2-Starttyp](configure-cloudwatch-ec2-launch-type.md)
+ [Amazon ECS-Containerprotokolle für die Starttypen EC2 und Fargate](ec2-fargate-logs.md)
+ [Verwenden von benutzerdefiniertem Protokoll-Routing mit FireLens für Amazon ECS](firelens-custom-log-routing.md)
+ [Metriken für Amazon ECS](ecs-metrics.md)
# Konfiguration CloudWatch mit einem EC2-Starttyp
Mit einem EC2-Starttyp stellen Sie einen Amazon ECS-Cluster von EC2-Instances bereit, die den CloudWatch Agenten für die Protokollierung und Überwachung verwenden. Ein für Amazon ECS optimiertes AMI ist mit dem [Amazon ECS-Container-Agenten](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/ECS_agent.html) vorinstalliert und stellt CloudWatch Metriken für den Amazon ECS-Cluster bereit.
Diese Standardmetriken sind in den Kosten von Amazon ECS enthalten, aber die Standardkonfiguration für Amazon ECS überwacht keine Protokolldateien oder zusätzliche Metriken (z. B. freier Festplattenspeicher). Sie können den verwenden AWS-Managementkonsole , um einen Amazon ECS-Cluster mit dem EC2-Starttyp bereitzustellen. Dadurch wird ein CloudFormation Stack erstellt, der eine Amazon EC2 Auto Scaling Gruppe mit einer Startkonfiguration bereitstellt. Dieser Ansatz bedeutet jedoch, dass Sie kein benutzerdefiniertes AMI auswählen oder die Startkonfiguration mit anderen Einstellungen oder zusätzlichen Startskripten anpassen können.
Um zusätzliche Protokolle und Metriken zu überwachen, müssen Sie den CloudWatch Agenten auf Ihren Amazon ECS-Container-Instances installieren. Sie können den Installationsansatz für EC2-Instances aus dem [Installation des CloudWatch Agenten mithilfe von Systems Manager Distributor und State Manager](install-cloudwatch-systems-manager.md) Abschnitt dieses Handbuchs verwenden. Das Amazon ECS AMI enthält jedoch nicht den erforderlichen Systems Manager Manager-Agenten. Sie sollten eine benutzerdefinierte Startkonfiguration mit einem Benutzerdatenskript verwenden, das den Systems Manager Manager-Agent installiert, wenn Sie Ihren Amazon ECS-Cluster erstellen. Dadurch können sich Ihre Container-Instances bei Systems Manager registrieren und die State Manager-Verknüpfungen anwenden, um den CloudWatch Agenten zu installieren, zu konfigurieren und zu aktualisieren. Wenn State Manager Ihre CloudWatch Agentenkonfiguration ausführt und aktualisiert, wendet er auch Ihre standardisierte Konfiguration auf Systemebene für Amazon CloudWatch EC2 an. Sie können auch standardisierte CloudWatch Konfigurationen für Amazon ECS im S3-Bucket für Ihre CloudWatch Konfiguration speichern und sie automatisch mit State Manager anwenden.
Sie sollten sicherstellen, dass die auf Ihre Amazon ECS-Container-Instances angewendete IAM-Rolle oder das Instance-Profil die erforderlichen `CloudWatchAgentServerPolicy` `AmazonSSMManagedInstanceCore` Richtlinien enthält. Sie können die Vorlage [ecs\$1cluster\$1with\$1cloudwatch\$1linux.yaml verwenden, um Linux-basierte Amazon](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/ecs/ecs_cluster_with_cloudwatch_linux.yaml) CloudFormation ECS-Cluster bereitzustellen. Diese Vorlage erstellt einen Amazon ECS-Cluster mit einer benutzerdefinierten Startkonfiguration, der Systems Manager installiert und eine benutzerdefinierte CloudWatch Konfiguration zur Überwachung von Amazon ECS-spezifischen Protokolldateien bereitstellt.
Sie sollten die folgenden Protokolle für Ihre Amazon ECS-Container-Instances sowie Ihre standardmäßigen EC2-Instance-Protokolle erfassen:
+ **Startausgabe des Amazon ECS-Agenten** — `/var/log/ecs/ecs-init.log`
+ **Amazon ECS-Agentenausgabe** — `/var/log/ecs/ecs-agent.log`
+ Protokoll der **Anfragen des IAM-Anmeldeinformationsanbieters** — `/var/log/ecs/audit.log`
Weitere Informationen zu Ausgabeebene, Formatierung und zusätzlichen Konfigurationsoptionen finden Sie in der [Amazon ECS-Dokumentation unter Speicherorte der Amazon ECS-Protokolldateien](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/logs.html).
**Wichtig**
Für den Fargate-Starttyp ist keine Agenteninstallation oder -konfiguration erforderlich, da Sie keine EC2-Container-Instances ausführen oder verwalten.
Amazon ECS-Container-Instances sollten den neuesten Amazon AMIs ECS-optimierten Container-Agenten verwenden. AWS speichert öffentliche Systems Manager Parameter Store-Parameter mit für Amazon ECS optimierten AMI-Informationen, einschließlich der AMI-ID. Sie können das neueste, zuletzt optimierte AMI aus dem Parameter Store abrufen, indem Sie das [Parameter Store-Parameterformat](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html) für Amazon ECS optimized verwenden AMIs. Sie können in Ihren CloudFormation Vorlagen auf den Parameter public Parameter Store verweisen, der auf das neueste AMI oder eine bestimmte AMI-Version verweist.
AWS stellt in jeder unterstützten Region dieselben Parameter Store-Parameter bereit. Das bedeutet, dass CloudFormation Vorlagen, die auf diese Parameter verweisen, für alle Regionen und Konten wiederverwendet werden können, ohne dass das AMI aktualisiert werden muss. Sie können die Bereitstellung neuerer Amazon ECS AMIs in Ihrem Unternehmen steuern, indem Sie auf eine bestimmte Version verweisen. Auf diese Weise können Sie die Verwendung eines neuen Amazon ECS-optimierten AMI verhindern, bis Sie es getestet haben.
# Amazon ECS-Containerprotokolle für die Starttypen EC2 und Fargate
Amazon ECS verwendet eine Aufgabendefinition, um Container als Aufgaben und Services bereitzustellen und zu verwalten. Sie konfigurieren die Container, die Sie in Ihrem Amazon ECS-Cluster starten möchten, innerhalb einer Aufgabendefinition. Die Protokollierung wird mit einem Protokolltreiber auf Containerebene konfiguriert. Mehrere Protokolltreiberoptionen bieten Ihren Containern unterschiedliche Protokollierungssysteme (z. B.,,,,`awslogs`,`fluentd`,`gelf`,`json-file`, oder) `journald``logentries`,`splunk`,,`syslog`, oder`awsfirelens`), je nachdem, ob Sie den Starttyp EC2 oder Fargate verwenden. Der Fargate-Starttyp bietet eine Teilmenge der folgenden Protokolltreiberoptionen: `awslogs``splunk`, und. `awsfirelens` AWS stellt den `awslogs` Protokolltreiber zur Erfassung und Übertragung von Container-Ausgaben an Logs bereit CloudWatch . Mit den Protokolltreibereinstellungen können Sie die Protokollgruppe, die Region und das Protokollstream-Präfix sowie viele andere Optionen anpassen.
Die Standardbenennung für Protokollgruppen und die Option, die von der Option ** CloudWatch Protokolle automatisch konfigurieren** auf der verwendet wird, AWS-Managementkonsole lautet`/ecs/`. Der von Amazon ECS verwendete Protokollstreamname hat das `//` Format. Wir empfehlen Ihnen, einen Gruppennamen zu verwenden, der Ihre Protokolle nach den Anforderungen Ihrer Organisation gruppiert. In der folgenden Tabelle `image_tag` sind die `image_name` und im Namen des Protokolldatenstroms enthalten.
| | |
| --- |--- |
| Name der Protokollgruppe | ///// |
| Präfix für den Namen des Protokollstreams | `//` |
Diese Informationen sind auch in der Aufgabendefinition verfügbar. Aufgaben werden jedoch regelmäßig mit neuen Versionen aktualisiert, was bedeutet, dass in der Aufgabendefinition möglicherweise ein anderes `image_name` und `image_tag` als das aktuell in der Aufgabendefinition verwendete verwendet wurde. Weitere Informationen und Benennungsvorschläge finden Sie im [Planung Ihres CloudWatch Einsatzes](planning-cloudwatch-deployment.md) Abschnitt dieses Handbuchs.
Wenn Sie einen kontinuierlichen Integrations- und CI/CD) pipeline or automated process, you can create a new task definition revision for your application with each new Docker image build. For example, you can include the Docker image name, image tag, GitHub revision, or other important information in your task definition revision and logging configuration as a part of your CI/CD Continuous-Delivery-Prozess (Prozess) verwenden.
# Verwenden von benutzerdefiniertem Protokoll-Routing mit FireLens für Amazon ECS
FireLens für Amazon ECS können Sie Protokolle an [Fluentd](https://www.fluentd.org/) oder [Fluent Bit](https://docs.fluentbit.io/manual) weiterleiten, sodass Sie Container-Protokolle direkt an AWS Services und AWS Partner Network (APN) -Ziele senden und den Protokollversand an Logs unterstützen können. CloudWatch
AWS bietet ein [Docker-Image für Fluent Bit](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/firelens-using-fluentbit.html) mit vorinstallierten Plugins für Amazon Kinesis Data Streams, Amazon Data Firehose und Logs. CloudWatch Sie können den FireLens Protokolltreiber anstelle des Protokolltreibers verwenden, um mehr Anpassungen und Kontrolle über die an `awslogs` Logs gesendeten Protokolle zu erhalten. CloudWatch
Sie können beispielsweise den FireLens Protokolltreiber verwenden, um die Ausgabe im Protokollformat zu steuern. Das bedeutet, dass die CloudWatch Protokolle eines Amazon ECS-Containers automatisch als JSON-Objekte formatiert werden und JSON-formatierte Eigenschaften für`ecs_cluster`,, `ecs_task_arn``ecs_task_definition`, `container_id` und enthalten. `container_name` `ec2_instance_id` Der Fluent-Host wird Ihrem Container über die `FLUENT_PORT` Umgebungsvariablen `FLUENT_HOST` und zur Verfügung gestellt, wenn Sie den Treiber angeben. `awsfirelens` Das bedeutet, dass Sie sich mithilfe von Fluent-Logger-Bibliotheken direkt von Ihrem Code aus beim Log-Router anmelden können. Ihre Anwendung könnte beispielsweise die `fluent-logger-python` Bibliothek für die Protokollierung bei Fluent Bit mithilfe der in den Umgebungsvariablen verfügbaren Werte enthalten.
Wenn Sie sich FireLens für Amazon ECS entscheiden, können Sie dieselben Einstellungen wie für den `awslogs` Protokolltreiber konfigurieren [und auch andere Einstellungen verwenden](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit). Sie können beispielsweise die Amazon ECS-Aufgabendefinition [ecs-task-nginx-firelense.json](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/ecs/ecs-task-nginx-firelense.json) verwenden, die einen NGINX-Server startet, der FireLens für die Anmeldung konfiguriert ist. CloudWatch Außerdem wird ein FireLens Fluent Bit-Container als Sidecar für die Protokollierung gestartet.
# Metriken für Amazon ECS
[Amazon ECS bietet CloudWatch Standardmetriken](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/cloudwatch-metrics.html) (z. B. CPU- und Speicherauslastung) für die Starttypen EC2 und Fargate auf Cluster- und Serviceebene mit dem Amazon ECS-Container-Agenten. Sie können auch Metriken für Ihre Services, Aufgaben und Container mithilfe von CloudWatch Container Insights oder Ihre eigenen benutzerdefinierten Container-Metriken mithilfe des eingebetteten Metrikformats erfassen.
Container Insights ist eine CloudWatch Funktion, die Metriken wie CPU-Auslastung, Speicherauslastung, Netzwerkverkehr und Speicher auf Cluster-, Container-Instance-, Service- und Task-Ebene bereitstellt. Container Insights erstellt außerdem automatische Dashboards, mit denen Sie Dienste und Aufgaben analysieren und die durchschnittliche Speicher- oder CPU-Auslastung auf Container-Ebene einsehen können. Container Insights veröffentlicht benutzerdefinierte Metriken im `ECS/ContainerInsights` [benutzerdefinierten Namespace](https://docs.aws.amazon.com//AmazonECS/latest/developerguide/cloudwatch-metrics.html), die Sie für grafische Darstellung, Alarmierung und Dashboards verwenden können.
Sie können Container Insight-Metriken aktivieren, indem Sie Container Insights für jeden einzelnen Amazon ECS-Cluster aktivieren. Wenn Sie auch Metriken auf Container-Instance-Ebene sehen möchten, können Sie [den CloudWatch Agenten als Daemon-Container auf Ihrem Amazon ECS-Cluster starten](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-instancelevel.html). Sie können die CloudFormation Vorlage [cwagent-ecs-instance-metric-cfn.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/ecs/cwagent-ecs-instance-metric-cfn.yaml) verwenden, um den CloudWatch Agenten als Amazon ECS-Service bereitzustellen. Wichtig ist, dass in diesem Beispiel davon ausgegangen wird, dass Sie eine entsprechende benutzerdefinierte CloudWatch Agentenkonfiguration erstellt und diese zusammen mit dem Schlüssel im Parameter Store gespeichert haben. `ecs-cwagent-daemon-service`
Der als Daemon-Container für CloudWatch Container Insights bereitgestellte [CloudWatchAgent](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) enthält zusätzliche Festplatten-, Arbeitsspeicher- und CPU-Metriken wie `instance_cpu_reserved_capacity` und `instance_memory_reserved_capacity` mit den `InstanceId` Dimensionen `ClusterName``ContainerInstanceId`,. Metriken auf Container-Instance-Ebene werden von Container Insights mithilfe des CloudWatch eingebetteten Metrikformats implementiert. Sie können zusätzliche Metriken auf Systemebene für Ihre Amazon ECS-Container-Instances konfigurieren, indem Sie den Ansatz aus dem [Richten Sie State Manager und Distributor für die Bereitstellung und Konfiguration von CloudWatch Agenten ein](install-cloudwatch-systems-manager.md#set-up-systems-manager-distributor) Abschnitt dieses Handbuchs verwenden.
## Erstellen von benutzerdefinierten Anwendungsmetriken in Amazon ECS
Sie können benutzerdefinierte Metriken für Ihre Anwendungen erstellen, indem Sie das [CloudWatcheingebettete Metrikformat](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) verwenden. Der `awslogs` Protokolltreiber kann CloudWatch eingebettete Anweisungen im metrischen Format interpretieren.
Die `CW_CONFIG_CONTENT` Umgebungsvariable im folgenden Beispiel ist auf den Inhalt des `cwagentconfig` Systems Manager-Parameterspeicher-Parameters gesetzt. Sie können den Agenten mit dieser Basiskonfiguration ausführen, um ihn als eingebetteten Endpunkt im metrischen Format zu konfigurieren. Dies ist jedoch nicht mehr erforderlich.
```
{
"logs": {
"metrics_collected": {
"emf": { }
}
}
}
```
Wenn Sie Amazon ECS-Bereitstellungen in mehreren Konten und Regionen haben, können Sie ein AWS Secrets Manager Geheimnis verwenden, um Ihre CloudWatch Konfiguration zu speichern und die geheime Richtlinie so zu konfigurieren, dass sie mit Ihrer Organisation geteilt wird. Sie können die Option Secrets in Ihrer Aufgabendefinition verwenden, um die `CW_CONFIG_CONTENT` Variable festzulegen.
Sie können die AWS bereitgestellten [Open-Source-Bibliotheken für eingebettete metrische Formate](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) in Ihrer Anwendung verwenden und die `AWS_EMF_AGENT_ENDPOINT` Umgebungsvariable angeben, um eine Verbindung zu Ihrem CloudWatch Agent-Sidecar-Container herzustellen, der als eingebetteter Endpunkt im metrischen Format fungiert. Sie können beispielsweise die Python-Beispielanwendung [ecs\$1cw\$1emf\$1example](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/tree/main/examples/ecs/ecs_cw_emf_example) verwenden, um Metriken im eingebetteten metrischen Format an einen CloudWatch Agent-Sidecar-Container zu senden, der als eingebetteter Endpunkt im metrischen Format konfiguriert ist.
Das [Fluent Bit-Plug-In](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) für CloudWatch kann auch verwendet werden, um eingebettete Nachrichten im metrischen Format zu senden. Sie können auch die Python-Beispielanwendung [ecs\$1firelense\$1emf\$1example](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/tree/main/examples/ecs/ecs_firelense_emf_example) verwenden, um Metriken im eingebetteten metrischen Format an einen Firelens for Amazon ECS-Sidecar-Container zu senden.
[https://docs.aws.amazon.com//AmazonCloudWatch/latest/APIReference/Welcome.html](https://docs.aws.amazon.com//AmazonCloudWatch/latest/APIReference/Welcome.html) Wir empfehlen diesen Ansatz nur, wenn Sie einen bestimmten Anwendungsfall haben, da er den Wartungs- und Verwaltungsaufwand für Ihren Code erhöht.