手里有两套监控集群——kube-prometheus-stack 和 VictoriaMetrics k8s-stack。想用一个 PromQL 入口同时查两边数据，Promxy 就是干这个的。
不存储数据，只做查询代理。收到 PromQL → scatter 到多个下游 → gather 合并结果 → 返回。
123Grafana → Promxy → Prometheus A → VM B → VM C
拉取chart、部署123456789101112131415161718192021222324252627#...
一直听说 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...
在开始之前，我收回之前对于langchain的所有诋毁，langchain难啃是难啃，东西确实都是干货
总体思路Prometheus → Crontab脚本 → Dify API → DeepSeek
少了一层Alertmanager和Webhook转发，只需要维护脚本
提取参数，从用户自然语言中提取登录总人数
得到方案，通过代码判断异常登录的比例，从而判断是否要继续
细化方案，输入基本解决方案，通过知识库检索详细解决方案
生成报表LLM，输出解决方案
dify安装部署1234567891011git clone https://github.com/langgenius/dify....