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.
# Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner
Vous pouvez utiliser Amazon ECS FireLens pour utiliser les paramètres de définition des tâches pour acheminer les journaux vers un AWS service ou une destination AWS Partner Network (APN) à des fins de stockage et d'analyse des journaux. AWS Partner Network Il s'agit d'une communauté mondiale de partenaires qui tire parti des programmes, de l'expertise et des ressources pour créer, commercialiser et vendre des offres aux clients. Pour plus d'informations, veuillez consulter [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). FireLens fonctionne avec [Fluentd](https://www.fluentd.org/) et [Fluent Bit](https://fluentbit.io/). Nous fournissons l'image AWS pour Fluent Bit ou vous pouvez utiliser votre propre image Fluentd ou Fluent Bit.
Par défaut, Amazon ECS configure la dépendance du conteneur pour que le conteneur Firelens démarre avant tout conteneur qui l’utilise. Le conteneur Firelens s’arrête également une fois que tous les conteneurs qui l’utilisent se sont arrêtés.
Pour utiliser cette fonctionnalité, vous devez créer un rôle IAM pour vos tâches qui fournit les autorisations nécessaires pour utiliser les AWS services requis par les tâches. Par exemple, si un conteneur achemine des journaux vers Firehose, la tâche nécessite l’autorisation d’appeler l’API `firehose:PutRecordBatch`. Pour plus d'informations, consultez [Ajout et suppression d'autorisations basées sur l'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l'utilisateur IAM*.
Votre tâche peut également nécessiter le rôle d’exécution de tâche Amazon ECS dans les conditions suivantes. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md).
+ Si votre tâche est hébergée sur Fargate et que vous extrayez des images de conteneurs depuis Amazon ECR ou que vous faites référence à des données sensibles AWS Secrets Manager depuis votre configuration de journal, vous devez inclure le rôle IAM d'exécution de la tâche.
+ Lorsque vous utilisez un fichier de configuration personnalisé hébergé dans Amazon S3, votre rôle IAM d’exécution de tâche doit inclure l’autorisation `s3:GetObject`.
Tenez compte des points suivants lors de l'utilisation FireLens pour Amazon ECS :
+ Nous vous recommandons d’ajouter `my_service_` au nom du conteneur de journaux afin de pouvoir facilement le distinguer dans la console.
+ Amazon ECS ajoute par défaut une dépendance relative à l’ordre des conteneurs de démarrage entre les conteneurs d’applications et le conteneur FireLens. Lorsque vous spécifiez un ordre de conteneur entre les conteneurs d’applications et le conteneur FireLens, l’ordre de conteneur de départ par défaut est remplacé.
+ FireLens pour Amazon ECS est pris en charge pour les tâches hébergées à la fois sur AWS Fargate sur Linux et Amazon EC2 sur Linux. Les conteneurs Windows ne prennent pas en charge FireLens.
Pour plus d'informations sur la configuration de la journalisation centralisée pour les conteneurs Windows, consultez la section [Journalisation centralisée pour les conteneurs Windows sur Amazon ECS à l'aide de Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/).
+ Vous pouvez utiliser CloudFormation des modèles FireLens pour configurer Amazon ECS. Pour plus d'informations, voir [AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)le *guide de AWS CloudFormation l'utilisateur*
+ FireLensécoute sur le port`24224`. Pour vous assurer que le routeur de FireLens journaux n'est pas accessible en dehors de la tâche, vous ne devez pas autoriser le trafic entrant sur le port `24224` du groupe de sécurité utilisé par votre tâche. Pour les tâches utilisant le mode réseau `awsvpc`, il s'agit du groupe de sécurité associé à la tâche. Pour les tâches utilisant le mode réseau `host`, il s'agit du groupe de sécurité associé à l'instance Amazon EC2 qui héberge la tâche. Pour les tâches utilisant le mode réseau `bridge`, ne créez pas de mappages de ports utilisant le port `24224`.
+ Pour les tâches qui utilisent le mode `bridge` réseau, le conteneur contenant la FireLens configuration doit démarrer avant que les conteneurs d'applications qui en dépendent ne démarrent. Pour contrôler l'ordre de début de vos conteneurs, utilisez les conditions de dépendance dans la définition de tâche. Pour de plus amples informations, veuillez consulter [Dépendances du conteneur](task_definition_parameters.md#container_definition_dependson).
**Note**
Si vous utilisez des paramètres de condition de dépendance dans les définitions de conteneur avec une FireLens configuration, assurez-vous que chaque conteneur possède une exigence de `HEALTHY` condition `START` or.
+ Par défaut, FireLens ajoute le nom du cluster et de la définition de tâche ainsi que le nom de ressource Amazon (ARN) du cluster en tant que clés de métadonnées stdout/stderr dans vos journaux de conteneurs. Voici un exemple du format de métadonnées.
```
"ecs_cluster": "cluster-name",
"ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE",
"ecs_task_definition": "task-def-name:revision",
```
Si vous ne souhaitez pas que les métadonnées figurent dans vos journaux, définissez `enable-ecs-log-metadata` sur `false`dans la section `firelensConfiguration` de la définition de tâche.
```
"firelensConfiguration":{
"type":"fluentbit",
"options":{
"enable-ecs-log-metadata":"false",
"config-file-type":"file",
"config-file-value":"/extra.conf"
}
```
Vous pouvez configurer le FireLens conteneur pour qu'il s'exécute en tant qu'utilisateur non root. Éléments à prendre en compte :
+ Pour configurer le FireLens conteneur afin qu'il s'exécute en tant qu'utilisateur non root, vous devez spécifier l'utilisateur dans l'un des formats suivants :
+ `uid`
+ `uid:gid`
+ `uid:group`
Pour plus d'informations sur la spécification d'un utilisateur dans une définition de conteneur, consultez le [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)manuel *Amazon Elastic Container Service API Reference*.
Le FireLens conteneur reçoit les journaux des applications via un UNIX socket. L'agent Amazon ECS utilise le `uid` pour attribuer la propriété du répertoire de sockets au FireLens conteneur.
+ La configuration du FireLens conteneur pour qu'il s'exécute en tant qu'utilisateur non root est prise en charge sur les versions Amazon ECS Agent `1.96.0` et ultérieures, ainsi que sur les versions AMI optimisées pour Amazon ECS et `v20250716` versions ultérieures.
+ Lorsque vous spécifiez un utilisateur pour le FireLens conteneur, celui-ci `uid` doit être unique et ne pas être utilisé pour d'autres processus appartenant à d'autres conteneurs de la tâche ou de l'instance de conteneur.
Pour plus d’informations sur l’utilisation de plusieurs fichiers de configuration avec Amazon ECS, y compris les fichiers que vous hébergez ou les fichiers dans Amazon S3, consultez la section [Processus d’initialisation pour Fluent Bit sur ECS, support multiconfigurations](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit).
Pour plus d'informations sur les exemples de configurations, consultez[Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens](firelens-taskdef.md).
Pour plus d'informations sur la configuration des journaux pour un débit élevé, consultez[Configuration des journaux Amazon ECS pour un débit élevé](firelens-docker-buffer-limit.md).
# 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, consultez[Utilisation d’un fichier de configuration](firelens-taskdef.md#firelens-taskdef-customconfig). Pour des exemples supplémentaires, consultez les [ FireLens exemples d'Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) sur GitHub.
**Note**
Certaines options de configuration de cette section, telles que `workers` et`threaded`, nécessitent AWS la Fluent Bit version 3 ou ultérieure. Pour plus d'informations sur les versions disponibles, voir [AWS les versions de Fluent Bit](https://github.com/aws/aws-for-fluent-bit/releases).
## 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](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) dans la Fluent Bit documentation et [Qu'est-ce qu'un chunk ?](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-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
```
**Important**
Lorsqu'il `Mem_Buf_Limit` est dépassé pour un plugin, la Fluent Bit saisie est interrompue et les nouveaux enregistrements sont perdus. Cela peut provoquer une contre-pression et ralentir votre application. L'avertissement suivant apparaît dans les Fluent Bit journaux :
```
[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](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) dans la Fluent Bit documentation et [Memory Buffering Only](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-1-memory-buffering-only-default-or-storagetype-memory) 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](https://docs.fluentbit.io/manual/administration/buffering-and-storage) dans la Fluent Bit documentation.
La mise en mémoire tampon du système de fichiers présente les avantages suivants :
+ **Capacité de mémoire tampon plus importante** : l'espace disque est généralement plus abondant que la mémoire.
+ **Persistance** : les données mises en mémoire tampon survivent Fluent Bit aux redémarrages.
+ **Dégradation progressive** : lors de défaillances de sortie, les données s'accumulent sur le disque au lieu d'épuiser la mémoire.
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 :
`storage.path`
Le répertoire dans lequel sont Fluent Bit stockés les fragments mis en mémoire tampon sur le disque.
`storage.backlog.flush_on_shutdown`
Lorsque cette option est activée, Fluent Bit tente de vider tous les fragments du système de fichiers en attente vers leur destination lors de l'arrêt. Cela permet de garantir la livraison des données avant les Fluent Bit arrêts, mais peut augmenter le temps d'arrêt.
`storage.max_chunks_up`
Le nombre de segments qui restent en mémoire. La valeur par défaut est de 128 blocs, qui peuvent consommer plus de 500 Mo de mémoire, car chaque bloc peut utiliser jusqu'à 4 à 5 Mo. Dans les environnements où la mémoire est limitée, réduisez cette valeur. Par exemple, si vous disposez de 50 Mo pour la mise en mémoire tampon, définissez ce paramètre sur 8 à 10 segments.
`storage.type filesystem`
Active le stockage du système de fichiers pour le plugin d'entrée. Malgré son nom, il permet Fluent Bit de `mmap` mapper des fragments à la fois à la mémoire et au disque, garantissant ainsi la persistance sans sacrifier les performances.
`storage.total_limit_size`
Espace disque maximal pour les données mises en mémoire tampon pour un plugin OUTPUT spécifique. Lorsque cette limite est atteinte, les enregistrements les plus anciens de cette sortie sont supprimés. Pour plus d'informations sur le dimensionnement, consultez[Présentation du code `storage.total_limit_size`](#firelens-storage-sizing).
`threaded true`
Exécute l'entrée dans son propre thread, séparé Fluent Bit de la boucle d'événements principale. Cela empêche les entrées lentes de bloquer l'ensemble du pipeline.
Pour plus d'informations, consultez la section Mise en [mémoire tampon du système de fichiers](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) dans la Fluent Bit documentation et Mise en [mémoire tampon du système de fichiers et de la mémoire](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem) 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 :
| Taux de journalisation | 1 heure | 6 heures | 12 heures | 24 heures |
| --- | --- | --- | --- | --- |
| 0,25 Mo/s | 0,9 GO | 5,4 GO | 10,8 GO | 21,6 GO |
| 0,5 Mo/s | 1,8 GO | 10,8 GO | 21,6 GO | 43,2 GO |
| 1 Mo/s | 3,6 GO | 21,6 GO | 43,2 GO | 86,4 GO |
| 5 Mo/s | 18 GO | 108 GO | 216 GO | 432 GO |
| 10 Mo/s | 36 GO | 216 GO | 432 GO | 864 GO |
Pour observer le débit maximal et choisir les tailles de tampon appropriées, utilisez l'échantillon de débit de [mesure. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)
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 \$1 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 :
Supports Bind (stockage éphémère)
+ Pour AWS Fargate, la valeur par défaut est de 20 Go de stockage éphémère (200 Go maximum). Configurez `ephemeralStorage` en utilisant dans la définition de la tâche. Pour plus d’informations, consultez [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) dans le *Guide de l’utilisateur AWS CloudFormation *.
+ Pour EC2, la valeur par défaut est de 30 Go lorsque vous utilisez l'AMI optimisée pour Amazon ECS (partagée entre le système d'exploitation et Docker). Augmentez en modifiant la taille du volume racine.
Volumes Amazon EBS
+ Fournit un stockage par blocs à haute disponibilité, durable et hautes performances.
+ Nécessite une configuration du volume et `mountPoint` une définition de tâche pointant vers `storage.path` (par défaut :`/var/log/flb-storage/`).
+ Pour de plus amples informations, veuillez consulter [Report de la configuration du volume au moment du lancement dans une définition de tâche Amazon ECS](specify-ebs-config.md).
Volumes Amazon EFS
+ Permet un stockage de fichiers simple et évolutif.
+ Nécessite une configuration du volume et `mountPoint` une définition de tâche pointant vers `storage.path` (par défaut :`/var/log/flb-storage/`).
+ Pour de plus amples informations, veuillez consulter [Spécification d’un système de fichiers Amazon EFS dans une définition de tâche Amazon ECS](specify-efs-config.md).
Pour plus d'informations sur les volumes de données, consultez[Options de stockage pour les tâches Amazon ECS](using_data_volumes.md).
## 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 :
`retry_limit`
Nombre maximal de tentatives après la première tentative avant de supprimer des enregistrements. La valeur par défaut est 1. Par exemple, `retry_limit 3` cela signifie 4 tentatives au total (1 tentative initiale \$1 3 tentatives). Pour les environnements de production, nous recommandons une durée de 15 minutes ou plus, ce qui couvre plusieurs minutes d'interruption avec un ralentissement exponentiel.
Défini pour `no_limits` ou `False` pour un nombre infini de tentatives :
+ Avec la mise en mémoire tampon, des tentatives infinies entraînent une pause du plug-in d'entrée lorsque les limites de mémoire sont atteintes.
+ Avec la mise en mémoire tampon du système de fichiers, les enregistrements les plus anciens sont supprimés lorsqu'ils `storage.total_limit_size` sont atteints.
Après avoir épuisé toutes les tentatives (1 tentative initiale et nouvelles `retry_limit` tentatives), les enregistrements sont supprimés. AWS les plugins avec `auto_retry_requests true` (par défaut) fournissent une couche de nouvelle tentative supplémentaire avant Fluent Bit le mécanisme de nouvelle tentative. Pour plus d'informations, consultez la section [Configurer les nouvelles tentatives](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries) dans la Fluent Bit documentation.
Par exemple, `retry_limit 3` avec les paramètres par défaut (`scheduler.base 5`,,`net.connect_timeout 10s`)`scheduler.cap 2000`, le temps d'attente du planificateur est d'environ 70 secondes (10 s \$1 20 \$1 40 s), les délais de connexion au réseau de 40 secondes (4 tentatives × 10 s), plus de nouvelles tentatives de AWS plug-in, soit un total d'environ 2 à 10 minutes en fonction des conditions du réseau et des délais TCP du système d'exploitation.
`scheduler.base`
Les secondes de base entre les tentatives (par défaut : 5). Nous recommandons 10 secondes.
`scheduler.cap`
Nombre maximal de secondes entre deux tentatives (par défaut : 2000). Nous recommandons 60 secondes.
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` :
+ Première tentative : attente aléatoire comprise entre 10 et 20 secondes
+ Deuxième tentative : attente aléatoire comprise entre 10 et 40 secondes
+ Troisième tentative et versions ultérieures : attente aléatoire comprise entre 10 et 60 secondes (plafonnée)
Pour plus d'informations, consultez [Configurer le temps d'attente pour une nouvelle tentative](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry) et [Mise en réseau](https://docs.fluentbit.io/manual/administration/networking) dans la Fluent Bit documentation.
`workers`
Nombre de threads pour le traitement en sortie parallèle. Plusieurs opérateurs autorisent des purges simultanées, ce qui améliore le débit lors du traitement de nombreux fragments.
`auto_retry_requests`
Un paramètre AWS spécifique au plugin qui fournit une couche de nouvelle tentative supplémentaire avant le mécanisme Fluent Bit de nouvelle tentative intégré. La valeur par défaut est `true`. Lorsqu'il est activé, le plugin AWS de sortie réessaie les demandes ayant échoué en interne avant que la demande ne soit considérée comme un échec du rinçage et soumise à la `retry_limit` configuration.
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 contenant`stopTimeout`. 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.
Limite de tentatives dépassée
Se produit après de nouvelles tentatives du AWS plugin (if`auto_retry_requests true`) plus 1 Fluent Bit tentative initiale plus de nouvelles `retry_limit` tentatives. Pour atténuer les effets, définissez `retry_limit no_limits` chaque plugin OUTPUT pour un nombre infini de tentatives :
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
retry_limit no_limits
auto_retry_requests true
```
Un nombre indéfini de tentatives permet d'éviter de perdre des enregistrements en cas d'épuisement des tentatives, mais cela peut `storage.total_limit_size` entraîner un remplissage.
Limite de stockage atteinte (mise en mémoire tampon du système de fichiers)
Se produit lorsque la destination de sortie n'est pas disponible plus longtemps que la mémoire tampon que `storage.total_limit_size` vous avez configurée. Par exemple, une mémoire tampon de 10 Go à un débit MB/s journalier fournit environ 2,7 heures de mise en mémoire tampon. Pour atténuer les risques, augmentez `storage.total_limit_size` le nombre de plug-ins OUTPUT et fournissez un stockage de tâches Amazon ECS adéquat :
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
storage.total_limit_size 10G
```
### 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 de`Mem_Buf_Limit`.
Espace disque épuisé (mise en mémoire tampon du système de fichiers)
Se produit lorsque l'espace disque est complètement épuisé. Fluent Bitne parvient pas à mettre en file d'attente les nouveaux enregistrements et ils sont perdus. Pour atténuer les risques, additionnez toutes les `storage.total_limit_size` valeurs et fournissez un stockage de tâches Amazon ECS adéquat. Pour de plus amples informations, veuillez consulter [Exigences relatives au stockage des tâches Amazon ECS](#firelens-storage-task-requirements).
Limite de mémoire atteinte (mise en mémoire tampon)
Se produit lorsque la destination de sortie n'est pas disponible et que la mémoire tampon est pleine. Les plugins d'entrée en pause cessent d'accepter de nouveaux enregistrements. Pour atténuer, utiliser `storage.type filesystem` pour améliorer la résilience ou augmenter`Mem_Buf_Limit`.
### Bonnes pratiques pour minimiser les pertes de données
Tenez compte des meilleures pratiques suivantes pour minimiser les pertes de données :
+ **Utiliser la mise en mémoire tampon du système de fichiers** : configurée `storage.type filesystem` pour une meilleure résilience en cas de panne.
+ **Dimensionnez le stockage de manière appropriée** : calculez en `storage.total_limit_size` fonction du taux de journalisation et de la fenêtre de restauration souhaitée.
+ **Provisionner un disque adéquat** : assurez-vous que la tâche Amazon ECS dispose d'un espace de stockage éphémère suffisant, Amazon EBS ou Amazon EFS.
+ **Configurer le comportement des nouvelles tentatives** : équilibre entre `retry_limit` (supprime les enregistrements après avoir épuisé les tentatives) et `no_limits` (nouvelles tentatives indéfiniment mais risque de remplir l'espace de stockage).
## 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](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) dans la Fluent Bit documentation.
La journalisation à destinations multiples peut offrir les avantages suivants :
+ **Redondance** : si une destination échoue, les journaux continuent d'atteindre l'autre.
+ **Rétablissement** — Reconstituer les lacunes d'un système par rapport à l'autre.
+ **Durabilité** — Archivez les journaux dans Amazon S3 pour les conserver à long terme.
+ **Optimisation des coûts** : conservez les journaux récents dans un service de requête rapide tel que les CloudWatch journaux à durée de conservation plus courte, tout en archivant tous les journaux dans un espace de stockage Amazon S3 à moindre coût pour une conservation à long terme.
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 :
+ **Suivi des décalages** — Le plugin tail peut stocker les décalages de fichiers dans un fichier de base de données (en utilisant l'`DB`option), garantissant ainsi une durabilité lors des Fluent Bit redémarrages. Cela permet d'éviter la perte de journal lors du redémarrage du conteneur.
+ **Mise en mémoire tampon au niveau** de l'entrée : vous pouvez configurer les limites de mémoire tampon directement sur le plug-in d'entrée`Mem_Buf_Limit`, ce qui permet de contrôler plus précisément l'utilisation de la mémoire.
+ **Évite la surcharge de Docker** : les journaux passent directement du fichier au fichier Fluent Bit sans passer par les mémoires tampon de Docker.
Pour utiliser cette approche, votre application doit écrire des journaux dans des fichiers plutôt que dans`stdout`. 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 :
+ Implémentez la rotation des journaux de vos applications afin d'éviter l'épuisement du disque. Surveillez les indicateurs de volume sous-jacents pour évaluer les performances.
+ Tenez compte de paramètres tels que `Ignore_Older``Read_from_Head`, et des analyseurs multilignes basés sur le format de votre journal.
Pour plus d'informations, consultez [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail) dans la Fluent Bit documentation. Pour connaître les meilleures pratiques, consultez [la section Configuration de Tail avec les meilleures pratiques](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) 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 :
`FLUENT_HOST`
Adresse IP attribuée au FireLens conteneur.
Si vous utilisez EC2 en mode `bridge` réseau, la variable d'`FLUENT_HOST`environnement de votre conteneur d'applications peut devenir inexacte après le redémarrage du conteneur FireLens log router (le conteneur contenant l'`firelensConfiguration`objet dans sa définition de conteneur). Cela est dû au fait que `FLUENT_HOST` est une adresse IP dynamique qui peut changer après un redémarrage. La journalisation directe depuis le conteneur de l’application vers l’adresse IP `FLUENT_HOST` peut commencer à échouer après le changement d’adresse. Pour obtenir plus d’informations sur le redémarrage de conteneurs individuels, consultez la section [Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs](container-restart-policy.md).
`FLUENT_PORT`
Port sur lequel le protocole Fluent Forward écoute.
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 sur`stdout`. Cette approche contourne la couche de pilote de journalisation Docker, ce qui offre les avantages suivants :
+ **Latence réduite** : les journaux sont directement accessibles Fluent Bit sans passer par l'infrastructure de journalisation de Docker.
+ **Journalisation structurée** : envoyez des données de journal structurées de manière native sans surcharge de codage JSON.
+ **Meilleur contrôle** : votre application peut implémenter sa propre logique de mise en mémoire tampon et de gestion des erreurs.
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 :
+ **Go** – [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python** : [fluent-logger-python](https://github.com/fluent/fluent-logger-python)
+ **Java** : [fluent-logger-java](https://github.com/fluent/fluent-logger-java)
+ **Node.js** : [fluent-logger-node](https://github.com/fluent/fluent-logger-node)
+ **Ruby** – [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby)
## 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 dans`log-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](https://docs.docker.com/engine/logging/drivers/fluentd/) 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 :
+ Cette option est prise en charge sur le type de lancement Amazon EC2 et le type de lancement Fargate avec la version de plateforme `1.4.0` ou une version ultérieure.
+ L'option n'est valide que lorsque `logDriver` est défini sur `awsfirelens`.
+ La limite par défaut du tampon est de `1048576` lignes de journal.
+ La limite de mémoire tampon doit être supérieure ou égale à `0` et inférieure à `536870912` lignes de journal.
+ La quantité maximale de mémoire utilisée pour cette mémoire tampon est le produit de la taille de chaque ligne de journal par la taille de la mémoire tampon. Par exemple, si les lignes de journal de l'application sont en moyenne en `2` KiB, une limite de mémoire tampon de 4 096 utiliserait au maximum 1 `8` MiB. La quantité totale de mémoire allouée au niveau de la tâche doit être supérieure à la quantité de mémoire allouée à tous les conteneurs, en plus du tampon mémoire du pilote de journalisation.
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
}
]
}
```
# AWS pour les référentiels Fluent Bit d'images pour Amazon ECS
AWS fournit une Fluent Bit image avec des plugins pour CloudWatch Logs et Firehose. Nous vous recommandons d'utiliser Fluent Bit comme routeur de journal car il a un taux d'utilisation des ressources inférieur à Fluentd. Pour plus d'informations, consultez [CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) et [Amazon Kinesis Firehose](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit) for Fluent Bit.
L'image **AWS for Fluent Bit** est disponible sur Amazon ECR à la fois dans la galerie publique Amazon ECR et dans un référentiel Amazon ECR pour une haute disponibilité.
## Galerie publique Amazon ECR
L'Fluent Bitimage AWS pour est disponible sur la galerie publique Amazon ECR. Il s'agit de l'emplacement recommandé pour télécharger l'Fluent Bitimage AWS for, car il s'agit d'un dépôt public et peut être utilisé par tous Régions AWS. Pour plus d'informations, consultez [aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit)la galerie publique Amazon ECR.
### Linux
L'Fluent Bitimage AWS for de la galerie publique Amazon ECR prend en charge le système d'exploitation Amazon Linux avec l'`x86-64`architecture `ARM64` or.
Vous pouvez extraire l'Fluent Bitimage AWS for de la galerie publique Amazon ECR en spécifiant l'URL du référentiel avec la balise d'image souhaitée. Les étiquettes d'image disponibles peuvent être trouvées sur la page **Étiquettes d'image** dans la galerie publique Amazon ECR.
L'exemple suivant montre la syntaxe à utiliser pour la CLI Docker.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
Par exemple, vous pouvez extraire la dernière image de la famille « 3.x » de quatre Fluent Bit versions à l'aide AWS de cette commande Docker CLI.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
**Note**
Les extractions non authentifiées sont autorisées, mais ont une limite de débit inférieure à celle des extractions authentifiées. Pour vous authentifier à l'aide de votre AWS compte avant de le tirer, utilisez la commande suivante.
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
#### AWS pour Fluent Bit 3.0.0
Outre les Fluent Bit versions existantes`2.x`, AWS AWS for Fluent Bit prend en charge une nouvelle version majeure`3.x`. La nouvelle version majeure inclut la mise à niveau des images d'Amazon Linux 2 vers Amazon Linux 2023 et de Fluent Bit la version `1.9.10` vers`4.1.1`. Pour plus d'informations, consultez le [Fluent Bitréférentiel AWS for](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) surGitHub.
Les exemples suivants illustrent les balises mises à jour AWS pour les Fluent Bit `3.x` images :
Vous pouvez utiliser des balises multi-architectures pour l'Fluent Bitimage AWS for.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
### Windows
L'Fluent Bitimage AWS for de la galerie publique Amazon ECR prend en charge l'`AMD64`architecture avec les systèmes d'exploitation suivants :
+ Windows Server 2022 Full
+ Windows Server 2022 Core
+ Windows Server 2019 Full
+ Windows Server 2019 Core
Les conteneurs Windows installés sur AWS Fargate ne sont pas pris en charge. FireLens
Vous pouvez extraire l'Fluent Bitimage AWS for de la galerie publique Amazon ECR en spécifiant l'URL du référentiel avec la balise d'image souhaitée. Les étiquettes d'image disponibles peuvent être trouvées sur la page **Étiquettes d'image** dans la galerie publique Amazon ECR.
L'exemple suivant montre la syntaxe à utiliser pour la CLI Docker.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
Par exemple, vous pouvez extraire l'Fluent Bitimage stable la plus récente AWS à l'aide de cette commande Docker CLI.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable
```
**Note**
Les extractions non authentifiées sont autorisées, mais ont une limite de débit inférieure à celle des extractions authentifiées. Pour vous authentifier à l'aide de votre AWS compte avant de le tirer, utilisez la commande suivante.
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
## Amazon ECR
L'image AWS for Fluent Bit est disponible sur Amazon ECR pour une haute disponibilité. Les commandes suivantes peuvent être utilisées pour récupérer une image URIs et établir la disponibilité de l'image dans une image donnée. Région AWS
### Linux
La dernière version stable de AWS l'URI d'image Fluent Bit peut être récupérée à l'aide de la commande suivante.
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/stable \
--region us-east-1
```
Toutes les versions de l'image AWS for Fluent Bit peuvent être répertoriées à l'aide de la commande suivante pour interroger le paramètre Systems Manager Parameter Store.
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit \
--region us-east-1
```
L'image stable la plus récente AWS pour Fluent Bit peut être référencée dans un CloudFormation modèle en faisant référence au nom du magasin de paramètres Systems Manager. Voici un exemple :
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/stable
```
**Note**
Si la commande échoue ou s'il n'y a aucune sortie, l'image n'est pas disponible dans le Région AWS fichier dans lequel la commande est appelée.
### Windows
La dernière version stable de AWS l'URI d'image Fluent Bit peut être récupérée à l'aide de la commande suivante.
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/windowsservercore-stable \
--region us-east-1
```
Toutes les versions de l'image AWS for Fluent Bit peuvent être répertoriées à l'aide de la commande suivante pour interroger le paramètre Systems Manager Parameter Store.
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit/windowsservercore \
--region us-east-1
```
La dernière image stable AWS pour Fluent Bit peut être référencée dans un CloudFormation modèle en faisant référence au nom du magasin de paramètres Systems Manager. Voici un exemple :
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable
```
# Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens
Pour utiliser le routage des journaux personnalisé avec FireLens, vous devez spécifier les éléments suivants dans votre définition de tâche :
+ Conteneur de routeur journal contenant une configuration FireLens. Nous recommandons que le conteneur soit marqué comme `essential`.
+ Un ou plusieurs conteneurs d'application contenant une configuration de journal spécifiant le pilote de journal `awsfirelens`.
+ Un rôle IAM de tâche Amazon Resource Name (ARN) qui contient les autorisations nécessaires à la tâche pour acheminer les journaux.
Lorsque vous créez une nouvelle définition de tâche à l'aide de AWS Management Console, il existe une section FireLens d'intégration qui facilite l'ajout d'un conteneur de routeurs de journaux. Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md).
Amazon ECS convertit la configuration du journal et génère la configuration de sortie Fluentd ou Fluent Bit. La configuration de sortie est montée dans le conteneur de routage des journaux à `/fluent-bit/etc/fluent-bit.conf` pour Fluent Bit et `/fluentd/etc/fluent.conf` pour Fluentd.
**Important**
FireLens écoute sur le port `24224`. Par conséquent, pour garantir que le routeur de FireLens journaux n'est pas accessible en dehors de la tâche, vous ne devez pas autoriser le trafic entrant sur le port `24224` du groupe de sécurité utilisé par votre tâche. Pour les tâches utilisant le mode réseau `awsvpc`, il s'agit du groupe de sécurité associé à la tâche. Pour les tâches utilisant le mode réseau `host`, il s'agit du groupe de sécurité associé à l'instance Amazon EC2 qui héberge la tâche. Pour les tâches utilisant le mode réseau `bridge`, ne créez pas de mappages de ports utilisant le port `24224`.
Par défaut, Amazon ECS ajoute des champs supplémentaires dans vos entrées de journal qui aident à identifier la source des journaux.
+ `ecs_cluster` : nom du cluster dont la tâche fait partie.
+ `ecs_task_arn` : Amazon Resource Name (ARN) de la tâche dont le conteneur fait partie.
+ `ecs_task_definition` : nom et révision de la définition de tâche que la tâche utilise.
+ `ec2_instance_id` : ID de l'instance Amazon EC2 sur laquelle le conteneur est hébergé. Ce champ est uniquement valide pour les tâches qui utilisent le type de lancement EC2.
Vous pouvez définir `enable-ecs-log-metadata` sur `false` si vous ne souhaitez pas les métadonnées.
L'exemple de définition de tâche suivant définit un conteneur de routeur de journaux qui utilise Fluent Bit pour acheminer ses CloudWatch journaux vers Logs. Il définit également un conteneur d’application qui utilise une configuration de journal pour acheminer les journaux vers Amazon Data Firehose et définit la mémoire utilisée pour mettre en mémoire tampon les événements à 2 Mio.
**Note**
Pour plus d'exemples de définitions de tâches, consultez [les FireLens exemples d'Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) sur GitHub.
```
{
"family": "firelens-example-firehose",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role",
"containerDefinitions": [
{
"name": "log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"portMappings": [],
"essential": true,
"environment": [],
"mountPoints": [],
"volumesFrom": [],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/ecs-aws-firelens-sidecar-container",
"mode": "non-blocking",
"awslogs-create-group": "true",
"max-buffer-size": "25m",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "firelens"
},
"secretOptions": []
},
"systemControls": [],
"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": "1048576"
}
},
"memoryReservation": 100
}
]
}
```
Les paires clés/valeurs spécifiées en tant qu'options dans l'objet `logConfiguration` sont utilisées pour générer la configuration de sortie Fluentd ou Fluent Bit. Voici un exemple de code à partir d'une définition de sortie Fluent Bit.
```
[OUTPUT]
Name firehose
Match app-firelens*
region us-west-2
delivery_stream my-stream
```
**Note**
FireLens gère la `match` configuration. Vous ne spécifiez pas la configuration `match` dans votre définition de tâche.
## Utilisation d’un fichier de configuration
Vous pouvez spécifier un fichier de configuration personnalisé. Le format du fichier de configuration est le format natif du routeur de journal que vous utilisez. Pour plus d’informations, consultez les sections [Syntaxe du fichier de configuration Fluentd](https://docs.fluentd.org/configuration/config-file) et [Fichier de configuration YAML](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml).
Dans votre fichier de configuration personnalisé, pour les tâches utilisant le mode réseau `bridge` ou `awsvpc`, ne définissez pas d'entrée de transfert Fluentd ou Fluent Bit sur TCP, car FireLens l'ajoute à la configuration d'entrée.
Votre configuration FireLens doit contenir les options suivantes pour spécifier un fichier de configuration personnalisé :
`config-file-type`
Emplacement source du fichier de configuration personnalisé. Les options disponibles sont `s3` ou `file`.
Les tâches hébergées sur AWS Fargate ne prennent en charge que le type `file` de fichier de configuration. Toutefois, vous pouvez utiliser les fichiers de configuration hébergés dans Amazon S3 sur AWS Fargate en utilisant AWS le Fluent Bit conteneur for init. Pour plus d'informations, voir [Processus d'initialisation pour Fluent Bit sur ECS, support multi-configurations activé](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub
`config-file-value`
Source du fichier de configuration personnalisé. Si le type de fichier de configuration `s3` est utilisé, la valeur du fichier de configuration est l'ARN complet du compartiment Amazon S3 et du fichier. Si le type de fichier de configuration `file` est utilisé, la valeur du fichier de configuration est le chemin d'accès complet du fichier de configuration qui existe soit dans l'image du conteneur, soit sur un volume monté dans le conteneur.
Lorsque vous utilisez un fichier de configuration personnalisé, vous devez spécifier un chemin différent de celui utilisé par FireLens. Amazon ECS réserve les chemins de fichier `/fluent-bit/etc/fluent-bit.conf` pour Fluent Bit et `/fluentd/etc/fluent.conf` pour Fluentd.
L'exemple suivant montre la syntaxe requise lors de la spécification d'une configuration personnalisée.
**Important**
Pour spécifier un fichier de configuration personnalisé hébergé dans Amazon S3, vérifiez que vous avez créé un rôle IAM d'exécution de tâche avec les autorisations appropriées.
Voici la syntaxe requise lors de la spécification d'une configuration personnalisée.
```
{
"containerDefinitions": [
{
"essential": true,
"image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:3",
"name": "log_router",
"firelensConfiguration": {
"type": "fluentbit",
"options": {
"config-file-type": "s3 | file",
"config-file-value": "arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf | filepath"
}
}
}
]
}
```
**Note**
Les tâches hébergées sur AWS Fargate ne prennent en charge que le type `file` de fichier de configuration. Toutefois, vous pouvez utiliser les fichiers de configuration hébergés dans Amazon S3 sur AWS Fargate en utilisant AWS le Fluent Bit conteneur for init. Pour plus d'informations, voir [Processus d'initialisation pour Fluent Bit sur ECS, support multi-configurations activé](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub