Configuration des journaux Amazon ECS pour un débit élevé

Pour les scénarios de débit de journalisation élevé, nous vous recommandons d'utiliser le pilote de awsfirelens journalisation avec FireLens etFluent Bit. Fluent Bitest un processeur de journaux léger qui utilise efficacement les ressources et peut gérer des millions d'enregistrements de journaux. Cependant, pour obtenir des performances optimales à grande échelle, il faut ajuster sa configuration.

Cette section couvre les techniques Fluent Bit d'optimisation avancées permettant de gérer un débit de journalisation élevé tout en préservant la stabilité du système et en évitant toute perte de données.

Pour plus d'informations sur l'utilisation de fichiers de configuration personnalisés avec FireLens, consultezUtilisation d’un fichier de configuration. Pour des exemples supplémentaires, consultez les FireLens exemples Amazon ECS sur GitHub.

Comprendre les morceaux

Fluent Bittraite les données en unités appelées blocs. Lorsqu'un plug-in INPUT reçoit des données, le moteur crée un bloc qui est stocké en mémoire ou sur le système de fichiers avant d'être envoyé aux destinations OUTPUT.

Le comportement de la mise en mémoire tampon dépend du storage.type réglage de vos sections INPUT. Par défaut, Fluent Bit utilise la mise en mémoire tampon. Pour les scénarios de haut débit ou de production, la mise en mémoire tampon du système de fichiers offre une meilleure résilience.

Pour plus d'informations, consultez les sections Chunks dans la Fluent Bit documentation et Qu'est-ce qu'un chunk ? dans le référentiel AWS pour Fluent Bit exemples.

Mise en mémoire tampon (par défaut)

Par défaut, Fluent Bit utilise la mise en mémoire tampon (storage.type memory). Vous pouvez limiter l'utilisation de la mémoire par plug-in INPUT à l'aide du Mem_Buf_Limit paramètre.

L'exemple suivant montre une configuration d'entrée avec mémoire tampon :

[INPUT]
    Name          tcp
    Tag           ApplicationLogs
    Port          5170
    storage.type  memory
    Mem_Buf_Limit 5MB

[input] tcp.1 paused (mem buf overlimit)

La mise en mémoire tampon convient aux cas d'utilisation simples avec un débit de journalisation faible à modéré. Pour les scénarios de haut débit ou de production où la perte de données est un problème, utilisez plutôt la mise en mémoire tampon du système de fichiers.

Pour plus d'informations, consultez la section Mise en mémoire tampon et mémoire dans la Fluent Bit documentation et la section Mise en mémoire tampon uniquement dans le référentiel AWS d'Fluent Bitexemples.

Mise en mémoire tampon du système de fichiers

Pour les scénarios à haut débit, nous vous recommandons d'utiliser la mise en mémoire tampon du système de fichiers. Pour plus d'informations sur la gestion de la Fluent Bit mise en mémoire tampon et du stockage, consultez la section Mise en mémoire tampon et stockage dans la Fluent Bit documentation.

La mise en mémoire tampon du système de fichiers présente les avantages suivants :

Pour activer la mise en mémoire tampon du système de fichiers, fournissez un fichier de Fluent Bit configuration personnalisé. L'exemple suivant montre la configuration recommandée :

[SERVICE]
    # Flush logs every 1 second
    Flush 1
    # Wait 120 seconds during shutdown to flush remaining logs
    Grace 120
    # Directory for filesystem buffering
    storage.path             /var/log/flb-storage/
    # Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
    storage.max_chunks_up    32
    # Flush backlog chunks to destinations during shutdown (prevents log loss)
    storage.backlog.flush_on_shutdown On

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    # Run input in separate thread to prevent blocking
    threaded true
    # Enable filesystem buffering for persistence
    storage.type filesystem

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    # Use multiple workers for parallel processing
    workers 2
    # Retry failed flushes up to 15 times
    retry_limit 15
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 10G

Paramètres de configuration clés :

Pour plus d'informations, consultez Filesystem Buffering dans la Fluent Bit documentation et Filesystem and Memory Buffering dans le AWS référentiel d'exemples. Fluent Bit

Comprendre storage.total_limit_size

Le storage.total_limit_size paramètre de chaque plug-in OUTPUT contrôle l'espace disque maximal pour les données mises en mémoire tampon pour cette sortie. Lorsque cette limite est atteinte, les enregistrements les plus anciens pour cette sortie sont supprimés pour faire de la place pour de nouvelles données. Lorsque l'espace disque est complètement épuisé, les enregistrements Fluent Bit ne sont pas mis en file d'attente et ils sont perdus.

Utilisez la formule suivante pour calculer la valeur appropriée en storage.total_limit_size fonction de votre taux de journalisation et de la fenêtre de restauration souhaitée :

If log rate is in KB/s, convert to MB/s first:
log_rate (MB/s) = log_rate (KB/s) / 1000

storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB)

Le tableau suivant présente des exemples de calculs pour les taux de journalisation et les fenêtres de restauration courants :

