Lambda 层使用OpenTelemetry

“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《Lambda 层使用OpenTelemetry》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

有什么方法可以减少 lambda layer 丢弃事件吗？在痕迹到达中央收集器之前，它会不断地丢弃痕迹。在导出跟踪之前，它将获取令牌以将跟踪授权发送到中央收集器。但它不会推送正在删除的跟踪，因为 lambda 函数执行已经完成。

lambda 扩展层参考：https://github.com/open-telemetry/opentelemetry-lambda/tree/main/collector

出口商错误：

Exporting failed. No more retries left. Dropping data.
{
    "kind": "exporter",
    "data_type": "traces",
    "name": "otlp",
    "error": "max elapsed time expired rpc error: code = DeadlineExceeded desc = context deadline exceeded",
    "dropped_items": 8
}

正确答案

我遇到了同样的问题并做了一些研究。 不幸的是，这是一个已知问题，最新版本的 AWS Distro for OpenTelemetry Lambda (ADOT Lambda) 尚未解决

Github 问题票：

• Spans being dropped github.com/aws-observability/aws-otel-lambda 问题 #229
• ADOT collector sends response to Runtime API instead of waiting for sending traces github.com/open-telemetry/opentelemetry-lambda 问题 #224

简短的回答：目前，otel 收集器扩展无法可靠地工作，因为它在向导出器发送数据时被 lamda 环境冻结。作为解决方法，您可以将跟踪直接发送到在 lambda 容器外部运行的收集器。

问题是：

• lambda 在执行期间将跟踪发送到收集器扩展进程
• 收集器将它们排队以便将它们发送到配置的导出器
• 收集器扩展不会等待收集器完成处理其队列，然后才通知 lambda 环境扩展已完成；相反，它总是立即告诉环境它已经完成，而不查看收集器正在做什么
• 当 lambda 完成时，扩展也已完成，因此 lambda 容器将被冻结，直到下一次 lambda 调用。
• 当下一个 lambda 调用到达时，容器将被解冻。如果下一次调用很快到来并且需要足够长的时间，收集器可能能够完成向导出器发送跟踪。否则，在发送完成之前与后端系统的连接超时。

使解决方案变得复杂的是，扩展程序很难检测主 lambda 是否已完成处理。

理想情况下，遥测扩展应该：

1. 等待 lambda 完成处理
2. 检查 lambda 是否向其发送了任何要处理和转发的数据
3. 等待所有处理和转发完成（如果有）
4. 向 lambda 环境发出扩展已完成的信号

lambda 扩展协议不会告诉扩展主 lambda 何时完成处理（如果 AWS 可以将其作为新的事件类型添加到扩展协议中，那就太好了）。

有 a proposed PR 尝试通过假设 lambda 始终发送跟踪来解决此问题，因此它不是等待 lambda 完成，而是等待发往 OTLP 接收器的 TCP 请求到达。这是可行的，但如果 lambda 从未发送任何跟踪，它会使扩展永远挂起。

注意：我们在跟踪中看到的相同问题也存在于指标中。

今天关于《Lambda 层使用OpenTelemetry》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！