k8s—Prometheus原理

一、Prometheus

1.Prometheus介绍

        Prometheus 是一个开源的系统监控和报警系统,现在已经加入到 CNCF 基金会,成为继k8s 之后第二个在 CNCF 托管的项目,在 kubernetes 容器管理系统中,通常会搭配prometheus 进行监控,同时也支持 多种 exporter 采集数据,还支持 pushgateway 进行数据上报, Prometheus 性能足够支撑上万台规模的集 群;
1.1  Prometheus特点
1)多维度数据模型
        每一个时间序列数据都由 metric 度量指标名称和它的标签 labels 键值对集合唯一确定:这个 metric 度量指标名称指定监控目标系统的测量特征(如:http_requests_total- 接收 http 请 求的总计数)。labels 开启了 Prometheus 的多维数据模型:对于相同的度量名称,通过不同标签列表的 结合, 会形成特定的度量维度实例。(例如:所有包含度量名称为/api/tracks 的 http 请求,打上 method=POST 的标签,则形成了具体的 http 请求)。这个查询语言在这些度量和标签列表的基础上进行过 滤和聚合。改变任何度量上的任何标签值,则会形成新的时间序列图
2)灵活的查询语言
3)可以直接在本地部署,不依赖其他分布式存储;
4)通过基于 HTTP 的 pull 方式采集时序数据;
5)可以通过中间网关 pushgateway 的方式把时间序列数据推送到 prometheus server 端;
6)可通过服务发现或者静态配置来发现目标服务对象(targets)。
7)高效的存储,每个采样数据占 3.5 bytes 左右,300 万的时间序列,30s 间隔,保留 60 天,消耗磁盘大概 200G。
8)做高可用,可以对数据做异地备份,联邦集群
1.2  样本

        在时间序列中的每一个点称为一个样本(sample),样本由三部分组成:

        指标(metric):指标名称和描述当前样本特征的 labelsets;

        时间戳(timestamp):一个精确到毫秒的时间戳
        样本值(value): 一个 folat64 的浮点型数据表示当前样本的值。

表达方式:<metric name>{<label name>=<label value>, ...}

       例如,指标名称为 api_http_requests_total,标签为 method="POST"handler="/messages"
的时间序列可以表示为:
        api_http_requests_total{method="POST", handler="/messages"}

2. Prometheus组件介绍

        1)Prometheus Server: 用于收集和存储时间序列数据。
        2)Client Library: 客户端库,检测应用程序代码,当 Prometheus 抓取实例的 HTTP 端点时,客户端库会将所有跟踪的 metrics 指标的当前状态发送到 prometheus server 端。
        3)Exporters: prometheus 支持多种 exporter,通过 exporter 可以采集 metrics 数据,然后发送到prometheus server 端,所有向 promtheus server 提供监控数据的程序都被称为exporter
        4)Alertmanager: 从 Prometheus server 端接收到 alerts 后,会进行去重,分组,并路由到相应的接收方,发出报警,常见的接收方式有:电子邮件,微信,钉钉, slack 等。
        5)Grafana:监控仪表盘,可视化监控数据
        6)pushgateway: 各个目标主机可上报数据到 pushgateway,然后 prometheus server 统一从pushgateway 拉取数据

        从上图可发现,Prometheus 整个生态圈组成主要包括 prometheus server,Exporter,
pushgateway,alertmanager,grafana,Web ui 界面;
Prometheus server 由三个部分组成, Retrieval,Storage,PromQL
1)Retrieval 负责在活跃的 target 主机上抓取监控指标数据
2)Storage 存储主要是把采集到的数据存储到磁盘中
3) PromQL 是 Prometheus 提供的查询语言模块

3.Prometheus工作流程

        1)Prometheus server 可定期从活跃的(up)目标主机上(target)拉取监控指标数据,目标主机的监控数据可通过配置静态 job 或者服务发现的方式被 prometheus server 采集到,这种方式默认的 pull  方式拉取指标;也可通过 pushgateway 把采集的数据上报到 prometheus server 中;还可通过一些组件 自带的 exporter 采集相应组件的数据;
        2)Prometheus server 把采集到的监控指标数据保存到本地磁盘或者数据库;
        3)Prometheus 采集的监控指标数据按时间序列存储,通过配置报警规则,把触发的报警发送到alertmanager
        4)Alertmanager 通过配置报警接收方,发送报警到邮件,微信或者钉钉等
        5)Prometheus 自带的 web ui 界面提供 PromQL 查询语言,可查询监控数据
        6)Grafana 可接入 prometheus 数据源,把监控数据以图形化形式展示出

4.Prometheus和zabbix对比分析

