apm监控系统 视频监控系统设计方案

开箱即用的性能分析工具pinpoint

pinpoint是开源在github上的一款APM监控工具，它是用Java编写的，用于大规模分布式系统监控，属于分布式调用链监控组件。

apm监控系统 视频监控系统设计方案

它主要的特点是开箱即用、完备的Web界面，对性能影响较小，无侵入式安装探针，小团队懒人的必备佳品。

官网：

监控截图如下：

服务器端主要分为三部分：

1.pinpoint-collector.war 控制器，用于接受各客户端传回来的数据，保存在Hbase里。需要部署在中间件(比如tomcat)中

2.pinpoint-web.war 监控界面，即上图这个还不错的Web界面。需要部署在中间件(比如tomcat)中

3.Habse数据库 ，用于存储数据

客户端pinpoint-agent，其实就是一个jar包，主要是放在待监控的目标机器上，随待监控的jvm启动即可。支持tomcat、jboss、spring boot.

以tomcat为例：只需要在tomcat的catalina.sh中加入以下代码即可

安装部署都比较简单，不赘述，参考官网即可

注意事项

pinpoint-collector对外开放的三个端口9994\9995\9996，主要用于从agent处获取数据，其中9994为tcp协议，9995及9996均为udp协议，在生产环境开通网络权限时需要注意

还有就是pinpoint-agent并不是把所有的请求都会拦截发送到pinpoint-collector上，只是部分请求（大约20%）,因此只能做性能分析告警用，不能作为全数据参考。

APM的主要功能

应用性能管理主要功能如下：

监测企业关键应用性能：过去，企业的IT部门在测量系统性能时，一般重点测量为最终用户提供服务的硬件组件的利用率，如CPU利用率以及通过网络传输的字节数。虽然这种方法也提供了一些宝贵的信息，但却忽视了最重要的因素--最终用户的响应时间。现在通过事务处理过程监测、模拟等手段可真实测量用户响应时间，此外还可以报告谁正在使用某一应用、该应用的使用频率以及用户所进行的事务处理过程是否成功完成。

快速定位应用系统性能故障：通过对应用系统各种组件（数据库、中间件）的监测，迅速定位系统故障，如发生Oracle数据库死锁等问题。

优化系统性能：精确分析系统各个组件占用系统资源情况，中间件、数据库执行效率，根据应用系统性能要求提出专家建议，保证应用在整个寿命周期内使用的系统资源要求最少，节约TCO。

新应用性能管理环境的一个关键特性是部署在需要的地方：靠近服务。有多种方式来实现这一点：· 在虚拟机管理程序环境中，监控空间内虚拟机的响应时间和资源消耗情况；· 在没有管理程序（例如专用物理服务器）或管理程序遥不可及（即在IaaS环境）时，在操作系统上运行；· 在容器内；· 在Java或.Net应用服务器环境内；·在终端用户设备，连续或按需即时下载。

linux安装全链路追踪工具skywalking8.0

SkyWalking是一个针对分布式系统的APM（应用性能监控）系统，特别针对微服务、cloud native和容器化架构，其核心是个分布式追踪系统。它通过探针自动收集所需的指标，且基于探针技术对应用零侵入零耦合。通过这些调用链路以及指标，SkyWalking APM会感知应用间关系和服务间关系，并进行相应的指标统计。

解压后，进入目录，默认自带了agent，这个是用来追踪java项目的。我因为是用来追踪php项目，所以这个用不上，如果要追踪php项目，需要另外安装php的agent，请查看我另外一篇文章( linux安装sky-php-agent )

bin里面是启动文件

config目录里面是配置文件

webapp目录里面是UI界面项目文件和配置文件

默认情况下，只需要更改一下 config/application.yml文件

默认的restHost和gRPCHost的IP为0.0.0.0，我这里改成我这边内网的IP。这里要注意一下，一旦改了IP，就只能用这个IP，比如我这里改成了内网IP，那么用127.0.0.1都不能访问。

如果需要更改UI界面访问的端口，可以修改 webapp/webapp.yml，里面配置文件很简单

