Opentelemetry 收集器与 Instana 收集器

Question

我们有一堆微服务，目前使用 instana 收集器进行跟踪。 我知道这是一个广泛的问题，但即使我个人是 opentelemetry 的支持者，我也找不到 otel 收集器和收集器 rest 之间的任何比较。

如果我们进行比较，使用 otel 收集器的 prons/crons 是什么？ 例如，如果考虑 linkerd 服务网格，使用 otel 或 instana 收集器是否更好，或者无关紧要。

任何比较和论点将不胜感激。

Answer 1

TL;DR：归结为在收集器中提供所有组件（接收器、导出器等）与使用 select 且通常更少的收集器的安全且（基于 SLA）支持版本之间的权衡成分。 如果您查看 20 多个供应商，只有少数拥有自己的收集器（免责声明：我是其中一个的产品所有者，AWS）。

因此，您可以选择使用OpenTelemetry contrib发行版的“厨房水槽”（所有组件可用，但您负责安全性和性能）与供应商提供的发行版（或构建您自己的，这非常简单，这要归功于社区建立的很棒的工具）。

我的建议：使用上游otelcol-contrib收集器进行实验（我每天都这样做），并为产品制定明确的策略（供应商提供或滚动你自己的发行版/收集器），包括支持的所有含义。 例如，想想去年 log4j vuln 所造成的影响，你就会知道一个强大 150 倍的代理如何导致操作痛苦。

一些数据点：我今年进行了一项 OpenTelemetry 调查（结果现在可通过mhausenblas/otel-adoption-survey-2022 获得），显示 ca. 50:50 一方面分为上游和另一方面供应商/DIY。

Answer 2

我想到的一个明显区别是 OTel（在撰写本文时）无法将跟踪与底层基础设施相关联。

Instana 将告诉您此跟踪是在此进程中的此运行时提供的，该进程在此特定主机上的此 K8 集群中此 Pod 上的此容器中运行。 在跟踪和基础设施之间建立这种关联允许 Instana 在出现问题时提出根本原因。 因此，Instana 的跟踪功能已紧密集成到完整产品中，而 OTel（目前）还没有。

免责声明：我为 Instana 工作。