使用OpenTelemetry进行基础设施指标收集
这是2022年OpenTelemetry在线日历的第13天的文章。
OpenTelemetry可用于基础设施监控，是这样说的。
提到OpenTelemetry时，人们会关注到分布式追踪，但它的用途不仅限于此，还可以轻松应用于应用程序所建立的基础设施和中间件。
对于那些正在考虑迁移到云端或容器化的主机，以前用Zabbix之类的工具进行监控，但现在开始听说了微服务等传闻，不知道是否应该继续这样下去，这可能会给基础架构工程师带来困扰。若这能为他们提供一些参考，将不胜荣幸。
立即安装Otel
Otel支持Docker、Kubernetes、Linux、Windows、MacOS等操作系统。
本次我们将使用功能扩展版的Otel Collector Contrib版。
对于Linux系统，每个软件包都有提供。
※在接下来的步骤中，我们将发送数据至Splunk Observability Cloud。您当然可以使用官方的Otel版本，但使用Splunk的Otel Distribution会更加便利。
我想先在Ubuntu上安装Otel。
※虽然这次我们将手动安装Otel，但当然也可以使用Ansible或Puppet等进行分发。
wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.67.0/otelcol-contrib_0.67.0_linux_amd64.deb
sudo apt install ./otelcol-contrib_0.67.0_linux_amd64.deb -y
就这样。
接下来是指标发送设置。
Contrib版将写在/etc/otelcol-contrib/config.yaml中。
第一次使用Otel的人可能会对设置方法感到困惑。
详细信息请参考其他文章，但是Otel由三个组件组成：Receiver（数据收集）、Processor（数据处理）和Exporter（数据传输）。
只需将这些定义写入config.yaml文件即可。
接收者
这里是接收者名单。
关于主机，可以使用Hostmetrics Receiver。可以收集与CPU、内存、硬盘、进程等相关的指标。可以进行过滤等操作，但暂时会进行全部数据的收集。
receivers:
hostmetrics:
collection_interval: 10s
scrapers:
cpu:
disk:
load:
filesystem:
memory:
network:
paging:
processes:
process:
处理器
这里是处理器一览。
接下来是处理器。
处理器即使没有也可以工作。但默认情况下它甚至不能获取主机名，所以我们会使用能良好获取资源信息的Resource Detection Processor。
processors:
resourcedetection:
detectors: [ec2]
由于我们在EC2上使用Ubuntu，所以我们指定了EC2。这样一来，它会自动收集以下信息，并将其作为维度添加到指标中。
* cloud.provider ("aws")
* cloud.platform ("aws_ec2")
* cloud.account.id
* cloud.region
* cloud.availability_zone
* host.id
* host.image.id
* host.name
* host.type
出口商
出口商名单在这里。
最后，我们将数据发送到一个地方。这次我们将使用SignalFx Metrics Exporter，将数据发送到Splunk Observability Cloud。
exporters:
signalfx:
access_token: "*****"
realm: "*****"
顺便提一句，Otel的特色是只要是适用于Otel的工具，无论是什么都可以。就像支持供应商列表中提到的，无论是Grafana还是Elastic都可以。只要调整一下Exporter的设置，就不需要修改Receiver和Processor。
管道
我們至此所做的只是各自定義而已。
要使用定義，需要搭建Pipeline。
service:
pipelines:
metrics:
receivers: [otlp, opencensus, prometheus, hostmetrics]
processors: [batch, resourcedetection]
exporters: [signalfx]
如上所述，我们指定了之前定义过的Receiver、Processor和Exporter的定义名称。
我们保留了默认设置。
现在，config.yaml已经完成。
启用设置
请重新启动Otel并激活它。
sudo systemctl restart otelcol-contrib
日志可以在下面查看。
sudo journalctl | grep otelcol-contrib
看一下
当使用Splunk Observability Cloud的基础设施监控功能进行确认时…
太棒了！
顺便提一下中间件
如果Nginx正在运行，我也想收集Nginx的指标数据。
现在是Nginx接收器的时间了。
将用于Nginx的Receiver定义加入Pipeline的receivers。
receivers:
nginx:
endpoint: "http://localhost:80/status"
collection_interval: 10s
service:
pipelines:
metrics:
receivers: [otlp, opencensus, prometheus, hostmetrics, nginx]
processors: [batch, resourcedetection]
exporters: [signalfx]
当Otel重新启动时，…
sudo systemctl restart otelcol-contrib
太棒了！！！
最后，这是整个config.yaml文件的概览。
※包含了本次没有特别提及的默认设置。
extensions:
health_check:
pprof:
endpoint: 0.0.0.0:1777
zpages:
endpoint: 0.0.0.0:55679
receivers:
otlp:
protocols:
grpc:
http:
opencensus:
# Collect own metrics
prometheus:
config:
scrape_configs:
- job_name: 'otel-collector'
scrape_interval: 10s
static_configs:
- targets: ['0.0.0.0:8888']
jaeger:
protocols:
grpc:
thrift_binary:
thrift_compact:
thrift_http:
zipkin:
hostmetrics:
collection_interval: 10s
scrapers:
cpu:
disk:
load:
filesystem:
memory:
network:
paging:
processes:
process:
nginx:
endpoint: "http://localhost:80/status"
collection_interval: 10s
processors:
batch:
resourcedetection:
detectors: [ec2]
exporters:
logging:
logLevel: debug
signalfx:
access_token: "*****"
realm: "*****"
service:
pipelines:
traces:
receivers: [otlp, opencensus, jaeger, zipkin]
processors: [batch]
exporters: [logging]
metrics:
receivers: [otlp, opencensus, prometheus, hostmetrics, nginx]
processors: [batch, resourcedetection]
exporters: [signalfx]
extensions: [health_check, pprof, zpages]
那又怎样？
Otel的真正优势在于能够统一满足所谓可观察性三要素之一的指标(Metrics)、追踪(Trace)、日志(Log)。与应用程序一样，通过Otel也可以获取基础设施部分的指标，并将其发送到相同的后端，这样就能在故障排除时迅速判断是应用程序问题还是基础设施问题（当然，前提是后端具备这种相关分析功能）。
提到日志，Advent Calendar的第一天可以参考OpenTelemetry Collector来更新日志文件。
祝你度过美好的酒店生活！