注意一下，如果要想能够让受控端访问到skywalking服务，那么必须将12800端口对受控端服务器打开。WEB界面的端口，我这里是8081，大家可以改成自己需要的端口。

变更完配置后，就可以进去bin目录下，运行 startup.sh ，服务就会启动。然后通过http://服务器ip:8081进行界面访问。

受控端如果也启动了的话，这个时候，界面里就自动会出现数据了。

emmmm.....这里有个坑，默认情况下，打开界面什么数据都看不到，这个需要点击右上角的“自动”按钮，让按钮变成蓝色，这个时候就会有数据出现了。

如果还是没有出现数据，那就检查受控端服务是不是已经启动了，或者去看一下logs目录下的日志。如果受控端连接服务端出现错误，就看skywalking-oap-server.log；如果受控端一切正常，界面数据还是不显示，就看webapp.log

我在安装的时候，使用startup.sh启动文件，又遇到一个坑。这个启动文件，无论中间是不是有报错，都会提示启动成功。而且因为没有停止的命令，如果重复运行startup.sh，日志里会提示端口占用。这个时候，需要使用命令先查看占用端口的进程，然后杀掉进程，再重新运营启动文件才可以。

apm素质测评系统有监控吗

apm素质测评系统有监控。APM的测评理念基于全面人才评价理论，全面人才评价是全面人才管理的核心，它是全面人才激励体系的基础和前提、全面人才发展体系的依据和标准，最终促进全面人才战略落地。全面人才评价的关键是对全部人才的一贯表现和全部工作的评价，包括全面素质评价、全面行为评价和全面绩效评价，这可全面满足组织和人才的双向需求。

有什么知名的开源apm(Application Performance Management)工具吗？

aver/pinpoint(github上2148个star)

韩国的一个公司开源的，有待评估使用情况，就是整体还不是JDK8，有些还是有点费劲，技术上采用agent的方式，对java友好

大众点评cat(github上1725个star)

看接入的公司还是挺多的，个人感觉是点评名气还可以，但是搭建起来有点费劲，很多东西都写死配置了，不灵活。整体设计的话，由于没有采用agent的方式，采用的是api手工埋点的方式，跟SNG的很像，好处的是跨语言，不好的地方就是对java来说用起来还需要包装一下

ky-walking(github上374个star)

开发团队加入了OneAPM,目前看使用的公司不多，整体技术采用agent方式，对java友好。提供了对dubbo等的支持，属于soa时代的产品

从技术架构上看，对于log的存储都使用了hbase，也都是自己实现了日志/监控数据的上报。pinpoint支持udp的方式，这个好一点。这类还是有点SOA时代的痕迹，更为符合大数据时代的做法是，监控数据丢给kafka，然后监控server来消费数据即可，这一点在cat中使用了consumer有点这个味道，但是没有彻底转型过来。

APM整体的功能结构，主要是 1.日志追踪，2.监控报警 3.性能统计。对于日志追踪，已经有spirng cloud zipkin了，这个对spring cloud体系结合的很好，确的就是监控报警和性能统计，可以采用agent的方式进行无侵入的监控，或者采用log appender的方式到kafka，之后再进行error的监控报警，以及把performance的数据log到日志，发送到kafka来进行统计。

inpoint

大众点评Cat--架构分析

透过CAT，来看分布式实时监控系统的设计与实现

ky-walking

什么是APM应用性能管理？有哪些服务商？

APM是应用性能监控（Application Performance Monitoring）或应用性能管理（Application Performance Management）的缩写。而应用性能管理，就是指使用特定的工具或者进程对软件应用的性能和可用性进行监控和管理，帮助IT运维人员和应用开发人员完成对系统的监测，致力于发现、诊断并定位复杂应用的性能瓶颈和故障，及时完成对性能的修复处理，以保证应用达到预期的服务水平和用户体验。

国外有dynatrace、appdynamics，国内就是博睿数据、云智慧、基调等，博睿数据的产品不仅能够发现问题，更能定位问题，这对于企业打破性能瓶颈，改善用户体验有着深远意义。

安全网站

360移动端性能监控实践QDAS-APM（iOS篇）

揭秘 APM iOS SDK 的核心技术

iOS-APM-Secrets

