Amazon OpenSearch Ingestion 的最佳實務 - Amazon OpenSearch Service
一般最佳實務建議 CloudWatch 警示

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

Amazon OpenSearch Ingestion 的最佳實務

本主題提供建立和管理 Amazon OpenSearch Ingestion 管道的最佳實務，並包含適用於許多使用案例的一般準則。每個工作負載都是獨一無二的，具有獨特的特性，因此沒有任何一個通用建議適合每個使用案例。

一般最佳實務

下列一般最佳實務適用於建立和管理管道。

  • 為了確保高可用性，請使用兩個或三個子網路設定 VPC 管道。如果您只將管道部署在一個子網路中，且可用區域故障，您將無法擷取資料。

  • 在每個管道中，我們建議將子管道的數量限制為 5 個或更少。

  • 如果您使用的是 S3 來源外掛程式，請使用平均大小的 S3 檔案來獲得最佳效能。

  • 如果您使用的是 S3 來源外掛程式，請在 S3 儲存貯體中每 0.25 GB 的檔案大小新增 S30 秒的額外可見性逾時，以獲得最佳效能。

  • 在管道組態中包含無效字母佇列 (DLQ)，以便您可以卸載失敗的事件並使其可供分析。如果您的接收器因為不正確的映射或其他問題而拒絕資料，您可以將資料路由到 DLQ，以便對問題進行故障診斷和修正。

建議 CloudWatch 警示

當 CloudWatch 指標在經過一些時間超過指定的值時，CloudWatch 警示會執行動作。例如，如果您 AWS 的叢集運作狀態超過一分鐘red，建議您傳送電子郵件給您。本節包含 Amazon OpenSearch Ingestion 的一些建議警示，以及如何回應這些警示。

如需有關設定警示的詳細資訊，請參閱 《Amazon CloudWatch 使用者指南》中的建立 Amazon CloudWatch 警示。

警示 問題

computeUnits 最大值為 = maxUnits已設定 15 分鐘、連續 3 次

 管道已達到最大容量，可能需要maxUnits更新。增加管道的最大容量

opensearch.documentErrors.count sum = 1 分鐘{sub_pipeline_name}.opensearch.recordsIn.count的總和，連續 1 次

 管道無法寫入 OpenSearch 接收器。檢查管道許可，並確認網域或集合運作狀態良好。如果已設定失敗事件，您也可以檢查無效字母佇列 (DLQ)。

bulkRequestLatency.max 最大值為 >= x 持續 1 分鐘，連續 1 次

 管道正在經歷將資料傳送至 OpenSearch 接收器的高延遲。這可能是由於接收器過小或碎片策略不佳，導致接收器落後。持續高延遲可能會影響管道效能，並可能導致用戶端背壓。

httpAuthFailure.count 總和 >= 1，持續 1 分鐘，連續 1 次

 未驗證擷取請求。確認所有用戶端都已正確啟用 Signature 第 4 版身分驗證。

system.cpu.usage.value 平均 >= 80%，持續 15 分鐘，連續 3 次

 持續高 CPU 用量可能有問題。考慮增加管道的最大容量。

bufferUsage.value 平均 >= 80%，持續 15 分鐘，連續 3 次

 持續的高緩衝區用量可能有問題。考慮增加管道的最大容量。

您可能會考慮的其他警示

請考慮根據您經常使用的 Amazon OpenSearch Ingestion 功能設定下列警示。

警示 問題

dynamodb.exportJobFailure.count 總和 1

 嘗試觸發匯出至 Amazon S3 失敗。

opensearch.EndtoEndLatency.avg 平均 > X 持續 15 分鐘，連續 4 次

 EndtoEndLatency 高於從 DynamoDB 串流讀取所需的 。這可能是由於 OpenSearch 叢集規模過小，或管道 OCU 容量上限對 DynamoDB 資料表上的 WCU 輸送量而言太低所致。 匯出後 EndtoEndLatency會較高，但 應該會隨著時間減少，因為它會趕上最新的 DynamoDB 串流。

