Prometheus

Prometheus是一个开源系统监控和警告工具包。不同于zabbix,前者使用多维数据模型，而后者使用较简单的键值模型。

键值数据模型：只能为每个维度组合创建一个新的，独立的指标名，这会导致指标数量爆炸并且难以查询管理。

例如在监控一个web服务器的请求数，对于http_abc是500，cpu_usage是80，memory_usage是400。这时候就能发现它的局限性，当数据量太大的时候不能一下子知道哪些接口请求量比较大，哪些HTTP的get/post的错误率高，哪些城市的请求延迟大等等问题。

而多维数据模型带着标签的监控，是由以一个指标名称和一组键值对标签共同唯一标识。

同样是监控一个web服务器的请求数，多维数据模型它的指标名称是例如http_abc，而键值对标就比如是method="GET", status="200", handler="/api/users", city="beijing"。简单来说就是多了筛选条件。

能够将此模型运用的就是Prometheus另一个特点，PromQL语言。刚才的时间序列选择器就是他的最核心最基础的组成部分，但他通常还有与其他函数和运算符相结合才能形成有意义的表达式。比如加一个筛选，统计比较等等操作。

除此之外他还有拉取模型，不依赖分布式存储和无缝与服务集成的特点。

而他的缺点就是精准度不是百分之百，原因是当监控目标突然发生故障将会导致数据丢失。比如每隔15spod向Prometheus传送一次数据，可是在第14s的时候pod崩溃，导致这期间的数据直接丢失。同时他并不适合保存一些历史数据，因为他的默认配置是保留15天，超过保留期间的数据会自动删除，而且如果其所在的磁盘等故障或Pod被pv收回数据也将会丢失。对此也有解决方法，就是Thanos 与 Cortex。最后就是对短生命周期任务不友好，没等Prometheus拉取就已经结束。

然后是他的工作流程：

首先是通过Prometheus server完成数据抓取，其目标可以是有指标端点的应用程序，也可以是导出器。接下来将抓取到的数据以时间序列存储的本地时间数据库。然后用之前说得PromQL语言来进行聚合处理，结果就能通过Prometheus web UI短暂查询或者Grafana可视化展示。在监控期间用户可以定义promQL来定义警报规则，一旦满足规则会发送警报给altermanager,然后其在对警报进行处理。

而他在集群中部署的方式有使用 Helm Chart 和使用operator。

前者比较简单流行，Prometheus提供了一个官方的helm chart。这个chart里面有很多yaml模板，这些yaml模板描述了Prometheus在部署上需要的组件。他可以通过value.yaml这个文件暴露配置参数。而部署只用你使用一条命令即可，Helm 会根据你的 values.yaml 渲染模板，并将生成的实际 YAML 文件提交给 Kubernetes API Server，完成部署。

而operator则更像是Prometheus的扩展。

Prometheus Operator 会向你的 Kubernetes 集群中引入几种新的、专为 Prometheus 设计的资源类型：Prometheus，servicemonitor，podmonitor和altermanger。而operator的职责是监听这些资源，自动生成并更新Prometheus的配置文件并更新。

二者明显的区别是前者在修改配置文件需要修改value.yaml，并且需要重启或者重建pod。而后者修改配置文件修改CRD,动态优雅的重载，不需要重启。

除此之外，还有服务发现机制。

Prometheus向k8s api查询service，pod这些资源。然后service Monitor来通过selector选择监控哪些资源，然后Prometheus自动发现service背后的pod并作为监控目标，并开始拉取目标。当 Pod 发生扩缩容或更新时，Prometheus 会自动更新目标列表，实现动态监控。

感谢观看，如有错误欢迎指出。