背景：服务器很多，人只有一双手
当时在公司兼职运维，服务器数量多，日常检查靠逐台登录：看负载、看磁盘、看进程、看日志。问题发现得晚，历史状态也留不下来，故障复盘基本靠回忆。
于是自己写了一套监控站点，核心目标很朴素：不用登录每台机器，也能知道它们现在怎么样、过去发生过什么。
核心难点
- 采集开销：采集脚本不能影响业务，频率和指标要可控。
- 数据增长：指标持续写入，存储和查询都要考虑成本。
- 检索：按主机、时间、指标快速定位历史异常。
- 展示：非运维人员也能看懂状态和趋势。
方案：采集、存储、检索、展示
1. Shell 采集
用 shell 脚本采集 CPU、内存、磁盘、网络、负载和关键进程状态，统一格式化后发送到采集后端。采集任务错峰执行，避免同时打满被监控机器。
2. Python 后端与 ES
Python 服务接收指标、做基础清洗和聚合，写入 Elasticsearch。索引按日期划分，字段类型统一，既支持实时查询，也支持历史回溯；Redis 用于缓存最新状态和短期聚合。
3. 检索与可视化
用前端图表展示实时状态和趋势，支持按主机、时间范围和指标筛选；异常阈值触发标记，历史数据可以按条件检索，故障时不必再逐台翻日志。
这套系统的关键不是“采了多少指标”，而是把监控数据从一次性输出变成可检索的时间序列。后来做日志检索、业务监控，思路是一样的：先建模，再采集，最后才是展示。
结果
自动采集多台 Linux 服务器实时指标
ES 检索历史数据快速定位
可视化状态、趋势与异常一目了然
服务器状态从“登录查看”变成“打开页面就知道”，历史指标可检索、可对比；故障定位从翻日志变成按主机和时间过滤。系统后来也持续演进，成为日常运维的基础工具。
复盘
监控系统的价值在于“可查询的历史”，而不只是“实时的数字”。把采集、存储、检索和展示分开设计，小系统也能有长期价值。