在IT世界里，和系统相关联的有研发、测试、运维、产品、运营、客服、用户等，我们如何保证系统稳定运行？之前我也讲过了系统高可用，其中的有一点就是监控，它能让我们及时发现问题，不至于被动地等着用户来反馈。尤其是在互联网行业里，系统都是7*24小时可用的。所以我们的监控目标就是：
24小时守护系统
监视运行状态，实时控制
统计数据，分析指标
实时报警
那么我们如何设计我们的监控系统呢？ 首先我们先确定我们的监控点：
方法性能监控：对被监控方法或代码段的执行时间以毫秒为单位进行统计分析，产生出统计参数指标供参考和作为报警依据。TP指标：TP50：指在一个时间段内（如1分钟），统计该方法每次调用所消耗的时间，并将这些时间按从小到大的顺序进行排序，取第50%的那个值作为TP50 值；配置此监控指标对应的报警阀值后，需要保证在这个时间段内该方法所有调用的消耗时间至少有50%的值要小于此阀值，否则系统将会报警。TP90，TP99，TP999与TP50值计算方式一致，它们分别代表着对方法的不同性能要求，TP50相对较低，TP90则比较高，TP99，TP999则对方法性能要求很高。
方法心跳监控：根据业务需要，假设被监控方法或代码段在一定时间内必然被执行，如果未被执行则认为此方法心跳停止，可以在系统中设置报警。系统默认在方法有调用记录的情况下每间隔20秒发送一次心跳，因此在系统中配置超时阀值次数的方法是用估量的心跳超时时间（单位秒）除以20得到的整数。
自定义监控：当应用系统根据判断达到某种情况需要报警时直接进行报警，主要应用于应用程序发生异常被捕获时发送报警通知，根据业务逻辑判断，需要报警时发出报警通知，例如某个接口调用失败，或某个业务执行失败等等。
URL存活监控：主要针对重要的url和接口进行监控，可监控对外提供的接口或者依赖的外部服务接口是否存活、响应的内容是否符合预期。
端口存活监控：主要针对重要的端口存活进行监控，可监控自身系统依赖的端口（数据库，redis，mq等）是否正常，可监控依赖服务的端口是否正常。
系统存活监控：用于监控实例进程是否存活，当进程异常退出时会发出报警。
JVM监控：用于实时监控java应用虚拟机资源使用情况，并根据自定义的报警预警规则进行分析进行报警。监控的服务有：监控JVM的CPU，堆和非堆内存使用情况，Full GC，Young GC情况，JVM开启线程数，提供实时的数据展示。
服务器性能监控：针对应用部署的服务器的基础性能进行监控，监控服务器CPU，内存，磁盘使用情况、服务器负载，网络IO，TCP链接数，探活等服务
业务监控：用于监控具体的业务运行情况，根据传入的数据进行分析展示和报警。
下面介绍下在上个公司设计的一套监控平台，参考京东的监控平台，不过我们数据量没那么大，设计的相对简单些。
profiler-sdk主要为接入监控平台的应用提供调用接口，应用系统通过调用这些接口将分别产生预定格式的性能、心跳、自定义日志、jvm日志以及业务监控日志，并分别将这些日志信息写入后缀为tp.log，alive .log，business.log及jvm.log,biz.log等文件日志文件。
用filebeat作为日志采集器，虽然Logstash功能强大，但是它依赖java、在数据量大的时候，Logstash进程会消耗过多的系统资源，这将严重影响业务系统的性能，filebeat用go语言开发，占用系统资源少。
数据接收中心从Kafka中分类获取各业务系统产生的日志，对接收到的日志信息进行解析，对于不满足格式要求的日志则直接抛弃，jvm的报警分析在接收中心直接处理，通过web配置的阈值配置日志进行jvm运行情况分析，如果达到报警规则，则直接进行报警处理，存储数据到到redis，hbase，mysql中，供接收中心和前端展示使用
任务调度中心从数据库中取出要下发任务的详细信息并缓存，任务调度中心从数据库中取出要下发任务的时间频率并缓存，根据每一个任务下发的时间频率开启timer，每一个任务timer开始执行的时间为一个整点分钟数，按照一定的时间频率把任务下发到MQ中
数据分析中心从MQ中获取任务（分析存活监控这种任务类型，其他的类似），任务内容中包含监控点的基本信息和报警规则等信息，分解获取的任务，开始进行访问监控点的工作（http/socket），判断是否符合报警规则，如符合则调用报警接口并进行报警，存储每次访问的数据信息到数据库（存活监控记录表）
业务方接入很简单，只需引入profiler-sdk，在想要监控的方法上加一行注解即可，在web管理端，我们可以看下效果
方法层面的阈值设置和监控效果：
JVM层面的阈值设置和监控效果：
推荐阅读：
想要交流的朋友可以关注我公号，加我微信进读者群。