序言
事件过得好快，日子一晃就过去好多个月了，今年也快过了一半了
今年注定是坎坷的一年，反复的疫情、经济下行、互联网大厂的裁员也给今年带来了不少阴霾。
话风突转 –>
居家办公已成为常态，但是我们依然要积极阳光正能量，不断深耕前端领域，站在巨人的肩上眺望。
本次一次性更新三篇文章，来总结一些最近的收获
APM的核心概念
- APM的概念与必要性
- 常见APM的形态与对于Node.js的使用场景
前端 日常工作中的问题：当某个产品按钮点击无响应时，你怎么排查问题？
一般的排查链路：
- 检查浏览器是否报错，点击按钮时是否触发了js异常
- 检查接口是否正确返回数据，接口是否响应
- 接口报错，检查接口逻辑是否有问题
做为后端工程师或者全栈工程是出现问题，定位起来就比较麻烦，真实的场景
- 运营商问题，比如用户的运营商劫持了js，导致前端代码出错
- CDN的某个节点缓存出现问题，导致了一个老版本的js上线了
- 用户的浏览器版本正好有一个bug，代码触发了这个bug
- 服务所在的某个机房某台机器故障了(着火了)，导致服务挂掉了
- 服务依赖的一个第三方服务，欠费了
业内为了解决这一系列的问题，在17年Google提出了APM这个概念
- 终端用户体检-反应用户的真实体验
- 应用架构映射-从监控逆向分析出真实链路
- 应用事务分析-能从一个唯一的线索(用户)找出整条事务或操作
- 深度应用诊断-精准定位问题
- 分析与报告-提供实时精准的大数据查询和可视化
Application Performance Management （简称APM）是监控服务的一套技术手段，致力于监控并管理程序的性能和可用性。 广义来讲就是监控
2.APM的组成原理
APM包括 Agent, Monitor 及 Dashboard/Console
Agent用于上报数据， Monitor用于数据收集，Dashboard 用于展示数据 （与前端监控一模一样）
3.APM的形态
3.1 服务器性能指标监控
- 对服务依赖的硬件性能进行监控，如 CPU内存 硬盘容量
- 监控服务器性能指标的实时值，用于紧急问题及时报警
- 监控历史趋势，可以观察每天的访问情况以及对异常点进行分析
服务器性能指标是**最基本且最重要**的APM，他就想身体的各项指标，一旦出现异常都是比较严重的问题。
3.2 服务监控
服务端开发者最常看的监控
- 对提供的服务进行监控
- 监测服务的情况，如 请求数、响应数、成功率等
- 监测服务的热点，异常波动
- 监测服务来源，调用方分析
服务监控是比较大范围的监控，用于获取服务的大致情况，也用于服务提供者根据服务的流量来配置机器，同时可以看到大范围异常的节点
3.3 错误/异常监控
在前端非常常见，目前张勋 就在配置中心做相关的工作
- 对报错或者异常进行监控
- 一般需要主动上报
- 需要提供大量上线文信息才有意义，如 但是的URL，错误堆栈，甚至用户信息
- 价值与上报的消息多少成正比，同样成本也是
所以错误/异常 监控 对于后端慢慢的也不常用了 获取信息有限
3.4 日志收集
- 对服务的所以情况进行记录，日志是必不可少的。不管是业务本身，还是访问记录，都需要尽可能记录日志
- 日志的查询分析比较困难，所以APM一般都是有日志收的和分析的能力（通过文本文件存在硬盘上的）→ 称为 ELK
- 日志会占用大量硬盘空间，所以需要定期清除，清除掉就很难查到问题了
日志是服务器中最重要的“证据”，打日志就像前端的“打点”，因此日志一定要记录有价值的信息，如时间，关键指标, TraceId
3.5 依赖监控
- 对服务的依赖进行监控，如数据库，缓存，外部服务
- 几乎所有的响应缓慢问题均由依赖导致
- 依赖监控也是比较大范围的监控，只能发现问题，很难跟服务本身关联起来
3.6 终极形态→ 分布式事务追踪
- 真实场景，一个服务从发起到完成，要经历很多的节点
- 传统的APM工具只能监测一个或多个节点的情况，无法串起来
- 分布式事务追踪可以通过一个ID就可以查询到一次请求的全链路情况
3.7 代码级监控分析
- 一般利用自动化的代码插桩技术，获取Node.js进程内方法的调用链路
- 可以查看调用栈上的总执行时间和每个方法占的百分比
- 结合V8 Profiling，查看可能出现的内存泄漏情况
