Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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.

Utiliser la mise en mémoire tampon du système de fichiers

Par défaut, toutes Fluent Bit les données en mémoire tampon sont mises en mémoire tampon. Lorsque les données sont ingérées plus rapidement qu'elles ne peuvent être transférées vers les sorties, la mémoire tampon se remplit. Une fois plein, le plugin d'entrée s'arrête jusqu'à ce que de l'espace tampon soit disponible, ce qui peut provoquer une contre-pression et ralentir votre application.

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 :

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 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 la valeur Grace est de 120 secondes, stopTimeout réglez-la 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

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 où 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
        }
    ]
}