CloudWatch Referenz zum Logs-Agenten

Wichtig

Diese Referenz bezieht sich auf den älteren, veralteten CloudWatch Logs-Agenten. Wenn Sie Instance Metadata Service Version 2 (IMDSv2) verwenden, müssen Sie den neuen Unified Agent verwenden. CloudWatch Auch wenn Sie IMDSv2 nicht verwenden, empfehlen wir dringend, den neueren Unified CloudWatch Agent anstelle des älteren Logs-Agenten zu verwenden. Weitere Informationen zum neueren Unified Agent finden Sie unter Erfassung von Metriken und Protokollen von Amazon EC2 EC2-Instances und lokalen Servern mit dem CloudWatch Agenten.

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

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

• Ein Plug-in für das AWS CLI , das Protokolldaten in Logs überträgt. CloudWatch

• Ein Skript (Daemon), das den Prozess initiiert, um Daten in Logs zu übertragen. CloudWatch

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

Agent-Konfigurationsdatei

Die CloudWatch Logs-Agent-Konfigurationsdatei beschreibt Informationen, die der CloudWatch Logs-Agent benötigt. 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-Konfigurationsdateiformat (https://docs.python.org/2/library/logging.config.html #logging-config-fileformat). 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 sie auf true gesetzt ist (Standard), aktiviert sie die Gzip-HTTP-Inhaltskodierung, um komprimierte Nutzlasten an Logs zu CloudWatch senden. Dies verringert die CPU-Auslastung NetworkOut, senkt und verringert die Put-Latenz. Um diese Funktion zu deaktivieren, fügen Sie use_gzip_http_content_encoding = false zum Abschnitt [general] der CloudWatch Logs-Agent-Konfigurationsdatei hinzu und starten Sie den Agenten 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 Protokolldateien an, die Sie per Push in Logs speichern möchten. CloudWatch Die Datei kann auf eine bestimmte Datei oder mehrere Dateien (mit Platzhaltern wie /var/log/system.log*) verweisen. 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.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. Fingerabdruckzeilen werden nur dann an CloudWatch Logs gesendet, wenn alle angegebenen Zeilen verfügbar sind.

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.

Verwenden des CloudWatch Logs-Agenten mit HTTP-Proxys

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

Anmerkung

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

Um den CloudWatch Logs-Agent mit HTTP-Proxys zu verwenden

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

   1. Führen Sie für eine Neuinstallation des CloudWatch Logs-Agenten 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 EC2-Benutzerhandbuch.

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

   2. Für eine bestehende Installation des CloudWatch Logs-Agenten bearbeiten Sie /var/awslogs//etc/proxy.conf und fügen Sie Ihre Proxys 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

CloudWatch Kompartimentierung der Logs-Agent-Konfigurationsdateien

Wenn awslogs-agent-setup Sie.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 Logs-Agent gestartet wird, nimmt er alle Stream-Konfigurationen in diese zusätzlichen Konfigurationsdateien auf. CloudWatch 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

CloudWatch Häufig gestellte Fragen zum Log-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 für die Installation des CloudWatch Logs-Agenten ein Setup-Skript verwendet haben, können Sie mit /var/awslogs/bin/awslogs-version.sh überprüfen, welche Version des Agenten Sie verwenden. Dabei werden die Version des Agent und seine großen Abhängigkeiten gedruckt. Wenn Sie Yum zur Installation des CloudWatch Logs-Agenten verwendet haben, können Sie „yum info awslogs“ und „yum info aws-cli-plugin-cloudwatch -logs“ verwenden, um die Version des Logs-Agenten und des Plugins zu überprüfen. CloudWatch

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 sein 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 beginnen, an der er aufgehört hat, und die Protokolldaten weiterleiten.

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)?

Der CloudWatch Logs-Agent benötigt die PutLogEvents Operationen CreateLogGroup CreateLogStreamDescribeLogStreams,, und. 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 automatisch Protokollgruppen oder Protokollstreams 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.