Prometheus简介
一 Prometheus介绍
Prometheus是一个开源系统监控和警报工具包,最初是在SoundCloud 上构建的 。自 2012 年成立以来,许多公司和组织都采用了 Prometheus,该项目拥有非常活跃的开发者和用户社区。它现在是一个独立的开源项目,独立于任何公司进行维护。为了强调这一点,并澄清项目的治理结构,Prometheus于 2016 年加入 云原生计算基金会,作为继Kubernetes之后的第二个托管项目。
Prometheus 将其指标收集并存储为时间序列数据,即指标信息与记录的时间戳一起存储,以及称为标签的可选键值对。
官方文档:https://prometheus.io/docs/introduction/overview/
二 时序数据库介绍
时序数据,是在一段时间内通过重复测量而获得的观测值的集合;将这些观测值绘制于图形之上,它会有一个数据轴和一个时间轴。
服务器指标数据、应用程序性能监控数据、网络数据等都是时序数据。
三 Prometheus架构
Prometheus server:主服务,接收外部http请求,收集、存储与查询数据等;
Prometheus targets:静态收集的目标服务数据;
serveice discovery:动态发现服务;
Prometheus alerting:报警通知;
push gateway:数据收集代理服务器;
data visualization and export:数据可视化与数据导出(访问客户端);
四 Prometheus工作流程
基于HTTP call,从配置文件中指定的网络端点(endpoint)上周期性获得指标数据。
Prometheus支持三种类型的途径从目标上抓取指标数据:
- Exporters
- Instrumentation
- Pushgateway
Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上拉取(pull)数据,而非等待被监控端的推送(push);
两个方式各有优劣,其中,Pull模型的优势在于:
- 集中控制:有利于将配置集中在Prometheus Server上完成,包括指标及采取速率等;
- Prometheus的根本目标在于收集在Target上预先完成聚合的聚合性数据,而非一款由事件驱动的存储系统;
五 Prometheus的特征
- 一个多维数据模型,具有由指标名称和键/值对标识的时间序列数据
- PromQL,一种 利用这种维度的灵活查询语言
- 不依赖分布式存储;单个服务器节点是自治的
- 时间序列收集通过 HTTP 上的拉模型发生
- 通过中间网关支持推送时间序列
- 通过服务发现或静态配置发现目标
- 多种图形和仪表板支持模式
六 Prometheus的生态组件
- Prometheus Server:收集和存储时间序列数据;
- Client Library:客户端库,目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径;
- Push Gateway:接收那些通常由短期作业生成的指标数据的网关,并支持由Prometheus Server进行指标拉取操作;
- Exporters:用于暴露现有应用程序或服务(不支持Instrumentation)的指标给Prometheus Server;
- Alertmanager:从Prometheus Server接收到告警通知后,通过去重、分组、路由等预处理功能后以高效向用户完成告警信息发送;
- Data Visualization:Prometheus Web UI。及Grafana等;
- Service Discovery:动态发现待监控的Target,从而完成监控配置的重要组件,在容器化环境中尤为有用;该组件目前由Prometheus Server内建支持;
七 Prometheus 关键组件
- Prometheus Server:Prometheus监控系统的核心组件;
- Exporters:指标暴露器
- node-exporter
- mysql-exporter
- AlertManager
- PushGateway
八 Prometheus数据模型
Prometheus仅用于以键值形式存储时序试的聚合数据,它并不支持存储文本信息;
- 其中的键称为指标(Metric),它通常意味着cpu速率、内存使用率或分区空闲比例等;
- 同一指标可能会适配到多个目标或设备,因而它使用标签作为元数据,从而为Metric添加更多的信息描述维度;
- 这个标签还可以作为过滤器进行指标过滤及集合运算;
九 Prometheus指标类型
- Counter:计数器,用于保存单调递增型的数据,例如站点访问次数等;不能为负值。也不支持减少。但可以重置为0;
- Gauge:仪表盘,用于存储有着起伏特征的指标数据。例如内存空闲大小等;
- gauge是出counter的超集,但存在指标数据丢失的可能性时,counter能让用户确切了解指标随时间的变化状态,而Gauge则可能随时间流逝而精确度越来越低;
- Histogram:直方图,它会在一段时间范围内对数据进行采样,并将其计入可配置的bucket之中;Histogram能够存储更多的信息,包括样本值分布在每个bucket中的数量、所有样本值之和以及总的样本数量,从而Prometheus能够使用内置的函数进行如下操作:
- 计算样本平均值:以值的总和除以值的数量;
- 计算样本分为值:分位数有助于了解符合特定标准的数据个数;例如评估响应时长超过1秒的请求比例,如超过20%即发送告警等;
- Summary:摘要。Histogram的扩展类型,但它是直接由被监控端自行聚合计算出分位数,并将计算结果响应给Prometheus Server的样本采集请求;因而,其分位数计算是由监控端完成;
十 Prometheus 工作模式
- Prometheus Server基于服务发现(Server Discovery)机制或静态配置获取要监控的目标(Target),并通过每个目标上的指标Exporters来采集(scrape)指标数据;
- Prometheus Server内置了一个基于文件的时间序列存储来维持存储指标数据,用户可使用PromDash或PromQL接口来检测数据,也能够按需将告警需求发往Alertmanager完成告警内容发送;
- 一些短期运行的作业的生命周期过短,难以有效地将必要的指标数据提供给到server端,它们一般会采用推送(Push)方式输出指标数据,Prometheus借助于Pushgateway接收这些推送的数据,进而由Server端进行抓取;
十一 Prometheus术语
11.1 Instance(实例)
Instance(实例):能够接收Prometheus Server数据scrape操作的每个网络端点(endpoint)即为一个Instance(实例);
11.2 Job(作业)
Job(作业)通常,具有类似功能的Instance的集合成为一个Job,例如一个mysql主从复制集群中的所有mysql进程;
11.3 PromQL
Prometheus提供了内置的数据查询语音PromQL(全称为Prometheus Query Language),支持用户进行实时的数据查询及聚合操作;
- PromQL支持处理两种向量,并内置提供了一组用户数据处理的函数
- 即时向量:最近一次的时间戳上跟踪的数据指标;
- 时间范围向量:指标时间范围内的所有时间戳上的数据指标;
11.4 Instrumentation(程序仪表)
任何能够支持scrape指标数据的应用程序都首先具有一个测量系统;
- 在Prometheus的语境中,Instrumentation是指附加到应用程序中的那些用于暴露程序指标数据的客户端库;
- 程序员借助于这些客户端库编写代码生成可暴露的指标数据;
11.5 Exporters
对于那些未内建Instrumentation,且也不方便自行添加改类型组件以暴露指标数据的应用程序来说,常用的办法是于待监控的目标应用程序外部运行一个独立指标暴露程序,改类型的程序即统称为Exporterl;
换句话说,Exporter负责从目标应用程序上采集和聚合原始格式的数据,并转换或聚合为Prometheus格式的指标向外暴露;
Prometheus站点上提供了大量的Exporter;
11.6 Alerts
抓到异常值后,Prometheus支持通过告警(alert)机制向用户发送反馈或警示,以触发用户能够及时采用应对措施;
Prometheus Server仅负责生成告警指示,具体的告警行为由另一个独立的应用程序AlertManager负责;
- Alertmanager接收到Prometheus Server发来的告警指示后,基于用户定义的告警路由(route)向告警接收人(receivers)发送告警信息;
十二 Prometheus的使用场景
Prometheus 适用于记录任何纯数字时间序列。它既适合以机器为中心的监控,也适合监控高度动态的面向服务的架构。在微服务的世界中,它对多维数据收集和查询的支持是一个特殊的优势。
Prometheus 是为可靠性而设计的,它是您在中断期间访问的系统,让您能够快速诊断问题。每个 Prometheus 服务器都是独立的,不依赖于网络存储或其他远程服务。当基础架构的其他部分损坏时,您可以依赖它,并且您无需设置大量基础架构即可使用它。
十三 Prometheus的局限性
Prometheus是一款指标监控系统,不适合存储事件及日志等;它更多的展示的是趋势性的监控,而非精准数据;
Prometheus认为只有最近的监控数据才有查询的需要,其本地存储的设计初衷只是保存短期数据,因而不支持针对大量的历史数据进行存储;
Prometheus的集群机制成熟度不高,即便基于Thanos亦是如此;