比如说要提高效率，并且确定是降低 latency，所以打算收集服务的 response time，那么，response time 是看 line chart 还是 bar chart，知道了 latency 突然升高这件事之后，下一步呢？怎么知道再看什么？要和其它 metrics / event 关联么？关联哪些，怎么关联？想想意外事件发生之后，作为唯一可以背锅的程序员，身后一堆产品运营盯着你的屏幕，丧着个个脸，表情比出殡还悲壮，好像你一秒钟给公司损失几十万上下似的。在紧张的汗水打湿了你的格子衫时，你能看些什么，你该看些什么？

这样从解决什么问题，收集什么 metrics，怎么关联使用 metrics，一层层定义下来之后，我们可以确保两件事情：1. 当坏事发生的时候，我第一个知道。比如：对外的 API 的 95 percentile 的 response time 过去 5 分钟突然增加了 30%。2. 我能快速锁定问题的大致范围。比如：从其它 metrics 上看，是因为 diagon alley 服务的 latency 突然升高，进一步地，diagon alley 的 disk write IOPS 显著提高。那么这个问题，我就看为什么 diagon alley 的 disk write 不正常。

接下来是 logs。

logs 是不出问题不必太在意，但一旦出问题一定要能够方便定位具体的位置的

• 失眠后如何治疗 有哪些方法呢
• 如何护理身体 早上晨练有何好处
• 练瑜伽为什么要选择瑜伽馆，而非健身房？
• 推进网络安全法治建设，提高网络治理能力
• 老司机教你如何赶上 “绿波带”
• 总结一些常见的运动问题！想提高运动体验的你，来开眼界吧
• 如何解决你的大象腿？其实用这些跑步方法就能收获好的效果！
• 网络时代如何保障“离线权”
• 戴上博士帽冲击东京奥运？孙杨是如何成为“学霸”的
• 心理学：在这张图里你第一眼看到的是什么？测你最近的状态如何