iOS_APM从入门到放弃,剖析移动端性能监控

网易NeteaseAPM iOS SDK技术实现分享

iOS性能优化探讨

谈谈iOS app的线上性能监测

iOS APM监控总览

iOS开发——实时监控网速（初探）

ios 实时监控每秒请求的网络数据

APM(网络监控方面)

iOS网络监控的实现- for APM System

全面优化 iOS App 性能

iOS面试 自己实现一个自旋锁

掌上链家iOS端组件化分享

资深技术Leader曹乐：如何成为技术大牛

iOS性能优化实践：头条抖音如何实现OOM崩溃率下降50%+

一款可让大型iOS工程编译速度提升50%的工具

教您构建移动APM监控系统

美团外卖iOS App冷启动治理

爱奇艺iOS移动端网络优化实践：请求成功率优化

为你的ios程序穿上安全的外衣

马蜂窝 iOS App 启动治理：回归用户体验

关于iOS电量检测和分析的调研

APMCon

字节跳动的技术实践分享

Android线上轻量级APM性能监测方案

Github 链接 Collie

如何衡量一个APP性能好坏？直观感受就是：启动快、流畅、不闪退、耗电少等感官指标，反应到技术层面包装下就是：FPS（帧率）、界面渲染速度、Crash率、网络、CPU使用率、电量损耗速度等，一般挑其中几个关键指标作为APP质量的标尺。目前也有多种开源APM监控方案，但大部分偏向离线检测，对于线上监测而言显得太重，可能会适得其反，方案简单对比如下：

还有其他多种APM检测工具，功能复杂多样，但其实很多指标并不是特别重要，实现越复杂，线上风险越大，因此，并不建议直接使用。而且，分析多家APP的实现原理，其核心思路基本相同，且门槛也并不是特别高，建议自研一套，在灵活性、安全性上更有保障，更容易做到轻量级。本文主旨就是 围绕几个关键指标 ：FPS、内存（内存泄漏）、界面启动、流量等，实现 轻量级 的线上监测。

Crash统计与聚合有比较通用的策略，比如Firebase、Bugly等，不在本文讨论范围

每个APP的网络请求一般都存在统一的Hook点，门槛很低，且各家请求协议与SDK有别，很难实现统一的网络请求监测，其次，想要真正定位网络请求问题，可能牵扯整个请求的链路，更适合做一套网络全链路监控APM，也不在讨论范围。

线上监测的重点就聚焦后面几个，下面逐个拆解如何实现。

直观上说界面启动就是：从点击一个图标到看到下一个界面首帧，如果这个过程耗时较长，用户会会感受到顿挫，影响体验。从场景上说，启动耗时间简单分两种：

本文粒度较粗，主要聚焦Activity，这里有个比较核心的时机：Activity首帧可见点，这个点究竟在什么时候？经分析测试发现，不同版本表现不一，在Android 10 之前这个点与onWindowFocusChanged回调点基本吻合，在Android 10 之后，系统做了优化，将首帧可见的时机提前到onWindowFocusChanged之前，可以简单看做onResume（或者onAttachedToWindow）之后，对于一开始点击icon的点，可以约等于APP进程启动的点，拿到了上面两个时间点，就可以得到冷启动耗时。

APP进程启动的点可以通过加载一个空的ContentProvider来记录，因为ContentProvider的加载时机比较靠前，早于Application的onCreate之前，相对更准确一点，很多SDK的初始也采用这种方式，实现如下：

这样就得到了冷启动的开始时间，如何得到第一个Activity界面可见的时间呢？大概回执流程如下

网上有一些认为可以监听onAttachedToWindow或者OnWindowFocusChange，onAttachedToWindow的问题是可能太过靠前，还没有Draw, OnWindowFocusChange的缺点可能是太过滞后。其实可以简单认为在view draw以后，View的绘制就算完成，虽然到展示还可能相差一个VSYNC等待图层合成，但是对于性能监测的评定，误差一个固定值可以接受：

