公司刚上线的新项目，每天访问量还没破万，服务器监控告警却响个不停。运维老张打开账单一看，光是性能监控这一块，上个月就花了将近八千。这数字让他直咂舌：监控是得做，但不能把自己给‘监’破产了。
别盲目采集，按需取舍才是关键
很多团队一上来就把所有指标全开：CPU、内存、磁盘IO、网络延迟、每个接口响应时间……恨不得连鼠标点击次数都记一笔。结果数据量爆炸，存储和处理成本蹭蹭往上涨。其实大多数时候，真正影响业务的只有核心链路的几个关键指标。比如电商系统，订单创建、支付回调这两个接口的延迟和错误率最重要，其他边缘服务采样率可以降到10%甚至更低。
合理设置采样率，省下一半开销
全量采集在小规模系统还能扛住，一旦用户量上来，数据量就是几何级增长。某创业公司曾把APM的采样率设为100%，日均生成2TB监控数据，光存储每月就要三万多。后来改成动态采样——高峰期80%，低峰期20%，再配合异常自动提升采样，不仅问题照样能发现，费用直接砍掉近六成。
自建方案也能打，ELK+Prometheus组合很香
商用监控工具确实省事，但价格也不亲民。中小团队完全可以考虑开源组合拳。用Prometheus抓指标，Grafana做可视化，日志走Filebeat+ES存储，整套跑在几台旧服务器上，月成本不过几百块。虽然初期要搭环境、写配置，但长远看划算得多。
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['192.168.1.10:9100', '192.168.1.11:9100']
scrape_interval: 30s
- job_name: 'app_metrics'
metrics_path: /metrics
static_configs:
- targets: ['app-server-01:8080']设置分级告警，避免被垃圾消息淹没
监控不是越多告警越好。半夜三点因为某个非核心服务的CPU短暂冲高就被叫醒，几次下来团队就麻木了。应该区分等级：P0级故障（如数据库宕机）必须立刻通知，P2级（如某个后台任务延迟）可以汇总成日报。这样既能保证关键问题不遗漏，又不会浪费人力反复排查噪音。
定期清理历史数据，别让归档吃掉预算
很多人设完监控就不管了，数据一股脑往硬盘里塞。一年后发现90%的存储空间存的都是半年前的冷数据。其实可以通过索引策略自动删除或归档。比如Elasticsearch里用ILM策略，超过30天的日志自动转入低频存储，超过90天的直接删掉。既满足审计需求，又控制成本。
监控的本质是服务业务，不是制造负担。选对工具、定好策略、管住采集范围，才能让性能监控真正成为技术团队的助力，而不是财务报表上的累赘。