聊系统监控的时候我们在聊什么 监控聊天记录违法吗

现在的互联网产品功能越来越强大，需要的服务也越来越多，我们在手机APP上的一个简单的操作可能会对应服务端的一长串链路，就拿简单的发朋友圈这个功能来说，我们发送朋友圈后服务端需要解析请求的合法性，权限校验，流控校验，图片上传，入库，写缓存，推送到朋友的朋友圈列表等等，在这个链路中任何一个环节都有可能出问题，任何一个环节出问题都可能导致影响产品的正常使用，导致公司经济上和形象上的损失，但是由于服务端的复杂度越来越高，出现问题的原因也是多方面的，比如硬件故障，软件故障，数据库故障，或者代码bug等等，所以再牛逼的公司也没法保障系统完全没有问题，也就是说故障只能尽可能减少，而不可能能完全消除，既然如此，我们能够做的是尽可能的保证服务的稳定性，要保证服务的稳定性就必须能够在出现问题后尽快解决。

那么问题来了，如果知道目前的服务出了问题呢？靠用户反馈？肯定晚了，一般都是大批量故障的时候才会在网上“火”起来，靠人工？更不靠谱，现在的服务基本都是要保持7*24小时的，而且产品的功能是五花八门的，不可能有人专门去一直试各种功能，所以最好的办法当然还是依靠机器来监控，那么应该如何监控呢？

首先我们先梳理一下系统的部署方式，最底层肯定是服务器以及操作系统，然后是自己的应用系统，然后我们的业务代码会依赖很多外部的服务，比如MySQL，MQ，Redis等，按照这个分类我们大致可以把系统监控分为3大类：

1.运行环境

服务器的cpu，内存，硬盘等

2.依赖服务

入口层：SLB，nginx等

中间件：MQ，注册中心，配置中心，日志中心等

存储服务：数据库，缓存等

3.应用系统

接口请求耗时，接口错误率等

看起来好像比较全了，基本能覆盖大部分场景，但是这里要提醒一句，这里的监控都是技术层面的监控，试想一个场景，比如因为某种原因（eg：DNS被劫持）导致用户的请求没法正常的请求到我们的服务器，按照我们目前的监控其实是感知不到这些问题的，因为我们的服务是运行正常的，没有请求进来，所以无法感知到此类问题，所以业务监控也显得格外重要，我们可以指定一些核心业务指标，比如订单量或者接口调用量等，找一个合理的阈值，这样可以在出现问题后及时感知并处理。

作为一个从业人员，实现业务需求只是其中的一部分，如何稳定的提供服务是我们更应该去思考的，所有的大厂都会把系统监控作为重中之重，投入的精力甚至不亚于在业务开发上的投入，在监控这个领域没有最好只有更好，今天写此文分享一下自己的心得，后续有精力再细化一下各种监控应该如何落地，希望能给大家带来帮助。