我们为什么需要监控?
众所周知,几乎所有的应用程序通常都是运行在一个大型动态的环境上,它们依赖于成百上千台主机。当然,这样的方式非常有利于扩展,能够保证良好的用户体验。但是,对运维和业务人员来说,这简直就是「噩梦」,那些传统的监控方式已经跟不上云时代的要求了。
首先,人类已经很难从大规模海量的数据中识别出那些有问题的节点;其次,服务器本身也在不断的变化——根据企业的需求进行动态的拓展或者缩减,单个主机经常会出现响应问题;所以,区分出哪些服务器是否处于一个正常的状态并不是一件很简单的事情。那么,我们就需要一个现代化的监控平台:
第一,必须能够毫不费力地跟踪我们所有的服务器,并且能够在数据量激情的情况下保持稳定;
第二,必须能够分辨出那些可执行程序,尽可能少出现误报问题,还要避免「兴师动众」,反而忽略更重要的问题;
第三,必须能够收集足够多的信息,使我们能够快速诊断出问题发生的根本原因,当然,这也意味着我们的监控平台应该与关键技术相互配合;
第四,应该还能收集详尽的数据以供我们进行分析,并能保留长期的数据用于对未来趋势的预测;
第五,必须能够让我们监控到所有的主机状态,同时也能监测到特定属性的主机。
最后一点,这个作为我们「操作神经中枢」的监控平台,必须能够帮助我们的团队高效地发现潜在问题的信息,如果有一个可视化的仪表板那就更好了,这样就可以有助于我们进行快速、明确的团队沟通。
严格来说,线上的服务器没有监控,是不允许上线的,在真实的生产环境中,我们运维工作,需要时时刻刻了解我们线上平台的运行状态,服务器出现故障的时候方便我们更直观的去依靠监控平台去排除问题。
运维工作就是大部分时候都是通过各种工具来让我们完成特定的任务, 监控也是如此, 目前也有很多开源的监控软件可供我们使用
常见的开源监控简单介绍
Zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。能监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位,解决存在的各种问题。
Zabbix 由两部分构成,Zabbix server 与可选组件 Zabbix agent,Zabbix server 可以通过 SNMP,Zabbix agent,ping,端口监视等方法提供对远程服务器/网络状态的监视,数据收集等功能,它可以运行在 Linux、Solaris、HP-UX、AIX,Free BSD、Open BSD以及OS X 等平台上。
Zabbix 主要功能包括: CPU 负荷,内存使用,磁盘使用,网络状况,端口监视,日志监视等等。
Nagios 是一款开源的免费网络监视工具,能有效监控 Windows、Linux 和 Unix 的主机状态,交换机路由器等网络设置,打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员,在状态恢复后发出正常的邮件或短信通知。
Nagios 可以监控的功能包括:监控网络服务;监控主机资源;简单地插件设计使得用户可以方便地扩展自己服务的检测方法;并行服务检查机制;具备定义网络分层结构的能力;报警「通过 EMail、短信、用户定义方式」;定义一些处理程序,使之能够在服务或者主机发生故障时起到预防作用;自动的日志滚动功能;支持并实现对主机的冗余监控;可选的 WEB 界面用于查看当前的网络状态、通知和故障历史、日志文件等。
Zabbix是一个基于web界面的分布式系统监控的企业级开源软件。可以监视各种系统与设备的参数,保障服务器及设备的安全运营。
Zabbix的功能和特性
(1)安装与配置简单。
(2)可视化web管理界面。
(3)免费开源。
(4)支持中文。
(5)自动发现。
(6)分布式监控。
(7)实时绘图。
1. Zabbix Server:负责接收Agent发送的报告信息,组织所有配置、数据和操作。
2. Database Storage:存储配置信息以及收集到的数据。
3. Web Interface:Zabbix的GUI 接口,通常与Server运行在同一台机器上。
4. Proxy:可选组件,常用于分布式监控环境中。
5. Agent:部署在被监控主机上,负责收集数据发送给Server。
默认情况下zabbix包含5个程序:
zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server,另外一个zabbix_java_gateway是可选,这个需要另外安装。下面来分别介绍下他们各自的作用。
(1)zabbix_agentd:客户端守护进程,此进程收集客户端数据,例如cpu负载、内存、硬盘使用情况等。
(2)zabbix_getzabbix工具:,单独使用的命令,通常在server或者proxy端执行获取远程客户端信息的命令。通常用户排错。例如在server端获取不到客户端的内存数据,我们可以使用zabbix_get获取客户端的内容的方式来做故障排查。
(3)zabbix_senderzabbix工具:,用于发送数据给server或者proxy,通常用于耗时比较长的检查。很多检查非常耗时间,导致zabbix超时。于是我们在脚本执行完毕之后,使用sender主动提交数据。
zabbix_serverzabbix服务端守护进程。zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway的数据最终都是提交到server
备注:当然不是数据都是主动提交给zabbix_server,也有的是server主动去取数据。
(4)zabbix_proxyzabbix:代理守护进程。功能类似server,唯一不同的是它只是一个中转站,它需要把收集到的数据提交/被提交到server里。为什么要用代理?代理是做什么的?卖个关子,请继续关注运维生存时间zabbix教程系列。
(5)zabbix_java_gateway:zabbix2.0之后引入的一个功能。顾名思义:Java网关,类似agentd,但是只用于Java方面。需要特别注意的是,它只能主动去获取数据,而不能被动获取数据。它的数据最终会给到server或者proxy。
1、主机(host):要监控的网络设备,可由IP或DNS名称指定;
2、主机组(host group):主机的逻辑容器,可以包含主机和模板,但同一个组织内的主机和模板不能互相链接;主机组通常在给用户或用户组指派监控权限时使用;
3、监控项(item):一个特定监控指标的相关的数据;这些数据来自于被监控对象;item是zabbix进行数据收集的核心,相对某个监控对象,每个item都由”key”标识;
4、触发器(trigger):一个表达式,用于评估某监控对象的特定item内接收到的数据是否在合理范围内,也就是阈值;接收的数据量大于阈值时,触发器状态将从”OK”转变为”Problem”,当数据再次恢复到合理范围,又转变为”OK”;
5、事件(event):触发一个值得关注的事情,比如触发器状态转变,新的agent或重新上线的agent的自动注册等;
6、动作(action):指对于特定事件事先定义的处理方法,如发送通知,何时执行操作;
7、报警升级(escalation):发送警报或者执行远程命令的自定义方案,如每隔5分钟发送一次警报,共发送5次等;
8、媒介(media):发送通知的手段或者通道,如Email、Jabber或者SMS等;
9、通知(notification):通过选定的媒介向用户发送的有关某事件的信息;
10、远程命令(remote command):预定义的命令,可在被监控主机处于某特定条件下时自动执行;
11、模板(template):用于快速定义被监控主机的预设条目集合,通常包含了item、trigger、graph、screen、application以及low-level discovery rule;模板可以直接链接至某个主机;
12、应用(application):一组item的集合;
13、web场景(web scennario):用于检测web站点可用性的一个活多个HTTP请求;
14、前端(frontend):Zabbix的web接口;
Zabbix的流程图,其串联了各术语之间的关系
Zabbix的监控架构
常用的监控架构平台
1.server-agebtd模式:
这是最简单的架构,常用于监控主机较少的情况。
2.server-proxy-agentd模式:
这个常用于比较多的机器,使用proxy进行分布式监控,有效的减轻server端的压力。