做软件开发十几年，其中5年专攻ITIMS监控。过去接触的是交换机、路由器、WebLogic、东方通、IBM存储那套传统体系——更偏向稳定、合规、集中式管控。
今年从0上手Prometheus+Grafana，到现在基本可用。
这篇不做教程，做一次阶段性复盘：现状、不足、以及为什么不盲目往深了做。

---

一、当前监控体系已落地内容

目前整套环境基于HP服务器 + 第二台虚拟机节点，Docker部署，核心模块都已跑通：

• Prometheus + Grafana 基础环境：容器化部署，配置持久化，基础指标采集、存储正常，面板可正常展示、查询

• 服务器基础监控：CPU、内存、负载、磁盘使用率、网络流量、TCP连接数等系统指标，覆盖两台服务器节点

• MySQL 主从监控：连接数、慢查询、运行状态、主从同步状态可视化展示

• Redis 基础监控：内存使用、命中率、连接数、键数量、基本运行健康度

• 告警通道与告警大屏：邮件告警已打通，服务异常可正常通知；独立告警总览大屏，核心组件异常能及时感知

整体来说，这套监控已经实现了 “能看、能告警、能发现问题”，满足DevOps底座最基本的可观测性需求。

---

二、和传统ITIMS监控的差异感受

因为有多年传统监控背景，这次搭建云原生风格监控，感受特别明显：

维度	传统ITIMS监控	DevOps监控
定位	更重、更全、更偏向基础设施层	更轻、更灵活、更贴近服务与容器
覆盖	网络设备、存储、应用服务器、中间件全覆盖	指标更细、更自动化
目标	稳定、统一、合规	快速部署、动态扩容、自助式排查

一个保稳定，一个保迭代。 思路不一样，但核心目标一致：系统稳不健康、出问题能不能快速发现。

---

三、当前监控体系的明显不足

虽然能用，但离“好用、细致、企业级”还有明显差距：

• 只有基础指标，没有服务级指标：目前更多是机器层面，Java服务、接口状态、业务相关指标几乎没有

• 告警依赖固定阈值，容易误报/漏报：阈值靠经验拍，没有动态基线，高峰期容易误告警，低负载又可能发现不了问题

• 没有和日志联动：监控看到异常后，还要手动去翻日志，无法一站式定位根因

• 没有告警降噪、分级、收敛：一个故障可能引发一堆告警，没有重点、没有优先级

• 没有自动自愈：告警之后还是要人处理，无法自动重启、自动恢复、自动扩容

这些都是后续可以优化的方向，但我不打算一口气全做。

---

四、为什么不盲目把监控做深、做全？

很多人一上手监控，就想一步到位：全指标、全面板、全告警、全链路。以我过去的经验，这样很容易陷入 “为了监控而监控”。

我现阶段保持克制，主要有几个原因：

• 没有明确业务需求前，不做过度设计：我的平台还在迭代，业务规模、接口量级、访问模型都没稳定，监控太细没有实际意义

• DevOps底座优先于监控精细化：环境稳定、部署顺畅、双活可用、数据库可靠，这些优先级远高于花哨面板

• 避免精力分散：一边做DevOps，一边学AI，还要写文章、做个人内容，监控先做到“够用”即可

• 未来会结合AI升级，现在没必要重复造轮子：后面计划用AI做告警优化、根因分析、日志聚类，现在堆太多规则，后面反而要重构

监控是S级重要，但不代表要一上来就做到极致。先解决“有没有”，再逐步优化“好不好”。

---

五、后续监控体系精细化规划

结合整体DevOps路线，我的监控会按下面节奏逐步推进：

1. 补全组件监控：把Nginx、Jenkins、Docker容器、FRP等关键组件先覆盖完整

2. 优化告警规则，减少噪音：分级、降噪、调整阈值，让告警“准、少、有用”

3. 接入日志系统（Loki）：实现指标+日志联动，异常一键下钻

4. 逐步加入服务级指标：随着业务接口稳定，再接入JVM、接口耗时、错误率等指标

5. AI辅助告警（中长期）：用AI做动态阈值、根因分析、异常预测

整体思路：先稳定、再完善、后智能。

---

六、总结

监控是整个DevOps体系的“眼睛”，重要性毋庸置疑，对我这种有ITIMS背景的人来说更是核心赛道。

但越是重要，越不能急、不能堆功能、不能盲目深入。现阶段做到“基本可用”已经足够支撑后续开发与迭代。

后续再围绕真实需求、真实场景、真实问题一点点精细化，不做花架子，不做无用功，不盲目跟风，只做真正能提升效率、保障稳定的事情。

---

 关注我

持续更新《人生底稿》成长史 &《技术底稿》实战干货一起踏实成长，不焦虑、不内卷。

 📚 系列导航：

 【人生底稿 01】｜农村少年（1995–2005）

 【技术底稿】01：37岁老码农，用4台机器搭了套个人DevOps平台