监视，跟踪和分析有什么区别？

这是我用这些词的方式。 其他人可能有其他或不同的用法。 根据手头的工作，我将使用不同的术语。 开发团队和运营团队有不同的使用需求。

监视正在监视。 通常它正在进行，并且最好是自动的。 像Munin ， Nagios和MRTG这样的开源工具就属于这一类。 还有很多商业工具。 我也会在这个类别中包括sar连续运行，但其结果通常不会被监控。 监控工具可用于在监控资源高于或低于触发级别时触发警报。 许多监控工具在异构环境中运行良好。

分析通常是在特定的程序上完成的，以查看哪些代码使用的资源最多。 通常这是CPU时间，但也可以包括内存，I / O和执行（墙）时间。 通常用于识别优化的候选代码。 分析工具倾向于语言和/或平台依赖性。

使用日志和/或监视数据完成不同types的分析。 这是使用情况分析，可以由于各种原因。 我还没有find许多工具来做到这一点。

我以几种不同的方式使用跟踪。 我经常跟踪networking路由。 根据networking和防火墙的设置，可能会使用多种工具，或多或less取得成功。 其中大部分都在他们的名字或描述traceroute。

程序跟踪正在追踪程序的执行。 这通常在testing情况下完成。 这可以通过多种方式完成（按我的使用顺序和经验）：

• 使用strace工具调用跟踪来查看调用的代码。 这可以用于确定程序为什么失败或没有按预期做出响应。
• 跟踪级别日志logging，取决于代码中包含的相应日志logging语句。 大多数日志logging套件都支持这个级别的细节 跟踪级日志logging往往代码覆盖率较差。 我通常会根据需要添加它，并将其留在代码中供将来使用。
• 代码覆盖率跟踪logging代码的哪些部分已经在testing套件中执行。 这对确定遗漏的testing用例很有用。 代码的100％覆盖是很难得到的。 正常stream量的100％覆盖应该是可以实现的。
• 桌面检查：通过阅读代码来追踪代码。 在较大的程序中不是非常有用，而是一种很好的方式来确定unit testing的边界情况，或者当可能的来源被缩小时，找出可能的问题。 Som = e IDE和编辑器使跟踪实现代码的调用变得相对容易。
• 现场debugging; 在使用debugging器运行时跟踪代码执行。 通过指令跟踪执行指令是可能的，但是如果问题是定时问题，则可能会被遮蔽。 可以将代码链接到当前指令的debugging器有很多帮助，但是可能需要debugging版本的程序来构build。

在SAP WEB应用服务器中，我们可以定义这三个关键字，如下所述 –

Web提供的监视，跟踪和分析技术以及其他SAP和外部系统提供的技术可以使用经过validation的CCMS架构进行集成，这可能会大大简化对大型，分布式和异构安装的维护。