APM 监控系统：APM小结

8、 APM 小结

一般来讲各个端的监控能力是不太一致的，技术实现细节也不统一。因此在技术方案评审的时候须要将监控能力对齐统一。每一个能力在各个端的数据字段必须对齐（字段个数、名称、数据类型和精度），由于 APM 自己是一个闭环，监控了以后需符号化解析、数据整理，进行产品化开发、最后须要监控大盘展现等android
一些 crash 或者 ANR 等根据等级须要邮件、短信、企业内容通讯工具告知干系人，以后快速发布版本、hot fix 等。git
监控的各个能力须要作成可配置，灵活开启关闭。github
监控数据须要作内存到文件的写入处理，须要注意策略。监控数据须要存储数据库，数据库大小、设计规则等。存入数据库后如何上报，上报机制等会在另外一篇文章讲：打造一个通用、可配置的数据上报 SDKobjective-c

尽可能在技术评审后，将各端的技术实现写进文档中，同步给相关人员。好比 ANR 的实现数据库

/*
android 端

根据设备分级，通常超过 300ms 视为一次卡顿
hook 系统 loop，在消息处理先后插桩，用以计算每条消息的时长
开启另外线程 dump 堆栈，处理结束后关闭
*/
new ExceptionProcessor().init(this, new Runnable() {
            @Override
            public void run() {
                //监测卡顿
                try {
                    ProxyPrinter proxyPrinter = new ProxyPrinter(PerformanceMonitor.this);
                    Looper.getMainLooper().setMessageLogging(proxyPrinter);
                    mWeakPrinter = new WeakReference<ProxyPrinter>(proxyPrinter);
                } catch (FileNotFoundException e) {
                }
            }
        })
        
/*
iOS 端

子线程经过 ping 主线程来确认主线程当前是否卡顿。
卡顿阈值设置为 300ms，超过阈值时认为卡顿。
卡顿时获取主线程的堆栈，并存储上传。
*/ 
- (void) main() {
    while (self.cancle == NO) {
        self.isMainThreadBlocked = YES;
        dispatch_async(dispatch_get_main_queue(), ^{
            self.isMainThreadBlocked = YES;
            [self.semaphore singal];
        });
        [Thread sleep:300];
        if (self.isMainThreadBlocked) {
            [self handleMainThreadBlock];
        }
        [self.semaphore wait];
    }
}
复制代码

整个 APM 的架构图以下markdown

说明：session
- 埋点 SDK，经过 sessionId 来关联日志数据
APM 技术方案自己是随着技术手段、分析需求不断调整升级的。上图的几个结构示意图是早期几个版本的，目前使用的是在此基础上进行了升级和结构调整，提几个关键词：Hermes、Flink SQL、InfluxDB。架构

文章内容过长，拆分为多个篇章，请自行点击查看，若是想总体连贯查看，请访问这里async