在 Elastic,我们最近决定全面采用 OpenTelemetry 作为首选的数据收集框架。作为一名可观测性工程师,我坚信供应商无关性对于为我们的客户提供最大价值至关重要。通过致力于 OpenTelemetry,我们不仅与技术进步保持同步,而且还在推动它们向前发展。这项投资使我们处于行业的前沿,倡导一种更加开放和灵活的可观测性方法。
Elastic 向 OpenTelemetry 捐赠了 Elastic Common Schema (ECS),并积极致力于将其与语义约定 融合。同时,我们致力于支持我们的用户,确保他们不必处理不同的标准。我们的目标是为用户提供在使用 OpenTelemetry 和我们的应用程序和基础设施监控解决方案时无缝的端到端体验。这一承诺允许用户在没有任何摩擦的情况下从两者的优势中获益。
在本博客中,我们将探讨如何使用 OpenTelemetry (OTel) 收集器从各种来源(如 AWS EC2、Google Compute、Kubernetes 集群以及运行 Linux 或 MacOS 的各个系统)捕获核心系统指标。
使用两条摄取路径为基础设施 UI 提供支持
希望将 OpenTelemetry 作为其数据收集机制的 Elastic 用户现在可以使用 Elastic Observability 中提供的“主机”和“库存”UI 监控部署 OpenTelemetry 收集器的主机的运行状况。
Elastic 提供两条不同的摄取路径来为基础设施 UI 提供支持:ElasticsearchExporter 摄取路径和 OTLP Exporter 摄取路径。
ElasticsearchExporter 摄取路径
OpenTelemetry 中的 hostmetrics 接收器以 OTel 模式收集主机机器的 CPU、内存和磁盘使用情况等系统级指标。ElasticsearchExporter 摄取路径利用 Hostmetrics 接收器以 OTel 模式生成主机指标。我们开发了 ElasticInfraMetricsProcessor,它利用 opentelemetry-lib 将这些指标转换为 Elastic UI 可以理解的格式。
例如,
处理器随后将这些指标转发到 Elasticsearch Exporter,该导出器现在已得到增强,支持以 ECS 模式导出指标。导出器将指标发送到 Elasticsearch 端点,从而使用富有洞察力的数据点亮基础设施 UI。
要使用此路径,您可以从 Elastic Collector Distro 部署收集器,该发行版在此处可用。
此摄取路径的收集器配置示例
receivers:
hostmetrics:
collection_interval: 10s
scrapers:
cpu:
metrics:
system.cpu.utilization:
enabled: true
system.cpu.logical.count:
enabled: true
memory:
metrics:
system.memory.utilization:
enabled: true
process:
metrics:
process.open_file_descriptors:
enabled: true
process.memory.utilization:
enabled: true
process.disk.operations:
enabled: true
network:
processes:
load:
disk:
filesystem:
processors:
resourcedetection/system:
detectors: ["system", "ec2"]
elasticinframetrics:
exporters:
logging:
verbosity: detailed
elasticsearch/metrics:
endpoints: <elasticsearch_endpoint>
api_key: <api_key>
mapping:
mode: ecs
service:
pipelines:
metrics/host:
receivers: [hostmetrics]
processors: [resourcedetection/system, elasticinframetrics]
exporters: [logging, elasticsearch/ metrics]
对于那些更喜欢使用自定义 Elastic Collector Distro 的用户来说,Elastic 导出器路径是理想选择。此路径包括 ElasticInfraMetricsProcessor,它通过 Elasticsearch 导出器将数据发送到 Elasticsearch。
OTLP Exporter 摄取路径
在 OTLP Exporter 摄取路径中,hostmetrics 接收器以 OTel 模式收集主机机器的 CPU、内存和磁盘使用情况等系统级指标。这些指标被发送到 OTLP Exporter,后者将它们转发到 APM Server 端点。APM Server 使用相同的 opentelemetry-lib 将这些指标转换为与 Elastic UI 兼容的格式。随后,APM Server 将指标推送到 Elasticsearch,从而为基础设施 UI 提供支持。
APM 摄取路径的收集器配置示例
receivers:
hostmetrics:
collection_interval: 10s
scrapers:
cpu:
metrics:
system.cpu.utilization:
enabled: true
system.cpu.logical.count:
enabled: true
memory:
metrics:
system.memory.utilization:
enabled: true
process:
metrics:
process.open_file_descriptors:
enabled: true
process.memory.utilization:
enabled: true
process.disk.operations:
enabled: true
network:
processes:
load:
disk:
filesystem:
processors:
resourcedetection/system:
detectors: ["system"]
system:
hostname_sources: ["os"]
exporters:
otlphttp:
endpoint: <mis_endpoint>
tls:
insecure: false
headers:
Authorization: <api_key_>
logging:
verbosity: detailed
service:
pipelines:
metrics/host:
receivers: [hostmetrics]
processors: [resourcedetection/system]
exporters: [logging, otlphttp]
OTLP Exporter 摄取路径可以帮助已经在使用 Elastic APM 并希望看到也填充了基础设施 UI 的现有用户。这些用户可以使用默认的 OpenTelemetry 收集器。
基础设施 UI 的一瞥
基础设施 UI 展示了主机和 Kubernetes 级别的视图。以下是 UI 的一些预览
主机概览 UI
主机库存 UI
主机的进程相关详细信息
Kubernetes 库存 UI
Pod 级别指标
我们的下一步是创建由本机 OTel 数据提供支持的基础设施 UI,以及在此本机数据上运行的专用 OTel 仪表板。
结论
Elastic 与 OpenTelemetry 的集成简化了可观测性领域,在我们努力使 ECS 与 OpenTelemetry 的语义约定保持一致的同时,我们当前的重点是通过简化用户体验来支持用户。通过此额外的支持,我们的目标是为那些将 OpenTelemetry 与我们的应用程序和基础设施监控解决方案结合使用的用户提供无缝的端到端体验。我们很高兴看到我们的用户将如何利用这些功能来更深入地了解他们的系统。