Referenz zum CloudWatch-Logs-Agenten

Wichtig

Diese Referenz gilt für den älteren, überholten CloudWatch-Logs-Agenten. Wenn Sie Instance-Metadaten-Service-Version 2 (IMDSv2) verwenden, müssen Sie den neuen einheitlichen CloudWatch-Agenten verwenden. Auch wenn Sie IMDSv2 nicht verwenden, empfehlen wir dringend, den neueren einheitlichen CloudWatch-Agenten anstelle des älteren Protokollagenten zu verwenden. Weitere Informationen über diesen neueren einheitlichen Agenten finden Sie unter Erfassen von Metriken und Protokollen von Amazon-EC2-Instances und On-Premises-Servern mit dem CloudWatch-Agent.

Weitere Informationen zur Migration vom älteren CloudWatch-Logs-Agenten zum einheitlichen Agenten finden Sie unter Erstellen der Konfigurationsdatei des CloudWatch-Agenten mit dem Assistenten.

Der CloudWatch-Logs-Agent bietet eine automatisierte Methode, von Amazon-EC2-Instances aus Protokolldaten an CloudWatch Logs zu senden. Der Agent enthält die folgenden Komponenten:

• Ein Plug-In in der AWS CLI, der die Protokolldaten an CloudWatch Logs überträgt.

• Ein Skript (Daemon), das den Prozess startet, Daten an CloudWatch Logs zu übertragen.

• Ein Cron-Auftrag, der sicherstellt, dass der Daemon ständig ausgeführt wird.

Agent-Konfigurationsdatei

Die CloudWatch-Logs-Agent-Konfigurationsdatei beschreibt Informationen, die für den CloudWatch-Logs-Agent erforderlich sind. Im Abschnitt [general] der Agent-Konfigurationsdatei werden gängige Konfigurationen definiert, die für alle Protokoll-Streams gelten. Im Abschnitt [logstream] werden die erforderlichen Informationen zum Senden einer lokalen Datei an einen Remote-Protokoll-Stream definiert. Sie können mehrere [logstream]-Abschnitte definieren, von denen aber jeder einen eindeutigen Namen innerhalb der Konfigurationsdatei haben muss, z. B. [logstream1], [logstream2] und so weiter. Der Wert von [logstream] sowie die erste Datenzeile in der Protokolldatei definieren die Identität der Protokolldatei.

[general]
state_file = value
logging_config_file = value
use_gzip_http_content_encoding = [true | false]

[logstream1]
log_group_name = value
log_stream_name = value
datetime_format = value
time_zone = [LOCAL|UTC]
file = value
file_fingerprint_lines = integer | integer-integer
multi_line_start_pattern = regex | {datetime_format}
initial_position = [start_of_file | end_of_file]
encoding = [ascii|utf_8|..]
buffer_duration = integer
batch_count = integer
batch_size = integer

[logstream2]
...

state_file

Gibt an, wo die Zustandsdatei gespeichert ist.

logging_config_file

