在实施线上监控之前的梳理，核心还是要对业务系统有比较深刻的了解，才能对症下药，对于业务系统的梳理，可以套一下的框架
简单举个例子，从阶段来说，一般初创期和快速迭代的系统，业务和功能都未必稳定，这时就不宜去做比较深度的监控，把核心场景覆盖即可，结合系统的核心目标，如用户活跃和流水，对流水和用户活跃数据的敏感度的监控等，同时一般面向外部用户的业务系统都是一个前台的角色，用户敏感度比较高，所以把一些用户高频操作的功能给监控起来，再者要结合当前的技术方向以及业务方向，如技术方向，可以引入一些新技术，或者在原有的逻辑上补充监控点，技术方向有个前提是技术栈统一或相近，不然会加大监控点建立的难度和后期的维护成本，有了前置对业务系统的分析，再实施监控时才少走弯路，降低成本
按照个人的经验总结，我们可以按这样子的一个框架去建立监控体系
依据上图，我们具体说一下里面的几个大点
做监控梳理的第一个步骤是要明确监控的范围，哪些点是要监控起来的，那就要清晰明确业务系统的架构，技术栈以及依赖方等各种方面，并梳理优先级，简单总结为查缺补漏
1.查找整理当前有哪些监控点，具体的监控范围，从业务覆盖度（功能层面）和系统覆盖度（资源层面，如 cpu 资源等）盘点当前已应用的监控点及其价值
2.检查是否已有监控中是否有由于迭代等因素，已经废弃的监控点，或者是有影响到正常排查问题思路的监控点，已经失去监控的价值的，可以废弃
3.检查是否有核心功能或核心数据等没有监控起来，出现问题的时候往往都是用户反馈才发现，补全监控点
4.检查告警机制是否到位，是否出现确实有监控起来但没有很好的反馈到需要关注的相关人员处，补全告警机制
首先讲一下系统监控，如下图
系统监控更多的是关注业务系统所在的环境及其资源的情况，简单理解就是能让系统正常运行起来的先决条件的监控，这里将系统监控分为资源层，基础架构层，数据层以及依赖方
资源层会关注运行环境的硬件等资源，如 cpu，内存，磁盘的使用率以及网络流量等，这也是通用的监控点，同时也是会中间网络服务监控起来，比如 DNS 的访问，保证域名等有效性，是否负载均衡，机器流量分布不均会导致业务流程阻塞，资源也未必很好地利用起来，中间件如一些消息服务是否有出现消息堆积等情况
基础架构层会关注实现业务系统的技术底层运行情况,以 java 开发的系统为例，比如 jvm，一般会对其线程进行监控，如线程占用的内存，内存回收机制是否正常，是否有内存泄漏，同时在方法区，方法的调用情况是否正常，堆栈使用是否合理，代码逻辑异常时是否有正常抛出，日志是否清晰等等
数据层为关注数据库读写情况，比如 proxy 连接数是否在运行范围内，慢查询的数量，数据量的大小以及表的大小会影响读写情况，在一些耗时超时的跟踪上是可以通过监控手段跟踪起来
依赖方这里更多的是关注调用情况，调用链路是否正常，是否有越权调用的情况，调用耗时等各种方面
不同的业务系统有不的监控方式，这里只例举一些通用的场景，如下图：
业务监控主要关注两个方面，就是系统功能以及数据
监控点都梳理情况之后，就可以设计监控实施的方案，这里会涉及需要用到的工具或技术栈，以及对于的一个预警方案和救火方案，可以通过这几个明细项去设计实施方案
1.监控层：比如系统监控中的运行环境资源
2.监控项：比如系统监控中的运行环境资源中的 cpu，内存等
3.监控点：比如网络使用中的网络 io，网络连接数据，丢包率、重传率等
4.监控工具（方案）：其实就是应用在这个监控点上具体的工具或者是方法
5.预警策略：当监控工具将对应的监控点都监控起来，我们就能得到相关的数据，依据数据或信息设置一些预警策略，在业务层面上，比如当库存少于 XXX 量时，就告警，系统层面上比如磁盘使用率超过 90% 时就告警
6.告警载体：如以邮件，钉钉等方式通知到关注方
7.关注方：如前文所说
举个实际的例子，如下图
上图通过上述的一部分监控类型举例如果是设计监控方案落地，大家可以参考一下
在监控工具（方案）上面，上述是通过一些点去选择具体的工具或方案，但尤其是在系统监控方面，一个个点用工具去实施维护肯定是不切实际的，现在行业里面也有很多具体的方案或工具可以全面的对系统方面进行监控，比如新型监控告警工具Prometheus，像利用Prometheus+Grafana搭建起监控运维平台，就基本上面可以满足系统监控的实施需求
