作者：来自 Elastic Ishleen Kaur
了解并探索 Elastic 中的 OpenTelemetry 内容包如何为你的遥测数据提供即时仪表板、告警和 SLO。
如果你在过去几年一直关注可观测性领域，你会看到 OpenTelemetry 已经从 “有前景的标准” 变成了收集指标、日志和追踪数据的默认选择。Elastic 很早就参与了这一过程 —— 这也是我们构建 Elastic Distributions of OpenTelemetry（ EDOT ）的原因：一个经过加固、可用于生产环境的 OTel 组件套件，包括 EDOT Collector 和各语言 SDK，专为基础设施与应用监控进行优化，避免了传统部署中的复杂配置负担。
EDOT 现已正式可用（ GA ）。Collector、SDK 以及整个技术栈——均已生产就绪，企业级支持，没有任何附加条件。
但问题在于：将数据接入 Elastic 只是完成了一半工作。实际更困难的另一半，是接入之后的事情。仍然需要有人构建仪表板、编写告警规则，并确定哪些 SLO 值值得追踪——在这些变得有用之前。
OpenTelemetry 内容包正是为了解决这一鸿沟而设计的。
什么是 OpenTelemetry 内容包？
Elastic 传统的基于 Beats 的集成通常会将数据采集和可视化打包在一起 —— 当你启用某个功能时，就会立即获得精心设计的仪表板和告警。随着 Elastic 向 OpenTelemetry 优先的架构演进，这一理念被延续下来，但模型变得更加清晰。
OpenTelemetry 内容包专注于某一特定服务的可观测性资产。不再包含任何数据采集配置，因为在 OTel 体系中，这部分由 Collector 负责。每个包包含：
- 仪表板 —— 为所监控服务定制的预构建 Kibana 可视化
- 告警规则 —— 预先配置好的告警规则，在关键阈值触发时提醒团队，从而减少平均检测时间（ MTTD ）和平均修复时间（ MTTR ）
- SLO 模板 —— 可直接使用的服务级别目标定义，用于跟踪可靠性目标、错误预算和消耗速率
随着内容包模型的持续演进，未来的版本还将支持更多类型的资产。
如何工作？
核心理念很简单：一旦数据进入 Elastic，对应的仪表板、告警规则和 SLO 模板就会立即可用。内容包会根据传入的数据自动激活，而不依赖这些数据是如何被采集的。
这个系统最强大的特性之一是自动安装。当 Elastic 检测到某个特定服务的数据开始进入 Elasticsearch 时，相应的内容包会自动安装 —— 无需任何手动步骤，也无需在集成目录中查找。当你打开 Kibana 时，你的仪表板已经在那里等你，告警规则也已准备好启用，SLO 模板也已预先加载。
为了让数据真正流动起来，我们需要配置 Collector —— 一个 YAML 文件，用于定义遥测管道的构建模块：
- Receivers —— 定义要采集什么数据以及从哪里采集。每个服务都有自己的 receiver（例如 MySQL receiver 会直接从数据库抓取指标）。
- Exporters —— 定义采集到的数据发送到哪里。在这里，我们使用 Elasticsearch exporter，将遥测数据以 OpenTelemetry 原生格式直接发送到 Elasticsearch。
- Pipelines —— 将 receivers 和 exporters 连接起来，定义数据在 Collector 中的流动路径。
完成这些配置并启动 Collector 后，数据就会开始流入 Elasticsearch —— 然后由内容包接管后续工作。
数据来源
OpenTelemetry 数据可以通过以下方式进入 Elastic：
- EDOT Collector —— Elastic 分发版 OpenTelemetry Collector，可嵌入 Elastic Agent 或与其配合使用
- 上游 OTel Collector —— 标准的社区版 OpenTelemetry Collector（ Contrib 或自定义构建版本）
- EDOT Cloud Forwarder（ ECF ）—— 一种无服务器 OpenTelemetry Collector，可从 AWS、GCP 和 Azure 收集遥测数据（如 VPC Flow Logs、CloudTrail、CloudWatch 等），并直接转发到 Elastic Observability，无需管理基础设施
内容包不关心数据如何到达 —— 只关心数据是否已经存在。
实践示例：MySQL 监控
假设有一个团队在运行 MySQL，他们希望跟踪查询吞吐量、连接数、缓冲池利用率以及慢查询速率——并在小问题演变成凌晨 2 点事故之前收到告警。传统做法意味着需要花费大量时间构建仪表板、编写自定义告警查询，并且很大程度依赖经验去判断哪些指标真正重要。
使用 MySQL OpenTelemetry 资产包，这些工作已经提前完成。下面来看整体是如何组合在一起的。
步骤 1：获取数据
数据管道由一个 Collector 配置驱动，该配置定义了 receivers（从哪里抓取数据）、processors（如何增强或转换数据）以及 exporters（将数据发送到哪里 —— 在这里是 Elasticsearch）。
无论你使用 EDOT Collector 还是 Upstream OTel Collector，基础配置结构都是一致的。下面的配置为主实例和副本实例分别使用了不同的 receiver，因为复制指标仅在副本上可用。请将其中的占位符替换为你的实际端点、凭据以及 Elasticsearch 配置信息。
`
1. receivers:
2. mysql/primary:
3. endpoint: <MYSQL_PRIMARY_ENDPOINT>
4. username: <MYSQL_USER>
5. password: <MYSQL_PASSWORD>
6. collection_interval: 10s
7. statement_events:
8. digest_text_limit: 120
9. limit: 250
10. query_sample_collection:
11. max_rows_per_query: 100
12. events:
13. db.server.query_sample:
14. enabled: true
15. db.server.top_query:
16. enabled: true
17. metrics:
18. mysql.client.network.io:
19. enabled: true
20. mysql.connection.errors:
21. enabled: true
22. mysql.max_used_connections:
23. enabled: true
24. mysql.query.client.count:
25. enabled: true
26. mysql.query.count:
27. enabled: true
28. mysql.query.slow.count:
29. enabled: true
30. mysql.table.rows:
31. enabled: true
32. mysql.table.size:
33. enabled: true
35. processors:
36. resourcedetection:
37. detectors: [system, env]
39. exporters:
40. elasticsearch/otel:
41. endpoint: <ES_ENDPOINT>
42. api_key: <ES_API_KEY>
43. mapping:
44. mode: otel
46. service:
47. pipelines:
48. metrics:
49. receivers: [mysql/primary, mysql/replica]
50. processors: [resourcedetection]
51. exporters: [elasticsearch/otel]
`AI写代码收起代码块
MySQL receiver 会按照配置的时间间隔从数据库中抓取指标和事件，并将其作为 OpenTelemetry metrics 输出。这些数据会流经 pipeline 并进入 Elasticsearch，随后即可用于可视化。
步骤 2：打开 Kibana —— 一切已就绪
仪表板
一旦 MySQL 的指标和事件进入 Elasticsearch，MySQL OpenTelemetry 资产包就会在后台自动安装。当你进入 Kibana 时，仪表板已经被填充好并等待使用。
用户可以立即获得以下可观测性视图：
- 活跃连接数与最大连接数
- 查询吞吐量——每秒执行的语句数
- InnoDB 缓冲池命中率与内存使用情况
- 慢查询数量与趋势
- 表锁等待与资源争用情况
- 随时间变化的发送与接收字节数
- 复制延迟（用于主从架构）
无需手动字段映射，无需从零构建仪表板。只需数据进入，即可获得洞察。
下面是 Kibana 中 MySQL OpenTelemetry 仪表板的截图，展示了当数据开始流动时即可自动使用的开箱即用可视化内容。
概览仪表板
查询仪表板
可用性仪表板
告警规则，已准备启用
该内容包包含六条预构建告警规则 —— 涵盖高连接错误率、慢查询激增、线程饱和、复制延迟、缓冲池脏页比例（buffer pool dirty page ratio）以及行锁竞争 —— 每一条都带有推荐阈值和严重级别。这些规则在安装后即可使用，并且可以在 Kibana 中直接启用、调整和扩展，无需编写任何自定义查询。下面是其中一条告警的示例。
SLO 模板，已预加载
开箱即用包含四个 SLO 模板，用于跟踪复制延迟、连接耗尽错误、慢查询速率以及已连接线程数——每个模板都预先配置了目标值和 30 天滚动窗口。团队可以直接采用这些模板，也可以调整阈值以匹配自身的可靠性需求。
当前可用内容
MySQL OpenTelemetry 资产包只是 Elastic 已构建的不断增长的 OpenTelemetry 内容包库中的一个示例。内容包已覆盖多种服务——同时我们也开始将其扩展到云端，初步支持云服务提供商集成，通过 EDOT Cloud Forwarder（ ECF ）将 AWS、GCP 和 Azure 的遥测数据引入 Elastic，并提供现成的仪表板。
这一模式在所有内容包中都是一致的——数据进入后，一个完整的可观测性套件（仪表板、告警规则、SLO 模板）会立即可用——无论你是在监控自建数据库，还是来自你首选云服务提供商的云原生服务。
未来的发展方向
值得关注的下一步是 OTel 集成包，它将允许你直接从 Kibana UI 推送 Collector 配置——让整个设置体验变为点选式操作，从数据采集到可视化全流程完成，无需编辑 YAML。
开始使用
准备好尝试了吗？从 EDOT Collector 文档开始，并在 Kibana 的 Integrations 页面中探索不断扩展的 OpenTelemetry 内容包库。