dynamodb.changeEventsProcessed.count sum == 0 表示 X 分鐘

 不會從 DynamoDB 串流收集任何記錄。這可能是由於 資料表上沒有活動，或存取 DynamoDB 串流時發生問題所致。

opensearch.s3.dlqS3RecordsSuccess.count sum >= sum opensearch.documentSuccess.count 持續 1 分鐘，連續 1 次

 與 OpenSearch 接收器相比，傳送到 DLQ 的記錄數量較多。檢閱 OpenSearch 接收器外掛程式指標，以調查和判斷根本原因。

grok.grokProcessingTimeouts.count sum = recordsIn.count 總和 1 分鐘，連續 5 次

 當 Grok 處理器嘗試模式比對時，所有資料都會逾時。這可能會影響效能並減慢您的管道速度。考慮調整您的模式以減少逾時。

grok.grokProcessingErrors.count sum >= 1 持續 1 分鐘，連續 1 次

 Grok 處理器無法比對管道中資料的模式，導致錯誤。檢閱您的資料和 Grok 外掛程式組態，以確保模式符合預期。

grok.grokProcessingMismatch.count sum = recordsIn.count 總和 1 分鐘，連續 5 次

 Grok 處理器無法將模式與管道中的資料相符。檢閱您的資料和 Grok 外掛程式組態，以確保模式符合預期。

date.dateProcessingMatchFailure.count sum = recordsIn.count 總和 1 minut，連續 5 次

 日期處理器無法將任何模式與管道中的資料相符。檢閱您的資料和日期外掛程式組態，以確保預期模式。

s3.s3ObjectsFailed.count 總和 >= 1，持續 1 分鐘，連續 1 次

 發生此問題是因為 S3 物件不存在，或管道的權限不足。擷取 s3ObjectsNotFound.count和 s3ObjectsAccessDenied.count指標以判斷根本原因。確認 S3 物件存在和/或更新許可。

s3.sqsMessagesFailed.count 總和 >= 1，持續 1 分鐘，連續 1 次

 S3 外掛程式無法處理 Amazon SQS 訊息。如果您的 SQS 佇列已啟用 DLQ，請檢閱失敗的訊息。佇列可能會收到管道嘗試處理的無效資料。

http.badRequests.count 總和 >= 1，持續 1 分鐘，連續 1 次

 用戶端傳送錯誤的請求。確認所有用戶端傳送的是適當的承載。

http.requestsTooLarge.count 總和 >= 1，持續 1 分鐘，連續 1 次

 來自 HTTP 來源外掛程式的請求包含過多的資料，超過緩衝容量。調整用戶端的批次大小。

http.internalServerError.count 總和 >= 0，持續 1 分鐘，連續 1 次

 HTTP 來源外掛程式無法接收事件。

http.requestTimeouts.count 總和 >= 0，持續 1 分鐘，連續 1 次

 來源逾時可能是管道佈建不足的結果。考慮增加管道maxUnits來處理額外的工作負載。

otel_trace.badRequests.count 總和 >= 1，持續 1 分鐘，連續 1 次

 用戶端傳送錯誤的請求。確認所有用戶端傳送的是適當的承載。

otel_trace.requestsTooLarge.count 總和 >= 1，持續 1 分鐘，連續 1 次

 來自 Otel Trace 來源外掛程式的請求包含過多的資料，這超過緩衝區容量。調整用戶端的批次大小。

otel_trace.internalServerError.count 總和 >= 0，持續 1 分鐘，連續 1 次

 Otel Trace 來源外掛程式無法接收事件。

otel_trace.requestTimeouts.count 總和 >= 0，持續 1 分鐘，連續 1 次

 來源逾時可能是管道佈建不足的結果。考慮增加管道maxUnits來處理額外的工作負載。

otel_metrics.requestTimeouts.count sum >= 0 持續 1 分鐘，連續 1 次

 來源逾時可能是管道佈建不足的結果。考慮增加管道maxUnits來處理額外的工作負載。