背景 公司让调研流量回放工具goreplay，实现部分能力，其中包括要统计线上业务还在使用的api(代码陈旧，俗称屎山，无法从代码层面去做)，

修改coreDNS的configmap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 hosts

在之前的文章中，基本完成了opentelemetry可观测中：日志、链路、告警以及周边的类似于存储、拓扑等额外小功能。最重要的监控指标却没有

在之前的文章中完成了alertmanager发日志相关的告警，今天这篇是关于发送Prometheus告警的，在上篇中，日志的告警规则比较简单

在之前的文章中，告警的架构如下 由于我们公司的监控相关内容均是使用的阿里云，包括ECS、RDS、REDIS、MQ，ACK等，所以在目前部署的这

在之前的文章内容中，已经完成了一套可观测平台的搭建及配置，主要包括监控、日志、链路的可视化和互相关联，告警的配置、使用、通知。本篇主要针对O

在上一篇文章中，成功将JVM的监控集成到整个系统当中，最后只剩下告警和通知两块没做了，在我的这套系统中，常规监控告警可以直接通过Promet

在上一篇中说到了日志和链路的结合使用，基本实现了opentelemetry的主要功能，就剩下监控相关了，那么本篇就继续针对opentelem

根据上一篇文章的内容，我们成功的观测到了java服务中的链路信息，可以轻松排查到问题，但是整体架构比较复杂，本篇将对日志架构进行优化，主要针

sealos是什么，功能过多，这里就不介绍了，本篇仅介绍通过sealos部署一套kubeadmin的kubernetes。 环境准备 提前准备3