recording rules的核心优势，是将海量数据进行提前计算比如cpu mem使用率这类基础的数据，如果节点只有10 50台可能无所谓，查询的时候感觉不出区别，但如果有500台，那是否使用recording rules的差异就会相当明显
编写recording rules——使用prometheusRule CRD旨在说明如何进行recording rules配置编写与使用，这种方式也是kube-prometheus-stack使用的方式，是使用Operator的原生方式
1234567891011121314151617181920212223242526272829303132...
很多exporter都是对机器或服务自身做监控，像是机器CPU利用率、redis内存利用率、网卡丢包率，这种都属于白盒测试
那么是不是会出现一种情况，各个方面的指标都没问题，但是服务就是访问不通呢？
这个时候就需要使用blackbox-exporter，作为一种黑盒测试的手段，能够在服务外部使用http tcp icmp https DNS探测等方式进行服务检查
探测目标
举例
意义
K8s Service
http://nginx-svc.default:80
验证 Service → Pod 链路是否通
Ingress 域名
https://blog.example....
一直听说 VM 压缩率比 Prometheus 高 7 倍，手上正好有套 kube-prometheus-stack 跑在 Kind 集群，从零搭一套把告警链路跑通。
单机版部署与接入Prometheus123456789101112131415161718192021222324252627282930# clone helm chart，国内需要代理export http_proxy="http://192.168.10.238:7897"export https_proxy="http://192.168.10.238:7897"git cl...
是一种工作在进程层面的exporter
比如k8s集群中，如果节点总是发生不明原因的OOM，在节点监控node-exporter的基础上，就很适合用这种exporter来进行针对性监控
二进制部署因为我当前的k8s集群是kind，不太适用，如果在k8s内，就可以用daemonset
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647wget https://github.com/ncabatoff/process-exporter/releases/download/v...
Prometheus-client模块自定义metrics指标
特征维度
SDK（直接暴露）
Exporter（转换代理）
Pushgateway（推送中转）
数据流向
拉取 (Pull)
拉取 (Pull)
推送 → 暂存 → 拉取 (Push → Pull)
侵入性
高（需改代码）
无（独立进程）
低（调用推送API即可）
适用对象
可控的、自研的服务
不可控的、第三方的服务
生命周期短、无法被拉取的任务
模型契合度
完全契合 Prometheus 拉模型
完美契合，是拉模型的延伸
妥协方案，破坏了部分语义（如实例状态）
123456789101112131...
环境准备123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354# 使用kind部署k8s集群，版本v1.31，有代理curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.31.0/kind-linux-amd64chmod +x ./kindsudo mv ./kind /usr/local/bin/kindcat > kind-config.yaml <<EOFkind: Cluster...
在大规模监控场景下如果只用一个Prometheus server采集数据，可能跨数据中心，延迟大，配置复杂，同时单个Prometheus压力大，容易性能瓶颈
分布式采集：每个数据中心独立 Prometheus 负责本地采集
集中聚合：中心 Prometheus 通过 /federate 拉取部分指标
降低压力：避免单个 Prometheus 采集全网数据。
标签保真：honor_labels: true 保留原始标签，方便分析来源
灵活选择：match[] 决定上游拉哪些数据，不浪费带宽。
部署下级Prometheus123456789101112131415161718...
概述之前学习普罗米修斯的时候还是个初学者，现在工作了几年，因为接触了很多其他领域的知识，对Prometheus有更深的理解了，
所以我就以现在的角度重新整理一遍Prometheus相关的知识点
exporter官网：Exporters and integrations | Prometheus
特点数据特点
数据 = 指标(metric)+标签(labels)+时间序列(time series)
指标：要监控的具体项，比如CPU用户态使用率、CPU等待时间、可用内存等 标签：要为指标附加的维度信息，用来区分不同业务、环境等，同k8s的labels 时间序列：指标随时间变化的数值...
本文基于上一篇《Zabbix7使用docker-compose部署》
集成deepseek
准备zabbix如果需要执行一个脚本，而我们的zabbix-server使用的是docker-compose的方式部署的，所以就需要在容器中/usr/lib/zabbix/alertscripts/目录中存放脚本文件。所以我们可以在docker-compose文件中修改，让本地某一目录挂载到脚本目录中
那么先在本地创建一个目录用以存放脚本文件的123456mkdir -p /root/zabbix-docker-compose/zabbix-scr...
Docker Compose部署zabbix-server
单文件管理所有服务
依赖关系清晰
一键启停/重建
版本控制友好
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970# 参考文档https://github.com/zabbix/zabbix-dockermkdir zabbix-docker-composecd zabbix-docker-compose/g...