故障排除和错误处理
编辑故障排除和错误处理
编辑部署错误的故障排除
编辑您可以查看部署操作的状态，并获取有关事件的附加信息，包括特定事件失败的原因，例如配置错误详细信息。
- 在serverlessrepo-elastic-serverless-forwarder的应用程序页面上，单击部署。
- 您可以在此处查看部署历史记录，并在应用程序部署时刷新页面以获取更新。部署大约需要 5 分钟——如果部署由于任何原因失败，创建事件将回滚，您将能够看到导致哪个事件失败的说明。
例如，如果您没有按照Amazon S3（通过 SQS 事件通知）中所述增加 SQS 队列的可见性超时，您将看到事件的CREATE_FAILED状态，并且状态原因会提供更多详细信息。
防止意外成本
编辑监控 Elastic 无服务器转发器 Lambda 函数的超时非常重要，以防止意外成本。您可以为此使用AWS Lambda 集成。如果超时持续出现，则应限制 Lambda 函数以停止其执行，然后再执行任何故障排除步骤。在大多数情况下，持续的超时会导致事件触发器的记录和消息返回其源并再次触发函数，这将导致进一步的超时并强制循环，从而导致意外的高成本。有关限制 Lambda 函数的更多信息，请参阅AWS 文档。
增加调试信息
编辑为了帮助进行调试，您可以通过添加环境变量来增加日志记录详细信息，如下所示：
- 从Lambda > 函数中选择无服务器转发器应用程序
- 单击配置并选择环境变量，然后选择编辑
- 单击添加环境变量，输入
LOG_LEVEL作为键，输入DEBUG作为值，然后单击保存
使用事件 ID 格式（1.6.0 版及更高版本）
编辑1.6.0 版引入了新的事件 ID 格式，该格式可在将大量事件导入 Elasticsearch 时防止重复 ID 错误。此新格式将时间戳与从转发器接收到的 AWS Lambda 事件中提取的相关 AWS 资源的特定数据相结合。
时间戳用作 ID 的前缀，因为根据排序顺序而不是完全随机的标识符，随着时间的推移逐渐增加的标识符通常会带来更好的 Elasticsearch 索引性能。有关更多信息，请参阅这篇关于基于事件的数据的 Elastic 博客。
如果使用 1.6.0 版之前的 Elastic 无服务器转发器版本已发布到 Elasticsearch 的旧事件再次被导入，它们将被视为新事件并作为重复项发布到 Elasticsearch。
错误处理
编辑在转发器执行期间可能会发生两种错误
- 在摄取阶段开始之前的错误
- 在摄取阶段期间的错误
摄取之前的错误
编辑对于在摄取开始之前（1）发生的错误，函数将返回失败。这些错误大多是由于配置错误、AWS 资源的权限不正确等造成的。最重要的是，当此阶段发生错误时，我们没有要摄取的事件的状态，因此不需要保留数据，函数可以安全地失败。对于 SQS 消息和 Kinesis 数据流记录，两者都将返回队列并使用相同的有效负载再次触发函数。
摄取期间的错误
编辑对于在摄取期间（2）发生的错误，情况有所不同。我们确实有N 个失败事件中有X 个总事件的状态；如果我们使整个函数失败，则所有X 个事件都将再次被处理。虽然N 个失败的事件可能会成功，但其余的X-N 个事件肯定会失败，因为数据流是仅追加的（函数将尝试使用相同的文档 ID 重新创建已摄取的文档）。
因此，转发器不会返回摄取期间错误的失败；相反，未能摄取的事件的有效负载将被发送到重放 SQS 队列，该队列在部署期间会自动设置。重放 SQS 队列默认情况下未设置为函数的事件源映射，这意味着您可以根据需要调查和使用（或不使用）消息。
您可以临时将重放 SQS 队列设置为转发器的事件源映射，这意味着队列中的消息将被函数使用，并为瞬态故障重试摄取。如果故障仍然存在，则受影响的日志条目将在三次重试后移动到 DLQ。
转发器执行期间发生的任何其他错误都将被静默忽略，如果启用了检测，则会报告给 APM 服务器。
执行超时
编辑在 Lambda 函数超时之前有一个 2 分钟的宽限期，在此期间不会发生更多摄取。相反，在此宽限期内，转发器将收集和处理用作触发器的输入批次中任何未处理的有效负载。
对于 CloudWatch Logs 事件、Kinesis 数据流、S3 SQS 事件通知和直接 SQS 消息有效负载输入，未处理的批次将发送到 SQS 继续队列。