在onResume函数中插入一条消息可以吗，理论上来说，太过靠前，这条消息在执行的时候，还没Draw，因为请求VSYNC的同步栅栏是在是在Onresume结束后才插入的，无法拦截之前的Message，但是由于VSYNC可能存在复用，Onresume中插入的消息也有可能会在绘制之后执行，这个不是完全一定的，比如点击MaterialButton启动一个Activity，第二个Activity的setView触发的VSYNC就可能复用MaterialButton的波纹触发的VSYNC，从而导致第二个Activity的performTraval复用第一个VSYNC执行，从而发生在onResume插入消息之前，如下

综上所述， 将指标定义在第一次View的Draw执行可能比较靠谱 。具体可以再DecorView上插入一个透明View，监听器onDraw回调即可，如果觉得不够优雅，就退一步，监听OnWindowFocusChange的回调，也勉强可以接受, OnWindowFocusChange一定是在Draw之后的。如此就可以检测到冷启动耗时。APP启动后，各Activity启动耗时计算逻辑类似，首帧可见点沿用上面方案即可，不过这里还缺少上一个界面暂停的点，经分析测试，锚在上一个Actiivty pause的时候比较合理，因此Activity启动耗时定义如下：

同样为了减轻对业务入侵，也依赖registerActivityLifecycleCallbacks来实现：补全上方缺失

到这里就获取了两个比较关键的启动耗时，不过，时机使用中可能存在各种异常场景：比如闪屏页在onCreate或者onResume中调用了finish跳转首页，对于这种场景就需要额外处理，比如在onCreate中调用了finish，onResume可能不会被调用，这个时候就要在 onCreate之后进行统计，同时利用用Activity.isFinishing()标识这种场景，其次，启动耗时对于不同配置也是不一样的，不能用绝对时间衡量，只能横向对比，简单线上效果如下：

FPS是图像领域中的定义，指画面每秒传输帧数，每秒帧数越多，显示的动作就越流畅。FPS可以作为衡量流畅度的一个指标，但是，从各厂商的报告来看，仅用FPS来衡量是否流畅并不科学。电影或视频的FPS并不高，30的FPS即可满足人眼需求，稳定在30FPS的动画，并不会让人感到卡顿，但如果FPS 很不稳定的话，就很容易感知到卡顿，注意，这里有个词叫 稳定 。举个 极端 例子：前500ms刷新了59帧，后500ms只绘制一帧，即使达到了60FPS，仍会感知卡顿，这里就突出 稳定 的重要性。不过FPS也并不是完全没用，可以用其上限定义流畅，用其下限可以定义卡顿，对于中间阶段的感知，FPS无能为力，如下示意：

上面那个是极端例子，Android 系统中，VSYNC会杜绝16ms内刷新两次，那么在中间的情况下怎么定义流畅？比如，FPS降低到50会卡吗？答案是不一定。50的FPS如果是均分到各个节点，用户是感知不到掉帧的，但，如果丢失的10帧全部在一次绘制点，那就能明显感知卡顿，这个时候， 瞬时帧率 的意义更大，如下

Matrix给的卡顿标准：

总之，相比1s平均FPS，瞬时掉帧程度的严重性更能反应界面流畅程度，因此FPS监测的重点是侦测瞬时掉帧程度。

在应用中，FPS对动画及列表意义较大， 监测开始的时机 放在界面启动并展示第一帧之后，这样就能跟启动完美衔接起来，

侦测停止的时机也比较简单在onActivityPaused：界面失去焦点，无法与用户交互的时候

如何侦测瞬时FPS？有两种常用方式

360的实现依赖Choreographer VSYNC回调，具体实现如下：循环添加Choreographer.FrameCallback

这种监听有个问题就是，监听过于频繁，因为在无需界面刷新的时候Choreographer.FrameCallback还是不断循环执行，浪费CPU资源，对线上运行采集并不友好，相比之下BlockCanary的监听单个Message执行要友善的多，而且同样能够涵盖UI绘制耗时、两帧之间的耗时，额外执行负担较低，也是本文采取的策略，核心实现参照Matrix：

为Looper设置一个LooperPrinter，根据回传信息头区分消息执行开始于结束，计算Message耗时：原理如下

自定义LooperPrinter如下：

