prometheus 时间戳_Prometheus 简单概念以及基本用法

Prometheus 是一个基于 Metric 的监控告警系统，生态好，许多项目都有原生接口。

首先官方文档：prometheus 官方文档 。

本文章只是简单概念和基本用法。详细信息以及基本安装等请移步官方文档。

主要监控方式

Logging

日志

常规监控方式，记录离散事件。

Tracing

调用链

记录调用链信息。

Metric

基于时间的离散数据值

比较

Metric 优势在于开发成本低，运维成本低，可靠性强。但是准确性不如 Logging.

特别是对于分布式系统，查找问题能力不如 Logging，Tracing快速。

Logging 优势在于开发简单。主要是运维成本大点，需要不断调优和扩容。

Tracing 优势在于查找问题最强。但是开发成本也是最大。

总结

根据系统实际情况，选用不同的监控告警方案。可以多种结合方式，对于一般监控选用 Metric 。

官方文档也有专门说明：

When does it not fit?
Prometheus values reliability. You can always view what statistics are available about your system, even under failure conditions. If you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice as the collected data will likely not be detailed and complete enough. In such a case you would be best off using some other system to collect and analyze the data for billing, and Prometheus for the rest of your monitoring.

对于准确性很高的采用 Logging 方式，例如 ELK。

对于实时性要求高的采用 Logging方式记录，程序内部直接发出告警。

对于复杂调用链，问题查找困难，可以采用 Tracing 。

Prometheus 架构图

Prometheus Server

核心组件，数据的获取，存储以及查询。

Exporters

可以理解为客户端，负责收集数据，并暴露给Prometheus Server，Server定期采集。

分为直接和间接方式。

直接方式：类似于白盒测试。自己开发应用程序，埋点 。有些项目原生支持，内置了埋点监控 例如 docker ,k8s,etcd。

间接方式：类似于黑盒测试。某些组件不支持，我们可以通过它对外暴露的接口采集数据。

AlertManager

告警处理中心，

Prometheus Server 通过 PromQL 设置的告警规则，触发告警。AlertManager 则对这些告警做分发和管理，例如把告警信息接入到邮件、企业微信等。

PromQL

PromQL 接口可以对接其它图形界面。例如 grafana 可以配置 Prometheus 作为数据源。

PushGateway

应用程序主动 push 数据到 PushGateway ，Prometheus Server 定期 pull 数据。

Metric

概念

指监控指标。Metric 监控意味着采用各种指标，维度来监控系统状态。

以下说明均专指 Prometheus 里实现的 Metric 。

在 Prometheus 里一个数据点由 Metric(metric + labelsets) + timestamp + value 组成。

数据点，具体是在 Prometheus pull 采集的数据后处理并存储后形成的。所以 timestamp 时间戳是针对于 pull 后的时间，并不是在客户端采集时候的的时间戳。

整个数据则是以这些点以时间戳为横轴的集合。例如 Prometheus 自监控的一个数据点：

# TYPE http_requests_total counter
|--------------------------- Metric ----------------------------|-timestamp -|-value-|
|--- metric name --|------------------ labelsets ---------------|
http_requests_total{code="200",handler="prometheus",method="get"}               721

labelsets 代表了这个 metric name 下的一个维度，可以有多个维度，后期方便做聚合操作。

类型

Counter

计数器 记录事件发生的总次数，无法重置。可以通过函数计算变化速率等。

例如 rpc 请求总数。http请求总数。

Gauge

仪表盘 反应实时数据，代表当前时间某个指标状态。可以通过函数计算，一段时间差异，波动等。

例如内存/cup占用，goroutine数量等。

Histogram

直方图 反应样本的随机正态分布数据。可以反应指标落在哪个区间的统计。

例如rpc请求延迟分布。

Summary

汇总 根据样本统计百分位。

分位数由客户端计算，相比于 Histogram 会占用一定资源。

总结

从 Go prometheus 客户端来讲。

Counter 以及 Gauge 都是对收集的样本 value 采用 atomic 方式操作。

Histogram 以及 Summary 则加入了统计操作相关算法，所以使用时候：

1.最好满足随机正态分布。例如请求延迟分布，一般都大部分集中在某个区间。

2.大概预估好桶即 bucket 的取值。

PromQL