端到端的业务性能监控、统一日志分析平台及应用性能监控有何定位上的不同？

业务性能监控，其主要的监控点在于业务，通常通过捕获网络报文的方式获取实时的业务内部或者业务间的交互数据，再进行智能解码，分析出报文当中的不同字段的内容，并进行归纳、统计、分析、告警、展示等。
日志分析平台，其主要的监控点在于日志，通常通过ES+FLUME的方式，一方面实时收集日志，一方面实时分析日志，统计分析日志，按不同字段进行解析、分析等。
应用性能监控，其主要的监控点在于应用程序，通常通过AGENT代理的方式，实时捕获应用程序进程、线程、连接池、内存等详细内容，知晓当前应用程序运行到了哪一行代码，耗时如何，调用数据库时的耗时、SQL语句、数据库操作完成情况等。
因此，三个监控平台其实际上是有共性的部分的，比如交易量、响应时间、业务成功率等指标上的解析，三种监控都可以胜任，但三个监控平台的监控角度、倚重有所不同，一个是剖析业务层面的东西，例如交易类型、机构、区域、金额、渠道等指标；一个是解析日志的上下文，输出更友好、清晰的日志格式给运维人员查询，也有一些归纳、统计的指标，但并不偏向业务层面，更多的是技术层面；最后一个是解析应用程序代码，有很多种方式，比如应用程序预埋HOOK钩子输出，或者JAVA程序内嵌代码输出分析等，这种方式更倾向于深层次的技术细节，代码层的解析。

准确断定端业务性能监控，确实还有很长一段路需要探索和实践。目前就某一种框架下的业务性能监控其实还是比较完善。比如某一个服务一秒钟调用了几次、一秒钟内调用多少服务及其链路情况进行分析，这些仅限于某一个框架下，比如SOA，Spring系等。但是诸如手机端/Web端--前置--业务逻辑--后台核心--数据库类似这样业务链路，其实就比较有挑战性，甚至说在业务应用程序中就得植入端到端的监控入口，并将这数据放入合成工厂，通过工厂来处理这些端到端的业务性能监控，如此其实投入巨大。所以现在很多银行采用旁路检测，只关注业务的有效性和失败性，即成功率的结果，也是不错的监控体系。
统一日志分析平台，作为业务监控还是很有必要，但是同样需要应用开发对日志进行统一和标准，形成可统一使用粒度的解析，以便获取准确分析结论。日志分析肯定是应用性能监控中不可替代的补充，尤其在为服务化下，日志分析对业务性能更具有不可或缺的作用。就看是采用 ELK 自主研发还是 splunk 的商业精品来服务应用性能监控了。