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

Pour les scénarios à haut débit de log, nous recommandons d'utiliser le pilote de awsfirelens log 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 décrit les techniques Fluent Bit d'optimisation avancées permettant de gérer un débit de log é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 d'Amazon ECS sur GitHub.

Comprendre les morceaux

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

Le comportement de mise en mémoire tampon dépend du storage.type paramètre défini dans vos sections INPUT. Par défaut, Fluent Bit utilise la mise en mémoire tampon. Pour les scénarios à 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 for Fluent Bit examples.

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 mise en 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 log faible à modéré. Pour les scénarios à 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 Buffering and Memory dans la Fluent Bit documentation et Memory Buffering Only dans le référentiel AWS for Fluent Bit examples.

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

Pour les scénarios à haut débit, nous recommandons d'utiliser la mise en mémoire tampon du système de fichiers. Pour plus d'informations sur la Fluent Bit gestion de la 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

Principaux paramètres de configuration :

Pour plus d'informations, consultez la section Mise en mémoire tampon du système de fichiers dans la Fluent Bit documentation et Mise en mémoire tampon du système de fichiers et de la mémoire dans le AWS référentiel d'exemples. Fluent Bit

Présentation du code 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 de cette sortie sont supprimés pour faire de la place aux 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 le montant approprié 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 tampon appropriées, utilisez l'échantillon de débit de mesure. FireLens

Utilisez la formule, des exemples de calculs et des analyses comparatives pour choisir la piste la mieux adaptée storage.total_limit_size à une reprise optimale en cas de panne.

Exigences relatives au stockage des tâches Amazon ECS

Additionnez toutes les storage.total_limit_size valeurs des sections OUTPUT et ajoutez de la 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 le stockage disponible, les enregistrements Fluent Bit risquent de ne pas être mis en file d'attente et ils seront 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 de sortie

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

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

Le temps d'attente entre les nouvelles tentatives utilise un recul exponentiel associé à de l'instabilité :

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

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

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

Le Grace paramètre de la [SERVICE] 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 ce délai stopTimeout dépasse le Grace délai imparti pour Fluent Bit permettre le rinçage complet avant de le recevoir. SIGKILL Par exemple, si elle Grace est de 120 secondes, définie stopTimeout 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 contenues dans ce guide constituent des approches optimales pour minimiser les pertes de données, mais ne peuvent garantir aucune perte en cas de panne prolongée. La compréhension de ces scénarios vous aide Fluent Bit à configurer 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 davantage de données.

Les plus anciens records abandonnés

Les enregistrements mis en mémoire tampon les plus anciens sont supprimés lorsque les nouvelles tentatives sont épuisées ou lorsqu'ils sont storage.total_limit_size pleins et doivent 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 l'entrée est interrompue en raison deMem_Buf_Limit.

Bonnes pratiques pour minimiser les pertes de données

Tenez compte des meilleures pratiques suivantes pour minimiser les pertes de données :

Utilisez la journalisation à destinations multiples pour plus de fiabilité

L'envoi de journaux vers plusieurs destinations élimine les points de défaillance uniques. Par exemple, en cas de panne de CloudWatch Logs, les journaux continuent d'atteindre Amazon S3.

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

La journalisation à destinations multiples peut offrir 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. En cas de panne d'une destination, les journaux continuent de circuler vers l'autre tandis que les purges échouées s'accumulent dans la mémoire tampon du système de fichiers pour une nouvelle tentative ultérieure.

Utiliser la journalisation basée sur des fichiers avec le plugin d'entrée tail

Pour les scénarios à haut débit dans lesquels la perte de journaux est un problème critique, vous pouvez utiliser une autre approche : demandez à votre application d'écrire des journaux dans des fichiers sur disque et de les 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.

La journalisation basée sur des fichiers avec le plugin tail offre les avantages suivants :

Pour utiliser cette approche, votre application doit écrire des journaux dans des fichiers plutôt que dansstdout. 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 secondaire conforme aux 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 plugin d'entrée tail, 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 surstdout. Cette approche contourne la couche de pilote de journalisation Docker, ce qui offre 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 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 et. Fluent 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.

Tenez compte des points suivants lorsque vous utilisez cette option :

La définition de tâche suivante indique 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
        }
    ]
}