Nombre maximal de tentatives

Par défaut, l'adresse Agent de journalisation est configurée de manière à ce que les tentatives d'envoi de journaux se poursuivent jusqu'à ce qu'elles aboutissent en cas d'erreur. Le comportement par défaut est configuré par le paramètre retryLimit: false paramètre. Dans Kubernetes, cette fonction est gérée dans la carte de configuration Agent de journalisation, et dans les environnements Linux, elle est gérée dans le fichier de configuration Agent de journalisation.

Si vous modifiez la valeur par défaut de retryLimit, vous risquez de perdre des données. Par exemple, retryLimit: "no_retries" indique que le site Agent de journalisation ne réessaie pas du tout d'envoyer des journaux en cas d'erreur. La spécification d'une valeur entière, par exemple retryLimit: 8, indique que le site Agent de journalisation tente d'envoyer des journaux le nombre de fois spécifié (8) avant que les journaux ne soient abandonnés.

Pour plus d'informations sur la façon dont Fluent Bit planifie les intervalles de tentatives, voir Planification et tentatives

Fluent Bit buffering

Le site Agent de journalisation est configuré par défaut pour utiliser Fluent Bit filesystem buffering. Cette configuration signifie que les journaux traités par le site Agent de journalisation sont conservés dans un fichier en cas de défaillance du système. Lorsque le site Agent de journalisation redémarre, les journaux contenus dans la mémoire tampon du site filesystem sont traités.

Si vous modifiez la configuration pour utiliser la mémoire tampon memory et qu'un problème survient lorsque Agent de journalisation se termine ou se termine de manière inattendue, les journaux dans la mémoire tampon memory peuvent être abandonnés.

Pour plus d'informations, voir Mise en mémoire tampon et stockage.

Rotation des grumes

Si l'environnement fait tourner les fichiers journaux avant que le site Agent de journalisation ne puisse les traiter, il est possible que des journaux soient abandonnés. La perte de données due à la rotation des journaux peut se produire si le site Agent de journalisation s'arrête pendant une longue période.

Kubernetes

Dans les clusters gérés par IBM, tous les fichiers journaux des conteneurs stdout dans /var/log/containers sont gérés par kublet. Chaque fichier journal d'un conteneur fait l'objet d'une rotation lorsqu'il atteint la taille de 100MiB. Après la rotation, jusqu'à trois fichiers journaux seront conservés par conteneur. La taille et le nombre de ces fichiers ne sont pas configurables.

Si les fichiers journaux se remplissent et tournent avant que le site Agent de journalisation ne traite les données, les journaux non traités peuvent être abandonnés.

Linux

Le traitement de la rotation des journaux peut être configuré à l'adresse Linux. Par exemple, en utilisant l'outil logrotate.

Si les fichiers journaux se remplissent et tournent avant que le site Agent de journalisation ne traite les données, les journaux non traités peuvent être abandonnés.

Windows

Le traitement de la rotation des journaux peut être configuré dans Windows. Cependant, il n'existe pas d'outil Windows intégré pour la rotation des journaux. Des applications tierces ou des paramètres d'application intégrés peuvent être utilisés pour configurer la rotation des journaux.

Si les fichiers journaux se remplissent et tournent avant que le site Agent de journalisation ne traite les données, les journaux non traités peuvent être abandonnés.