為高輸送量設定 Amazon ECS 日誌 - Amazon Elastic Container Service

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

為高輸送量設定 Amazon ECS 日誌

對於高日誌輸送量案例,我們建議搭配 FireLens 和 使用awsfirelens日誌驅動程式Fluent Bit。 Fluent Bit 是一種輕量型日誌處理器,可有效處理 資源,並可處理數百萬筆日誌記錄。不過,大規模實現最佳效能需要調校其組態。

本節涵蓋處理高日誌輸送量的進階Fluent Bit最佳化技術,同時維持系統穩定性並確保不會遺失資料。

如需如何搭配 FireLens 使用自訂組態檔案的詳細資訊,請參閱 使用自訂組態檔案。如需其他範例,請參閱 GitHub 上的 Amazon ECS FireLens 範例

注意

本節中的某些組態選項,例如 workersthreaded, AWS 需要 第 3 Fluent Bit版或更新版本。如需可用版本的資訊,請參閱 AWS 以取得 Fluent Bit 版本

使用檔案系統緩衝

根據預設, 會Fluent Bit緩衝記憶體中的所有資料。當資料擷取速度快於可以排清到輸出時,緩衝區會填滿。完成後,輸入外掛程式會暫停,直到緩衝空間變成可用為止,這可能會導致背壓並減慢您的應用程式速度。

對於高輸送量案例,建議使用檔案系統緩衝。如需有關 如何Fluent Bit管理緩衝和儲存的詳細資訊,請參閱 Fluent Bit 文件中的緩衝和儲存

檔案系統緩衝提供下列優點:

  • 較大的緩衝容量 – 磁碟空間通常比記憶體更豐富。

  • 持久性 – 緩衝的資料在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+ 的記憶體,因為每個區塊最多可使用 4–5 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。確保 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

使用多目的地記錄來確保可靠性

將日誌傳送至多個目的地可消除單一失敗點。例如,如果 CloudWatch Logs 遇到中斷,則日誌仍會到達 Amazon S3。

多目的地記錄提供下列優點。Amazon S3 輸出外掛程式也支援壓縮選項,例如 gzip 和 Parquet 格式,這可以降低儲存成本。如需詳細資訊,請參閱 Fluent Bit 文件中的 S3 壓縮

多目的地記錄可提供下列優點:

  • 備援 – 如果一個目的地失敗,日誌仍會到達另一個目的地。

  • 復原 – 從另一個系統重建一個系統中的差距。

  • 耐用性 – 在 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 記錄驅動程式層。

使用尾端外掛程式以檔案為基礎的記錄可提供下列優點:

  • 位移追蹤 – 尾端外掛程式可以將檔案位移存放在資料庫檔案中 (使用 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。如需最佳實務,請參閱《》中的 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 任務中重新啟動個別容器

FLUENT_PORT

流利轉送通訊協定正在接聽的連接埠。

您可以使用這些環境變數,使用 Fluent Forward 通訊協定直接從應用程式程式碼登入Fluent Bit日誌路由器,而不是寫入 stdout。此方法略過 Docker 記錄驅動程式層,可提供下列優點:

  • 低延遲 – 日誌會直接傳送至 ,Fluent Bit而不會傳遞 Docker 的記錄基礎設施。

  • 結構化記錄 – 以原生方式傳送結構化日誌資料,無需 JSON 編碼額外負荷。

  • 更好的控制 – 您的應用程式可以實作自己的緩衝和錯誤處理邏輯。

下列 Fluent 記錄程式庫支援 Fluent Forward 通訊協定,可用於將日誌直接傳送到 Fluent Bit:

設定 Docker 緩衝區限制

當您建立任務定義時,您可以透過在 中指定 值,來指定在記憶體中緩衝的日誌行數log-driver-buffer-limit。這會控制 Docker 和 之間的緩衝區Fluent Bit。如需詳細資訊,請參閱 Docker 文件中的 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 } ] }