Pour observer le débit maximal et choisir les tailles de mémoire tampon appropriées, utilisez l'échantillon de mesure du débit FireLens .

Utilisez la formule, des exemples de calculs et des analyses comparatives pour choisir une solution appropriée storage.total_limit_size qui offre une piste permettant une reprise optimale en cas de panne.

Exigences en matière de stockage des tâches Amazon ECS

Additionnez toutes les storage.total_limit_size valeurs des sections OUTPUT et ajoutez une mémoire tampon pour les frais généraux. Ce total détermine l'espace de stockage nécessaire dans votre définition de tâche Amazon ECS. Par exemple, 3 sorties × 10 Go chacune = 30 Go + mémoire tampon (5 à 10 Go) = 35 à 40 Go au total requis. Si le total dépasse l'espace de stockage disponible, il est Fluent Bit possible que les enregistrements ne soient pas mis en file d'attente et qu'ils soient perdus.

Les options de stockage suivantes sont disponibles :

Pour plus d'informations sur les volumes de données, consultezOptions de stockage pour les tâches Amazon ECS.

Optimisation de la configuration des sorties

Les problèmes de réseau, les pannes de service et la limitation des destinations peuvent empêcher la distribution des journaux. Une configuration de sortie appropriée garantit la résilience sans perte de données.

En cas d'échec d'un rinçage de sortie, Fluent Bit vous pouvez recommencer l'opération. Les paramètres suivants contrôlent le comportement des nouvelles tentatives :

Le temps d'attente entre les nouvelles tentatives utilise un retard exponentiel avec gigue :

wait_time = random(base, min(base × 2^retry_number, cap))

Par exemple, avec scheduler.base 10 et scheduler.cap 60 :

Pour plus d'informations, voir Configurer le temps d'attente avant une nouvelle tentative et Mise en réseau dans la Fluent Bit documentation.

Le Grace paramètre de [SERVICE] cette section définit le temps d'Fluent Bitattente pendant l'arrêt pour vider les données mises en mémoire tampon. La Grace période doit être coordonnée avec celle du contenantstopTimeout. Assurez-vous que cela stopTimeout dépasse la Grace période nécessaire Fluent Bit pour terminer le rinçage avant de recevoirSIGKILL. Par exemple, s'il Grace est de 120 secondes, stopTimeout réglez sur 150 secondes.

L'exemple suivant montre une Fluent Bit configuration complète avec tous les paramètres recommandés pour les scénarios à haut débit :

[SERVICE]
    # Flush logs every 1 second
    Flush 1
    # Wait 120 seconds during shutdown to flush remaining logs
    Grace 120
    # Directory for filesystem buffering
    storage.path             /var/log/flb-storage/
    # Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
    storage.max_chunks_up    32
    # Flush backlog chunks to destinations during shutdown (prevents log loss)
    storage.backlog.flush_on_shutdown On
    # Minimum seconds between retries
    scheduler.base           10
    # Maximum seconds between retries (exponential backoff cap)
    scheduler.cap            60

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    # Run input in separate thread to prevent blocking
    threaded true
    # Enable filesystem buffering for persistence
    storage.type filesystem

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    # Use multiple workers for parallel processing
    workers 2
    # Retry failed flushes up to 15 times
    retry_limit 15
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 10G

Comprendre les scénarios de perte de données

Les enregistrements peuvent être perdus lors de pannes prolongées ou de problèmes liés aux destinations de sortie. Les recommandations de configuration présentées dans ce guide constituent des approches efficaces pour minimiser les pertes de données, mais ne peuvent garantir l'absence de perte lors de pannes prolongées. La compréhension de ces scénarios vous aide à effectuer les configurations Fluent Bit nécessaires pour optimiser la résilience.

Les enregistrements peuvent être perdus de deux manières : les enregistrements les plus anciens sont supprimés lorsque le stockage est plein, ou les enregistrements les plus récents sont rejetés lorsque le système ne peut pas accepter plus de données.

Les plus vieux records ont été déposés

Les enregistrements mis en mémoire tampon les plus anciens sont supprimés lorsque les tentatives de nouvelle tentative sont épuisées ou lorsqu'storage.total_limit_sizeil est temps de faire de la place pour de nouvelles données.

Nouveaux enregistrements rejetés

Les enregistrements les plus récents sont supprimés lorsque l'espace disque est épuisé ou lorsque la saisie est suspendue pour cause deMem_Buf_Limit.

Meilleures pratiques pour minimiser les pertes de données

Prenez en compte les bonnes pratiques suivantes pour minimiser les pertes de données :

Utilisez la journalisation multidestination pour plus de fiabilité

L'envoi de journaux vers plusieurs destinations élimine les points de défaillance uniques. Par exemple, si CloudWatch Logs rencontre une panne, les journaux parviennent toujours à Amazon S3.

Multi-destination la journalisation offre les avantages suivants. Le plug-in de sortie Amazon S3 prend également en charge des options de compression telles que le format gzip et Parquet, ce qui permet de réduire les coûts de stockage. Pour plus d'informations, consultez la section Compression S3 dans la Fluent Bit documentation.

