我们把用户和IT系统的交互类比成一次购买行为，你掏出钱递给便利店服务员说“给我一瓶农夫山泉”，服务员从她后面的冰柜中拿出一瓶水递给你，购买完成。这说明，我们和系统是存在交换的具体“数据”内容的，数据需要“传递”给响应的“对象”的，然后经过“处理”后才返回给你，这里每个环节出现了错误都会导致这次的交互行为的失败，因此我们需要了解系统运行相关的数据包括下面这些内容。

数据从用户A提交到系统处理完成返回结果，数据流经了哪些环节？

这要求我们能够监测一笔完整的交易中数据流经的所有节点。

    每个环节的处理结果是失败的还是成功的？

这要求我们标识出节点的处理结果是成功还是失败。

如果是环节N上处理失败，那么是系统运行依赖关系中的哪个因素出现了问题导致的？这可能是CPU、内存、磁盘I/O或是系统代码执行本身？

这要求我们能够标识出运行依赖各因素的实时状态数据。

为什么这个用户访问需要10秒而不是3秒呢？时间都花销在哪里了呢？应该优化哪个模块呢？

这就要求我们能够监测在整个应用交付链上各个环节的时间消耗。

系统代码出错了错误在哪个模块哪个方法呢？错误信息记录在哪个日志文件中？错误提示信息是什么？

这要求我们能够提供足够详细的运行错误细节。

同样的错误出现了多少次？都有哪些用户收到了影响？

这需要我们能够把错误和用户进行直接关联。

而上面这些问题需要在最快的时间内获得答案，减少不同人员沟通的时间，减少从海量日志中查找错误信息的时间，这要求我们在一个统一的平台上进行所有工作的处理，在一个界面中查看更多的信息，将更多的人工操作交给系统自动完成。

现在系统运行是正常的，以前出现的问题怎么查找？

这要求所有交易出错的历史数据我们都需要能够保留。

满足了上述内容后，我们就可以“看得见”哪个节点出错，从而进行故障隔离，协调具体负责团队进行处理，“摸得着”出错的详细信息，知道了错误影响了多少用户，就能够确定“改得了”系统，明确系统优化的重点和方向。