本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 為高輸送量設定 Amazon ECS 日誌
對於高日誌輸送量案例，我們建議您搭配 FireLens 和 使用`awsfirelens`日誌驅動程式Fluent Bit。 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`， AWS 需要 第 3 Fluent Bit版或更新版本。如需可用版本的資訊，請參閱 [AWS 以取得 Fluent Bit 版本](https://github.com/aws/aws-for-fluent-bit/releases)。
## 了解區塊
Fluent Bit 會以稱為*區塊的*單位處理資料。當 INPUT 外掛程式接收資料時，引擎會建立區塊，在傳送至 OUTPUT 目的地之前存放在記憶體或檔案系統上。
緩衝行為取決於 INPUT 區段中的`storage.type`設定。根據預設， Fluent Bit會使用記憶體緩衝。對於高輸送量或生產案例，檔案系統緩衝可提供更好的彈性。
如需詳細資訊，請參閱 Fluent Bit 文件中的[區塊](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks)和[什麼是區塊？](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) 中 AWS Fluent Bit的範例儲存庫。
## 記憶體緩衝 （預設）
根據預設， Fluent Bit會使用記憶體緩衝 (`storage.type memory`)。您可以使用 `Mem_Buf_Limit` 參數限制每個 INPUT 外掛程式的記憶體用量。
下列範例顯示記憶體緩衝的輸入組態：
```
[INPUT]
Name tcp
Tag ApplicationLogs
Port 5170
storage.type memory
Mem_Buf_Limit 5MB
```
**重要**
`Mem_Buf_Limit` 超過外掛程式的 時， 會Fluent Bit暫停輸入，並遺失新記錄。這可能會導致背壓並拖慢您的應用程式。Fluent Bit 日誌中會顯示下列警告：
```
[input] tcp.1 paused (mem buf overlimit)
```
記憶體緩衝適用於日誌輸送量低至中等的簡單使用案例。對於需要資料遺失的高輸送量或生產案例，請改用檔案系統緩衝。
如需詳細資訊，請參閱 Fluent Bit 文件中的[緩衝和記憶體](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory)，以及 中的[僅限記憶體緩衝](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) AWS ，以取得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 個區塊，這可能會耗用 500 MB\$1 的記憶體，因為每個區塊最多可使用 4–5 MB。在記憶體受限的環境中，降低此值。例如，如果您有 50 MB 可用於緩衝，請將此設為 8–10 個區塊。
`storage.type filesystem`
啟用輸入外掛程式的檔案系統儲存。儘管名稱為 ， Fluent Bit使用 `mmap`將區塊映射到記憶體和磁碟，提供持久性而不犧牲效能。
`storage.total_limit_size`
特定 OUTPUT 外掛程式緩衝資料的最大磁碟空間。達到此限制時，會捨棄該輸出的最舊記錄。如需調整大小的詳細資訊，請參閱 [了解 `storage.total_limit_size`](#firelens-storage-sizing)。
`threaded true`
在自己的執行緒中執行輸入，與 Fluent Bit的主要事件迴圈分開。這可防止慢速輸入封鎖整個管道。
如需詳細資訊，請參閱 Fluent Bit 文件中的[檔案系統緩衝](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering)，以及 AWS 中Fluent Bit的範例儲存庫中的[檔案系統和記憶體緩衝](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem)。
## 了解 `storage.total_limit_size`
每個 OUTPUT 外掛程式上的 `storage.total_limit_size` 參數會控制該輸出緩衝資料的磁碟空間上限。達到此限制時，會捨棄該輸出的最舊記錄，為新資料騰出空間。當磁碟空間完全用盡時， Fluent Bit 無法將記錄排入佇列，而且會遺失。
使用以下公式`storage.total_limit_size`，根據您的日誌速率和所需的復原時段計算適當的 ：
```
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)
```
下表顯示常見日誌速率和復原時段的範例計算：
| 日誌速率 | 1 小時 | 6 小時 | 12 小時 | 24 小時 |
| --- | --- | --- | --- | --- |
| 0.25 MB/s | 0.9 GB | 5.4 GB | 10.8 GB | 21.6 GB |
| 0.5 MB/s | 1.8 GB | 10.8 GB | 21.6 GB | 43.2 GB |
| 1 MB/s | 3.6 GB | 21.6 GB | 43.2 GB | 86.4 GB |
| 5 MB/s | 18 GB | 108 GB | 216 GB | 432 GB |
| 10 MB/s | 36 GB | 216 GB | 432 GB | 864 GB |
若要觀察尖峰輸送量並選擇適當的緩衝區大小，請使用[量值輸送量 FireLens 範例](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)。
使用公式、範例計算和基準測試，選擇適合`storage.total_limit_size`的執行通道，以便在中斷期間進行最佳復原。
## Amazon ECS 任務儲存需求
在 OUTPUT 區段中加總所有`storage.total_limit_size`值，並新增額外負荷緩衝區。此總計會決定 Amazon ECS 任務定義中所需的儲存空間。例如，3 個輸出 × 10 GB，每個 = 30 GB \$1 緩衝 (5–10 GB) = 總共需要 35–40 GB。如果總計超過可用儲存體， Fluent Bit可能會無法將記錄排入佇列，而且會遺失。
可用的儲存選項如下：
綁定掛載 （暫時性儲存）
+ 對於 AWS Fargate，預設值為 20 GB 的暫時性儲存 （上限為 200 GB)。在任務定義`ephemeralStorage`中使用 設定 。如需詳細資訊，請參閱*AWS CloudFormation 《 使用者指南*》中的 [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html)。
+ 對於 EC2，使用 Amazon ECS 最佳化 AMI （在作業系統和 Docker 之間共用） 時，預設值為 30 GB。透過變更根磁碟區大小來增加 。
Amazon EBS 磁碟區
+ 提供高可用性、耐用、高效能的區塊儲存。
+ 需要磁碟區組態，並在任務定義`mountPoint`中指向 `storage.path`（預設：`/var/log/flb-storage/`)。
+ 如需詳細資訊，請參閱[在 Amazon ECS 任務定義中將磁碟區組態延至啟動時進行](specify-ebs-config.md)。
Amazon EFS 磁碟區
+ 提供簡單、可擴展的檔案儲存。
+ 需要磁碟區組態，並在任務定義`mountPoint`中指向 `storage.path`（預設：`/var/log/flb-storage/`)。
+ 如需詳細資訊，請參閱[在 Amazon ECS 任務定義中指定 Amazon EFS 檔案系統](specify-efs-config.md)。
如需資料磁碟區的詳細資訊，請參閱 [Amazon ECS 任務的儲存選項](using_data_volumes.md)。
## 最佳化輸出組態
網路問題、服務中斷和目的地限流可防止日誌交付。適當的輸出組態可確保彈性而不會遺失資料。
當輸出排清失敗時， Fluent Bit可以重試 操作。下列參數控制重試行為：
`retry_limit`
捨棄記錄之前，初次嘗試後的重試次數上限。預設為 1。例如， `retry_limit 3`表示總共 4 次嘗試 (1 次初始 \$1 3 次重試）。對於生產環境，我們建議使用 15 或更高版本，這涵蓋了幾分鐘的中斷和指數退避。
將`False`無限次重試設為 `no_limits`或 ：
+ 透過記憶體緩衝，無限次重試會導致輸入外掛程式在達到記憶體限制時暫停。
+ 使用檔案系統緩衝時，最舊的記錄會在到達`storage.total_limit_size`時捨棄。
耗盡所有重試嘗試 (1 次初始 \$1 `retry_limit` 重試） 後，會捨棄記錄。 AWS 具有 `auto_retry_requests true`（預設） 的 外掛程式會在 Fluent Bit的重試機制之前提供額外的重試層。如需詳細資訊，請參閱 Fluent Bit 文件中的[設定重試](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries)。
例如，`retry_limit 3`使用預設設定 (`scheduler.base 5`、`scheduler.cap 2000`、`net.connect_timeout 10s`) 可提供約 70 秒的排程器等待時間 (10 秒 \$1 20 秒 \$1 40 秒）、40 秒的網路連線逾時 (4 次嘗試 × 10 秒），加上 AWS 外掛程式重試 – 總計約 2–10 分鐘，取決於網路條件和作業系統 TCP 逾時。
`scheduler.base`
重試之間的基本秒數 （預設值：5)。我們建議 10 秒。
`scheduler.cap`
重試之間的秒數上限 （預設值：2000)。我們建議 60 秒。
重試之間的等待時間使用指數退避與抖動：
```
wait_time = random(base, min(base × 2^retry_number, cap))
```
例如，使用 `scheduler.base 10`和 `scheduler.cap 60`：
+ 第一次重試：隨機等待 10-20 秒
+ 第二次重試：隨機等待 10-40 秒
+ 第三次重試和更新時間：隨機等待 10-60 秒 （上限）
如需詳細資訊，請參閱 Fluent Bit 文件中的[設定重試和聯網的等待時間](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry)。 [https://docs.fluentbit.io/manual/administration/networking](https://docs.fluentbit.io/manual/administration/networking)
`workers`
平行輸出處理的執行緒數目。多個工作者允許並行排清，在處理許多區塊時改善輸送量。
`auto_retry_requests`
AWS 外掛程式特定的設定，可在 的Fluent Bit內建重試機制之前提供額外的重試層。預設值為 `true`。啟用時， AWS 輸出外掛程式會在內部重試失敗的請求，再將請求視為失敗的排清並受`retry_limit`組態約束。
`[SERVICE]` 區段中的 `Grace` 參數會設定關機期間Fluent Bit等待的時間，以排清緩衝的資料。`Grace` 期間必須與容器的 協調`stopTimeout`。在接收 之前，請確定 `stopTimeout`超過允許 Fluent Bit完成排清的`Grace`期間`SIGKILL`。例如，如果 `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
```
## 了解資料遺失案例
長時間中斷或輸出目的地發生問題時，記錄可能會遺失。本指南中的組態建議是將資料遺失降至最低的最佳方法，但無法保證長時間故障期間的零遺失。了解這些案例可協助您設定 Fluent Bit以最大化彈性。
記錄可能會以兩種方式遺失：儲存填滿時會捨棄最舊的記錄，或是在系統無法接受更多資料時拒絕最新的記錄。
### 捨棄的最早記錄
當重試嘗試用盡或`storage.total_limit_size`填滿且需要為新資料騰出空間時，會捨棄最舊的緩衝記錄。
超過重試限制
在 AWS 外掛程式重試 （如果 `auto_retry_requests true`) 加上 1 次初始Fluent Bit嘗試加上`retry_limit`重試後發生。若要緩解，`retry_limit no_limits`為每個 OUTPUT 外掛程式設定無限次重試：
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
retry_limit no_limits
auto_retry_requests true
```
無限次重試可防止因重試耗盡而捨棄記錄，但可能導致 `storage.total_limit_size` 填滿。
已達到儲存限制 （檔案系統緩衝）
當輸出目的地無法使用的時間超過您設定的`storage.total_limit_size`緩衝時間時，便會發生。例如，以 1 MB/s 日誌速率的 10 GB 緩衝區可提供大約 2.7 小時的緩衝時間。若要緩解、增加`storage.total_limit_size`每個 OUTPUT 外掛程式並佈建足夠的 Amazon ECS 任務儲存：
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
storage.total_limit_size 10G
```
### 拒絕的最新記錄
當磁碟空間耗盡或輸入因 而暫停時，會捨棄最新的記錄`Mem_Buf_Limit`。
磁碟空間用盡 （檔案系統緩衝）
當磁碟空間完全用盡時，便會發生。 Fluent Bit 無法將新記錄排入佇列並遺失。若要緩解，請加總所有`storage.total_limit_size`值，並佈建足夠的 Amazon ECS 任務儲存體。如需詳細資訊，請參閱[Amazon ECS 任務儲存需求](#firelens-storage-task-requirements)。
已達到記憶體限制 （記憶體緩衝）
當輸出目的地無法使用且記憶體緩衝區填滿時，便會發生。暫停的輸入外掛程式會停止接受新記錄。若要緩解，請使用 `storage.type filesystem`以獲得更好的彈性，或增加 `Mem_Buf_Limit`。
### 將資料遺失降至最低的最佳實務
請考慮下列最佳實務，將資料遺失降至最低：
+ **使用檔案系統緩衝 –** 設定 `storage.type filesystem`以在中斷期間獲得更好的彈性。
+ **適當的大小儲存** – 根據`storage.total_limit_size`日誌速率和所需的復原時段來計算。
+ **佈建足夠的磁碟** – 確保 Amazon ECS 任務有足夠的暫時性儲存、Amazon EBS 或 Amazon EFS。
+ **設定重試行為** – 平衡 `retry_limit`（耗盡重試後捨棄記錄） 和 `no_limits`（無限期重試，但可能會填滿儲存體）。
## 使用多目的地記錄來確保可靠性
將日誌傳送至多個目的地可消除單一失敗點。例如，如果 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 *`模式，因此所有記錄都會獨立傳送至兩個目的地。在某個目的地中斷期間，日誌會繼續流向另一個目的地，而失敗的排清會在檔案系統緩衝區中累積以供稍後重試。
## 將檔案型記錄與尾端輸入外掛程式搭配使用
對於日誌遺失至關重要的輸送量案例，您可以使用替代方法：讓應用程式將日誌寫入磁碟上的檔案，並設定 Fluent Bit 使用`tail`輸入外掛程式讀取它們。此方法完全略過 Docker 記錄驅動程式層。
使用 tail 外掛程式以檔案為基礎的記錄可提供下列優點：
+ **位移追蹤** – 尾端外掛程式可以將檔案位移存放在資料庫檔案中 （使用 `DB`選項），在Fluent Bit重新啟動時提供耐用性。這有助於防止在容器重新啟動期間日誌遺失。
+ **輸入層級緩衝** – 您可以使用 直接在輸入外掛程式上設定記憶體緩衝區限制`Mem_Buf_Limit`，以更精細地控制記憶體用量。
+ **避免 Docker 額外負荷** – 日誌會直接從檔案傳送至 ，Fluent Bit而不會傳遞 Docker 的日誌緩衝區。
若要使用此方法，您的應用程式必須將日誌寫入檔案，而不是 `stdout`。應用程式容器和Fluent Bit容器都會掛載存放日誌檔案的共用磁碟區。
下列範例顯示具有最佳實務的尾端輸入組態：
```
[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
```
使用尾端輸入外掛程式時，請考慮下列事項：
+ 為您的應用程式日誌實作日誌輪換，以防止磁碟耗盡。監控基礎磁碟區指標以衡量效能。
+ 根據您的日誌格式考慮設定`Ignore_Older`，例如 `Read_from_Head`、 和多行剖析器。
如需詳細資訊，請參閱 Fluent Bit 文件中的 [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail)。如需最佳實務，請參閱《》中的 [Tail config with best practices](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) AWS for Fluent Bit troubleshooting guide。
## 直接記錄到 FireLens
在任務定義中指定 `awsfirelens` 日誌驅動程式時，Amazon ECS 代理程式會將下列環境變數插入容器中：
`FLUENT_HOST`
指派給 FireLens 容器的 IP 位址。
如果搭配 `bridge` 網路模式使用 EC2，應用程式容器中的 `FLUENT_HOST` 環境變數可能會在重新啟動 FireLens 日誌路由器容器 (容器定義中具有 `firelensConfiguration` 物件的容器) 之後變得不準確。這是因為 `FLUENT_HOST` 是動態 IP 位址，重新啟動之後可能發生變更。從應用程式容器直接向 `FLUENT_HOST` IP 位址寫入日誌的操作，可能會在該位址變更後開始失敗。如需有關重新啟動個別容器的詳細資訊，請參閱[使用容器重新啟動政策在 Amazon ECS 任務中重新啟動個別容器](container-restart-policy.md)。
`FLUENT_PORT`
流利轉送通訊協定正在接聽的連接埠。
您可以使用這些環境變數，使用 Fluent Forward 通訊協定直接從應用程式程式碼登入Fluent Bit日誌路由器，而不是寫入 `stdout`。此方法略過 Docker 記錄驅動程式層，可提供下列優點：
+ **低延遲** – 日誌會直接傳送至 ，Fluent Bit而無需傳遞 Docker 的記錄基礎設施。
+ **結構化記錄** – 原生傳送結構化日誌資料，無需 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
}
]
}
```