菜鸟运维升级之路

在云原生技术蓬勃发展的今天，Kubernetes（K8S）已成为容器编排领域的事实标准，而监控作为保障系统稳定性和可观测性的核心环节，其重要性不言而喻。Prometheus 凭借其强大的时序数据采集能力和灵活的查询语言（PromQL），成为云原生监控体系的基石。然而，在动态变化的 K8S 环境中，传统静态配置的服务发现方式往往难以适应频繁的服务扩缩容和实例迁移。如何实现监控目标的自动化发现与动态管理，成为提升运维效率的关键挑战。为此，服务发现技术应运而生。

为什么需要配置自定义监控？当采用telegraf作为agent采集监控信息时，虽然telegraf的inputs插件提供了不少封装好的监控配置文件，但是在生产环境下，直接使用telegraf提供好的配置文件来监控相应的指标总是不全面的。例如:自己编写了一个azkaban组件监控脚本，实现对其中的任务状态及任务数进行监控，那么这时候telegraf提供的开源inputs插件就实现不了这个监控过程，那么怎么办?因此本篇文章主要针对telegraf的自定义监控实现方式进行展示。

在当今复杂多变的系统环境中，高效的警报管理和响应机制变得尤为重要。为了解决这一问题，Alertmanager作为Prometheus生态系统中的核心组件，提供了强大的警报处理功能。然而，Alertmanager的默认通知方式可能并不完全满足所有用户的需求。例如，将不同的告警发送到不同接收群体、客户自己的办公软件等，为了解决这个问题，Alertmanager Webhook 应运而生，它允许用户将Alertmanager的警报与外部媒介的Webhook集成，实现自定义的警报通知和处理流程。

当在https : //github.com/influxdata/telegraf/tree/release - 1.30/plugins/inputs中不到对应的服务监控配置时 , 则可以使用自定义监控项的方式实现监控。在github中可以找到大部分开源组件的telegraf的监控配置 , 粘贴修改后即可使用。

在第一篇文章中，主要针对运维监控平台组件的介绍及通过fpm工具对二进制安装的组件进行RPM包构建,让大家对整个运维监控平台从概念、安装部署有一个大致的认知。但是在企业环境中仅仅了解概念和安装部署是不够的，随着对技术的深入了解，还得学会prometheus如何监控某一个指标，并且这个指标怎么设置监控规则，只有当监控的指标值超过监控规则设置的阈值后，才会产生一条原始的告警。那么问题就来了，怎么配置监控项以及怎么设置监控规则就是本篇文章的核心思想。接下来，闲话少说开始实战。

本篇文章主要从当下主流监控prometheus+grafana出发，结合实际项目经验，从组件rpm包构建、安装部署、文件配置、告警采集、告警配置、告警发送、监控规则配置等多角度出发，构造出一个完全体的监控平台。上图为运维监控平台大纲，后续文章都会以该大纲为基础进行逐一实现该监控平台主要基于prometheus、alertmanager、blackbox_exporter、telegraf、consul等开源组件构建而成满足日常运维巡检、业务层面监控、服务器层面监控、应用层监控、容器化监控等功能。

在实际产生环境中主要以prometheus监控为主,在使用该监控时,有个很大的问题时,需要手动修改Prometheus.yml文件,将监控指标手动添加进去,当监控指标少的时候,维护和添加都很方便,但是当一套环境中监控指标多大几百个,添加工作繁琐,这时你会想到写个shell脚本,对多个监控指标进行添加,但是你有没有考虑过此时的prometheus.yaml文件的可维护性以及当添加的监控指标越来越多时,prometheus主机的cpu、内存也随之增长,这时你该怎么处理呢？