本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 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 的文件大小增加 30 秒的额外可见性超时时间，以获得最佳性能。
+ 在管道配置中加入[死信队列](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 警报以及如何响应这些警报。

有关配置警报的更多信息，请参阅[亚马逊* CloudWatch 用户指南中的创建亚马逊 CloudWatch*警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。


| 警报 | 问题 | 
| --- | --- | 
|  `computeUnits` 最大 = 配置的 `maxUnits` 达到 15 分钟，连续 3 次  | 管道已达到最大容量，可能需要 maxUnits 更新。增加管道的最大容量 | 
|  `opensearch.documentErrors.count` 总计 = `{sub_pipeline_name}.opensearch.recordsIn.count` 总计达到 1 分钟，连续 1 次  | 管道无法写入 OpenSearch 接收器。检查管道权限并确认域或集合运行状况良好。您还可以检查死信队列 (DLQ) 中是否存在失败的事件（如果已配置）。 | 
|  `bulkRequestLatency.max` 最大 >= *x* 达到 1 分钟，连续 1 次  | 该管道在向 OpenSearch 接收器发送数据时遇到了高延迟。这可能是由于接收器过小，或者分片策略不佳，从而导致接收器落后。持续的高延迟会影响管道性能，并可能给客户端带来反向压力。 | 
|  `httpAuthFailure.count` 总计 >= 1 达到 1 分钟，连续 1 次  | 未对提取请求进行身份验证。确认所有客户端均已正确启用签名版本 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 次  | 从 DynamoDB 流中读取时，EndtoEndLatency 高于预期值。这可能是由于 OpenSearch 集群规模不足，或者最大管道 OCU 容量太低，无法满足 DynamoDB 表上的 WCU 吞吐量。 EndtoEndLatency导出后会更高，但随着时间的推移，它会随着时间的推移而降低，因为它会赶上最新的 DynamoDB 流。 | 
|  `dynamodb.changeEventsProcessed.count` 总计 == 0 达到 X 分钟  | 没有从 DynamoDB 流收集任何记录。这可能是因为表中没有任何活动，或者访问 DynamoDB 流时出现问题。 | 
|  `opensearch.s3.dlqS3RecordsSuccess.count` 总计 >= `opensearch.documentSuccess.count` 总计达到 1 分钟，连续 1 次  | 发送到 DLQ 的记录数量多于 OpenSearch 接收器。查看 s OpenSearch ink 插件指标以调查并确定根本原因。 | 
|  `grok.grokProcessingTimeouts.count` 总计 = recordsIn.count sum 达到 1 分钟，连续 5 次  | 当 Grok 处理器尝试模式匹配时，所有数据都超时。这可能会影响性能并减慢您的管道速度。考虑调整模式以减少超时。 | 
|  `grok.grokProcessingErrors.count` 总计 >= 1 达到 1 分钟，连续 1 次  | Grok 处理器无法将模式与管道中的数据进行匹配，从而导致错误。查看您的数据和 Grok 插件配置，以确保模式匹配符合预期。 | 
|  `grok.grokProcessingMismatch.count` 总计 = recordsIn.count sum 达到 1 分钟，连续 5 次  | Grok 处理器无法将模式与管道中的数据进行匹配。查看您的数据和 Grok 插件配置，以确保模式匹配符合预期。 | 
|  `date.dateProcessingMatchFailure.count` 总计 = recordsIn.count sum 达到 1 分钟，连续 5 次  | 数据处理器无法将模式与管道中的数据进行匹配。查看您的数据和日期插件配置，以确保模式符合预期。 | 
|  `s3.s3ObjectsFailed.count` 总计 >= 1 达到 1 分钟，连续 1 次  | 此问题的原因在于 S3 对象不存在或管道权限不足。查看 s3ObjectsNotFound.count 和 s3ObjectsAccessDenied.count 指标以确定根本原因。确认 S3 对象存在 and/or 更新权限。 | 
|  `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 以处理额外的工作负载。 |