公司新上线的电商平台跑了一周，突然发现首页加载变慢，尤其在晚高峰时段，接口响应经常超过两秒。运维同事第一反应是查服务器负载、数据库连接数，结果一切正常。最后翻日志才发现，问题出在最近加的那套全链路性能监控工具上——它每秒采集上千条请求数据，光是上报就占了30%的网络带宽。
监控不是免费的
很多人以为性能监控只是“看看数据”，不影响实际运行。可现实是，任何监控都有代价。比如你在应用里接入APM（应用性能管理）工具，它得插桩方法调用、记录堆栈、统计耗时。这些操作本身就要消耗CPU和内存。一个原本10毫秒完成的方法，可能因为埋点变成12毫秒。单次看不出来，但高并发下累积效应就出来了。
采样频率决定负担大小
有些团队为了“看得更细”，把采样率设成100%，也就是每个请求都记录。这就像在高速公路上每辆车都拍照留档，不堵才怪。合理的做法是按比例采样，比如每100个请求记录1个。既能掌握趋势，又不至于压垮系统。
像这样的配置，在Spring Boot项目中可以通过修改配置文件实现：
<property name="traceSampleRate" value="0.01" />日志写入也得讲策略
除了实时监控，很多系统还会打大量调试日志。比如每次数据库查询都记一条info日志。看着挺安心，但磁盘I/O压力很快就上来了。更糟的是，如果日志库没做异步处理，主线程就得等着日志写完才能继续，响应时间自然拉长。
换成异步日志后，应用线程只负责把消息丢进队列，真正写文件由后台线程处理：
<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
<queueSize>512</queueSize>
<appender-ref ref="FILE" />
</appender>别让监控反客为主
有个客户曾把监控脚本直接嵌在前端页面里，每个用户访问都会触发十几个小资源请求，用来上报页面渲染时间。结果监控请求比业务接口还多，CDN流量翻倍。后来改成聚合上报，每分钟汇总一次，才把影响降下来。
关键是要意识到：监控是为了服务稳定，而不是制造新的不稳定因素。上线前做压测时，记得把监控组件一起带上，看看它在高负载下的表现。有时候关掉某些非核心指标，系统的流畅度反而提升明显。
说到底，性能监控就像汽车仪表盘。你不能因为想看清油量，就把发动机功率分一半给仪表供电。平衡好可观测性和系统开销，才是长久之道。