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

# Amazon OpenSearch Ingestion 的最佳實務
<a name="osis-best-practices"></a>

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

**Topics**
+ [一般最佳實務](#osis-best-practices-general)
+ [建議 CloudWatch 警示](#osis-cloudwatch-alarms)

## 一般最佳實務
<a name="osis-best-practices-general"></a>

下列一般最佳實務適用於建立和管理管道。
+ 為了確保高可用性，請使用兩個或三個子網路設定 VPC 管道。如果您只將管道部署在一個子網路中，且可用區域故障，您將無法擷取資料。
+ 在每個管道中，我們建議將子管道的數量限制為 5 個或更少。
+ 如果您使用的是 S3 來源外掛程式，請使用平均大小的 S3 檔案來獲得最佳效能。
+ 如果您使用的是 S3 來源外掛程式，請在 S3 儲存貯體中每 0.25 GB 的檔案大小新增 S30 秒的額外可見性逾時，以獲得最佳效能。
+ 在管道組態中包含[無效字母佇列](https://opensearch.org/docs/latest/data-prepper/pipelines/dlq/) (DLQ)，以便您可以卸載失敗的事件，並使其可供分析。如果您的接收器因為不正確的映射或其他問題而拒絕資料，您可以將資料路由到 DLQ，以便對問題進行故障診斷和修正。
+ 如果您在管道中使用彙總處理器，我們建議您使用 `“local_mode: true”` 旗標，以取得管道的最佳效能。

## 建議 CloudWatch 警示
<a name="osis-cloudwatch-alarms"></a>

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

如需有關設定警示的詳細資訊，請參閱 《*Amazon CloudWatch 使用者指南*》中的[建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。


| 警示 | 問題 | 
| --- | --- | 
|  `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 次  | 持續的高緩衝區用量可能有問題。考慮增加管道的最大容量。 | 

### 您可能會考慮的其他警示
<a name="osis-cw-alarms-additional"></a>

請考慮根據您經常使用的 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` 總和 >= 0，持續 1 分鐘，連續 1 次  | 來源逾時可能是管道佈建不足的結果。考慮增加管道maxUnits來處理額外的工作負載。 |