目录
Prometheus 概述
Prometheus 是一个开源的服务监控系统和时序数据库,其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件 Prometheus server 会定期从静态配置的监控目标或者基于服务发现自动配置的目标中进行拉取数据,新拉取到的数据会持久化到存储设备当中。
每个被监控的主机都可以通过专用的 exporter 程序提供输出监控数据的接口,它会在目标处收集监控数据,并暴露出一个 HTTP 接口供 Prometheus server 查询,Prometheus 通过基于 HTTP 的 pull 的方式来周期性的采集数据。
如果存在告警规则,则抓取到数据之后会根据规则进行计算,满足告警条件则会生成告警,并发送到 Alertmanager 完成告警的汇总和分发。
当被监控的目标有主动推送数据的需求时,可以以 Pushgateway 组件进行接收并临时存储数据,然后等待 Prometheus server 完成数据的采集。
任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示,监控目标可以通过配置信息以静态形式指定,也可以让 Prometheus 通过服务发现的机制进行动态管理。
Prometheus 能够直接把 API Server 作为服务发现系统使用,进而动态发现和监控集群中的所有可被监控的对象。
Prometheus 官网地址:https://prometheus.io
Prometheus github 地址:https://github.com/prometheus
TSDB 作为 Prometheus 的存储引擎完美契合了监控数据的应用场景
●存储的数据量级十分庞大
●大部分时间都是写入操作
●写入操作几乎是顺序添加,大多数时候数据都以时间排序
●很少更新数据,大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库
●删除操作一般为区块删除,选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据
●基本数据大,一般超过内存大小。一般选取的只是其一小部分且没有规律,缓存几乎不起任何作用
●读操作是十分典型的升序或者降序的顺序读
●高并发的读操作十分常见
Prometheus 的特点:
●多维数据模型:由度量名称和键值对标识的时间序列数据
时间序列数据:按照时间顺序记录系统、设备状态变化的数据,每个数据称为一个样本;服务器指标数据、应用程序性能监控数据、网络数据等都是时序数据●内置时间序列(Time Series)数据库:Prometheus ;外置的远端存储通常会用:InfluxDB、OpenTSDB 等
●promQL 一种灵活的查询语言,可以利用多维数据完成复杂查询
●基于 HTTP 的 pull(拉取)方式采集时间序列数据
●同时支持 PushGateway 组件收集数据
●通过静态配置或服务发现发现目标
●支持作为数据源接入 Grafana
Prometheus 的生态组件
Prometheus 负责时序型指标数据的采集及存储,但数据的分析、聚合及直观展示以及告警等功能并非由 Prometheus Server 所负责。
Prometheus 生态圈中包含了多个组件,其中部分组件可选:
(1)Prometheus server:服务核心组件,采用 pull 方式采集监控数据,通过 http 协议传输;存储时间序列数据;基于“告警规则”生成告警通知。
Prometheus server 由三个部分组成:Retrieval,Storage,PromQL
●Retrieval:负责在活跃的 target 主机上抓取监控指标数据。
●Storage:存储,主要是把采集到的数据存储到磁盘中。默认为 15 天。
●PromQL:是 Prometheus 提供的查询语言模块。
(2)Client Library: 客户端库,目的在于为那些期望原生提供 Instrumentation 功能的应用程序提供便捷的开发途径,用于基于应用程序内建的测量系统。
(3)Exporters:指标暴露器,负责收集不支持内建 Instrumentation 的应用程序或服务的性能指标数据,并通过 HTTP 接口供 Prometheus Server 获取。
换句话说,Exporter 负责从目标应用程序上采集和聚合原始格式的数据,并转换或聚合为 Prometheus 格式的指标向外暴露。
常用的 Exporters
●Node-Exporter:用于收集服务器节点的物理指标状态数据,如平均负载、CPU、内存、磁盘、网络等资源信息的指标数据,需要部署到所有运算节点。
指标详细介绍:https://github.com/prometheus/node_exporter●mysqld-exporter/nginx-exporter
●Kube-State-Metrics:为 Prometheus 采集 K8S 资源数据的 exporter,通过监听 APIServer 收集 kubernetes 集群内资源对象的状态指标数据,例如 pod、deployment、service 等等。同时它也提供自己的数据,主要是资源采集个数和采集发生的异常次数统计。
需要注意的是 kube-state-metrics 只是简单的提供一个 metrics 数据,并不会存储这些指标数据,所以可以使用 Prometheus 来抓取这些数据然后存储, 主要关注的是业务相关的一些元数据,比如 Deployment、Pod、副本状态等;调度了多少个 replicas ?现在可用的有几个?多少个 Pod 是 running/stopped/terminated 状态?Pod 重启了多少次?有多少 job 在运行中。●cAdvisor:用来监控容器内部使用资源的信息,比如 CPU、内存、网络I/O、磁盘I/O 。
●blackbox-exporter:监控业务容器存活性。
(4)Service Discovery:服务发现,用于动态发现待监控的 Target,Prometheus 支持多种服务发现机制:文件、DNS、Consul、Kubernetes 等等。 服务发现可通过第三方提供的接口,Prometheus 查询到需要监控的 Target 列表,然后轮询这些 Target 获取监控数据。该组件目前由 Prometheus Server 内建支持
(5)Alertmanager:是一个独立的告警模块,从 Prometheus server 端接收到 “告警通知” 后,会进行去重、分组,并路由到相应的接收方,发出报警, 常见的接收方式有:电子邮件、钉钉、企业微信等。
Prometheus Server 仅负责生成告警指示,具体的告警行为由另一个独立的应用程序 AlertManager 负责;告警指示由 Prometheus Server 基于用户提供的告警规则周期性计算生成,Alertmanager 接收到 Prometheus Server 发来的告警指示后,基于用户定义的告警路由向告警接收人发送告警信息。
(6)Pushgateway:类似一个中转站,Prometheus 的 server 端只会使用 pull 方式拉取数据,但是某些节点因为某些原因只能使用 push 方式推送数据, 那么它就是用来接收 push 而来的数据并暴露给 Prometheus 的 server 拉取的中转站。
可以理解成目标主机可以上报短期任务的数据到 Pushgateway,然后 Prometheus server 统一从 Pushgateway 拉取数据。
(7)Grafana:是一个跨平台的开源的度量分析和可视化工具,可以将采集的数据可视化的展示,并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。
Prometheus 的工作模式
●Prometheus Server 基于服务发现(Service Discovery)机制或静态配置获取要监视的目标(Target),并通过每个目标上的指标 exporter 来采集(Scrape)指标数据;
●Prometheus Server 内置了一个基于文件的时间序列存储来持久存储指标数据,用户可使用 PromQL 接口来检索数据,也能够按需将告警需求发往 Alertmanager 完成告警内容发送;
●一些短期运行的作业的生命周期过短,难以有效地将必要的指标数据供给到 Server 端,它们一般会采用推送(Push)方式输出指标数据, Prometheus 借助于 Pushgateway 接收这些推送的数据,进而由 Server 端进行抓取
Prometheus 的工作流程
(1)Prometheus 以 Prometheus Server 为核心,用于收集和存储时间序列数据。Prometheus Server 从监控目标中通过 pull 方式拉取指标数据,或通过 pushgateway 把采集的数据拉取到 Prometheus server 中。
(2)Prometheus server 把采集到的监控指标数据通过 TSDB 存储到本地 HDD/SSD 中。
(3)Prometheus 采集的监控指标数据按时间序列存储,通过配置报警规则,把触发的告警通知发送到 Alertmanager。
(4)Alertmanager 通过配置报警接收方,发送报警到邮件、钉钉或者企业微信等。
(5)Prometheus 自带的 Web UI 界面提供 PromQL 查询语言,可查询监