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.
# Konfiguration des CloudWatch Agenten für EC2-Instances und lokale Server
Viele Organisationen führen Workloads sowohl auf physischen Servern als auch auf virtuellen Maschinen aus (). VMs Diese Workloads werden in der Regel auf unterschiedlichen Workloads ausgeführt, für OSs die jeweils eigene Installations- und Konfigurationsanforderungen für die Erfassung und Erfassung von Metriken gelten.
Wenn Sie sich für die Verwendung von EC2-Instances entscheiden, können Sie ein hohes Maß an Kontrolle über Ihre Instance- und Betriebssystemkonfiguration haben. Dieses höhere Maß an Kontrolle und Verantwortung erfordert jedoch, dass Sie die Konfigurationen überwachen und anpassen, um eine effizientere Nutzung zu erreichen. Sie können Ihre betriebliche Effizienz verbessern, indem Sie Standards für die Protokollierung und Überwachung festlegen und für die Erfassung und Erfassung von Protokollen und Messdaten einen standardmäßigen Installations- und Konfigurationsansatz anwenden.
Organizations, die ihre IT-Investitionen in die AWS Cloud migrieren oder erweitern, können CloudWatch diese nutzen, um eine einheitliche Protokollierungs- und Überwachungslösung zu erhalten. CloudWatch Die Preisgestaltung bedeutet, dass Sie schrittweise für die Metriken und Protokolle zahlen, die Sie erfassen möchten. Sie können auch Protokolle und Metriken für lokale Server erfassen, indem Sie einen ähnlichen CloudWatch Agenteninstallationsprozess wie für Amazon EC2 verwenden.
Bevor Sie mit der Installation und Bereitstellung beginnen, stellen Sie sicher CloudWatch, dass Sie die Protokollierungs- und Metrikkonfigurationen für Ihre Systeme und Anwendungen evaluieren. Stellen Sie sicher, dass Sie die Standardprotokolle und Metriken definieren, die Sie für die Daten OSs , die Sie verwenden möchten, erfassen müssen. Systemprotokolle und Metriken sind die Grundlage und der Standard für eine Protokollierungs- und Überwachungslösung, da sie vom Betriebssystem generiert werden und sich für Linux und Windows unterscheiden. In allen Linux-Distributionen sind wichtige Metriken und Protokolldateien verfügbar, zusätzlich zu denen, die für eine Linux-Version oder -Distribution spezifisch sind. Diese Varianz tritt auch zwischen verschiedenen Windows-Versionen auf.
## Konfiguration des Agenten CloudWatch
CloudWatch erfasst Metriken und Protokolle für Amazon EC2- und lokale Server mithilfe von [CloudWatch Agenten und Agentenkonfigurationsdateien](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html), die für jedes Betriebssystem spezifisch sind. Wir empfehlen Ihnen, die Standardkonfiguration Ihrer Organisation für die Erfassung von Metriken und Protokollen zu definieren, bevor Sie mit der Installation des CloudWatch Agenten in großem Umfang in Ihren Konten beginnen.
Sie können mehrere CloudWatch Agentenkonfigurationen zu einer zusammengesetzten CloudWatch Agentenkonfiguration kombinieren. Ein empfohlener Ansatz besteht darin, Konfigurationen für Ihre Protokolle und Metriken auf System- und Anwendungsebene zu definieren und zu unterteilen. Das folgende Diagramm zeigt, wie mehrere CloudWatch Konfigurationsdateitypen für unterschiedliche Anforderungen zu einer zusammengesetzten CloudWatch Konfiguration kombiniert werden können:
![\[Konfigurationen für unterschiedliche Anforderungen werden zu einer zusammengesetzten CloudWatch Konfiguration kombiniert.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/logging-monitoring-image-1.png)
Diese Protokolle und Metriken können auch weiter klassifiziert und für bestimmte Umgebungen oder Anforderungen konfiguriert werden. Sie könnten beispielsweise eine kleinere Teilmenge von Protokollen und Metriken mit geringerer Genauigkeit für unregulierte Entwicklungsumgebungen und eine größere, vollständigere Gruppe mit höherer Genauigkeit für regulierte Produktionsumgebungen definieren.
## Konfiguration der Protokollerfassung für EC2-Instances
Standardmäßig überwacht oder erfasst Amazon EC2 keine Protokolldateien. Stattdessen werden Protokolldateien von der auf Ihrer EC2-Instance, AWS API oder AWS Command Line Interface () installierten CloudWatch Agentsoftware erfasst und in CloudWatch Logs aufgenommen.AWS CLI Wir empfehlen, den CloudWatch Agenten zu verwenden, um Protokolldateien in CloudWatch Logs für Amazon EC2- und lokale Server aufzunehmen.
Sie können Protokolle durchsuchen und filtern sowie Metriken extrahieren und die Automatisierung auf der Grundlage von Pattern-Patches aus den Protokolldateien in ausführen. CloudWatch CloudWatch unterstützt Klartext-, Leerzeichen- und JSON-formatierte Filter- und Mustersyntaxoptionen, wobei JSON-formatierte Protokolle die größte Flexibilität bieten. Um die Filter- und Analyseoptionen zu erweitern, sollten Sie eine formatierte Protokollausgabe anstelle von Klartext verwenden.
Der CloudWatch Agent verwendet eine Konfigurationsdatei, die die Protokolle und Metriken definiert, an die gesendet werden sollen CloudWatch. CloudWatch erfasst dann jede Protokolldatei als [Protokollstream](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) und gruppiert diese Protokollstreams in einer [Protokollgruppe](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html). Auf diese Weise können Sie Vorgänge anhand von Protokollen Ihrer EC2-Instances ausführen, z. B. nach einer passenden Zeichenfolge suchen.
Der Standard-Log-Stream-Name ist derselbe wie die EC2-Instance-ID und der Standard-Loggruppenname ist derselbe wie der Protokolldateipfad. Der Name des Log-Streams muss innerhalb der CloudWatch Protokollgruppe eindeutig sein. Sie können`instance_id`, `hostname``local_hostname`, oder `ip_address` für die dynamische Substitution im Logstream und in den Loggruppennamen verwenden, was bedeutet, dass Sie dieselbe CloudWatch Agent-Konfigurationsdatei für mehrere EC2-Instances verwenden können.
Das folgende Diagramm zeigt eine CloudWatch Agentenkonfiguration für die Erfassung von Protokollen. Die Protokollgruppe wird durch die erfassten Protokolldateien definiert und enthält separate Protokollstreams für jede EC2-Instance, da die `{instance_id}` Variable, die für den Protokollstreamnamen verwendet wird, und die EC2-Instance eindeutig IDs sind.
![\[Eine CloudWatch Agentenkonfiguration für die Erfassung von Protokollen.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/cloudwatch-image-1.png)
Protokollgruppen definieren die Aufbewahrung, die Tags, die Sicherheit, die Metrikfilter und den Suchbereich für die Protokollstreams, die sie enthalten. Das standardmäßige Gruppierungsverhalten, das auf dem Namen der Protokolldatei basiert, hilft Ihnen bei der Suche, Erstellung von Metriken und bei der Alarmierung von Daten, die für eine Protokolldatei spezifisch sind, auf EC2-Instances in einem Konto und einer Region. Sie sollten prüfen, ob eine weitere Verfeinerung der Protokollgruppe erforderlich ist. Beispielsweise könnte Ihr Konto von mehreren Geschäftsbereichen gemeinsam genutzt werden und unterschiedliche technische oder betriebliche Verantwortliche haben. Das bedeutet, dass Sie den Namen der Protokollgruppe weiter verfeinern müssen, um die Trennung und die Eigentümerschaft widerzuspiegeln. Dieser Ansatz ermöglicht es Ihnen, Ihre Analyse und Problembehandlung auf die jeweilige EC2-Instance zu konzentrieren.
Wenn mehrere Umgebungen ein Konto verwenden, können Sie die Protokollierung für Workloads, die in jeder Umgebung ausgeführt werden, trennen. Die folgende Tabelle zeigt eine Benennungskonvention für Protokollgruppen, die die Geschäftseinheit, das Projekt oder die Anwendung und die Umgebung umfasst.
| | |
| --- |--- |
| Name der Protokollgruppe | //// |
| Name des Protokollstreams | |
Sie können auch alle Protokolldateien für eine EC2-Instance in derselben Protokollgruppe gruppieren. Dies erleichtert das Suchen und Analysieren einer Reihe von Protokolldateien für eine einzelne EC2-Instance. Dies ist nützlich, wenn die meisten Ihrer EC2-Instances eine Anwendung oder einen Workload bedienen und jede EC2-Instance einem bestimmten Zweck dient. Die folgende Tabelle zeigt, wie Ihre Loggruppe und die Log-Stream-Benennung formatiert werden könnten, um diesen Ansatz zu unterstützen.
| | |
| --- |--- |
| Name der Protokollgruppe | //// |
| Name des Protokollstreams | |
## Konfiguration der Metrikerfassung für EC2-Instances
Standardmäßig sind Ihre EC2-Instances für die grundlegende Überwachung aktiviert, und ein [Standardsatz von Metriken](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) (z. B. CPU-, Netzwerk- oder speicherbezogene Metriken) wird automatisch alle fünf Minuten an sie CloudWatch gesendet. CloudWatch Die Metriken können je nach Instance-Familie variieren. Beispielsweise verfügen [Instances mit hoher Leistung](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/burstable-performance-instances.html) über Metriken für CPU-Guthaben. Amazon EC2 EC2-Standardmetriken sind in Ihrem Instance-Preis enthalten. Wenn Sie die [detaillierte Überwachung](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/using-cloudwatch-new.html) für Ihre EC2-Instances aktivieren, können Sie Daten innerhalb von einer Minute empfangen. Die Periodenfrequenz wirkt sich auf Ihre CloudWatch Kosten aus. Stellen Sie daher sicher, dass Sie abwägen, ob eine detaillierte Überwachung für alle oder nur für einige Ihrer EC2-Instances erforderlich ist. Sie könnten beispielsweise die detaillierte Überwachung für Produktionsworkloads aktivieren, aber die Basisüberwachung für Workloads außerhalb der Produktion verwenden.
Lokale Server enthalten keine Standardmetriken für CloudWatch und müssen den CloudWatch Agenten oder das AWS SDK verwenden AWS CLI, um Messwerte zu erfassen. Das bedeutet, dass Sie die Metriken, die Sie erfassen möchten (z. B. die CPU-Auslastung), in der CloudWatch Konfigurationsdatei definieren müssen. Sie können eine eindeutige CloudWatch Konfigurationsdatei erstellen, die die standardmäßigen EC2-Instance-Metriken für Ihre lokalen Server enthält, und diese zusätzlich zu Ihrer CloudWatch Standardkonfiguration anwenden.
Die [Metriken](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/working_with_metrics.html) in CloudWatch sind eindeutig durch den Metriknamen und null oder mehr Dimensionen definiert und in einem Metrik-Namespace eindeutig gruppiert. Metriken, die von einem AWS Service bereitgestellt werden, haben einen Namespace, der mit `AWS` (z. B.`AWS/EC2`) beginnt, und AWS Nicht-Metriken werden als benutzerdefinierte Metriken betrachtet. Metriken, die Sie mit dem CloudWatch Agenten konfigurieren und erfassen, gelten alle als benutzerdefinierte Metriken. Da sich die Anzahl der erstellten Metriken auf Ihre CloudWatch Kosten auswirkt, sollten Sie abwägen, ob jede Metrik für alle oder nur für einige Ihrer EC2-Instances erforderlich ist. Sie könnten beispielsweise einen vollständigen Satz von Metriken für Produktionsworkloads definieren, aber einen kleineren Teil dieser Metriken für Workloads außerhalb der Produktion verwenden.
`CWAgent`ist der Standard-Namespace für Metriken, die vom Agenten veröffentlicht werden. CloudWatch Ähnlich wie bei Protokollgruppen organisiert der Metrik-Namespace eine Reihe von Metriken, sodass sie zusammen an einem Ort gefunden werden können. Sie sollten den Namespace so ändern, dass er eine Geschäftseinheit, ein Projekt oder eine Anwendung und eine Umgebung widerspiegelt (z. B.). `///` Dieser Ansatz ist nützlich, wenn mehrere Workloads, die nichts miteinander zu tun haben, dasselbe Konto verwenden. Sie können auch Ihre Namespace-Benennungskonvention mit Ihrer Namenskonvention für CloudWatch Protokollgruppen korrelieren.
Metriken werden auch anhand ihrer Dimensionen identifiziert, die Ihnen helfen, sie anhand einer Reihe von Bedingungen zu analysieren. Sie sind die Eigenschaften, anhand derer Beobachtungen aufgezeichnet werden. Amazon EC2 enthält [separate Metriken](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-dimensions) für EC2-Instances mit `InstanceId` und `AutoScalingGroupName` -Dimensionen. Sie erhalten auch Metriken mit den `InstanceType` Dimensionen `ImageId` und, wenn Sie die detaillierte Überwachung aktivieren. Amazon EC2 bietet beispielsweise eine separate EC2-Instance-Metrik für die CPU-Auslastung mit den `InstanceId` Dimensionen, zusätzlich zu einer separaten CPU-Nutzungsmetrik für die `InstanceType` Dimension. [Auf diese Weise können Sie die CPU-Auslastung für jede einzelne EC2-Instance sowie für alle EC2-Instances eines bestimmten Instance-Typs analysieren.](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/instance-types.html)
Das Hinzufügen weiterer Dimensionen erhöht Ihre Analysefähigkeit, erhöht aber auch Ihre Gesamtkosten, da jede Kombination aus Metrik und eindeutigem Dimensionswert zu einer neuen Metrik führt. Wenn Sie beispielsweise eine Metrik für die prozentuale Speicherauslastung im Vergleich zur `InstanceId` Dimension erstellen, ist dies eine neue Metrik für jede EC2-Instance. Wenn Ihr Unternehmen Tausende von EC2-Instances betreibt, verursacht dies Tausende von Metriken und führt zu höheren Kosten. Um die Kosten zu kontrollieren und vorherzusagen, stellen Sie sicher, dass Sie die Kardinalität der Metrik bestimmen und festlegen, welche Dimensionen den größten Mehrwert bieten. Sie könnten beispielsweise einen vollständigen Satz von Dimensionen für Ihre Kennzahlen zur Produktionsauslastung definieren, aber eine kleinere Teilmenge dieser Dimensionen für Workloads außerhalb der Produktion.
Sie können die `append_dimensions` Eigenschaft verwenden, um Dimensionen zu einer oder allen in Ihrer Konfiguration definierten Metriken hinzuzufügen. CloudWatch Sie können`ImageId`,`InstanceId`, `InstanceType` und `AutoScalingGroupName` auch dynamisch an alle Metriken in Ihrer CloudWatch Konfiguration anhängen. Alternativ können Sie einen beliebigen Dimensionsnamen und -wert für bestimmte Metriken anhängen, indem Sie die `append_dimensions` Eigenschaft für diese Metrik verwenden. CloudWatch kann auch Statistiken zu metrischen Dimensionen aggregieren, die Sie mit der `aggregation_dimensions` Eigenschaft definiert haben.
Sie könnten beispielsweise den verwendeten Speicher gegen die `InstanceType` Dimension aggregieren, um den durchschnittlichen Speicherverbrauch aller EC2-Instances für jeden Instance-Typ zu ermitteln. Wenn Sie `t2.micro` Instances verwenden, die in einer Region ausgeführt werden, könnten Sie feststellen, ob Workloads, die die `t2.micro` Klasse verwenden, den bereitgestellten Speicher über- oder unterbeanspruchen. Eine Unterauslastung kann ein Zeichen dafür sein, dass Workloads EC2-Klassen mit nicht benötigter Speicherkapazität verwenden. Im Gegensatz dazu kann eine Überauslastung ein Zeichen dafür sein, dass Workloads Amazon EC2 EC2-Klassen mit unzureichendem Arbeitsspeicher verwenden.
Das folgende Diagramm zeigt ein Beispiel für eine CloudWatch Metrikkonfiguration, die einen benutzerdefinierten Namespace, zusätzliche Dimensionen und Aggregation von verwendet. `InstanceType`
![\[Beispiel für eine CloudWatch Metrikkonfiguration mit einem Agenten CloudWatch .\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/cloudwatch-image-2.png)
# Konfiguration auf Systemebene CloudWatch
Metriken und Protokolle auf Systemebene sind eine zentrale Komponente einer Überwachungs- und Protokollierungslösung, und der CloudWatch Agent verfügt über spezifische Konfigurationsoptionen für Windows und Linux.
Es wird empfohlen, den [CloudWatch Konfigurationsdatei-Assistenten oder das Konfigurationsdateischema](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) zu verwenden, um die CloudWatch Agentenkonfigurationsdatei für jedes Betriebssystem zu definieren, das Sie unterstützen möchten. Zusätzliche Workload-spezifische Protokolle und Metriken auf Betriebssystemebene können in separaten CloudWatch Konfigurationsdateien definiert und an die Standardkonfiguration angehängt werden. Diese eindeutigen Konfigurationsdateien sollten separat in einem S3-Bucket gespeichert werden, wo sie von Ihren EC2-Instances abgerufen werden können. Ein Beispiel für ein S3-Bucket-Setup für diesen Zweck wird im [CloudWatch Konfigurationen verwalten](create-store-cloudwatch-configurations.md#store-cloudwatch-configuration-s3) Abschnitt dieses Handbuchs beschrieben. Sie können diese Konfigurationen mit State Manager und Distributor automatisch abrufen und anwenden.
## Konfiguration von Protokollen auf Systemebene
Protokolle auf Systemebene sind für die Diagnose und Behebung von Problemen vor Ort oder in der Cloud unerlässlich. AWS Ihr Ansatz zur Protokollerfassung sollte alle vom Betriebssystem generierten System- und Sicherheitsprotokolle beinhalten. Die vom Betriebssystem generierten Protokolldateien können je nach Betriebssystemversion unterschiedlich sein.
Der CloudWatch Agent unterstützt die Überwachung von Windows-Ereignisprotokollen, indem er den Namen des Ereignisprotokolls angibt. Sie können wählen, welche Windows-Ereignisprotokolle Sie überwachen möchten (z. B. `System``Application`, oder`Security`).
Die System-, Anwendungs- und Sicherheitsprotokolle für Linux-Systeme werden normalerweise im `/var/log` Verzeichnis gespeichert. In der folgenden Tabelle sind die allgemeinen Standardprotokolldateien definiert, die Sie überwachen sollten. Sie sollten jedoch die `/etc/rsyslog.conf` `/etc/syslog.conf` OR-Datei überprüfen, um die spezifische Konfiguration der Protokolldateien Ihres Systems zu ermitteln.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/system-level-cloudwatch-configuration.html)
Möglicherweise verfügt Ihr Unternehmen auch über andere Agenten oder Systemkomponenten, die Protokolle generieren, die Sie überwachen möchten. Sie sollten auswerten und entscheiden, welche Protokolldateien von diesen Agenten oder Anwendungen generiert werden, und sie in Ihre Konfiguration aufnehmen, indem Sie ihren Dateispeicherort angeben. Sie sollten beispielsweise die Systems Manager- und CloudWatch Agentenprotokolle in Ihre Konfiguration aufnehmen. Die folgende Tabelle enthält den Speicherort dieser Agentenprotokolle für Windows und Linux.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/system-level-cloudwatch-configuration.html)
CloudWatch ignoriert eine Protokolldatei, wenn die Protokolldatei in der CloudWatch Agentenkonfiguration definiert, aber nicht gefunden wurde. Dies ist nützlich, wenn Sie eine einzige Protokollkonfiguration für Linux beibehalten möchten, anstatt separate Konfigurationen für jede Distribution zu verwenden. Dies ist auch nützlich, wenn eine Protokolldatei erst existiert, wenn der Agent oder die Softwareanwendung gestartet wird.
## Konfiguration von Metriken auf Systemebene
Die Auslastung von Arbeitsspeicher und Festplattenspeicher ist nicht in den Standardmetriken von Amazon EC2 enthalten. Um diese Metriken einzubeziehen, müssen Sie den CloudWatch Agenten auf Ihren EC2-Instances installieren und konfigurieren. Der Assistent zur CloudWatch Agentenkonfiguration erstellt eine CloudWatch Konfiguration mit [vordefinierten Metriken](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html#cloudwatch-agent-preset-metrics), und Sie können Metriken nach Bedarf hinzufügen oder entfernen. Vergewissern Sie sich, dass Sie die vordefinierten Metriksätze überprüfen, um zu ermitteln, welche Stufe Sie benötigen.
Endbenutzer und Workload-Besitzer sollten zusätzliche Systemmetriken veröffentlichen, die auf spezifischen Anforderungen für einen Server oder eine EC2-Instance basieren. Diese Metrikdefinitionen sollten in einer separaten CloudWatch Agentenkonfigurationsdatei gespeichert, versioniert und verwaltet und zur Wiederverwendung und Automatisierung an einem zentralen Ort (z. B. Amazon S3) gemeinsam genutzt werden.
Standardmetriken von Amazon EC2 werden nicht automatisch auf lokalen Servern erfasst. Diese Metriken müssen in einer CloudWatch Agent-Konfigurationsdatei definiert werden, die von den lokalen Instances verwendet wird. Sie können eine separate Metrik-Konfigurationsdatei für lokale Instances mit Metriken wie der CPU-Auslastung erstellen und diese Metriken an die Standard-Metrik-Konfigurationsdatei anhängen lassen.
# Konfiguration auf Anwendungsebene CloudWatch
Anwendungsprotokolle und Metriken werden bei der Ausführung von Anwendungen generiert und sind anwendungsspezifisch. Stellen Sie sicher, dass Sie die Protokolle und Metriken definieren, die erforderlich sind, um Anwendungen, die regelmäßig von Ihrem Unternehmen verwendet werden, angemessen zu überwachen. Beispielsweise könnte Ihre Organisation Microsoft Internet Information Server (IIS) für webbasierte Anwendungen standardisiert haben. Sie können eine Standardprotokoll- und CloudWatch Metrikkonfiguration für IIS erstellen, die auch in Ihrer gesamten Organisation verwendet werden kann. Anwendungsspezifische Konfigurationsdateien können an einem zentralen Ort gespeichert werden (z. B. in einem S3-Bucket). Workload-Besitzer können darauf zugreifen oder sie automatisch abrufen und in das CloudWatch Konfigurationsverzeichnis kopieren. Der CloudWatch Agent kombiniert automatisch CloudWatch Konfigurationsdateien, die sich im Konfigurationsdateiverzeichnis jeder EC2-Instanz oder jedes EC2-Servers befinden, zu einer zusammengesetzten Konfiguration. CloudWatch Das Endergebnis ist eine CloudWatch Konfiguration, die die Standardkonfiguration Ihres Unternehmens auf Systemebene sowie alle relevanten Konfigurationen auf Anwendungsebene umfasst. CloudWatch
Workload-Besitzer sollten Protokolldateien und Metriken für alle wichtigen Anwendungen und Komponenten identifizieren und konfigurieren.
## Konfiguration von Protokollen auf Anwendungsebene
Die Protokollierung auf Anwendungsebene hängt davon ab, ob es sich bei der Anwendung um eine kommerzielle off-the-shelf (COTS) oder eine individuell entwickelte Anwendung handelt. COTS-Anwendungen und ihre Komponenten bieten möglicherweise mehrere Optionen für die Protokollkonfiguration und -ausgabe, z. B. die Protokolldetailebene, das Protokolldateiformat und den Speicherort der Protokolldatei. Bei den meisten COTS- oder Drittanbieteranwendungen ist es Ihnen jedoch nicht möglich, die Protokollierung grundlegend zu ändern (z. B. den Code der Anwendung so zu aktualisieren, dass er zusätzliche Protokollanweisungen oder Formate enthält, die nicht konfigurierbar sind). Sie sollten zumindest die Protokollierungsoptionen für COTS oder Drittanbieteranwendungen so konfigurieren, dass Informationen zu Warnungen und Fehlern protokolliert werden, vorzugsweise im JSON-Format.
Sie können individuell entwickelte Anwendungen in CloudWatch Logs integrieren, indem Sie die Protokolldateien der Anwendung in Ihre Konfiguration aufnehmen. CloudWatch Benutzerdefinierte Anwendungen bieten eine bessere Protokollqualität und Kontrolle, da Sie das Protokollausgabeformat anpassen, die Komponentenausgabe kategorisieren und in separate Protokolldateien unterteilen und zusätzlich alle zusätzlichen erforderlichen Details angeben können. Stellen Sie sicher, dass Sie die Protokollierungsbibliotheken und die erforderlichen Daten und Formatierungen für Ihr Unternehmen überprüfen und standardisieren, damit Analyse und Verarbeitung einfacher werden.
Sie können auch mit dem CloudWatch CloudWatch `[PutLogEvents](https://docs.aws.amazon.com//AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)` Logs-API-Aufruf oder mithilfe des AWS SDK in einen Protokollstream schreiben. Sie können die API oder das SDK für benutzerdefinierte Protokollierungsanforderungen verwenden, z. B. für die Koordination der Protokollierung in einem einzigen Protokollstream über eine verteilte Gruppe von Komponenten und Servern. Die am einfachsten zu wartende und am weitesten verbreitete Lösung besteht jedoch darin, Ihre Anwendungen so zu konfigurieren, dass sie in Protokolldateien schreiben und dann den CloudWatch Agenten zum Lesen und Streamen der Protokolldateien verwenden. CloudWatch
Sie sollten auch die Art der Metriken berücksichtigen, die Sie anhand Ihrer Anwendungsprotokolldateien messen möchten. Sie können Metrikfilter verwenden, um diese Daten in einer CloudWatch Protokollgruppe zu messen, grafisch darzustellen und Warnmeldungen zu erstellen. Sie können beispielsweise einen Metrikfilter verwenden, um fehlgeschlagene Anmeldeversuche zu zählen, indem Sie sie in Ihren Protokollen identifizieren.
Sie können auch benutzerdefinierte Metriken für Ihre speziell entwickelten Anwendungen erstellen, indem Sie das [https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) in Ihren Anwendungsprotokolldateien verwenden.
## Konfiguration von Metriken auf Anwendungsebene
Benutzerdefinierte Metriken sind Metriken, die nicht direkt von AWS Services to CloudWatch bereitgestellt werden. Sie werden in einem benutzerdefinierten Namespace unter Metriken veröffentlicht. CloudWatch Alle Anwendungsmetriken werden als benutzerdefinierte CloudWatch Metriken betrachtet. Anwendungsmetriken können einer EC2-Instance, einer Anwendungskomponente, einem API-Aufruf oder sogar einer Geschäftsfunktion entsprechen. Sie müssen auch die Wichtigkeit und Kardinalität der Dimensionen berücksichtigen, die Sie für Ihre Metriken auswählen. Dimensionen mit hoher Kardinalität generieren eine große Anzahl von benutzerdefinierten Metriken und können Ihre Kosten in die Höhe treiben. CloudWatch
CloudWatch hilft Ihnen dabei, Metriken auf Anwendungsebene auf verschiedene Arten zu erfassen, unter anderem auf folgende Weise:
+ [Erfassen Sie Metriken auf Prozessebene, indem Sie die einzelnen Prozesse definieren, die Sie mit dem procstat-Plugin erfassen möchten.](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-procstat-process-metrics.html)
+ Eine Anwendung veröffentlicht eine Metrik im Windows Performance Monitor, und diese Metrik ist in der Konfiguration definiert. CloudWatch
+ Metrische Filter und Muster werden auf die Anmeldedaten einer Anwendung angewendet CloudWatch.
+ Eine Anwendung schreibt mithilfe des CloudWatch eingebetteten metrischen Formats in ein CloudWatch Protokoll.
+ Eine Anwendung sendet CloudWatch über die API oder das AWS SDK eine Metrik an.
+ Eine Anwendung sendet eine Metrik an einen [Collectd](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-collectd.html) - oder [StatsD-Daemon](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-statsd.html) mit einem konfigurierten Agenten. CloudWatch
Sie können procstat verwenden, um kritische Anwendungsprozesse mit dem Agenten zu überwachen und zu messen. CloudWatch Auf diese Weise können Sie einen Alarm auslösen und Maßnahmen ergreifen (z. B. eine Benachrichtigung oder einen Neustartprozess), wenn ein kritischer Prozess für Ihre Anwendung nicht mehr läuft. Sie können auch die Leistungsmerkmale Ihrer Anwendungsprozesse messen und einen Alarm auslösen, wenn sich ein bestimmter Prozess ungewöhnlich verhält.
Die Procstat-Überwachung ist auch nützlich, wenn Sie Ihre COTS-Anwendungen nicht mit zusätzlichen benutzerdefinierten Messwerten aktualisieren können. Sie können beispielsweise eine `my_process` Metrik erstellen, die das misst `cpu_time` und eine benutzerdefinierte `application_version` Dimension enthält. Sie können auch mehrere CloudWatch Agentenkonfigurationsdateien für eine Anwendung verwenden, wenn Sie unterschiedliche Dimensionen für verschiedene Metriken haben.
Wenn Ihre Anwendung unter Windows ausgeführt wird, sollten Sie prüfen, ob sie bereits Metriken im Windows Performance Monitor veröffentlicht. Viele COTS-Anwendungen sind in den Windows-Leistungsmonitor integriert, sodass Sie Anwendungsmetriken einfach überwachen können. CloudWatch lässt sich auch in den Windows Performance Monitor integrieren, sodass Sie alle Messwerte erfassen können, die bereits darin verfügbar sind.
Stellen Sie sicher, dass Sie das von Ihren Anwendungen bereitgestellte Protokollierungsformat und die Protokollinformationen überprüfen, um festzustellen, welche Metriken mit Metrikfiltern extrahiert werden können. Sie könnten die historischen Protokolle der Anwendung überprüfen, um festzustellen, wie Fehlermeldungen und ungewöhnliche Abschaltungen dargestellt werden. Sie sollten auch zuvor gemeldete Probleme überprüfen, um festzustellen, ob eine Kennzahl erfasst werden kann, um zu verhindern, dass sich das Problem wiederholt. Sie sollten auch die Dokumentation der Anwendung lesen und die Anwendungsentwickler bitten, zu bestätigen, wie Fehlermeldungen identifiziert werden können.
Definieren Sie bei kundenspezifisch entwickelten Anwendungen gemeinsam mit den Entwicklern der Anwendung wichtige Metriken, die mithilfe des CloudWatch eingebetteten metrischen Formats, des AWS SDK oder der AWS API implementiert werden können. Der empfohlene Ansatz besteht darin, das eingebettete metrische Format zu verwenden. Sie können die AWS bereitgestellten Open-Source-Bibliotheken für eingebettete metrische Formate verwenden, um Ihre Aussagen im erforderlichen Format zu verfassen. Außerdem müssten Sie Ihre [anwendungsspezifische CloudWatch Konfiguration](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Generation_CloudWatch_Agent.html) aktualisieren, um den eingebetteten metrischen Format-Agenten einzubeziehen. Dadurch fungiert der auf der EC2-Instance ausgeführte Agent als lokaler eingebetteter Endpunkt im metrischen Format, an den eingebettete Metriken im metrischen Format gesendet werden. CloudWatch
Wenn Ihre Anwendungen bereits die Veröffentlichung von Metriken für gesammelte oder statistische Daten unterstützen, können Sie diese nutzen, um Metriken in diese zu importieren. CloudWatch