以友盟+服务的客户场景来说，比如在拿到一份高质量的数据之后，KPI在确定情况下进行了拆解，现在要做的就是希望团队里的人知道自己的KPI，KPI大屏就可以轻松解决这个问题。
不管是SDK方式还是探针方式，非手工埋点形式的链路信息采集都依赖于链路追踪组件对于底层框架的识别。这些底层框架包含的领域非常广，其中包含应用对外提供服务所需要的框架，应用进程内部的通讯框架，应用之间相互访问所需要的框架，应用访问外部系统所需要的框架等等。
正是因为经历了大规模生产环境的长期验证，才使ARMS能够在易用性、功能性、稳定性方面做到极致，以开源领域最活跃的全链路监控项目Skywalking为例，我们可以从多个维度对两个产品进行对比：
主机监控功能用于监控CPU、内存、Disk（磁盘）、Load（负载）、网络流量和网络数据包的各项指标。当我们遇到硬件或网络故障的时候，这些基础资源的指标数据将非常有价值。当应用部署在Kubernetes的时候，Pod监控和主机监控能够分别从pod和宿主机维度分别对指标数据进行展示。
应用总览展示的数据中，最应该值得关注的是慢SQL数据。ARMS会记录应用访问数据库的情况，当发现应用存在大量慢SQL的时候，就可以直接给出判断：该应用在访问数据库的环节存在问题。我们可以从慢SQL分析视图找到到底是哪一条SQL存在问题，从而针对性的进行优化。对于慢SQL的定义，可以通过应用的自定义配置进行修改（默认执行时间超过500ms会标记为慢SQL）
所谓“冰冻三尺，非一日之寒，水滴石穿，非一日之功”，通往架构师的道路漫长而又艰巨，轻易放弃，则所有付出瞬间付之东流。要想成为优秀的架构师，贵在坚持！
优先为下限目标分配足够的资源。比如，事先规划好的旅行需要10天，这10天就必须预算出去。
按照各主目标的顺序依次分配资源。比如，最终分配给学习的时间是10天。
在项目中学习是最快的成长方式之一，很多工程师非常享受这个过程。但是一年到头都做项目，你可能是在一家外包公司。对于一个做产品的公司，如果年头到年尾都在做项目，要不然就是在初步创业阶段，要不然就是做了大量失败的项目，总之不算是特别理想的状态。正常情况，在项目之间都会有一些非项目时间。在这段时间，有些同学会产生迷茫，成长很慢。
第一类常见的问题是沟通的可靠性。从可靠性的角度来讲，沟通分为TCP模式和UDP模式。TCP模式的形象表述是：我知道你知道。UDP模式的形象表述是：希望你知道。TCP模式当然比较可靠，不过成本比较高，UDP模式成本低，但是不可靠。在沟通可靠性方面，常见错误有如下两种：
ReplicaSet与StatefulSet又是一个有意思的话题，笔者会在后续系列详细介绍。应用所需的CPU/内存资源定义在Pod内，因为CPU/内存资源是容器级别的，由Pod的spec->containers->resources定义。