(Optional) Gibt an, wo sich die Konfigurationsdatei für die Agent-Protokollierung befindet. Wenn Sie keine Konfigurationsdatei für die Agent-Protokollierung angeben, wird immer die Standarddatei awslogs.conf verwendet. Der Standardspeicherort der Datei ist /var/awslogs/etc/awslogs.conf, wenn Sie den Agenten mit einem Skript installiert haben, und /etc/awslogs/awslogs.conf, wenn Sie den Agenten mit rpm installiert haben. Die Datei ist im Python-Format für Konfigurationsdateien (https://docs.python.org/2/library/logging.config.html#logging-config-fileformat) geschrieben. Logger mit den folgenden Namen können angepasst werden.

cwlogs.push
cwlogs.push.reader
cwlogs.push.publisher
cwlogs.push.event
cwlogs.push.batch
cwlogs.push.stream
cwlogs.push.watcher

Im unten stehenden Beispiel ändert sich die Ebene für Reader und Veröffentlicher auf WARNUNG, während der Standardwert INFO lautet.

[loggers]
keys=root,cwlogs,reader,publisher
            
[handlers]
keys=consoleHandler
            
[formatters]
keys=simpleFormatter
           
[logger_root]
level=INFO
handlers=consoleHandler
            
[logger_cwlogs]
level=INFO
handlers=consoleHandler
qualname=cwlogs.push
propagate=0
            
[logger_reader]
level=WARNING
handlers=consoleHandler
qualname=cwlogs.push.reader
propagate=0
            
[logger_publisher]
level=WARNING
handlers=consoleHandler
qualname=cwlogs.push.publisher
propagate=0
            
[handler_consoleHandler]
class=logging.StreamHandler
level=INFO
formatter=simpleFormatter
args=(sys.stderr,)
            
[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(process)d - %(threadName)s - %(message)s

use_gzip_http_content_encoding

Wenn dieser Wert auf true (Standard) gesetzt ist, kann HTTP-Inhaltsverschlüsselung GZIP-komprimierte Nutzlasten an CloudWatch Logs senden. Dies verringert die CPU-Auslastung, reduziert NetworkOut und senkt die Put-Latenz. Um diese Funktion zu deaktivieren, fügen Sie use_gzip_http_content_encoding = false im Abschnitt [general] der CloudWatch-Logs-Agent-Konfigurationsdatei ein. Starten Sie dann den Agent neu.

Anmerkung

Diese Einstellung ist nur awscli-cwlogs Version 1.3.3 und höher verfügbar.

log_group_name

Gibt die Ziel-Protokollgruppe an. Eine Protokollgruppe wird automatisch erstellt, sofern diese nicht bereits vorhanden ist. Protokollgruppennamen können zwischen 1 und 512 Zeichen lang sein. Zulässige Zeichen sind a – z, A – Z, 0 – 9, "_" (Unterstrich), "-" (Bindestrich), "/" (Schrägstrich) und "." (Punkt).

log_stream_name

Gibt den Ziel-Protokoll-Stream an. Sie können den Protokoll-Stream-Namen mithilfe einer Literalzeichenfolge oder den vordefinierten Variablen ({instance_id}, {hostname} und {ip_address}) oder einer Kombination aus beiden definieren. Ein Protokoll-Stream wird automatisch erstellt, sofern dieser nicht bereits vorhanden ist.

datetime_format

Gibt an, wie der Zeitstempel aus Protokollen extrahiert wird. Der Zeitstempel wird zum Abrufen von Protokollereignissen und Generieren von Metriken verwendet. Wenn datetime_format nicht angegeben ist, wird für die einzelnen Protokollereignisse die aktuelle Uhrzeit verwendet. Wenn der vorhandene Wert datetime_format für eine bestimmte Protokollnachricht ungültig ist, wird der Zeitstempel ab dem letzten Protokollereignis mit erfolgreich analysiertem Zeitstempel verwendet. Sind keine vorherigen Protokollereignisse vorhanden, wird die aktuelle Uhrzeit verwendet.

Die häufig verwendeten datetime_format-Codes sind unten aufgeführt. Sie können auch alle datetime_format-Codes verwenden, die von Python, datetime.strptime() unterstützt werden. Der Zeitzonenversatz (%z) wird ebenfalls unterstützt, wenn auch nur bis python 3.2, [+ -]HHMM ohne Doppelpunkt (:). Weitere Informationen finden Sie unter strftime()- und strptime ()-Verhalten.

%y: Jahr ohne Jahrhundert als mit Nullen aufgefüllte Dezimalzahl. 00, 01, ..., 99

%Y: Jahr mit Jahrhundert als Dezimalzahl.1970, 1988, 2001, 2013

%b: Monat als regionale Abkürzung des Namens. Jan, Feb, ..., Dec (en_US);

%B: Vollständiger regionaler Name des Monats. January, February, ..., December (en_US);

%m: Monat als mit Nullen aufgefüllte Dezimalzahl. 01, 02, ..., 12

%d: Tag des Monats als mit Nullen aufgefüllte Dezimalzahl. 01, 02, ..., 31

%H: Stunde (24-Stunden) als mit Nullen aufgefüllte Dezimalzahl. 00, 01, ..., 23

%I: Stunde (12-Stunden) als mit Nullen aufgefüllte Dezimalzahl. 01, 02, ..., 12

%p: Regionales Äquivalent für AM oder PM.

%M: Minute als mit Nullen aufgefüllte Dezimalzahl. 00, 01, ..., 59

%S: Sekunde als mit Nullen aufgefüllte Dezimalzahl. 00, 01, ..., 59

%f: Mikrosekunde als links mit Nullen aufgefüllte Dezimalzahl. 000000, ..., 999999

%z: UTC-Verschiebung in Form von +HHMM oder -HHMM. +0000, -0400, +1030

Beispielformate:

Syslog: '%b %d %H:%M:%S', e.g. Jan 23 20:59:29

Log4j: '%d %b %Y %H:%M:%S', e.g. 24 Jan 2014 05:00:00

ISO8601: '%Y-%m-%dT%H:%M:%S%z', e.g. 2014-02-20T05:20:20+0000

time_zone

Gibt die Zeitzone des Zeitstempels des Protokollereignisses an. Die beiden unterstützten Werte sind UTC und LOCAL. Standardmäßig wird LOCAL verwendet, wenn die Zeitzone nicht von datetime_format abgeleitet werden kann.

file

Gibt die Protokolldateien an, die an CloudWatch Logs übertragen werden sollen. Die Datei kann auf eine bestimmte Datei oder mehrere Dateien (mit Platzhaltern wie /var/log/system.log*) verweisen. Nur die aktuelle Datei wird basierend auf dem Änderungsdatum der Datei an CloudWatch Logs übertragen. Wir empfehlen, dass Sie eine Reihe von Platzhaltern angeben, z. B. Dateien desselben Typs, access_log.2014-06-01-01, access_log.2014-06-01-02 und so weiter, 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 Konfigurationsdatei einen anderen Protokoll-Stream-Eintrag hinzu, damit jede Art von Protokolldatei in verschiedene Protokoll-Streams gestellt wird. Komprimierte Dateien werden nicht unterstützt.

file_fingerprint_lines

Gibt den Bereich von Zeilen an, über die eine Datei identifiziert wird. Gültige Werte sind eine Zahl oder zwei durch Gedankenstriche getrennten Zahlen, wie "1", "2-5". Der Standardwert ist 1, damit die erste Zeile für die Berechnung des Fingerabdrucks verwendet wird. Fingerabdruck-Zeilen werden nicht an CloudWatch Logs gesendet, es sei denn, alle angegebenen Zeilen sind verfügbar.

multi_line_start_pattern

Gibt das Muster an, anhand dessen der Beginn einer Protokolldatei identifiziert wird. Eine Protokollmeldung besteht aus einer Zeile, die mit dem angegebenen Muster übereinstimmt, und allen folgenden Zeilen, die nicht dem Muster entsprechen. Gültige Werte sind reguläre Ausdrücke oder {datetime_format} Bei der Verwendung von {datetime_format} muss die Option "datetime_format" angegeben werden. Der Standardwert ist "^ [^\s]", sodass bei jeder Zeile, die mit Zeichen ohne Leerzeichen beginnt, die vorherige Protokollmeldung abgeschlossen wird und eine neue Protokollnachricht startet.

initial_position

Gibt an, wo der Anfang zum Lesen der Daten ist (start_of_file oder end_of_file). Der Standardwert ist start_of_file. Es wird nur verwendet, wenn für diesen Protokoll-Stream kein Zustand besteht.

encoding

Gibt die Verschlüsselung der Protokolldatei an, damit die Datei korrekt gelesen werden kann. Der Standardwert ist utf_8. Hier können von Python codecs.decode() unterstützte Verschlüsselungen verwendet werden.

Warnung

Die Angabe einer fehlerhaften Kodierung kann zu Datenverlust führen, weil Zeichen, die nicht dekodiert werden können, durch ein anderes Zeichen ersetzt werden.

Im Folgenden sind einige gängige Kodierungen aufgeführt:

ascii, big5, big5hkscs, cp037, cp424, cp437, cp500, cp720, cp737, cp775, cp850, cp852, cp855, cp856, cp857, cp858, cp860, cp861, cp862, cp863, cp864, cp865, cp866, cp869, cp874, cp875, cp932, cp949, cp950, cp1006, cp1026, cp1140, cp1250, cp1251, cp1252, cp1253, cp1254, cp1255, cp1256, cp1257, cp1258, euc_jp, euc_jis_2004, euc_jisx0213, euc_kr, gb2312, gbk, gb18030, hz, iso2022_jp, iso2022_jp_1, iso2022_jp_2, iso2022_jp_2004, iso2022_jp_3, iso2022_jp_ext, iso2022_kr, latin_1, iso8859_2, iso8859_3, iso8859_4, iso8859_5, iso8859_6, iso8859_7, iso8859_8, iso8859_9, iso8859_10, iso8859_13, iso8859_14, iso8859_15, iso8859_16, johab, koi8_r, koi8_u, mac_cyrillic, mac_greek, mac_iceland, mac_latin2, mac_roman, mac_turkish, ptcp154, shift_jis, shift_jis_2004, shift_jisx0213, utf_32, utf_32_be, utf_32_le, utf_16, utf_16_be, utf_16_le, utf_7, utf_8, utf_8_sig

buffer_duration

Gibt die Dauer für die Stapelverarbeitung von Protokollereignissen an. Der Mindestwert und der Standardwert ist 5 000ms.

batch_count

Gibt die maximale Anzahl der Protokollereignisse in einem Stapel an, bis zu 10.000. Der Standardwert lautet 10.000.

batch_size

Gibt die maximale Größe von Protokollereignissen in einem Stapel in Byte an, bis zu 1048576 Byte. Der Standardwert lautet 1048576 Bytes. Diese Größe ist die Summe aller Ereignismeldungen in UTF-8 plus 26 Bytes pro Protokollereignis.

Verwendung des CloudWatch-Logs-Agenten mit HTTP-Proxys

Sie können den CloudWatch-Logs-Agent mit HTTP-Proxys verwenden.

Anmerkung

HTTP-Proxys werden in awslogs-agent-setup.py Version 1.3.8 oder höher unterstützt.

Verwendung des CloudWatch-Logs-Agent mit HTTP-Proxys

1. Führen Sie eine der folgenden Aktionen aus:

   1. Für eine Neuinstallation des CloudWatch-Logs-Agent, führen Sie die folgenden Befehle aus:

      curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O

      sudo python awslogs-agent-setup.py --region us-east-1 --http-proxy http://your/proxy --https-proxy http://your/proxy --no-proxy 169.254.169.254

      Um den Zugriff auf den Amazon-EC2-Metadatenservice für EC2-Instances zu behalten, verwenden Sie --no-proxy 169.254.169.254 (empfohlen). Weitere Informationen finden Sie unter Instance-Metadaten und Benutzerdaten im Amazon EC2-Benutzerhandbuch für Linux-Instances.

      Geben Sie in den Werten für http-proxy und https-proxy die gesamte URL ein.

   2. Zum Bearbeiten einer vorhandenen Installation des CloudWatch-Logs-Agent fügen Sie die Proxys in /var/awslogs/etc/proxy.conf hinzu:

      HTTP_PROXY=
      HTTPS_PROXY=
      NO_PROXY=

2. Starten Sie den Agenten, damit die Änderungen wirksam werden:

   sudo service awslogs restart

   Wenn Sie Amazon Linux 2 verwenden, verwenden Sie den folgenden Befehl, um den Agenten neu zu starten:

   sudo service awslogsd restart

Aufgliedern der Konfigurationsdateien für den CloudWatch-Logs-Agenten

Wenn Sie awslogs-agent-setup.py Version 1.3.8 oder höher mit awscli-cwlogs 1.3.3 oder höher verwenden, können Sie verschiedene Stream-Konfigurationen für verschiedene Komponenten unabhängig voneinander importieren, indem Sie zusätzliche Konfigurationsdateien im Verzeichnis /var/awslogs/etc/config/ erstellen. Wenn der CloudWatch-Logs-Agent gestartet wird, umfasst er sämtliche Stream-Konfigurationen in diesen zusätzlichen Konfigurationsdateien. Konfigurationseigenschaften im Abschnitt [general] müssen in der Haupt-Konfigurationsdatei (/var/awslogs/etc/awslogs.conf) definiert werden und werden in den anderen unter /var/awslogs/etc/config/ vorhandenen Konfigurationsdateien ignoriert.

Wenn Sie kein /var/awslogs/etc/config/-Verzeichnis haben, weil Sie den Agenten mit rpm installiert haben, können Sie stattdessen das Verzeichnis /etc/awslogs/config/ verwenden.

Starten Sie den Agenten, damit die Änderungen wirksam werden:

sudo service awslogs restart

Wenn Sie Amazon Linux 2 verwenden, verwenden Sie den folgenden Befehl, um den Agenten neu zu starten:

sudo service awslogsd restart

Häufig gestellte Fragen zum CloudWatch-Logs-Agenten

Welche Arten von Dateirotationen werden unterstützt?

Folgende Dateirotationsmechanismen werden unterstützt:

• Umbenennen vorhandener Protokolldateien mit einem numerischen Suffix, anschließendes Neuerstellen der ursprünglichen leeren Protokolldatei. Z. B. /var/log/syslog.log is renamed /var/log/syslog.log.1. Wenn /var/log/syslog.log.1 bereits aus einem vorherigen Durchgang vorhanden ist, wird es in /var/log/syslog.log.2 umbenannt.

• Kürzen der ursprünglichen Protokolldatei nach der Erstellung einer Kopie. Beispielsweise wird /var/log/syslog.log in /var/log/syslog.log.1 kopiert und /var/log/syslog.log wird gekürzt. In diesem Fall können Datenverluste entstehen. Verwenden Sie diesen Dateirotationsmechanismus also mit Bedacht.

• Erstellen einer neuen Datei mit dem gemeinsamen Muster der alten Datenbank. Beispielsweise bleibt /var/log/syslog.log.2014-01-01 bestehen und /var/log/syslog.log.2014-01-02 wird erstellt.

Der Fingerabdruck (Quell-ID) der Datei wird berechnet, indem ein Hash für den Protokoll-Stream-Schlüssel und die erste Zeile in der Datei durchgeführt wird. Zum Überschreiben dieses Verhaltens kann die Option file_fingerprint_lines verwendet werden. Bei einer Rotation sollte die neue Datei neue Inhalte haben, und die alte Datei sollte keine angehängten Inhalte haben. Der Agent überträgt die neue Datei, wenn der Lesevorgang der alten Datei abgeschlossen ist.

Wie kann ich bestimmen, welche Agent-Version ich verwende?

Wenn Sie ein Einrichtungsskript für die Installation des CloudWatch-Logs-Agent verwendet haben, können Sie mit /var/awslogs/bin/awslogs-version.sh prüfen, welche Agent-Version Sie verwenden. Dabei werden die Version des Agent und seine großen Abhängigkeiten gedruckt. Wenn Sie den CloudWatch-Logs-Agent mit yum installiert haben, können Sie die Version des CloudWatch-Logs-Agent und Plug-Ins mit "yum info awslogs" und "yum info aws-cli-plugin-cloudwatch-logs" prüfen.

Wie werden Protokolleinträge in Protokollereignisse umgewandelt?

Protokollereignisse enthalten zwei Eigenschaften: den Zeitstempel mit Datum und Uhrzeit des Ereignisses und die reine Protokollnachricht. Standardmäßig wird bei jeder Zeile , die mit Zeichen ohne Leerzeichen beginnt, die vorherige Protokollnachricht (falls vorhanden) abgeschlossen und eine neue Protokollnachricht gestartet. Um dieses Verhalten zu überschreiben, kann multi_line_start_pattern verwendet werden, und bei jeder Zeile, die mit dem Muster übereinstimmt, wird eine neue Protokollnachricht gestartet. Das Muster ist ein regulärer Ausdruck oder '{datetime_format}'. Wenn beispielsweise die erste Zeile in jeder Protokollnachricht einen Zeitstempel wie z. B."2014-01-02T13:13:01Z" enthält, kann das multi_line_start_pattern auf "\d\{4\}-\d\{2\}-\d\{2\}T\d\{2\}:\d\{2\}:\d\{2\}Z" gesetzt werden. Zum Vereinfachen der Konfiguration, kann die Variable '{datetime_format}' verwendet werden, wenn datetime_format option angegeben ist. Für dasselbe Beispiel gilt, wenn datetime_format auf '%Y-%m-%dT%H:%M:%S%z' gesetzt ist, dann könnte multi_line_start_pattern einfach '{datetime_format}' sein.

Wenn datetime_format nicht angegeben ist, wird für die einzelnen Protokollereignisse die aktuelle Uhrzeit verwendet. Wenn der vorhandene Wert datetime_format für eine bestimmte Protokollnachricht ungültig ist, wird der Zeitstempel ab dem letzten Protokollereignis mit erfolgreich analysiertem Zeitstempel verwendet. Sind keine vorherigen Protokollereignisse vorhanden, wird die aktuelle Uhrzeit verwendet. Eine Warnmeldung wird protokolliert, wenn ein Protokollereignis auf die aktuelle Uhrzeit oder den Zeitpunkt des vorherigen Protokollereignisses zurückgreift.

Zeitstempel dienen zum Abrufen von Protokollereignissen und Generieren von Metriken. Wenn Sie das falsche Format angeben, könnten die Protokollereignisse nicht abrufbar werden, und es werden falsche Metriken generiert.

Wie werden Protokollereignisse im Stapel verarbeitet?

Eine Stapel ist voll und wird veröffentlicht, wenn eine der folgenden Bedingungen erfüllt ist:

1. Der Zeitraum buffer_duration ist abgelaufen, nachdem das erste Protokollereignis hinzugefügt wurde.

2. Weniger als batch_size der Protokollereignisse wurden akkumuliert, aber durch das Hinzufügen des neuen Protokollereignisses wird batch_size überschritten.

3. Die Anzahl der Protokollereignisse hat batch_count erreicht.

4. Protokollereignisse aus dem Stapel umfassen nie mehr als 24 Stunden. Aber durch das Hinzufügen des neuen Protokollereignisses wird die 24-Stunden-Bedingung überschritten.

Wodurch werden Protokolleinträge, Protokollereignisse oder Stapel übersprungen oder gekürzt?

Zur Einhaltung der Bedingung für die PutLogEvents-Operation können folgende Probleme dazu führen, dass ein Protokollereignis oder ein Stapel übersprungen wird.

Anmerkung

Der CloudWatch-Logs-Agent schreibt eine Warnung in das Protokoll, wenn Daten übersprungen werden.

1. Wenn das Protokollereignis größer als 256 KB ist, wird es vollständig übersprungen.

2. Wenn der Zeitstempel des Protokollereignisses mehr als 2 Stunden in der Zukunft liegt, wird das Protokollereignis übersprungen.

3. Wenn der Zeitstempel des Protokollereignisses mehr als 14 Stunden in der Vergangenheit liegt, wird das Protokollereignis übersprungen.

4. Wenn ein Protokollereignis älter als der Aufbewahrungszeitraum der Protokollgruppe ist, wird der gesamte Stapel übersprungen.

5. Wenn der Stapel von Protokollereignissen in einer einzigen PutLogEvents-Anforderung mehr als 24 Stunden umfasst, schlägt die PutLogEvents-Operation fehl.

Führt das Anhalten des Agent zu Datenverlust/Duplikaten?

Nicht, solange die Zustandsdatei verfügbar ist und seit der letzten Ausführung keine Dateirotation stattgefunden hat. Der CloudWatch-Logs-Agent kann an der Stelle fortgesetzt werden, an der er angehalten wurde, und die Protokolldaten weiterhin übertragen.

Kann ich verschiedene Protokolldateien aus demselben Host oder aus unterschiedlichen Hosts demselben Protokoll-Stream zuweisen?

Die Konfiguration von mehreren Protokollquellen, damit Daten an einen einzelnen Protokoll-Stream gesendet werden, wird nicht unterstützt.

Welche API-Aufrufe führt der Agent durch (oder welche Aktionen sollte ich meiner IAM-Richtlinie hinzufügen)?

Für den CloudWatch-Logs-Agent sind die Operationen CreateLogGroup, CreateLogStream, DescribeLogStreams und PutLogEvents erforderlich. Wenn Sie den neuesten Agent verwendet, wird DescribeLogStreams nicht mehr benötigt. Weitere Informationen finden Sie im Beispiel für eine IAM-Richtlinie unten.

{
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Action": [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:PutLogEvents",
      "logs:DescribeLogStreams"
    ],
    "Resource": [
      "arn:aws:logs:*:*:*"
    ]
  }
 ]
}

Ich möchte nicht, dass der CloudWatch-Logs-Agent Protokollgruppen oder Protokoll-Streams automatisch erstellt. Wie kann ich verhindern, dass der Agent Protokollgruppen und Protokoll-Streams neu erstellt?

Sie können den Agent in Ihrer IAM-Richtlinie auf die folgenden Operationen beschränken: DescribeLogStreams, PutLogEvents.

Bevor Sie die Berechtigungen CreateLogGroup und CreateLogStream vom Agenten entziehen, müssen Sie sowohl die Protokollgruppen als auch die Protokolldatenströme erstellen, die der Agent verwenden soll. Der Protokoll-Agent kann keine Protokolldatenströme in einer Protokollgruppe erstellen, die Sie erstellt haben, es sei denn, er verfügt über die Berechtigungen CreateLogGroup und CreateLogStream.

Welche Protokolle sollte ich bei der Fehlerbehebung beachten?

Das Installationsprotokoll des Agenten finden Sie unter /var/log/awslogs-agent-setup.log und das Protokoll des Agenten unter /var/log/awslogs.log.