Multi-destination la journalisation peut apporter les avantages suivants :

La Fluent Bit configuration suivante envoie des journaux à la fois à CloudWatch Logs et à Amazon S3 :

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    workers 2
    retry_limit 15

[OUTPUT]
    Name s3
    Match *
    bucket my-logs-bucket
    region us-west-2
    total_file_size 100M
    s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
    upload_timeout 10m
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 5G

Les deux sorties utilisent le même Match * schéma, de sorte que tous les enregistrements sont envoyés aux deux destinations indépendamment. Lors d'une panne d'une destination, les journaux continuent de circuler vers l'autre tandis que les vidages échoués s'accumulent dans la mémoire tampon du système de fichiers pour une nouvelle tentative ultérieure.

Utilisez la journalisation basée sur des fichiers avec le plugin Tail Input

Pour les scénarios à haut débit où la perte de journaux constitue une préoccupation majeure, vous pouvez utiliser une autre approche : demander à votre application d'écrire des journaux dans des fichiers sur disque et de la configurer Fluent Bit pour les lire à l'aide du plug-in tail d'entrée. Cette approche contourne complètement la couche du pilote de journalisation Docker.

File-based la journalisation avec le plugin tail offre les avantages suivants :

Pour utiliser cette approche, votre application doit écrire des journaux dans des fichiers au lieu destdout. Le conteneur d'applications et le Fluent Bit conteneur montent tous deux un volume partagé dans lequel les fichiers journaux sont stockés.

L'exemple suivant montre une configuration d'entrée de queue avec les meilleures pratiques :

[INPUT]
    Name tail
    # File path or glob pattern to tail
    Path /var/log/app.log
    # Database file for storing file offsets (enables resuming after restart)
    DB /var/log/flb_tail.db
    # when true, controls that only fluent-bit will access the database (improves performance)
    DB.locking true
    # Skip long lines instead of skipping the entire file
    Skip_Long_Lines On
    # How often (in seconds) to check for new files matching the glob pattern
    Refresh_Interval 10
    # Extra seconds to monitor a file after rotation to account for pending flush
    Rotate_Wait 30
    # Maximum size of the buffer for a single line
    Buffer_Max_Size 10MB
    # Initial allocation size for reading file data
    Buffer_Chunk_Size 1MB
    # Maximum memory buffer size (tail pauses when full)
    Mem_Buf_Limit 75MB

Lorsque vous utilisez le plug-in Tail Input, tenez compte des points suivants :

Pour plus d'informations, consultez Tail dans la Fluent Bit documentation. Pour connaître les meilleures pratiques, consultez la section Configuration de Tail avec les meilleures pratiques dans AWS le guide de Fluent Bit dépannage.

Connectez-vous directement à FireLens

Lorsque le pilote de journal awsfirelens est spécifié dans une définition de tâche, l'agent de conteneur Amazon ECS injecte les variables d'environnement suivantes dans le conteneur :

Vous pouvez utiliser ces variables d'environnement pour vous connecter directement au routeur de Fluent Bit journaux à partir du code de votre application à l'aide du protocole Fluent Forward, au lieu d'écrire dansstdout. Cette approche contourne la couche du pilote de journalisation Docker, ce qui présente les avantages suivants :

Les bibliothèques d'enregistreurs Fluent suivantes prennent en charge le protocole Fluent Forward et peuvent être utilisées pour envoyer des journaux directement à Fluent Bit :

Configurer la limite de mémoire tampon de Docker

Lorsque vous créez une définition de tâche, vous pouvez spécifier le nombre de lignes de journal mises en mémoire tampon en spécifiant la valeur danslog-driver-buffer-limit. Cela contrôle la mémoire tampon entre Docker etFluent Bit. Pour plus d’informations, consultez la section Pilote de journalisation dans la documentation Docker.

Utilisez cette option lorsque le débit est élevé, car Docker risque de manquer de mémoire tampon et de rejeter les messages tampons afin d'en ajouter de nouveaux.

Lorsque vous utilisez cette option, tenez compte des points suivants :

La définition de tâche suivante montre comment configurer log-driver-buffer-limit :

{
    "containerDefinitions": [
        {
            "name": "my_service_log_router",
            "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
            "cpu": 0,
            "memoryReservation": 51,
            "essential": true,
            "firelensConfiguration": {
                "type": "fluentbit"
            }
        },
        {
            "essential": true,
            "image": "public.ecr.aws/docker/library/httpd:latest",
            "name": "app",
            "logConfiguration": {
                "logDriver": "awsfirelens",
                "options": {
                    "Name": "firehose",
                    "region": "us-west-2",
                    "delivery_stream": "my-stream",
                    "log-driver-buffer-limit": "52428800"
                }
            },
            "dependsOn": [
                {
                    "containerName": "my_service_log_router",
                    "condition": "START"
                }
            ],
            "memoryReservation": 100
        }
    ]
}