Prometheus 监控系统的初步了解与系统搭建

前言

        promethues 是一个开源的系统监控和报警系统，现在已经加入到CNCF基金会，成为继k8s之后第二个在CNCF托管的项目，在kubernetes容器管理系统中，通常会搭配prometheus进行监控，同时也支持多种exporter采集数据，还支持pushgateway进行数据上报，Prometheus性能足够支撑上万台规模的集群。 

一、Prometheus 的相关知识

1.1 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 地址：Prometheus · GitHub

1.2 Prometheus 的特点

● 多维数据模型：由度量名称和键值对标识的时间序列数据
   时间序列数据：按照时间顺序记录系统、设备状态变化的数据，每个数据称为一个样本；服务器     指标数据、应用程序性能监控数据、网络数据等都是时序数据

●  内置时间序列（Time Series）数据库：Prometheus ；外置的远端存储通常会用：                         InfluxDB、   OpenTSDB 等

● promQL 一种灵活的查询语言，可以利用多维数据完成复杂查询

● 基于 HTTP 的 pull（拉取）方式采集时间序列数据

● 同时支持 PushGateway 组件收集数据

● 通过静态配置或服务发现发现目标

● 支持作为数据源接入 Grafana

1.3 Prometheus 存储引擎TSDB 的特点优势

 TSDB 作为 Prometheus 的存储引擎完美契合了监控数据的应用场景

● 存储的数据量级十分庞大
● 大部分时间都是写入操作
● 写入操作几乎是顺序添加，大多数时候数据都以时间排序
● 很少更新数据，大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库
● 删除操作一般为区块删除，选定开始的历史时间并指定后续的区块。很少单独删除某个时间或        者 分开的随机时间的数据
● 基本数据大，一般超过内存大小。一般选取的只是其一小部分且没有规律，缓存几乎不起任何        作用
● 读操作是十分典型的升序或者降序的顺序读
● 高并发的读操作十分常见

1.4 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 功能的应用程序提供便捷的开发途径，用于基于应用程序内建的测量系统。

它主要用于在被监控的应用程序或服务中收集和暴露监控指标。

Client Libraries 主要是针对那些使用Prometheus生态内部或已经支持Prometheus监控格式的应用程序。它们通常被直接集成到应用程序代码中，允许开发者在应用内部生成和暴露监控指标，而无需额外的中间层。

（3）Exporters 

        指标暴露器，负责收集不支持内建 Instrumentation 的应用程序或服务的性能指标数据，并通过 HTTP 接口供 Prometheus Server 获取。

        Exporters 主要用于收集第三方系统、服务或应用程序的信息，这些系统可能并不直接支持Prometheus的监控指标格式。Exporters充当了一个桥梁的角色，它们可以从这些外部资源中提取数据，并将其转换为Prometheus能够识别的格式，通过HTTP端点暴露给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 在运行中。