监控是运维的第一道防线，业务系统可以不做运维自动化，甚至可以不做DevOps，但一定不能不做监控。监控是业务的“眼睛”，能让对应的异常问题在第一时间被发现，只有这样我们才能第一时间去解决问题。运维工作做的好不好，更多的是看监控有没有加好。下面是从传统环境到云环境各种监控方案使用的场景及特点介绍。
1、脚本监控
应用场景
通过Shell或者Python脚本，甚至Java、PHP来完成监控需求。这个监控解决方案一般用于不懂运维的研发人员，他们一般没听说过监控系统，也不知道用什么监控系统，所以就用自己擅长的开发语言，来完成日常的监控需求。
特点介绍
主要做些系统基础监控指标（CPU/内存/网卡/磁盘）报警。缺乏中间件、应用层监控。缺乏监控数据存储、数据查看等监控集中化管理平台。
2、Nagios监控
应用场景
IT基础架构监控的行业标准，主要应用在主机系统、交换机路由器等网络设备的监控上。
特点介绍
主要偏向做主机系统、交换机路由器等网络设备的监控。偏向主机层面监控，比如在Nginx、Tomcat等应用中间件性能方面监控偏弱。监控数据的图形展示效果很差。很多功能通过插件化来实现，对技术能力要求很高。
3、Nagios+Cacti监控
应用场景
Cacti是一套基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。Cacti可以单独部署使用用以监控网络流量，监控数据图形界面展示效果比较好。整合Cacti和Nagios是利用了Cacti的一个插件Nagios for Cacti（NPC），它的原理是将Nagios的数据通过ndo2db导入到MySQL数据库（Cacti的库）中，然后Cacti读取数据库信息将Nagios的结果展示出来。
特点介绍
Cacti的良好数据展示，弥补了Nagios监控软件的不足，但监控的内容和Nagios是一样的。
4、Zabbix监控
应用场景
Zabbix不仅仅能做Nagios主机、网络设备层面的监控，还能满足企业级其他方面的监控需求，用于监控中间件、日志。有完善详细的API，支持企业级定制化开发。可以通过API把Zabbix集成在其他运维自动化平台中。
特点介绍
资料丰富，入门简单，有完善的社区支持，有详细的报表图标绘制，支持自动发现网络设备和服务器，支持分布式集中管理、管理监控点。但是Server端的数据存储用的是以MySQL为主的关系型数据库，Server端存在很严重的性能问题。需要在监控的目标主机中安装Agent，这样将会存在安全隐患。同时对容器监控支持还在持续完善。
5、云监控
应用场景
云监控（CloudMonitor）是一项针对阿里云资源和互联网应用进行监控的服务。云监控是一项针对阿里云资源和互联网应用进行监控的服务。
特点介绍
提供自定义查看监控数据的功能，可以在一张监控大盘中跨产品、跨实例查看监控数据，将相同业务的不同产品实例进行集中展现。
提供跨云产品、跨地域的云产品资源分组管理功能，支持从业务角度集中管理业务线涉及的服务器、数据库、负载均衡、存储等资源。
提供云产品服务各类异常事件的报警功能，也支持自定义事件类型数据的上报、查询、报警功能。
开源中间件之类的监控，需要通过自定义监控调用云API来完成，有一定的研发要求，监控门槛较高。
6、Prometheus+Grafana监控
应用场景
监控系统&时序数据库，Prometheus是一个监控系统，并没有和关键字IT有所关联，这是因为任何监控目标，只要暴露出标准的HTTP协议的Metric数据，Prometheus就都能监控到。类似于容器监控需求，通过Prometheus很方便地就能实现，因此Prometheus被誉为容器开源解决方案的最佳实践。
特点介绍
时序数据库是典型NoSQL分布式数据库，使用它不用担心数据库的性能问题。
灵活的数据模型，特别适用于对动态灵活性高的容器的监控。
采用HTTP协议，使用pull模式拉取数据，简单易懂。
要每个中间件或者监控目标都要单独安装Export，如果有多个监控目标的话，多个监控目标对应暴露HTTP服务端口，在维护管理等方面非常不便。
Prometheus的监控项值只能为浮点数据类型，不能为字符串数据类型，这个就具有局限性了。
7、Telegraf+InfluxDB+Prometheus监控
应用场景
解决了原生态Prometheus需要安装多个Export且只能存储浮点数据类型的问题，同时也解决了TICK技术栈中在监控数据图形展示、报警通知等方面的缺陷。
特点介绍
但是该架构仅解决了主机+中间件的监控问题，无法解决以下监控问题：
云产品监控：对RDS、SLB、OSS、VPC、CDN等云产品的监控。
站点监控：站点的可用性、响应时间、延时监控。
日志监控：日志的存储、日志查询、日志监控报警。
代码监控：业务代码层次，比如Java、PHP代码层面的性能监控。
