Überlegungen bei der Konfiguration der Protokollierungsagent
Wenn Sie IBM® Cloud Logs Protokollierungsagent konfigurieren, müssen Sie verstehen, wie Protokolle verarbeitet werden und wie eine Änderung der Standardkonfiguration möglicherweise zu fehlenden Protokollen führen kann.
Um die Vorteile der besten Protokollverarbeitung zu nutzen und die Gefahr von Datenverlusten so gering wie möglich zu halten, sollten Sie die neueste Version von Protokollierungsagent verwenden. Diese Informationen setzen voraus, dass Sie Protokollierungsagent 1.6.1 oder höher verwenden.
Wiederholungslimit
Standardmäßig ist Protokollierungsagent so konfiguriert, dass im Falle eines Fehlers immer wieder versucht wird, Protokolle zu senden, bis dies gelingt. Das Standardverhalten wird durch den Parameter retryLimit: false parameter festgelegt. In Kubernetes wird dies in der Protokollierungsagent configmap verwaltet, und in Linux Umgebungen ist es in der Protokollierungsagent config file.
Wenn Sie den Standardwert retryLimit ändern, kann es zu Datenverlusten kommen. retryLimit: "no_retries" bedeutet zum Beispiel, dass Protokollierungsagent bei einem Fehler nicht erneut versucht, Protokolle
zu senden. Die Angabe eines ganzzahligen Werts, z. B. retryLimit: 8, bedeutet, dass Protokollierungsagent den Versand von Protokollen so oft wie angegeben (8) wiederholt, bevor die Protokolle gelöscht werden.
Informationen darüber, wie Fluent Bit die Wiederholungsintervalle plant, finden Sie unter Zeitplanung und Wiederholungen.
Fließende Bitpufferung
Die Protokollierungsagent ist standardmäßig so konfiguriert, dass Fluent Bit filesystem gepuffert wird. Diese Konfiguration bedeutet, dass die von Protokollierungsagent verarbeiteten Protokolle im Falle eines Systemausfalls in einer
Datei gespeichert werden. Wenn Protokollierungsagent neu gestartet wird, werden die Protokolle im Puffer filesystem verarbeitet.
Wenn Sie die Konfiguration so ändern, dass memory gepuffert wird, und ein Problem auftritt, bei dem Protokollierungsagent beendet wird oder unerwartet abbricht, können die Protokolle im Puffer von memory gelöscht werden.
Weitere Informationen finden Sie unter Pufferung und Speicherung.
Log-Rotation
Wenn die Umgebung die Protokolldateien rotiert, bevor Protokollierungsagent sie verarbeiten kann, besteht die Möglichkeit, dass Protokolle verloren gehen. Datenverluste aufgrund von Protokollrotation können auftreten, wenn Protokollierungsagent für eine längere Zeit nicht läuft.
Kubernetes
In IBM verwalteten Clustern werden alle stdout Container-Logdateien in /var/log/containers von kublet verwaltet. Jede
Container-Protokolldatei wird rotiert, wenn sie die Größe von 100MiB erreicht. Nach der Rotation werden bis zu 3 Protokolldateien pro Container aufbewahrt. Die Größe und Anzahl dieser Dateien ist nicht konfigurierbar.
Wenn sich die Protokolldateien füllen und rotieren, bevor die Protokollierungsagent die Daten verarbeitet, können die nicht verarbeiteten Protokolle gelöscht werden.
Linux
Die Verarbeitung der Protokollrotation kann unter Linux konfiguriert werden. Zum Beispiel durch die Verwendung des Tools logrotate.
Wenn sich die Protokolldateien füllen und rotieren, bevor die Protokollierungsagent die Daten verarbeitet, können die nicht verarbeiteten Protokolle gelöscht werden.
Windows
Die Verarbeitung der Protokollrotation kann in Windows konfiguriert werden. Es gibt jedoch kein integriertes Windows-Tool für die Protokollrotation. Anwendungen von Drittanbietern oder integrierte Anwendungseinstellungen können zur Konfiguration der Protokollrotation verwendet werden.
Wenn sich die Protokolldateien füllen und rotieren, bevor die Protokollierungsagent die Daten verarbeitet, können die nicht verarbeiteten Protokolle gelöscht werden.