# Amazon ECS ログを AWS サービスまたは AWS Partner に送信する
FireLens for Amazon ECS では、タスク定義パラメータを使用してログを AWS サービスや AWS Partner Network (APN) の宛先にルーティングし、ログを保存および分析できます。AWS Partner Network は、プログラム、専門知識、リソースを活用して顧客向けサービスの構築、マーケティング、販売を行うパートナーのグローバルコミュニティです。詳細については、「[AWS Partner](https://aws.amazon.com/partners/work-with-partners/)」を参照してください。FireLens は [Fluentd](https://www.fluentd.org/) および [Fluent Bit](https://fluentbit.io/) と連携しています。Fluent Bit イメージ用に AWS を提供していますが、Fluentd や Fluent Bit のイメージはご用意いただいたものを使用することもできます。
デフォルトでは、Amazon ECS は、Firelens コンテナを使用するコンテナより前に Firelens コンテナを起動するようにコンテナの依存関係を設定します。また Firelens コンテナは、それを使用するすべてのコンテナが停止した後で停止します。
この機能を使用するには、タスク用の IAM ロールを作成し、AWS のサービスを使用するために必要なアクセス許可をタスクに付与する必要があります。例えば、コンテナから Firehose にログをルーティングする場合、タスクには `firehose:PutRecordBatch` API を呼び出すためのアクセス許可が必要です。詳細については、*IAM ユーザーガイド*の「[IAM ID アクセス許可の追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
以下の場合は、タスクに Amazon ECS タスク実行ロールが必要になることもあります。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
+ タスクが Fargate でホストされていて、Amazon ECR からコンテナイメージをプルしたり、ログ設定で AWS Secrets Manager の機密データを参照したりする場合は、タスク実行 IAM ロールを含める必要があります。
+ Amazon S3 でホストされているカスタム設定ファイルを使用する場合は、タスク実行 IAM ロールに `s3:GetObject` アクセス許可が含まれている必要があります。
FireLens for Amazon ECS を使用する際は、以下の点を考慮してください。
+ コンソール上でコンテナ名を簡単に区別できるよう、`my_service_` をログコンテナ名に追加することをおすすめします。
+ Amazon ECS はデフォルトで、アプリケーションコンテナと FireLens コンテナの間に開始コンテナ順序依存関係を追加します。アプリケーションコンテナと FireLens コンテナ間でコンテナ順序を指定すると、デフォルトの開始コンテナ順序が上書きされます。
+ FireLens for Amazon ECS は、Linux の AWS Fargate と Linux の Amazon EC2 の両方でホストされたタスクでサポートされます。Windows コンテナは FireLens をサポートしていません。
Windows コンテナの集中ロギングを設定する方法については、「[Centralized logging for Windows containers on Amazon ECS using Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/)」(Fluent Bit を使用した Amazon ECS での Windows コンテナの集中ロギング) を参照してください。
+ Amazon ECS の FireLens は、CloudFormation テンプレートを使用して設定できます。詳細については、*AWS CloudFormation ユーザーガイド*の「[AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)」を参照してください。
+ FireLens はポート `24224` でリッスンするため、FireLens ログルーターがタスク外に到達できないようにするには、タスクが使用するセキュリティグループでポート `24224` でのインバウンドトラフィックを許可してはなりません。`awsvpc` ネットワークモードを使用するタスクの場合、これは、そのタスクに関連付けられたセキュリティグループです。`host` ネットワークモードを使用するタスクでは、そのタスクをホストする Amazon EC2 インスタンスに関連付けられているセキュリティグループです。`bridge` ネットワークモードを使用するタスクの場合、ポート `24224` を使用するポートマッピングを作成しないでください。
+ `bridge` ネットワークモードを使用するタスクの場合、FireLens 設定のコンテナは、それに依存するアプリケーションコンテナが開始する前に開始する必要があります。コンテナの開始順序を制御するには、タスク定義の依存関係条件を使用します。詳細については、「[コンテナの依存関係](task_definition_parameters.md#container_definition_dependson)」を参照してください。
**注記**
FireLens 設定のコンテナ定義で依存関係条件パラメータを使用する場合は、各コンテナに `START` または `HEALTHY` 条件要件があることを確認してください。
+ デフォルトでは、FireLens はクラスターとタスクの定義名、およびクラスターの Amazon リソースネーム (ARN) をメタデータキーとして stdout/stderr コンテナログに追加します。メタデータ形式の例を次に示します。
```
"ecs_cluster": "cluster-name",
"ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE",
"ecs_task_definition": "task-def-name:revision",
```
ログにメタデータを含めたくない場合は、タスク定義の「`firelensConfiguration`」セクションで `enable-ecs-log-metadata` を `false` に設定します。
```
"firelensConfiguration":{
"type":"fluentbit",
"options":{
"enable-ecs-log-metadata":"false",
"config-file-type":"file",
"config-file-value":"/extra.conf"
}
```
非ルートユーザーとして実行するように FireLens コンテナを設定できます。以下の点を考慮してください。
+ 非ルートユーザーとして実行するように FireLens コンテナを設定するには、次のいずれかの形式でユーザーを指定する必要があります。
+ `uid`
+ `uid:gid`
+ `uid:group`
コンテナ定義について、詳細は「*Amazon Elastic Container Service API リファレンス*」の「[ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)」を参照してください。
FireLens コンテナは UNIX ソケット経由でアプリケーションログを受け取ります。Amazon ECS エージェントは `uid` を使用してソケットディレクトリの所有権を FireLens コンテナに割り当てます。
+ 非ルートユーザーとして実行するための FireLens コンテナ設定は、Amazon ECS エージェントバージョン `1.96.0` 以降、および Amazon ECS 最適化 AMI のバージョン `v20250716` 以降でサポートされています。
+ FireLens コンテナのユーザーを指定する場合、`uid` は一意でなければならず、タスク内の他のコンテナまたはコンテナインスタンスに属する他のプロセスには使用されません。
Amazon S3 でホストするファイルや Amazon S3 内のファイルなど、Amazon ECS で複数の設定ファイルを使用する方法については、「[Init process for Fluent Bit on ECS, multi-config support](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit)」を参照してください。
構成例については、「[Amazon ECS タスク定義の例: FireLens にログをルーティングする](firelens-taskdef.md)」を参照してください。
高スループットのログ有効化と設定について、詳細は「[高スループットの Amazon ECS ログの設定](firelens-docker-buffer-limit.md)」を参照してください。
# 高スループットの Amazon ECS ログの設定
ログスループットの高いシナリオでは、FireLens と Fluent Bit を組み合わせた `awsfirelens` ログドライバーを使用することをお勧めします。 Fluent Bit は、リソースを効率的に処理し、数百万のログレコードを処理できる軽量ログプロセッサです。ただし、大規模に最適なパフォーマンスを実現するには、その設定を調整する必要があります。
このセクションでは、システムの安定性を維持し、データ損失を回避しながら、高いログスループットを処理するための高度な Fluent Bit 最適化手法について説明します。
FireLens でカスタム設定ファイルを使用する方法については、「[カスタム設定ファイルを使用する](firelens-taskdef.md#firelens-taskdef-customconfig)」を参照してください。その他の例については、GitHub の「[Amazon ECS FireLens の例](https://github.com/aws-samples/amazon-ecs-firelens-examples)」を参照してください。
**注記**
`workers` や `threaded` など、このセクションの一部の設定オプションでは、Fluent Bit バージョン 3 以降の AWS が必要です。使用可能なバージョンについては、「 [AWS for Fluent Bit リリース](https://github.com/aws/aws-for-fluent-bit/releases)」を参照してください。
## ファイルシステムのバッファリングを使用する
デフォルトでは、 Fluent Bit はメモリ内のすべてのデータをバッファします。データが出力にフラッシュされるよりも速く取り込まれると、バッファが満杯になります。満杯になると、入力プラグインはバッファスペースが使用可能になるまで一時停止します。これにより、バックプレッシャーが発生し、アプリケーションの速度が低下する可能性があります。
高スループットのシナリオでは、ファイルシステムのバッファリングを使用することをお勧めします。Fluent Bit がバッファリングとストレージを管理する方法の詳細については、 Fluent Bit ドキュメントの「[バッファリングとストレージ](https://docs.fluentbit.io/manual/administration/buffering-and-storage)」を参照してください。
ファイルシステムのバッファリングには、次の利点があります。
+ **バッファ容量が大きい** — 通常、ディスクスペースはメモリよりも豊富です。
+ **永続性** – バッファされたデータは Fluent Bit 再起動後も保持されます。
+ **グレースフルデグラデーション** – 出力の失敗時に、メモリの枯渇を引き起こすのではなく、データがディスクに蓄積されます。
ファイルシステムのバッファリングを有効にするには、カスタム Fluent 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
[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
```
主な設定パラメータ:
`storage.path`
Fluent Bit がバッファされたチャンクをディスクに保存するディレクトリ。
`storage.backlog.flush_on_shutdown`
有効にすると、Fluent Bit はシャットダウン中にすべてのバックログファイルシステムのチャンクを送信先にフラッシュしようとします。これにより、Fluent Bit が停止する前にデータ配信を確保できますが、シャットダウン時間が長くなる可能性があります。
`storage.max_chunks_up`
メモリに残っているチャンクの数。デフォルトは 128 チャンクで、各チャンクは最大 4～5 MB を使用できるため、500 MB 以上のメモリを消費する可能性があります。メモリに制約のある環境では、この値を小さくします。たとえば、バッファリングに 50 MB 使用できる場合は、これを 8～10 チャンクに設定します。
`storage.type filesystem`
入力プラグインのファイルシステムストレージを有効にします。名前にかかわらず、 Fluent Bit は `mmap` を使用してチャンクをメモリとディスクの両方にマッピングし、パフォーマンスを犠牲にすることなく永続性を提供します。
`threaded true`
Fluent Bit のメインイベントループとは別に、独自のスレッドで入力を実行します。これにより、遅い入力がパイプライン全体をブロックすることを防ぎます。
## 出力設定の最適化
ネットワークの問題、サービスの停止、送信先スロットリングにより、ログの配信が妨げられる場合があります。適切な出力設定により、データ損失のない耐障害性を保証します。
出力フラッシュが失敗した場合、 Fluent Bit はオペレーションを再試行できます。次のパラメータは再試行動作を制御します。
`retry_limit`
レコードを削除する前の最大再試行回数。デフォルトは 1 です。本番環境では、数分の停止に対応できるよう、エクスポネンシャルバックオフを用いた再試行数を 15 回以上に設定することをお勧めします。
`scheduler.base`
再試行間の最小秒数。10 秒をお勧めします。
`scheduler.cap`
エクスポネンシャルバックオフを使用する場合の再試行間の最大秒数。60 秒をお勧めします。
`workers`
並列出力処理のスレッド数。複数のワーカーが同時フラッシュを許可し、多くのチャンクを処理する際のスループットを向上させます。
`[SERVICE]` セクションの `Grace` パラメータは、バッファされたデータをフラッシュするためにシャットダウン中に Fluent Bit が待機する時間を設定します。`Grace` 期間はコンテナの `stopTimeout` と調整する必要があります。`SIGKILL` を受信する前に Fluent Bit がフラッシュを完了できるように、`stopTimeout` が `Grace` 期間を超えていることを確認します。たとえば、`Grace` が 120 秒の場合、 `stopTimeout` を 150 秒に設定します。
次の例は、高スループットシナリオで推奨されるすべての設定を含む完全な Fluent 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
```
## マルチ送信先ログを使用して信頼性を高める
複数の送信先にログを送信すると、単一障害点がなくなります。たとえば、CloudWatch Logs で機能停止が発生した場合でも、ログは Amazon S3 に到達します。
マルチ送信先ログには、次の利点があります。Amazon S3 出力プラグインは、gzip 形式や Parquet 形式などの圧縮オプションもサポートしているため、ストレージコストを削減できます。詳細については、「Fluent Bit ドキュメント」の「[S3 圧縮](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression)」を参照してください。
マルチ送信先ログには、次の利点があります。
+ **冗長性** – 一方の送信先が失敗しても、ログはもう一方の送信先に到達します。
+ **復旧** – 一方のシステムのギャップを他方のシステムから再構築します。
+ **耐久性** – ログを Amazon S3 にアーカイブして長期保持します。
+ **コスト最適化** – 最近のログを CloudWatch Logs などの高速クエリサービスに短期間保存し、すべてのログを低コストの Amazon S3 ストレージにアーカイブして長期保持します。
次の Fluent Bit 設定は、CloudWatch Logs と 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
```
どちらの出力も同じ `Match *` パターンを使用するため、すべてのレコードは両方の送信先に個別に送信されます。どちらか一方の送信先が停止しても、ログは引き続き他の送信先に流れ続け、失敗したフラッシュは後で再試行できるようにファイルシステムバッファに蓄積されます。
## tail 入力プラグインでファイルベースのログを使用する
ログ損失が重大な懸念事項となる高スループットのシナリオでは、別の方法として、アプリケーションがディスク上のファイルにログを書き込み、`tail` 入力プラグインを使用してそれらを読み取るように Fluent Bit を設定します。このアプローチは、Docker ログドライバーレイヤーを完全にバイパスします。
tail プラグインを使用したファイルベースのログ記録には、次の利点があります。
+ **オフセット追跡** – tail プラグインはデータベースファイルにファイルオフセットを保存できるため (`DB` オプションを使用)、Fluent Bit 再起動した際に耐久性があります。これにより、コンテナの再起動時にログが消失するのを防ぐことができます。
+ **入力レベルのバッファリング** – `Mem_Buf_Limit` を使用して入力プラグインでメモリバッファ制限を直接設定できるため、メモリ使用量をより詳細に制御できます。
+ **Docker のオーバーヘッドを回避** – Docker のログバッファを経由することなく、ログはファイルから Fluent Bit に直接送信されます。
このアプローチを使用するには、アプリケーションが `stdout` ではなくファイルにログを書き込む必要があります。アプリケーションコンテナと Fluent Bit コンテナの両方が、ログファイルが保存されている共有ボリュームをマウントします。
次の例は、ベストプラクティスを使用した tail 入力設定を示しています。
```
[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
```
tail 入力プラグインを使用する場合は、次の点を考慮してください。
+ ディスクの枯渇を防ぐために、アプリケーションログのログローテーションを実装します。基盤となるボリュームメトリクスをモニタリングしてパフォーマンスを測定します。
+ ログ形式に基づいて、`Ignore_Older`、`Read_from_Head` および複数行パーサーなどの設定を検討してください。
詳細については、「Fluent Bit ドキュメント」の「[Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail)」を参照してください。ベストプラクティスについては、「Fluent Bit トラブルシューティングガイド」の AWS の「[ベストプラクティスを使用した Tail 設定](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices)」を参照してください。
## FireLens に直接ログ記録する
`awsfirelens` ログドライバーがタスク定義で指定されている場合、Amazon ECS コンテナエージェントは次の環境変数をコンテナに挿入します。
`FLUENT_HOST`
FireLens コンテナに割り当てられた IP アドレス。
`bridge` ネットワークモードの EC2 を使用している場合、FireLens ログルーターコンテナ (コンテナ定義に `firelensConfiguration` オブジェクトがあるコンテナ) を再起動した後で、アプリケーションコンテナの `FLUENT_HOST` 環境変数が不正確になる可能性があります。これは、`FLUENT_HOST` が動的 IP アドレスであり、再起動後に変更される場合があるためです。アプリケーションコンテナから `FLUENT_HOST` IP アドレスへの直接的なロギングは、アドレスの変更後に失敗することがあります。個々のコンテナの再起動に関する詳細については、「[コンテナ再起動ポリシーを使用して Amazon ECS タスク内の個々のコンテナを再起動する](container-restart-policy.md)」を参照してください。
`FLUENT_PORT`
Fluent Forward プロトコルがリッスンしているポート。
これらの環境変数を使用して、`stdout` に書き込む代わりに Fluent Forward プロトコルを使用してアプリケーションコードから Fluent Bit ログルーターに直接ログを記録できます。このアプローチでは、Docker ログドライバーレイヤーをバイパスします。これにより、次の利点が得られます。
+ **低レイテンシー** – Docker のログインフラストラクチャを経由することなく、ログは Fluent Bit に直接送信されます。
+ **構造化ログ** – JSON エンコーディングのオーバーヘッドなしで、構造化ログデータをネイティブに送信します。
+ **より良い制御** – アプリケーションは独自のバッファリングとエラー処理ロジックを実装できます。
次の Fluent ロガーライブラリは Fluent Forward プロトコルをサポートし、ログを 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)
## Docker バッファ制限を設定する
タスク定義を作成する際は、`log-driver-buffer-limit` で値を指定することで、メモリにバッファリングされるログの行数を指定できます。これにより、Docker と Fluent Bit の間のバッファが制御されます。詳細については、Docker ドキュメントの「[Fluentd ロギングドライバー](https://docs.docker.com/engine/logging/drivers/fluentd/)」を参照してください。
このオプションは、スループットが高いために Docker がバッファメモリを使い果たし、新しいメッセージを追加するためにバッファメッセージを破棄する可能性がある場合に使用します。
このオプションを使用する場合は、次の点を考慮してください。
+ このオプションは、EC2 およびプラットフォームバージョン `1.4.0` 以降の Fargate でサポートされています。
+ このオプションは、`logDriver` が `awsfirelens` に設定されている場合にのみ有効です。
+ デフォルトのバッファ制限は `1048576` (ログの行数) です。
+ バッファ制限は、`0` ログ行以上、`536870912` ログ行未満である必要があります。
+ このバッファに使用されるメモリの最大量は、各ログ行のサイズとバッファのサイズ積です。たとえば、アプリケーションのログ行が平均 `2` KiB の場合、4096 のバッファ制限では最大 `8` MiB を使用します。タスクレベルで割り当てられるメモリの合計量は、ログドライバーのメモリバッファに加えて、すべてのコンテナに割り当てられたメモリ量よりも大きくなければなりません。
次のタスク定義は、`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
}
]
}
```
# Amazon ECS の Fluent Bit イメージリポジトリの AWS
AWS は、CloudWatch Logs と Firehose の両方のプラグインに Fluent Bit イメージを提供します。Fluent Bit は、リソース使用率が Fluentd よりも低いため、ログルーターとして使用することをお勧めします。詳細については、「[CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit)」および「[Amazon Kinesis Firehose for Fluent Bit](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit)」を参照してください。
**AWS for Fluent Bit** イメージは、Amazon ECR Public Gallery と Amazon ECR リポジトリの両方の Amazon ECR で利用が可能で、高可用性を実現できます。
## Amazon ECR Public Gallery
AWS for Fluent Bit イメージは Amazon ECR Public Gallery で利用できます。これはパブリックリポジトリであり、すべての AWS リージョン リージョンから使用できるため、AWS for Fluent Bit イメージのダウンロード先として推奨されます 詳細については、Amazon ECR Public Gallery の「[aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit)」を参照してください。
### Linux
Amazon ECR Public Gallery の AWS for Fluent Bit イメージは、`ARM64` または `x86-64` アーキテクチャの Amazon Linux オペレーティングシステムをサポートしています。
目的のイメージタグを使用してリポジトリ URL を指定することにより、Amazon ECR Public Gallery からAWS for Fluent Bit イメージをプルできます。利用可能な画像タグは、Amazon ECR Public Gallery の [**Image tags (画像タグ)**] タブにあります。
Docker CLI で使用する構文を以下に示します。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
たとえば、次の Docker CLI コマンドを使用すれば、Fluent Bit リリースの AWS の「3.x」ファミリの最新イメージをプルできます。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
**注記**
認証されていないプルは許可されますが、認証されたプルよりもレート制限が低くなります。プルする前に、次のコマンドを使用して AWS アカウントの使用を認証します。
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
#### Fluent Bit 3.0.0 向けの AWS
Fluent Bit バージョン `2.x` の既存 AWS に加えて、Fluent Bit の AWS は新しいメジャーバージョン `3.x` をサポートします。新しいメジャーバージョンには、イメージを Amazon Linux 2 から Amazon Linux 2023 にアップグレードし、Fluent Bit バージョン `1.9.10` を `4.1.1` にアップグレードすることが含まれます。詳細は GitHub の「[AWS for Fluent Bit repository](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md)」を参照してください。
次の例は、Fluent Bit `3.x` イメージの AWS の更新済みタグを示しています。
Fluent Bit イメージの AWS にはマルチアーキテクチャタグを使用できます。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
### Server
Amazon ECR Public Gallery の AWS for Fluent Bit イメージは、次のオペレーティングシステムを備えた `AMD64` アーキテクチャをサポートしています。
+ Windows Server 2022 Full
+ Windows Server 2022 Core
+ Windows Server 2019 Full
+ Windows Server 2019 Core
AWS Fargate の Windows コンテナは FireLens をサポートしません。
目的のイメージタグを使用してリポジトリ URL を指定することにより、Amazon ECR Public Gallery からAWS for Fluent Bit イメージをプルできます。利用可能な画像タグは、Amazon ECR Public Gallery の [**Image tags (画像タグ)**] タブにあります。
Docker CLI で使用する構文を以下に示します。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
例えば、次の Docker CLI コマンドを使用して、AWS for Fluent Bit イメージの最新安定版をプルできます。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable
```
**注記**
認証されていないプルは許可されますが、認証されたプルよりもレート制限が低くなります。プルする前に、次のコマンドを使用して AWS アカウントの使用を認証します。
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
## Amazon ECR
AWS for Fluent Bit イメージは、Amazon ECR で高可用性を活用できます。次のコマンドを使用して、イメージ URI の取得および特定の AWS リージョンでイメージの可用性を確立できます。
### Linux
最新の安定している AWS for Fluent Bit イメージの URI は、次のコマンドを使用して取得できます。
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/stable \
--region us-east-1
```
次のコマンドを使用して Systems Manager パラメータストアのパラメータをクエリすると、AWS for Fluent Bit イメージのすべてのバージョンを一覧表示できます。
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit \
--region us-east-1
```
AWS for Fluent Bit イメージの最新安定版は、Systems Manager パラメータストア名を参照することにより、CloudFormation テンプレート内に見つかります。次にの例を示します。
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/stable
```
**注記**
コマンドが失敗するか、出力がない場合、イメージはコマンドが呼び出される AWS リージョンでは使用できません。
### Server
最新の安定している AWS for Fluent Bit イメージの URI は、次のコマンドを使用して取得できます。
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/windowsservercore-stable \
--region us-east-1
```
次のコマンドを使用して Systems Manager パラメータストアのパラメータをクエリすると、AWS for Fluent Bit イメージのすべてのバージョンを一覧表示できます。
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit/windowsservercore \
--region us-east-1
```
最新の安定している AWS for Fluent Bit イメージは、Systems Manager パラメータストア名を参照することにより、CloudFormation テンプレートで参照できます。次にの例を示します。
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable
```
# Amazon ECS タスク定義の例: FireLens にログをルーティングする
FireLens でカスタムログルーティングを使用するには、タスク定義で以下を指定する必要があります。
+ FireLens 設定を含むログルーターコンテナ。コンテナは `essential` とマークすることが推奨されます。
+ `awsfirelens` ログドライバーを指定するログ設定を含む 1 つ以上のアプリケーションコンテナ。
+ タスクでログをルーティングするために必要なアクセス許可を含むタスク IAM ロール の、Amazon リソースネーム (ARN)。
AWS マネジメントコンソール を使用して新しいタスク定義を作成する場合、ログルーターコンテナを簡単に追加できる FireLens 統合セクションがあります。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
Amazon ECS はログ設定を変換し、Fluentd または Fluent Bit 出力設定を生成します。出力設定は、`/fluent-bit/etc/fluent-bit.conf` (Fluent Bit) および `/fluentd/etc/fluent.conf` (Fluentd) のログルーティングコンテナにマウントされます。
**重要**
FireLens は、ポート `24224` でリッスンします。したがって、FireLens ログルーターがタスクの外に到達できないようにするには、タスクが使用するセキュリティグループで、ポート `24224` での入力トラフィックを許可してはなりません。`awsvpc` ネットワークモードを使用する場合、このセキュリティグループは、タスクに関連付けられたセキュリティグループです。`host` ネットワークモードを使用する場合、これはタスクをホストする Amazon EC2 インスタンスに関連付けられているセキュリティグループです。`bridge` ネットワークモードを使用するタスクの場合、ポート `24224` を使用するポートマッピングを作成しないでください。
デフォルトでは、Amazon ECS は、ログのソースを識別するのに役立つ追加のフィールドをログエントリに追加します。
+ `ecs_cluster` - タスクが所属するクラスターの名前。
+ `ecs_task_arn` – コンテナが属しているタスクの完全な Amazon リソースネーム (ARN)。
+ `ecs_task_definition` - タスクが使用しているタスク定義名とリビジョン。
+ `ec2_instance_id` - コンテナがホストされている Amazon EC2 インスタンス ID。このフィールドは、EC2 起動タイプを使用するタスクでのみ有効です。
メタデータが必要ない場合は、`enable-ecs-log-metadata` を `false` に設定できます。
以下のタスク定義の例では、Fluent Bit を使用してログを CloudWatch Logs にルーティングするログルーターコンテナを定義しています。また、これによりアプリケーションコンテナを定義します。このコンテナでは、ログ設定を使用してログを Amazon Data Firehose にルーティングし、イベントのバッファリングに使用されるメモリを 2MiB に設定します。
**注記**
タスク定義のその他の例については、GitHub の [Amazon ECS FireLens の例](https://github.com/aws-samples/amazon-ecs-firelens-examples)を参照してください。
```
{
"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
}
]
}
```
`logConfiguration` オブジェクトのオプションとして指定されたキーバリューペアは、Fluentd または Fluent Bit 出力設定の生成に使用されます。Fluent Bit 出力定義のコード例は次のとおりです。
```
[OUTPUT]
Name firehose
Match app-firelens*
region us-west-2
delivery_stream my-stream
```
**注記**
FireLens は `match` 設定を管理します。タスク定義では `match` 設定を指定しません。
## カスタム設定ファイルを使用する
カスタム設定ファイルを指定できます。設定ファイルの形式は、使用しているログルーターでネイティブな形式を使用します。詳細については、「[Fluentd 設定ファイルの構文](https://docs.fluentd.org/configuration/config-file)」および「[YAML 設定](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml)」を参照してください。
カスタム設定ファイルでは、`bridge` または `awsvpc` ネットワークモードを使用するタスクについて、TCP 経由で Fluentd または Fluent Bit の転送入力を設定しないでください。入力設定は FireLens により追加されています。
カスタム設定ファイルを指定するには、FireLens 設定に次のオプションを含める必要があります。
`config-file-type`
カスタム設定ファイルのソースの場所。使用できるオプションは、`s3` または `file` です。
AWS Fargate でホストされるタスクは、`file` 設定ファイルタイプのみをサポートします。ただし、Fluent Bit init コンテナの AWS を使用して、AWS Fargate の Amazon S3 でホストされている設定ファイルを使用できます。詳細については、GitHub の「[Init process for Fluent Bit on ECS, multi-config support](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md)」を参照してください。
`config-file-value`
カスタム設定ファイルのソース。`s3` 設定ファイルタイプを使用する場合、設定ファイルの値は Amazon S3 バケットとファイルの完全な ARN です。`file` 設定ファイルタイプを使用する場合、設定ファイルのこの値は、コンテナイメージ内、またはそのコンテナにマウントされているボリューム上に存在する設定ファイルへの完全パスです。
カスタム設定ファイルを使用する場合、FireLens が使用するパスとは異なるパスを指定する必要があります。Amazon ECS は Fluent Bit に `/fluent-bit/etc/fluent-bit.conf` ファイルパスと Fluentd に `/fluentd/etc/fluent.conf` を指定します。
次の例は、カスタム設定を指定するときに必要な構文を示しています。
**重要**
Amazon S3 でホストされるカスタム設定ファイルを指定するには、適切なアクセス許可を持つタスク実行 IAM ロールが作成されている必要があります。
次に、カスタム設定を指定する際に必要な構文を示します。
```
{
"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"
}
}
}
]
}
```
**注記**
AWS Fargate でホストされるタスクは、`file` 設定ファイルタイプのみをサポートします。ただし、Fluent Bit init コンテナの AWS を使用して、AWS Fargate の Amazon S3 でホストされている設定ファイルを使用できます。詳細については、GitHub の「[Init process for Fluent Bit on ECS, multi-config support](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md)」を参照してください。