PrometheusMetrics：微服务运维实战

Prometheus将所有数据存储为时间序列，它是属于同一个指标和相同标签的带有时间戳的数据流。标签为指标提供了多个维度。

例如，如果希望根据来自代理的HTTP请求导出数据，那么可能会创建一个名为proxy_http_requests_total的指标。这样的指标可以有请求方法、状态和路径的标签。这三个标签可以指定如下：

最后需要一个指标值，在我们的例子中，它将是请求的总数。

将指标名称、标签和值组合在一起，示例结果可能如下所示：

通过这三个指标，可以看到有654个成功的GET请求，143个成功的PUT请求和13个失败的GET请求HTTP 403。

既然这些指标的格式还算得上清晰，那么可以讨论一下生成指标并将它们提供给Prometheus的不同方式。

Prometheus基于拉取机制，从配置的目标中拉取指标。有两种方式可以生成对Prometheus友好的数据。一个是主动测量我们自己的服务，Prometheus为Go（https：//github．com/prometheus/client_golang）、Python（https：//github．com/ prometheus/client_python）、Ruby（https：//github．com/prometheus/client_ruby）和Java（https：//github．com/prometheus/client_java）提供了客户端。除此之外，还有相当多的用于其他语言的非官方库。测量是指公开服务的指标。在某种程度上，测量你的代码和记录日志类似。(www.xing528.com)

尽管测量是提供将要存储在Prometheus中的数据的首选方式，但建议不要这样做。也就是说，除非没有别的手段能够获得相同的数据。建议的原因在于我们希望保持微服务与系统的其他部分解耦。如果能够把服务发现隔离在服务范围之外，那么也许可以对指标进行相同的处理。

当服务无法被测量，或者根本不想测量的时候，可以利用Prometheus exporters，它们用于收集已经存在的指标并将其转换为Prometheus格式。你会看到，系统已经公开了相当多的指标。期望所有解决方案都以Prometheus格式提供指标是不现实的，因此将使用exporters进行转换。

当拉取数据不能满足要求时，我们可以改变方向并推送数据。尽管拉取是Prometheus获取指标的首选方式，但有些情况下这种方法并不合适。一个例子是短期批处理作业。他们可能短到Prometheus无法在其工作完成并销毁之前提取数据。这种情况下，批处理作业可以将数据推送到Prometheus可以从中获取指标的Push Gateway（http：//github．com/prometheus/pushgateway）。

有关当前支持的exporters列表，请参阅Prometheus文档的Exporters and Ingegrations（https：//prometheus.io/docs/instrumenting/exporters/）部分。

现在，在简要介绍指标之后，我们准备创建将托管exporters的服务。