利用回调参数">>>>"与"<<<"的 区别即可诊断出Message执行耗时，从而确定是否导致掉帧。以上实现针对所有UI Message，原则上UI线程所有的消息都应该保持轻量级，任何消息超时都应当算作异常行为，所以，直接拿来做掉帧监测没特大问题的。但是，有些特殊情况可能对FPS计算有一些误判，比如，在touch时间里往UI线程塞了很多消息，单条一般不会影响滚动，但多条聚合可能会带来影响，如果没跳消息执行时间很短，这种方式就可能统计不到，当然这种业务的写法本身就存在问题，所以先不考虑这种场景。

Choreographer有个方法addCallbackLocked，通过这个方法添加的任务会被加入到VSYNC回调，会跟Input、动画、UI绘制一起执行，因此可以用来作为鉴别是否是UI重绘的Message，看看是不是重绘或者触摸事件导致的卡顿掉帧。Choreographer源码如下：

该方法不为外部可见，因此需要通过反射获取，

然后在每次执行结束后，重新将callback添加回Choreographer的Queue，监听下一次UI绘制。

这样就能检测到每次Message执行的时间，它可以直接用来计算 瞬时帧率 ，

瞬时掉帧小于2次可以认为没有发生抖动，如果出现了单个Message执行过长，可认为发生了掉帧，流畅度与瞬时帧率监测大概就是这样。不过，同启动耗时类似，不同配置结果不同，不能用绝对时间衡量，只能横向对比，简单线上效果如下：

内存泄露有个比较出名的库LeakCanary，实现原理也比较清晰，就是利用弱引用+ReferenceQueue，其实只用弱引用也可以做，ReferenceQueue只是个辅助作用，LeakCanary除了泄露检测还有个堆栈Dump的功能，虽然很好，但是这个功能并不适合线上，而且，只要能监听到Activity泄露，本地分析原因是比较快的，没必要将堆栈Dump出来。因此，本文只实现Activity泄露监测能力，不在线上分析原因。而且，参考LeakCanary，改用一个WeakHashMap实现上述功能，不在主动暴露ReferenceQueue这个对象。WeakHashMap最大的特点是其key对象被自动弱引用，可以被回收，利用这个特点，用其key监听Activity回收就能达到泄露监测的目的。核心实现如下：

线上选择监测没必要实时，将其延后到APP进入后台的时候，在APP进入后台之后主动触发一次GC，然后延时10s，进行检查，之所以延时10s，是因为GC不是同步的，为了让GC操作能够顺利执行完，这里选择10s后检查。在检查前分配一个4M的大内存块，再次确保GC执行，之后就可以根据WeakHashMap的特性，查找有多少Activity还保留在其中，这些Activity就是泄露Activity。

内存检测比较简单，弄清几个关键的指标就行，这些指标都能通过 Debug.MemoryInfo获取

这里关心三个就行，

一般而言total是大于nativ+dalvik的，因为它包含了共享内存，理论上我们只关心native跟dalvik就行，以上就是关于内存的监测能力，不过内存泄露不是100%正确，暴露明显问题即可，效果如下：

流量监测的实现相对简单，利用系统提供的TrafficStats.getUidRxBytes方法，配合Actvity生命周期，即可获取每个Activity的流量消耗。具体做法：在Activity start的时候记录起点，在pause的时候累加，最后在Destroyed的时候统计整个Activity的流量消耗，如果想要做到Fragment维度，就要具体业务具体分析了，简单实现如下

Android电量状态能通过一下方法实时获取，只是对于分析来说有点麻烦，需要根据不同手机、不同配置做聚合，单处采集很简单

不过并不能获取绝对电量，只能看百分比，因为对单个Activity来做电量监测并不靠谱，往往都是0，可以在APP推到后台后，对真个在线时长的电池消耗做监测，这个可能还能看出一些电量变化。

没想好怎么弄，显不出力

APP端只是完成的数据的采集，数据的整合及根系还是要依赖后台数据分析，根据不同配置，不同场景才能制定一套比较合理的基线，而且，这种 基线肯定不是绝对 的，只能是相对的，这套基线将来可以作为页面性能评估标准，对Android而言，挺难，机型太多。

GITHUB链接 Collie