最近刚离职，新公司还没去报道，就整天赋闲在家看看书写写技术文章。
下午和某个微信群的群友聊起互联网公司的监控系统，简短的描述了一些我的看法。
正好最近有空，这篇文章就来聊聊我自己在职业生涯里使用过以及了解过的一些监控系统，当做一篇小白扫盲或者个人漫谈就好。
基础必知
要对监控有个全面的了解，大体要了解三方面的知识，如下图所示：
一般在企业级技术监控领域，大体分为五种类型的监控：
基础监控：包括带宽、CDN、服务器CPU、Memory、DiskIO、Network、Load5等指标；
指标监控：服务+接口维度，常见指标有QPS、TPS、SLB、RT、99RT、timeout、activethreads等指标；
业务监控：拿电商来说，常见的有同比下单量、支付量、履约率、DAU、GMV、支付取消率等多重指标，一般需要根据具体的业务需要来定制化；
链路监控：链路监控主要用来快速定位排查问题，在目前大多数互联网公司的微服务架构下，服务调用关系复杂，链路追踪监控可以帮助技术同学快速的找到调用链路上某个环节的问题；
舆情监控：主要指对外部的一些讯息的监控，比如某APP突然挂了、下不了单、有BUG可以刷单、客诉等一些列对企业或者品牌不利的因素，便于快速处理甚至公关；
处理过程及注意点监控从采集到告警通知，大体分为五个步骤，每个步骤的注意事项各有不同又有部分通用的考虑。
数据采集
释义说明：通过各种方式采集原始的相关数据，常见的有agent、埋点等方式；
注意事项：主要为数据采集对业务服务的性能损耗以及对业务的侵入性两点：
一般采样都是百分比采样，比如10%，如果100%采样，对业务服务的性能损耗会比较大；
良好的监控系统，对业务来说应该是无感知的，能快速接入又不影响正常的业务迭代；
数据存储
释义说明：采集到的原始数据需要进行存储，以便于进行后续的聚合计算；
注意事项：这里需要注意的点为存储时间和成本控制两方面：
存储时间：大多场景只关注最近一周或最近一个月，但有时候为了审计安全等需要，部分数据需要存储的时间会比较长，甚至有1-2年，因此需要根据具体情况来设定数据过期和清理时间；
成本控制：有些场景对数据的实时性要求比较高，因此需要存储到高速SSD，有些场景数据实时性没那么高，就可以考虑更低成本的存储方式，甚至做数据归档，然后离线计算的方式来进行后续的计算；
数据计算
释义说明：通过对采集到的原始数据进行各种维度的计算，才能得到我们想要的监控指标；
注意事项：数据计算这一环节，主要考虑的点为计算速度和结果的准确性：
计算速度：上面提到了，某些场景对于数据的实时性要求较高，因此在计算环节就需要考虑到这点。在具体的技术方案实现过程中，需要根据不同的业务需要来采用不同的技术选型和实现；
数据准确：比如上面提到的每分钟订单量，以及履约率、错误率等指标，对准确度要求是比较高的。再比如QPS这种指标，如果实时计算，对服务压力比较大，但如果取单位时间的均值，又会造成结果的准确性降低，因此在实际实践过程中，需要综合考量。
数据展示
释义说明：即通过界面动态可视化的方式，将我们关注的监控指标进行展示。
注意事项
时延：时延这部分，上面已经阐述过了，主要还是要考虑到具体的业务场景，灵活采用技术方案；
便捷：监控是个很复杂庞大的体系，但对使用者来说，往往只关注和自己有关的模块，因此便捷可定制化的展示，良好的界面，是很需要下功夫去设计的。
告警通知
释义说明：将已发生的或者即将发生的错误异常及时通知给相关同学，快速处理，降低影响。
注意事项
时延：告警是需要及时的做到通知的，因此对实时性要求很高。