TL;DR（太长勿念）如果要实现统一监控，需要做到以下几点。阿里云有日志服务，开源有ELK。1.全链路调用的唯一ID2.标准化日志3.管理方案4.监控行情5.报警方案前言没有监控预警系统，我们基本上只是猜测。例如，如果没有客户投诉，那么系统可能运行良好。这是胡说八道，作为一个合格的工程师是不允许这样的事情发生的。投入一定的资源建设监控告警有什么好处？最大的好处就是知道依赖了多少服务，依赖了多少第三方服务，QPS是多少，接口的平均RT是多少，成功率是多少，失败是多少速度？每个错误码的分布情况如何，一旦超过了阈值，是否能够比较及时的到达开发运维人员手中。有了监控，我们可以随时更全面地了解我们的系统，进行更全面的控制。有了报警器，我们就可以在遇到问题的时候第一时间感知和干预。我们需要解决这些问题。每个公司、每个平台的技术实力和经济实力都不一样，所以解决方案也大不相同。这些可能是我们开发人员需要额外花费时间的事情。无论是一次性的营销方案还是长期运行的系统，我们都需要准备监控告警方案。用金钱换取时间，用时间换取金钱，这才是我们需要权衡的。当然，准备计划基本相同。这里我只讲接口层面的监控。其他关于数据库、JVM、消息队列、分布式缓存、tomcat线程、主机CPU磁盘网络等不在本次讨论范围之内。这些都需要更高层的聚合服务来实现监控，监控逻辑几乎是一样的。监控告警这五个部分想要实现统一监控，无外乎要做以下几件事，但是每一个都非常难，也很重要。1.全链路调用唯一ID2。标准化日志3。点计划4。监控市场5。报警计划1。全链路调用唯一ID判断某条调用链的调用过程，在故障排查溯源过程中保证溯源过程的准确性。比如我们有5个系统，如果没有这个唯一ID，我们跨5个系统的时候，就必须依赖时间、订单、人员等业务维度来确定调用链路。只有两个字，低效。正确的方案是在调用开始时生成一个几乎全局唯一的ID，然后在调用过程中不断传递给下游和分支，然后让下游链式传递给下游。比如Java中的处理方案。所有的接口输入参数都加上一个traceId，然后放在ThreadLocal中，方便随时随地记录日志。2.标准化日志如果需要最终统一分析，我们在打日志的过程中就需要对日志进行标准化和统一。每个人的全局日志格式都是一样的，所以我们最后的分析会比较简单。一个更可行的标准化日志方案如下所示。3.规范点方案的返回值。核心是返回值。具体可以参考PlananBanana的三个Java私房菜No.131中ResultExecutor+ResultDTO的组合。核心是标准化所有的输出参数，使AOP打印标准化。对于日志来说，核心价值是succ和code。将返回值标准化后，我们就可以对返回值进行管理，也就是第二步。AOP切面我们会用切面的方式来管理日志，比如调用提供的服务接口前后，调用数据库前后，调用公共缓存服务前后，调用消息中间件前后。如果是Java，建议使用AspectJAroundAdvice，可以增加统计rt（响应时间）。日志文件规划可以标准化为rpc_access.log（内部服务）、http_access.log（http类型服务，有登录状态）、proxy_access.log（代理调用外部服务）、db_access.log（db类型日志）。这种分类有两个优点。一是排查问题时可以有针对性地缩小调查范围，二是在最后做日志聚合时可以有针对性。当然，这么多日志，我们肯定会考虑是否真的会影响服务性能？这是第三步。Rollinglog&asynchronousappender我们每天都有海量的访问量。如果一直打log的话，不管机器多大，基本是不够用的，所以我们可以使用滚动log的方式，比如Java下的slf4j2。至于logging，其实就是一个磁盘IO的过程。如果这个进程比较大，可能会影响服务的rt。如果我们把它做成一个异步appender，那么我们的日志记录过程就会影响原来的服务。几乎可以忽略不计。那么，打印出来的日志是不是应该保存在本地呢？显然是不合适的。按照一定的策略，一定要有归档归档的地方。archivedatabases等归档数据库的编写其实有两种选择。第一种是使用SDK来编写。二是安装代理，定期扫描文件并上传到存档数据库。替代解决方案可能包括ElasticSearch、SLOG、时间序列数据库、HBase、Graphite和其他NOSQL数据库。强烈建议不要放在关系型数据库中。毕竟日志量太大了。不管放到哪个关系型数据库中，最终的结果都只会因为基础数据量太大，几乎任何查询都会失败。不能继续了。4.Graphite，一个用于监控市场的开源解决方案，做了两件事：存储数字时间序列数据按需渲染这些数据的图形这些数据以图表的形式显示。由于安装使用过程比较复杂，请自行阅读。https://www.infoq.cn/article/graphite-intro/ELK(ElasticSearch+Logstach+Kibana)这里的监控面板主要使用了Kibana的自定义视图能力，要求是数据必须写入ElasticSearch。高成本方案阿里云SLOG日志服务SLOG是阿里云提供的日志服务。只要将数据以key-value的形式写入SLOG，就可以自定义配置一些监控盘。一定数量内免费。所以如果量不大，技术实力不强，可以试试这个方案。当然，如果你有一定的资金，SLOG本身其实也不算太贵，可靠性和性能都非常强。除了官方的方法，你也可以连接自定义的日志平台或监控平台，通过API查询监控数据，并展示出来。高科技解决方案Flink实时计算这里主要使用的是Flink基于窗口的聚合能力，可以对大批量的流式数据进行聚合，然后将聚合结果输出到某个库，提供一定的大规模能力，比如双十AGMV计算的大屏幕。优点是定制性非常非常强，性能可以很好的调优定制。缺点是技术强度可能比较高，基本上每个需要监控的点都需要代码开发。5.告警解决方案高成本解决方案阿里云SLOG日志服务本身也提供了告警功能，具体可以到官网查看。这里的高科技方案主要针对自制力强的队伍。告警服务可以自行开发。主要技术手段是按照一定的聚合方式定时从时序数据库中查询，然后触发告警。当然，如果技术实力足够，也可以组装一定的规则引擎和配置能力来支持开发者的devOps，即告警的定制。联系方式出现报警后，我们当然希望能够准确快速的联系到相应的人员。一般来说，我们的联系方式可以包括钉钉群机器人、企业微信群机器人、邮件、电话、短信等。这些方法实现起来都比较方便。我们需要考虑的一点是需要触发什么样的告警。比如闹钟持续1分钟，就用一组机器人，重要的话就用短信。如果报警持续5分钟未关闭，则电话联系以自动语音播报的形式进行。总结一下为什么很多开发人员上线后感觉心慌，因为这些工程师对系统的性能没有概念，无所事事，没有控制能力。这就是我们监控和告警所需要的。监控是让我们对系统有一定的控制能力，报警是让我们不能时时刻刻盯着所谓的行情。以上都是我们在开发完成或者刚开始开发时需要考虑的，需要计入项目工作量（当然，如果项目经理不关心这个，你需要向他申报。或者给自己预留一定的缓冲区用于监控告警建设）。哪里需要管点，打什么样的点，怎么监控，需要告警什么内容。作为一名合格的工程师，这是一项非常非常值得提高效率的投资。一个没有监控的系统就废了一半。你敢上网吗？
