目录
1、prometheus如何收集k8s/服务的–三种方式收集
一.故事背景
今天讲解k8s中的Prometheus与发布部分
二. Prometheus
1.概述
1、什么是Prometheus
Prometheus（普罗米修斯） 是一个开源的监控系统，以多维数据模型（指标名称和键值对的标识）和基于 HTTP 的 Pull 模型，支持多种维度的数据采集和动态查询。
它的核心组件Prometheus server会定期从静态配置的监控目标或者基于服务发现自动配置的自标中进行拉取数据，当新拉取到的数据大于配置的内存缓存区时，数据就会持久化到存储设备当中。
每个被监控的主机都可以通过专用的exporter 程序提供输出监控数据的接口，它会在目标处收集监控数据，并暴露出一个HTTP接口供Prometheus server查询，Prometheus通过基于HTTP的pull的方式来周期性的采集数据。
任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示，监控目标可以通过配置信息以静态形式指定，也可以让Prometheus通过服务发现的机制进行动态管理。
Prometheus 能够直接把API Server作为服务发现系统使用，进而动态发现和监控集群中的所有可被监控的对象。
2、Zabbix和Prometheus区别
和Zabbix类似，Prometheus也是一个近年比较火的开源监控框架，和Zabbix不同之处在于Prometheus相对更灵活点，模块间比较解耦，比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用，不需要进行安装。zabbix则是一套安装把所有东西都弄好，很庞大也很繁杂。
zabbix的客户端 agent 可以比较方便的通过脚本来读取机器内数据库、日志等文件来做上报。而 Prometheus 的上报客户端则分为不同语言的SDK和不同用途的 exporter 两种，比如如果你要监控机器状态、mysql性能等，有大量已经成熟的 exporter 来直接开箱使用，通过http 通信来对服务端提供信息上报（server去pull信息）；而如果你想要监控自己的业务状态，那么针对各种语言都有官方或其他人写好的 sdk供你使用，都比较方便，不需要先把数据存入数据库或日志再供zabbix-agent采集。
zabbix的客户端更多是只做上报的事情，push模式。而Prometheus则是客户端本地也会存储监控数据，服务端定时来拉取想要的数据。
界面来说zabbix比较陈旧，而prometheus比较新且非常简洁，简洁到只能算一个测试和配置平台。要想获得良好的监控体验，搭配Grafana还是二者的必走之路。
3、Prometheus的特点
多维数据模型：由度量名称和键值对标识的时间序列数据 时序数据，是在一段时间内通过重复测量（measurement）而获得的观测值的集合；将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴；服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据；
内置时间序列（pime series）数据库：Prometheus；外置的远端存储通常会用：InfluxDB、openTsDB等
PromQL一种灵活的查询语言，可以利用多维数据完成复杂查询
基于HTTP的pull（拉取）方式采集时间序列数据
同时支持Push Gateway组件收集数据
通过服务发现或者静态配置，来发现目标服务对象
支持作为数据源接入Grafana
2.运维监控平台设计思路
数据收集模块
数据提取模块(prometheus-TSDB,查询语言是promQL)
监控告警模块（布尔值表达式判断是否需要告警，不成立是健康状态）
可以细化为6层
第六层:用户展示管理层 统一用户管理、集中监控、集中维护
第五层:告警事件生成层 实时记录告警事件、形成分析图表（趋势分析、可视化)
第四层:告警规则配置层 告警规则设置、告警阈值设置（定义布尔值表达式，筛选异常状态）
第三层:数据提取层 定时采集数据到监控模块
第二层:数据展示层 数据生成曲线图展示（对时序数据的动态展示)
第一层:数据收集层 多渠道监控数据（网络，硬件，应用，数据，物理环境）
3. Prometheus监控体系
1、系统层监控（需要监控的数据）
CPU、Load、Memory、swap、disk、I/O、process等
网络监控：网络设备、工作负载、网络延迟、丢包率等
2、中间件及基础设施类监控
消息中间件：kafka、RocketMQ、等消息代理（redis 中间件）
WEB服务容器：tomcat、weblogic、jboss、apache、php、spring系列
数据库/缓存数据库：Mysql、Postgresql、MongoDB、es、redis
redis监控内容
redis的服务状态
redis所在服务器的系统层监控
RDB和AOF日志监控
日志--->如果是哨兵模式--->哨兵共享集群信息，产生的日志--->直接包含的其他节点哨兵信息及mysql信息
3、应用层监控
用于衡量应用程序代码状态和性能
监控的分类：
白盒监控：自省指标，等待被下载（cadvisor）
黑盒监控：基于探针（snmp）的监控方式，不会主动干预、影响数据
4、业务层监控
用于衡量应用程序的价值，如电商业务的销售量，ops、dau日活、转化率等，
业务接口：登入数量，注册数、订单量、搜索量和支付量
4. prometheus时间序列数据
时序数据，是在一段时间内通过重复测量(measurement）而获得的观测值的集合将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴，服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据
1、数据来源
prometheus基于HTTP call (http/https请求），从配置文件中指定的网络端点(endpoint/IP:端口）上周期性获取指标数据。 很多环境、被监控对象，本身是没有直接响应/处理http请求的功能，prometheus-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为prometheus可识别，可使用的数据（兼容格式）
2、收集数据
监控概念:白盒监控、黑盒监控 白盒监控:自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可 黑盒监控:对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（snmp协议）
Prometheus支持通过三种类型的途径从目标上"抓取（Scrape)"指标数据（基于白盒监控);
Exporters ——>工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送
Instrumentation ——>指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取
Push gateway ——>短周期5s—10s的数据收集
3、prometheus(获取方式)
Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上拉取(pull)数据，而非等待被监控端的推送(push)
两个获取方式各有优劣，其中，Pull模型的优势在于:
集中控制:有利于将配置集在Prometheus server上完成，包括指标及采取速率等;
Prometheus的根本目标在于收集在target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统
通过targets（标识的是具体的被监控端）
比如配置文件中的 targets:['localhost:9090']
5. prometheus生态组件
1、Prometheus Server
收集和储存时间序列数据
Prometheus server：服务核心组件，采用pull方式收集监控数据，通过http协议传输。并存储时间序列数据。Prometheus server 由三个部分组成：Retrival，Storage，PromQL
Retrieval：负责在活跃的target 主机上抓取监控指标数据。
Storage：存储，主要是把采集到的数据存储到磁盘中。默认为15天（可修改）。
PromQL：是Prometheus提供的查询语言模块。
2、Client Library
client Library：客户端库，目的在于为那些期望原生提供 Instrumentation 功能的应用程序提供便捷的开发途径，用于基于应用程序内建的测量系统。
3、Push Gateway
Pushgateway：类似一个中转站，Prometheus的server端只会使用pull方式拉取数据，但是某些节点因为某些原因只能使用push方式推送数据，那么它就是用来接收push而来的数据并暴露给Prometheus的server拉取的中转站。可以理解成目标主机可以上报短期任务的数据到Pushgateway，然后Prometheus server 统一从Pushgateway拉取数据。
4、Exporters
用于暴露现有应用程序或服务（不支持Instrumentation)的指标给Prometheus Server，而pro内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus 采集过后，会存储在自己内建的TSDB数据库中，提供了promQL 支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析一场指标，一旦发生，通知给alerter来发送告警信息，还支持对接外置的UI工具（grafana）来展示数据；采集、抓取数据是其自身的功能，但一般被抓去的数据一般来自于: export/instrumentation （指标数据暴露器） 来完成的，或者是应用程序自身内建的测量系统（汽车仪表盘之类的，测量、展示）来完成
5、Alertmanager
Alertmanager：是一个独立的告警模块，从Prometheus server端接收到“告警通知”后，会进行去重、分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件、钉钉、企业微信等。
1.Prometheus Server 仅负责生成告警指示，具体的告警行为由另一个独立的应用程序AlertManager负责； 2.告警指示由 Prometheus Server基于用户提供的告警规则周期性计算生成，Alertmanager 接收到Prometheus Server发来的告警指示后，基于用户定义的告警路由向告警接收人发送告警信息。
6、Service Discovery
Service Discovery：服务发现，用于动态发现待监控的Target，Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes等等。
服务发现可通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持。
7、grafana
Grafana：是一个跨平台的开源的度量分析和可视化工具，可以将采集的数据可视化的展示，并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。
Prometheus 数据流向
Prometheus server 定期从配置好的 jobs 或者 exporters 中拉取 metrics（指标），或者接收来自Pushgateway 发送过来的metrics，或者从其它的Prometheus server中拉取 metrics。
Prometheus server在本地存储收集到的 metrics，并运行定义好的 alerts.rules，记录新的时间序列或者向Alert manager推送警报。
Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。
在图形界面中，可视化采集数据。
6. prometheus工作原理
1、prometheus工作模式
Prometheus Server 基于服务发现（Service Discovery）机制或静态配置获取要监视的目标（Target），并通过每个目标上的指标 exporter来采集（Scrape）指标数据；
Prometheus Server 内置了一个基于文件的时间序列存储来持久存储指标数据，用户可使用PromQL接口来检索数据，也能够按需将告警需求发往Altermanager完成告警内容发送；
一些短期运行的作业的生命周期过短，难以有效地将必要的指标数据供给到Server端，它们一般会采用推送（Push）方式输出指标数据，Prometheus借助于Pushgateway 接收这些推送的数据，进而由server端进行抓取。
2、prometheus工作流程
Prometheus以prometheus Server 为核心，用于收集和存储时间序列数据。Prometheus Server从监控目标中通过pull方式拉取指标数据，或通过pushgateway 把采集的数据拉取到Prometheus server中。
Prometheus server 把采集到的监控指标数据通过 TSDB存储到本地HDD/ssD中。
Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager。
Alertmanager 通过配置报警接收方，发送报警到邮件、钉钉或者企业微信等。
Prometheus 自带的Web UI 界面提供 PromQL 查询语言，可查询监控数据。
Grafana 可接入Prometheus 数据源，把监控数据以图形化形式展示出。
告警数据采集、告警信息提取、告警通知
首先，需要采集监控数据，pro会周期性的pull或被push指标数据，数据采集的方式主要包括exporters、instrumentation、pushgateway 3种方式，前两者为pull方式获取，pushgateway借助于push方式推送给prometheus。
根据prometheus配置文件中（K8S-configmap的配置中），获取被监控端的数据之后，保存在TSDB中，我们可以借助Grafana或者告警平台来展示数据，grafana的展示是通过PromQL来获取数据。
prometheus通过rule配置来借助于PromQL来定义布尔值表达式，产生告警信息
一旦出现告警，prometheus产生告警信息，发送给altermanager,altermanager根据自定义的告警路由，来进行告警通知，对接第三方平台，例如告警平台、邮件、钉钉。
3、prometheus的局限性
Prometheus是一款指标监控系统，不适合存储事件及日志等；它更多地展示的是趋势性的监控，而非精准数据；
Prometheus认为只有最近的监控数据才有查询的需要，其本地存储的设计初衷只是保存短期（例如一个月）数据，因而不支持针对大量的历史数据进行存储；若需要存储长期的历史数据，建议基于远端存储机制将数据保存于InfluxDB或openTsDB等系统中；
Prometheus的集群机制成熟度不高，可基于Thanos（和灭霸是一个单词）实现Prometheus集群的高可用及联邦集群
7. 总结
1、prometheus如何收集k8s/服务的–三种方式收集
Exporters（指标暴露器）：收集节点的信息、将数据格式化或转化为 promtheus 可识别的http这种转化方式/镜像拉取方式
Instrumentation （应用内置的指标暴露器）： 收集有内置指标暴露器的信息
Pushgateway ： 收集短周期的数据
2 、如何防止告警信息轰炸
alertmanager: prometheus可以生成告警信息，但是不能直接提供告警，需要使用一个外置的组件alertmanager来进行告警，emailetctif优势在于，收敛、支持静默、去重、可以防止告警信息的轰炸。 把这条告警规则中的支持静默开启，让它必须，配置文件里直接改alertmanager改一个单词
3、prometheus监控内容
| 级别 | 监控什么 | exporter |
|---|---|---|
| 网络 | 网络协议：http、dns、tcp、icmp; 网路硬件：路由器、交换机等 |
BlockBox Exporter;SNMP Exporter |
| 主机 | 资源用量 | node exporter |
| 容器 | 资源用量 | cadvisor |
| 应用（包括Library） | 延迟、错误，QPS,内部状态 | 代码集中集成Prometheus Client |
| 中间件状态 | 资源用量，以及服务状态 | 代码集中集成Prometheus Client |
| 编排工具 | 集群资源用量，调度等 | Kubernetes Components |
4、常见的时间序列数据库
| TSDB项目 | 官网 |
|---|---|
| influxDB | InfluxDB: Open Source Time Series Database | InfluxData |
| RRDtool | RRDtool - About RRDtool |
| Graphite | Graphite |
| OpenTSDB | OpenTSDB - A Distributed, Scalable Monitoring System |
| Kdb+ | KX: The Leading Provider of Time-Series Database Technology |
| Druid | Druid | Database for modern analytics applications |
| KairosDB | KairosDB |
| Prometheus | Prometheus - Monitoring system & time series database |
8. 安装与部署
版本对照表
| kube-prometheus stack | 1.23 | 1.24 | 1.25 | 1.26 | 1.27 | 1.28 | 1.29 | 1.30 | 1.31 |
|---|---|---|---|---|---|---|---|---|---|
| release-0.11 | √ | √ | × | × | × | × | × | × | × |
| release-0.12 | × | √ | √ | × | × | × | × | × | × |
| release-0.13 | × | × | × | √ | √ | √ | × | × | × |
| release-0.14 | × | × | × | √ | √ | √ | √ | √ | √ |
| main | × | × | × | × | √ | √ | √ | √ | √ |
部署安装
导入镜像
vim prometheus-service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: prometheus
app.kubernetes.io/instance: k8s
app.kubernetes.io/name: prometheus
app.kubernetes.io/part-of: kube-prometheus
app.kubernetes.io/version: 2.46.0
name: prometheus-k8s
namespace: monitoring
spec:
type: NodePort
ports:
- name: web
port: 9090
targetPort: web
- name: reloader-web
port: 8080
targetPort: reloader-web
selector:
app.kubernetes.io/component: prometheus
app.kubernetes.io/instance: k8s
app.kubernetes.io/name: prometheus
app.kubernetes.io/part-of: kube-prometheus
sessionAffinity: ClientIPvim grafana-service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: grafana
app.kubernetes.io/name: grafana
app.kubernetes.io/part-of: kube-prometheus
app.kubernetes.io/version: 9.5.3
name: grafana
namespace: monitoring
spec:
type: NodePort
ports:
- name: http
port: 3000
targetPort: http
selector:
app.kubernetes.io/component: grafana
app.kubernetes.io/name: grafana
app.kubernetes.io/part-of: kube-prometheus
vim alertmanager-service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: alert-router
app.kubernetes.io/instance: main
app.kubernetes.io/name: alertmanager
app.kubernetes.io/part-of: kube-prometheus
app.kubernetes.io/version: 0.26.0
name: alertmanager-main
namespace: monitoring
spec:
type: NodePort
ports:
- name: web
port: 9093
targetPort: web
- name: reloader-web
port: 8080
targetPort: reloader-web
selector:
app.kubernetes.io/component: alert-router
app.kubernetes.io/instance: main
app.kubernetes.io/name: alertmanager
app.kubernetes.io/part-of: kube-prometheus
sessionAffinity: ClientIP#以上配置文件分别增加如下配置：
spec:
type: NodePort
在node节点上添加镜像
##提交
kubectl create -f ./setup
kubectl create -f ./
#查看pod
kubectl -n monitoring get pod
查看端口号
此时登录并没有成功，查看问题发现3000端口（grafana本身）连接有问题，
去到配置文件内grafana-deployment.yaml中，40行将健康检查的路径去掉
更新yaml，等待状态正常
检查状态，发现正常
再将网络策略文件删除，以防阻止访问界面
刷新网站即可登录
#访问用户和密码
admin/admin
登录后需要修改密码
修改过后即可登录界面
汉化界面
完成汉化
三.发布
1. 蓝绿发布
在Kubernetes中，蓝绿发布（Blue-Green Deployment） 是一种部署策略，通过同时维护两个完全独立的生产环境（“蓝”和“绿”），在验证新版本（绿）后，一次性将流量从旧版本（蓝）切换到新版本，若发现问题则立即回退。其核心特点是零停机时间和快速回滚。
蓝绿发布的核心原理
双环境共存：
蓝环境（Blue）：当前生产环境，处理所有用户流量。
绿环境（Green）：新版本环境，部署完成后处于待命状态。
流量切换：
通过更新负载均衡规则或Service选择器，将所有流量从蓝环境切换到绿环境。
快速回滚：
若绿环境异常，只需将流量重新指向蓝环境即可恢复。
| 方法 | 适用场景 | 核心优势 | 局限性 |
|---|---|---|---|
| Service标签切换 | 简单场景，快速切换 | 无需额外工具 | 手动操作，无流量验证 |
| Ingress控制器 | HTTP服务，需精细路由控制 | 灵活配置路由规则 | 依赖Ingress更新速度 |
| Istio服务网格 | 复杂环境，需流量镜像或高级路由 | 支持流量镜像和动态路由 | 需引入Istio，复杂度高 |
| Argo Rollouts | 自动化全流程，需预发布验证 | 自动化创建、验证和清理环境 | 需额外组件支持 |
最佳实践
数据库兼容性：确保新版本与旧版本数据库模式兼容，或使用双写策略。
会话保持：若应用有状态（如用户登录），需确保流量切换后会话不丢失。
监控与告警：在切换前后监控关键指标（错误率、延迟、资源使用率）。
自动化测试：在切换前对绿环境进行自动化API测试和冒烟测试。
根据团队的技术栈和运维能力，选择最合适的蓝绿发布方案。对于需要全自动化和预发布验证的场景，推荐使用Argo Rollouts；对于已使用服务网格的团队，Istio是更优选择。
2. 金丝雀发布
在Kubernetes中，金丝雀发布（Canary Release） 是一种渐进式部署策略，目的是将新版本应用逐步暴露给一小部分用户或流量，通过持续监控确保其稳定性后，再逐步扩大范围直至完全替换旧版本。这种策略的名称来源于“矿井中的金丝雀”——早期矿工用金丝雀来检测有毒气体，如果金丝雀存活，说明环境安全。
金丝雀发布的核心原理
小范围验证：
先部署新版本（金丝雀版本）到生产环境，但仅允许少量用户或流量访问它（例如5%的请求）。
大部分流量仍由旧版本处理，确保用户整体体验不受影响。
监控与观察：
监控新版本的性能指标（如错误率、延迟、CPU/内存使用率等）。
如果新版本表现稳定，逐步增加其流量比例；如果发现问题，立即回滚。
逐步替换：
最终将100%流量切换到新版本，完成平滑升级。
为什么在Kubernetes中使用金丝雀发布？
降低风险：
避免一次性全量发布导致全局故障，尤其适用于关键业务场景。
快速反馈：
通过真实流量验证新版本，比测试环境更可靠。
无缝回滚：
发现问题时，只需将流量切回旧版本，无需重新部署。
| 方法 | 适用场景 | 核心优势 | 局限性 |
|---|---|---|---|
| Deployment副本数 | 简单场景，无需精确流量控制 | 无需额外工具 | 流量分配不精确，需手动调整 |
| Nginx Ingress | 需要按权重分流的HTTP服务 | 精确流量控制，配置简单 | 依赖Ingress控制器功能 |
| Istio服务网格 | 复杂路由需求（如基于请求头） | 高级流量控制，精准灵活 | 需引入Istio，复杂度高 |
| Flagger自动化工具 | 需要全自动化监控和回滚的关键业务 | 自动化渐进发布，安全可靠 | 依赖Prometheus和Flagger组件 |
金丝雀发布 vs 蓝绿部署
金丝雀发布：逐步替换，新旧版本共存，适合需要持续验证的场景。
蓝绿部署：同时运行两个完整环境（蓝/绿），一次性切换流量，适合快速回滚，但资源消耗更大。
最佳实践
关键指标监控：
错误率、请求延迟、资源利用率（CPU/内存）。
业务自定义指标（如订单成功率）。
设置回滚阈值：
例如：若错误率超过1%，自动回滚到旧版本。
结合A/B测试：
根据用户特征（如地理位置、设备类型）定向分发流量。
总结
金丝雀发布是Kubernetes中降低发布风险的核心策略，通过逐步验证新版本的稳定性，确保业务连续性。选择实现方式时需权衡团队技术栈、流量控制精度和运维复杂度。对于关键业务，建议结合自动化工具（如Flagger）和监控告警，实现安全可控的渐进式发布。
3. 蓝绿发布 vs 金丝雀发布区别
| 特性 | 蓝绿发布 | 金丝雀发布 |
|---|---|---|
| 环境数量 | 同时维护两个完整环境 | 新旧版本共存于同一环境 |
| 流量切换 | 一次性全量切换 | 逐步迁移流量 |
| 资源消耗 | 较高（需双倍资源） | 较低（仅需部分副本） |
| 回滚速度 | 极快（秒级切换） | 较快（需调整流量比例） |
| 适用场景 | 关键业务的全量验证 | 渐进式验证和风险控制 |
四.总结
本文首先介绍了Kubernetes中的Prometheus监控系统，包括其特点（多维数据模型、Pull采集方式等）、与Zabbix的对比，以及生态组件（Server、Alertmanager等）。随后详细讲解了Prometheus的监控体系设计思路、工作原理和局限性。第二部分探讨了两种发布策略：蓝绿发布（双环境全量切换）和金丝雀发布（渐进式流量迁移），并对比了它们的适用场景和实现方法。全文为Kubernetes环境下的监控与发布提供了实用指导。