情景1：排障先从全局开始
打开监控，看到调A应用的接口错误数较高，且健康度中显示仅有20%，内容写着：
您调用的A应用接口miaomiaomiao.Query错误数超过888！
自己调用接口有十几个，偏偏是A应用报错，大概率是他们的问题，立刻联系应用A的攻城狮协同处理……
情景2：有时一个坏节点就能乱了整个集群
A应用的攻城狮小A，打开了应用页面，在左侧列表中看到了异常指标：
晃眼的响应时间和异常数……平均响应时间是100秒！
这台机器八成有问题了，首先点击到这个IP，小A从主机数据中查看到了如下内容：
What？？
这一马平川的堆曲线是咋回事儿，小A知道，【堆/每分钟】这个水位图，水位大小是叠加的，也就是说，现在JVM进程内，old和eden等区域内存累加值是3G，他总共堆内存才3G啊……
这是内存直接被打满了啊！
此时小A想起来，异常数这个节点也比其他节点多，点击到异常分析，看到了如下图表：
RuntimeException有将近300多个，心里贼有B-Tree的小A马上心有戚戚的去改代码了，同组的小B不明就里，点击异常名称进入到了详情页，才看到原来代码里有用运行时异常封装业务警告，由此导致缓存剔除功能失效了……
情景3：谁动了我的流量
自从上次被小A坑了个故障之后，小C就给自己的应用多加了几个维度的告警，反正监控系统的告警规则配置简单易用还不收费……
成功排障且快速止血，加上平时努力，使小C以较好的评价通过了转正，意气风发的他这一日正在会议室中，和产品经理互喷，手机的钉钉忽然响了起来：
“您的应用XXX接口SSS调用量，持续5分钟超过1024次！”
“您的应用XXX节点192.168.0.1堆内存占用，持续5分钟超过1900M！”
刚刚转正，就来告警，是谁在给我上眼药？
小C左手指南，右手鼠标，打开监控系统的依赖监控界面……
从告警信息来看，其一是内存超高，其二是调用量超过阈值，根据负载均衡策略，这大概率不是自己系统的节点问题，所以这里要从流量入手。
在监控系统中，Dubbo服务、MQ Listener、HTTP服务在服务监控中，其他内容在依赖监控中，小C可以查看全部的统计，也可以看某个接口的统计，并且通过**+**号展开，可以看调用详情及IP分布。
从调用方上看，调用量最大的就是小B的应用，他的应该是提供外网访问的，调用量飙升，很可能是应用被攻击，且没有做好限流措施导致的，所以小C赶紧打电话给小B去了。
问题圆满解决，小C趁机又熟悉了一遍监控系统的流量排查机制。
首页的拓扑图可以很直观的看上下游流量，服务监控 、流量监控 中可以看到更详细的信息，且能查阅成功或失败的请求采样。在异常场景中，他可以点击异常分析，看到HTTP或Dubbo、SQL的慢调用，帮助自己定位问题。
情景4：链路跟踪，不放过每个细节
小B的问题解决了，但是小C在依赖监控中发现了新的问题，他有个业务逻辑需要调用小E的应用，但是这个接口95线耗时竟然超过了3秒，自己又没传大文件，这妥妥的有问题啊。
为了防止小E不承认，陷入无限扯皮环节中，小C打开了接口调用的采样。
图中的每个节点都可以点击查看详情，从图示中的右下半部分，可以看到小E的应用执行了多次相同的SQL，这很可能是没有批量提交数据导致的，在其他采样中，小C看到了严重的甚至调用了上百次SQL！
频繁与DB交互，导致接口响应时间变慢，这回进而拖垮自己的应用的，赶紧和小E沟通！
小C直接把URL丢给了小E，然后点击列表结构去看看这一次调用的详情……
总结
穷举解决不了故障。
但是流程化的方法可以使排障成本降低，减少时间浪费，缩短止血时间。
整个排障过程，实际中从两点着手，即由整体到局部。
全司的整体，是首页的各种TOP列表，局部是应用详情；
系统的整体，是系统页的概览信息，和IP栏中的重点数据，局部是主机数据，是流量详情，是链路跟踪。