ZabbixPrometheus
后端用C开发,界面用PHP开发,定制化难度很高后端用golang开发,前端是GRafana、json编辑即可解决,定制化难度较低
集群规模上限为10000个节点支持更大的集群规模,速度也更快
更适合监控物理机环境更适合云环境的监控,对openstack、kubernetes有更好的集成
监控数据存储在关系型数据库内,如MySQL监控数据存储在基于时间序列的数据库内,便于对已有数据进行新的聚合
安装简单,zabbix-server一个软件包中有所有的服务端功能安装相对复杂,监控、告警和界面部分属于不同的组件
图形化界面比较成熟,界面上基本能完成全部的配置操作界面相对较弱,很多配置需要修改配置文件
发展时间更长,对于很多监控场景都有现成的解决方案发展时间较短,成熟度不及zabbix

5.Prometheus的部署模式

5.1基本高可用模式
        基本的 HA 模式只能确保 Promthues 服务的可用性问题,但是不解决 Prometheus Server 之间的数据 一致性问题以及持久化问题(数据丢失后无法恢复),也无法进行动态的扩展。因此这种部署方式适合监 控规模不大,Promthues Server 也不会频繁发生迁移的情况,并且只需要保存短周期监控数据的场景;

5.2基本高可用+远程存储
        在解决了 Promthues 服务可用性的基础上,同时确保了数据的持久化,当 Promthues Server 发生宕 机或者数据丢失的情况下,可以快速的恢复。 同时 Promthues Server 可能很好的进行迁移。因此,该 方案适用于用户监控规模不大,但是希望能够将监控数据持久化,同时能够确保 Promthues Server 的可 迁移性的场景;

5.3基本高可用+远程存储+联邦集群方案

        Promthues 的性能瓶颈主要在于大量的采集任务,因此用户需要利用 Prometheus 联邦集群的特性,将不同类型的采集任务划分到不同的 Promthues 子服务中,从而实现功能分区

6.Prometheus的四种数据类型

6.1Counter计数器类型

        counter用于累计值,数值一直增加,不会减少;重启进程后会被重置;

6.2gauge测量器类型

        gauge是常规数值,可变大变小;重启进程后会被重置;

6.3 histogram柱状图

        在一段时间范围内对数据进行采样(通常是请求持续时间或响应大小等),并将其计入可配置的存储桶(bucket)中. 后续可通过指定区间筛选样本,也可以统计样本总数,最后一般将数据展示为直方图;对每个采样点值累计和(sum);对采样点的次数累计和(count);

        如果定义一个度量类型为 Histogram,则 Prometheus 会自动生成三个对应的指标

6.4 summary
        对于每个采样点进行统计,并形成分位图。(如:正态分布一样,统计低于 60 分不及格的同 学比例,统计低于 80 分的同学比例,统计低于 95 分的同学比例); 统计班上所有同学的总成绩(sum); 统计班上同学的考试总人数(count)

7.Prometheus能监控什么

        Databases-数据库、Hardware related-硬件相关、Messaging systems-消息服务、Storage-存储、HTTP-网站服务 、APIs 、Logging-日志、Other monitoring systems 、Miscellaneous、Software exposing Prometheus metrics-度量指标;

8.Prometheus对kubernetes的监控

         • 基础设施层(Node):集群节点,为整个集群和应用提供运行时资源
        • 容器基础设施(Container):为应用提供运行时环境
        • 用户应用(Pod):Pod 中会包含一组容器,它们一起工作,并且对外提供一个或一组功能
        • 内部服务负载均衡(Service):在集群内,通过 Service 在集群暴露应用功能,集群内应用和应用之间访问时提供内部的负载均衡
        • 外部访问入口(Ingress):通过 Ingress 提供集群外的访问入口,从而可以使外部客户端能够访问到部署在 Kubernetes 集群内的服务
        因此,如果要构建一个完整的监控体系,我们应该考虑,以下 5 个方面:
• 集群节点状态监控:从集群中各节点的 kubelet 服务获取节点的基本运行状态;
• 集群节点资源用量监控:通过 Daemonset 的形式在集群中各个节点部署 Node Exporter采集节点的资源使用情况;
  • 节点中运行的容器监控:通过各个节点中 kubelet 内置的 cAdvisor 中获取个节点中所有容器的运行状态和资源使用情况;    
• 如果在集群中部署的应用程序本身内置了对 Prometheus 的监控支持,那么我们还应该找到相应的 Pod 实例,并从该 Pod 实例中获取其内部运行状态的监控指标。
• 对 k8s 本身的组件做监控:apiserver、scheduler、controller-manager、kubelet、kube-proxy        

  • 17
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值