从零实现一个exporter(零)-exporter基本概念

Exporter简介

云原生模式下的主流监控已经变成Prometheus为主的一套监控技术栈，下图是Prometheus架构:

而Exporter类似于Agent，它负责收集指定指标，它可以独立出来单独运行，也可以和程序集合在一起。打个比方，之前的中间件，比如Redis，Kafka，ES这些都没有集成Exporter，而在云原生中，就需要通过operator去集成。而一些比较新的中间件，比如pulsar，ClickHouse等等则已经集成了，不需要去创建。

通过架构图可以看出来，Exporter收集到信息之后并不是主动pull到Prometheus上，而是创建一个内部http服务器，暴露/metrics端点，由Prometheus定期去轮询这些Exporter，之后存放在Prometheus中。

Metrics

具体写代码之前，我们需要明白什么是Metics，也就是指标。Metics是一个二元组:<value: timestamp>。表示这个指标在某个时间段的值是多少，举个例子，一个图片压缩服务，它的指标如下所示:

1. 处理速度（Processing Speed）：
   • 指标： 每秒处理的图片数量、平均处理时间等。
   • 原因： 了解服务的处理能力，确保它满足预期的性能需求。
2. 资源利用率（Resource Utilization）：
   • 指标： CPU 使用率、内存使用率、磁盘空间使用率等。
   • 原因： 监测服务的资源消耗，预防潜在的性能瓶颈和资源耗尽问题。
3. 请求成功率（Success Rate）：
   • 指标： 成功处理的请求比例、失败请求比例等。
   • 原因： 确保服务按预期处理请求，并及时检测和解决任何处理失败的问题。
4. 请求队列长度（Request Queue Length）：
   • 指标： 待处理请求的队列长度。
   • 原因： 监控请求队列长度，避免请求积压导致性能下降。
5. 错误率（Error Rate）：
   • 指标： 处理中发生错误的请求比例。
   • 原因： 跟踪服务的错误率，及时发现并解决潜在问题。
6. 网络延迟（Network Latency）：
   • 指标： 请求的网络往返时间（Round-Trip Time，RTT）。
   • 原因： 确保网络延迟在可接受范围内，避免用户体验差。
7. 系统负载（System Load）：
   • 指标： 系统的平均负载。
   • 原因： 监控系统的负载，预防过载导致的性能下降。
8. 缓存命中率（Cache Hit Rate）：
   • 指标： 图片压缩服务的缓存命中率。
   • 原因： 了解缓存的效果，提高性能和降低对底层存储系统的依赖。
9. 服务可用性（Service Availability）：
   • 指标： 服务的可用性百分比。
   • 原因： 确保服务随时可用，通过监控可用性识别潜在的故障。
10. 服务响应时间（Service Response Time）：
    • 指标： 请求到达服务并获得响应的时间。
    • 原因： 监测服务的响应时间，确保它在用户期望的范围内。

Metrics type

了解完Metrics之后，需要了解下关于Metrics Type，一共有四种核心类型:

• Counter : counter是一个累计指标，代表一个指标只会增不会减，它只有在重启和重置才会为零。可以使用它来表示已经处理过的请求数量，已经完成的任务数量，或者错误数量。
• Gauge : Gauge是一个代表单个数值的指标，可以任意上升或下降。比如当前内存使用量或者进程数量，以及并发请求数量。
• Histogram histogram对观测数量(通常是请求持续时间或响应大小等)进行采样，并将其计数在可配置桶中，它还提供了所有观测值的综合。
• Summary : 有点类似于Historygram，summary观测值一般是请求持续时间和响应大小之类的，并且提供观测值总和还有所有观测值总数。可以用来表示P99/P95等等。

Prometheus client

client暂时没什么好说的，之前提到的metrics相关操作支持比较好的客户端是:

• Go
• Java
• Python
• Ruby
• .Net

参考

• https://prometheus.io/docs/instrumenting/writing_exporters/#writing-exporters