在 Elastic 中使用 OpenTelemetry 内容包可视化 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 数据可以通过以下方式进入 ElasticEDOT 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 的指标和事件进入 ElasticsearchMySQL 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。