……我们去年将一个项目从statsd迁移到otel，我真的希望我们当时把时间花在别的事情上。我真的很希望我那时能花时间在别的事情上。statsd让聚合器来处理统计数据，所以应用程序的生命周期（你提到的lambda）不是问题。它们可以发送后不管，而且数据率比我们用OTEL实现的要高得多。OTEL的主要功能是标签，但亚马逊会对你使用标签收费。以至于我们不得不减少标签，直到它们只提供了很小的可观测性提升，最终这并不值得迁移的成本。如果我直接迁移的话，我们最终得到的数据量会是现在的40倍。OTEL对使用全局解释器锁的语言是敌对的。在这些语言中，你运行的进程数量与机器的内核数量成比例，每个进程都需要单独标记。如果你不这样做，那么统计数据就会互相干扰。
源讨论OpenTelemetry 当前的状况原帖 93 条评论 · 导入时统计OpenTelemetry最大的问题是它被过于激进地推广，尽管它还不够成熟。AWS X-Ray团队经常在错误报告和功能请求中建议切换到OTel，但目前OTel收集器在Lambda上的性能和资源开销真的很糟糕。这对任何对性能敏感的工作负载来说都不合适。 除此之外，它给人一种“过度设计”的感觉。它可能并不是这样，但作为一个可以跨多种不同变体工作的统一标准，其复杂性本身就必然需要大量的抽象，但使用OpenTelemetry感觉比一个有明确观点的可观测性SaaS要困难得多。
完整原文把你的经验，加入这段讨论。
> OTEL的主要功能是标签，但亚马逊会对你使用它收费。收费如此之高，以至于我们不得不减少标签的数量，直到它们只提供了很小的可观测性提升，最终并不值得迁移的成本。如果我直接迁移的话，我们最终产生的流量会是现在的40倍。 这部分真的很不幸。希望这不会太无用，但还有其他一些供应商不会像这样限制你。当然还有其他权衡（没有完美的可观测性工具），但我认为大多数专门的可观测性后端已经摆脱了这种定价模式。
完整原文收集器或协议并不关心你有重复的条目（来自不同的进程）。是你的遥测/存储后端会丢弃数据，就像我们和Datadog也有同样的问题，真该死，他们居然默默地丢弃数据。
完整原文在所有可观测性产品中的计费方式都让人感到非常沮丧。CloudWatch 指标是一个如此危险的陷阱，以至于我们团队的任何工程师提交包含它们的 PR 时，我都感到害怕。很容易不小心将账单增加 100 到 1000 倍。 我觉得你总是被迫在荒谬的定价模式和 AbstractSingletonProxyFactoryBeanProvider 级别的“企业级”配置之间做出选择。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。