前言：设计一个监控系统从哪入手呢？
前篇已经提到过监控系统的重要性，那么一个较为良好的监控系统应该从哪几方面上手的呢？我个人理解可以通过以下几个方面入手：
- 评估业务类型，架构体系；
- 分类监控；
- 监控技术方案选型；
- 监控人员规划；
- 监控系统的部署；
- 数据采集；
- 监控数据分析与算法；
- 系统测试；
- 自动化管理；
- 图形化展示。
大致从以上几点开始，下面我们简单来介绍上面所说。
1、评估业务类型与架构体系
当下各个企业的产品不同，业务方向不同，程序代码不同，系统架构更不同，对于各个地方的细节都需要有一定程度的认知才可以开启设计的源头。
比如，我们以系统架构为例，如果你是老牌服务 VS 微服务 我相信面向服务的监控体系一定会比面向主机监控更加顺畅的多；又比如Python亦或者Java，更甚者PHP都有着不同的监控体系，所以这里要根据自身情况相结合进行合理的选择。
2、分类监控
分类监控，我们将需要的监控项进行整合分类便于后期管理实施的便捷性，那么一般可分为：业务级别监控、系统级别监控、网络监控、程序代码监控、日志监控、用户行为分析监控、其他种类监控。
举例来如，如下：
- 业务监控： 包含 用户访问QPS, DAU日活, 访问状态, 业务接口等
- 系统监控： 主要是跟操作系统相关的 基本监控项 CPU/内存/硬盘/IO/TCP/带宽 等
- 网络监控： 对网络状态的监控，丢包率，延迟 等
- 日志监控： 监控中的重头戏，往往单独设计和搭建，全部种类的日志都有采集的需求；
- 程序监控： 一般需要和开发人员配合，程序中嵌入各种接口直接获取数据；
3、监控技术的方案
目前各种监控软件层出不穷，包括开源的、商业的、自行开发的等几百种的可选方案；选取呢应该针对企业的架构特点，大小，种类，人员多少 等等 选取合适的技术方案，而不应该熟悉那个则上那个，那样可能会给后期扩展升级带来巨大的挑战。
4、监控人员
运维团队自身就应该将相关任务进行消化掉，同时划分相关项目功能模块，责任到人；中间不免需要开发团队的配合，很多监控设计的工作，也需要寻求开发人员配合才可以进行。
5、监控系统的部署
监控系统首选需要评估，存储周期，高可用问题，以及多AZ（多机房，多可用区）问题，根据存在的这个问题我们进行选择部署形式。
6、数据采集
目前来说，数据采取形式多为Agent采取；工具多为一下几种：
- Shell：最快速清亮，不带有复杂逻辑的监控，最适合Get系统参数，或者搭载服务器上的应用参数；
- Python：运维人员的必备语言，模块非常多适合很多的复杂逻辑，但是Agent部署太重；
- awk：Linux的文本处理工具，一般搭配Shell使用；
- lua：嵌入式监控首选，比如：OpenResty；
- Go：未来有晋升为运维必回的另一门高性能语言了，客户端非常轻量，缺点：目前相关库还不够完善；
- 其他：。。。。
数据采集一般分为两种形式：
- 频率性采集：每隔多长时间获取下对应监控项的数值；
- 持续性采集：多用于网络监控，Log监控；
7、监控数据分析和算法
如果你不配置对数据的分析（有些分析需要算法的加持），那么存放在哪里的只是一堆没用的数据；当我们能够把数据转化成为监控公式与报警的阈值才能发挥出监控本该有的意义。
比如：CPU状态，传统监控多为采用系统负载load来判断系统繁忙状态， 那你如何确定是用户态还是系统态，以及更多的信息呢？ 假如我们通过算法对CPU使用情况统计5分钟的增长比率超过0.8，同时持续了30分钟呢？是不是比load更加可以清晰呢。
8、监控稳定测试
不管采集形式如何，只要运行才Linux上，多会对系统有或多或少的影响，所以稳定性测试，就是通过一段时间的观测，确保能平滑上线。
9、自动化管理
随着业务量增大，机器、服务增多我们就需要对监控值进行管理以及Agent的扩展等问题，自动化的因为会很大程度上缩短我们对监控系统的维护成本。
我这里推荐: Ansible，有兴趣的小伙伴可以了解下。
10、图形化
想一想酷炫的大屏；采集的数据和准备好的算法相结合，就可以做出一个非常棒的图形展示，比如：多数据源聚合展示，多源对比等等。
所以，监控成图也是很重要的一个点。
小结
上面扯了一堆，其实我们需要结合自身实际情况以及未来的发展趋势来做设计即可。