一、监控生态
1. 概述
监控是整个运维乃至整个产品生命周期中最重要的一环,事前及时预警发现故障,事后提供详实的数据用于追查定位问题。目前业界有很多不错的开源产品可供选择。选择一款开源的监控系统,是一个省时省力、效率最高的方案。当然,对监控不是很明白的朋友们,看了以下文章可能会对监控整个体系有比较深刻的认识。
2. 监控目标
每个人由于所在的行业、公司、业务、岗位不同,对监控的理解也不尽相同,但是我们需要注意,监控是需要站在公司的业务角度去考虑,而不是针对某个监控技术的使用。
对系统不间断的实时监控:实际上是对系统不间断的实时监控(这就是监控);
实时反馈系统当前状态:我们监控某个硬件、或者某个系统,都是需要能实时看到当前系统的状态,是正常、异常、或者故障
保证服务可靠性安全性:我们监控的目的就是要保证系统、服务、业务正常运行
保证业务持续稳定运行:如果我们的监控做得很完善,即使出现故障,能第一时间接收到故障报警,在第一时间处理解决,从而保证业务持续性的稳定运行。
3. 监控方法
发现问题:当系统发生故障报警,我们会收到故障报警的信息。
定位问题:故障邮件一般都会写某某主机故障、具体故障的内容,我们需要对报警内容进行分析。比如一台服务器连不上,我们就需要考虑是网络问题、还是负载太高导致长时间无法连接,又或者某开发触发了防火墙禁止的相关策略等,我们就需要去分析故障具体原因。
解决问题:当然我们了解到故障的原因后,就需要通过故障解决的优先级去解决该故障。
总结问题:当我们解决完重大故障后,需要对故障原因以及防范进行总结归纳,避免以后重复出现。
4. 监控工具
下面我们需要选择一款适合公司业务的监控工具进行监控,。这里我对监控工具进行了简单的分类。
4.1 老牌监控如下
MRTG(Multi Route Trffic Grapher)是一套可用来绘制网络流量图的软件,由瑞士奥尔滕的Tobias Oetiker与Dave Rand所开发,以GPL授权。MRTG最好的版本是1995年推出的,用Perl语言写成,可跨平台使用,数据采集用SNMP协议,MRTG将手机到的数据通过Web页面以GIF或者PNG格式绘制出图像。
Ganglia是一个跨平台的、可扩展的、高性能的分布式监控系统,如集群和网格。它基于分层设计,使用广泛的技术,用RRDtool存储数据。具有可视化界面,适合对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已有成千上万的集群正在使用这个监控系统,可以轻松地处理2000个节点的集群环境。
Cacti(英文含义为仙人掌)是一套基于PHP、MySQL、SNMP和RRDtool开发的网络流量监测图形分析工具,它通过snmpget来获取数据使用RRDtool绘图,但使用者无须了解RRDtool复杂的参数。提供了非常强大的数据和用户管理功能,可以指定每一个用户能查看树状结构、主机设备以及任何一张图,还可以与LDAP结合进行用户认证,同时也能自定义模板。在历史数据展示监控方面,其功能相当不错。Cacti通过添加模板,使不同设备的监控添加具有可复用性,并且具备可自定义绘图的功能,具有强大的运算能力(数据的叠加功能)
Nagios是一个企业级监控系统,可监控服务的运行状态和网络信息等,并能监视所指定的本地或远程主机状态以及服务,同时提供异常告警通知功能等。Nagios可运行在Linux和UNIX平台上。同时提供Web界面,以方便系统管理人员查看网络状态、各种系统问题、以及系统相关日志等。Nagios的功能侧重于监控服务的可用性,能根据监控指标状态触发告警。目前Nagios也占领了一定的市场份额,不过Nagios并没有与时俱进,已经不能满足于多变的监控需求,架构的扩展性和使用的便捷性有待增强,其高级功能集成在商业版Nagios XI中。
Smokeping主要用于监视网络性能,包括常规的ping、www服务器性能、DNS查询性能、SSH性能等。底层也是用RRDtool做支持,特点是绘制图非常漂亮,网络丢包和延迟用颜色和阴影来标示,支持将多张图叠放在一起,其作者还开发了MRTG和RRDtll等工具。 Smokeping的站点为:http://tobi.oetiker.cn/hp。
开源监控系统OpenTSDB用HBase存储所有时序(无须采样)的数据,来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集,支持永久存储,可以做容量规划,并很容易地接入到现有的告警系统里。OpenTSDB可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的采集指标,并进行存储、索引和服务,从而使这些数据更容易让人理解,如Web化、图形化等。
4.2 王牌监控
Zabbix是一个分布式监控系统,支持多种采集方式和采集客户端,有专用的Agent代理,也支持SNMP、IPMI、JMX、Telnet、SSH等多种协议,它将采集到的数据存放到数据库,然后对其进行分析整理,达到条件触发告警。其灵活的扩展性和丰富的功能是其他监控系统所不能比的。相对来说,它的总体功能做得非常优秀。从以上各种监控系统的对比来看,Zabbix都是具有优势的,其丰富的功能、可扩展的能力、二次开发的能力和简单易用的特点,读者只要稍加学习,即可构建自己的监控系统。
小米的监控系统:Open-Falcon。Open-Falcon的目标是做最开放、最好用的互联网企业级监控产品。
4.3 三方监控
现在市场上有很多不错的第三方监控,比如:监控宝、监控易、听云、还有很多云厂商自带监控,但在这里我不打算着重介绍,如果想了解三方监控可自行上官网咨询。(避免说广告植入)。
5. 监控流程
上面介绍了这么多,到底选择什么监控工具最合适呢?我这里推荐几款开源监控工具:Zabbix、Open-Falcon、LEPUS天兔(专用于监控数据库)。但本文还是基于Zabbix来构建整个监控体系生态圈。 下面我们就来聊聊Zabbix的整个流程:
数据采集:Zabbix通过SNMP、Agent、ICMP、SSH、IPMI等对系统进行数据采集;
数据存储:Zabbix存储在MySQL上,也可以存储在其他数据库服务;
数据分析:当我们事后需要复盘分析故障时,Zabbix能给我们提供图形以及时间等相关信息,方面我们确定故障所在;
数据展示:Web界面展示、(移动APP、java_php开发一个Web界面也可以);
监控报警:电话报警、邮件报警、微信报警、短信报警、报警升级机制等(无论什么报警都可以);
报警处理:当接收到报警,我们需要根据故障的级别进行处理,比如:重要紧急、重要不紧急,等。根据故障的级别,配合相关的人员进行快速处理。
6. 监控指标
上面了解了监控方法、目标、流程、也了解了监控有哪些工具,可能有人会疑惑,我们具体要监控些什么东西,在这里我进行了分类整理,包含硬件监控、系统监控、应用监控、网络监控、流量分析、日志监控、安全监控、API监控、性能监控、业务监控。
6.1 硬件监控
早期我们通过机房巡检的方式,查看硬件设备灯光闪烁情况判断是否故障,这样非常浪费人力,并且是重复性无技术含量的工作,大家懂得。
当然我们现在可以通过IPMI对硬件详细情况进行监控,并对CPU、内存、磁盘、温度、风扇、电压等设置报警设置报警阈值(自行对监控报警内容编写合理的报警范围) 。
IPMI监控硬件服务参考资料:Zabbix IPMI Interface
6.2 系统监控
中小型企业基本全是Linux服务器,那么我们肯定是要监控起系统资源的使用情况,系统监控是监控体系的基础。
监控主要对象:
CPU有几个重要的概念:上下文切换、运行队列和使用率。这也是我们CPU监控的几个重点指标。
通常情况,每个处理器的运行队列不要高于3,CPU 利用率中用“户态/内核态”比例维持在70/30,空闲状态维持在50%,上下文切换要根据系统繁忙程度来综合考量。
针对CPU常用的工具有:htop、top、vmstat、mpstat、dstat、glances。Zabbix提供系统监控模板:Zabbix Agent Interface。
CPU整体状态
上下文切换
负载状态
内存:通常我们需要监控内存的使用率、SWAP使用率、同时可以通过Zabbix描绘内存使用率的曲线图形发现某服务内存溢出等。
针对内存常用的工具有:free、top、vmstat、glances。
内存使用率
IO分为磁盘IO和网络IO。除了在做性能调优我们要监控更详细的数据外,日常监控只关注磁盘使用率、磁盘吞吐量、磁盘写入繁忙程度,网络也是监控网卡流量即可。
常用工具有:iostat、iotop、df、iftop、sar、glances。
磁盘使用率
磁盘读/写吞吐
网卡进出口流量
TCP的11种状态信息
其它系统监控还有运行的进程端口、进程数、登陆用户、Open File等(详细查看Zabbix自带OS Linux模板)。
6.3 应用监控
把硬件监控和系统监控研究明白后,我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务,都需要监控起来。
应用服务监控也是监控体系中比较重要的内容,例如:LVS、HAProxy、Docker、Nginx、PHP、Memcached、Redis、MySQL等,相关的服务都需要使用zabbix监控起来。
nginx_status
PHP-FPM_status
Redis_status
JVM监控
- Zabbix提供应用服务监控:Zabbix Agent UserParameter
- Zabbix提供的Java监控:Zabbix JMX Interface
- Percona提供MySQL数据库监控:percona-monitoring-plulgins
6.4 网络监控
作为一个针对全国用户的电商网站,时刻掌握各地到机房的网络状态也是必须的。
网络监控是我们构建监控平台是必须要考虑的,尤其是针对有多个机房的场景,各个机房之间的网络状态,机房和全国各地的网络状态都是我们需要重点关注的对象,那如何掌握这些状态信息呢?我们需要借助于网络监控工具Smokeping。
Smokeping 是rrdtool的作者Tobi Oetiker的作品,是用Perl写的,主要是监视网络性能,www服务器性能,DNS查询性能等,使用rrdtool绘图,而且支持分布式,直接从多个agent进行数据的汇总。
同时,由于自己监控点比较少,还可以借助很多商业的监控工具,比如监控宝、基调、博瑞等。同时这些服务提供商还可以帮助你监控CDN的状态。
监控宝
6.5 流量分析
网站流量分析对于运维人员来说,更是一门必须掌握的知识了。比如对于一家电商公司来说:通过对订单来源的统计和分析,可以了解我们在某个网站上的广告投入有没有收到预期的效果。 可以区分不同地区的访问人数、甚至商品交易额等。百度统计、Google分析、站长工具等,只需要在页面嵌入一个js即可。
但是,数据始终是在对方手中,个性化定制不方便,于是Google出一个叫Piwik的开源分析工具。
Piwik
百度统计
6.6 日志监控
通常情况下,随着系统的运行,操作系统会产生系统日志,应用程序会产生应用程序的访问日志、错误日志,运行日志,网络日志,我们可以使用ELK来进行日志监控。
对于日志监控来说,最见的需求就是收集、存储、查询、展示,开源社区正好有相对应的开源项目:Logstash(收集)+ElasticSearch(存储+搜索)+Kibana(展示)。
我们将这三个组合起来的技术称之为ELK Stack,所以说ELK Stack指的是Elasticsearch、Logstash、Kibana技术栈的结合。
如果收集了日志信息,部署更新有异常出现,可以立即在Kibana上看到。
ELK日志展示(当然也可以通过Zabbix过滤错误日志来进行告警。)
6.7 安全监控
虽然Linux开源的安全产品不少,比如四层iptables,七层WEB防护Nginx+Lua实现WAF,最后将相关的日志都收至ELkstack,通过图形化进行不同的攻击类型展示。但是始终是一件比较耗费时间,并且个人效果并不是很好。这个时候我们可以选择接入第三方服务厂商。
某某三方安全
三方厂商提供全面的漏洞库,涵盖服务、后门、数据库、配置检测、CGI、SMTP等多种类型。
全面检测主机、Web应用漏洞自主挖掘和行业共享相结合第一时间更新0-day漏洞,杜绝最新安全隐患。
6.8 API监控
由于API变得越来越重要,很显然我们也需要这样的数据来分辨我们提供的 API是否能够正常运作。
监控API接口GET、POST、PUT、DELETE、HEAD、OPTIONS的请求。可用性、正确性、响应时间为三大重性能指标。
API监控
三方API监控
响应时间
6.9 性能监控
全面监控网页性能,DNS响应时间、HTTP建立连接时间、页面性能指数、响应时间、可用率、元素大小等。Zabbix提供URL监控:Zabbix Web 监控。
Zabbix站点监控
终端响应时间
6.10 业务监控
没有业务指标监控的监控平台,不是一个完善的监控平台,通常在我们的监控系统中,必须将我们重要的业务指标进行监控,并设置阈值进行告警通知。比如电商行业:
每分钟产生多少订单、每分钟注册多少用户、每天有多少活跃用户、每天有多少推广活动、推广活动引入多少用户、推广活动引入多少流量、推广活动引入多少利润等,重要指标都可以加入Zabbix上,然后通过Screen展示。
注:由于业务监控图表,涉及到隐私的数据太多,就不截图了。
7. 监控报警
故障报警通知的方式有很多种,当然最常用的还是短信和邮件。
短信报警
邮件报警
8. 报警处理
报警后故障如何处理?首先我们可以通过告警升级机制先自动处理,比如Nginx服务down了,可以设置告警升级自动启动Nginx。
但是如果一般业务出现了严重故障,我们通常根据故障的级别、业务,来指派不同的运维人员进行处理。
当然不同业务形态、不同架构、不同服务可能采用的方式都不同,这个没有一个固定的模式套用。
10. 面试监控
在运维面试中,常常会被问题监控相关的问题,这个问题到底该如何来回答,我针对本文给大家提供了一个简单的回答思路
1、硬件监控
通过SNMP来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其它,可以通过IPMI来实现。当然如果没有硬件全都是云,直接跳过这一步骤。
2、系统监控
如CPU的负载,上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode使用率。当然这些都是需要配置触发器,因为默认太低会频繁报警。
3、服务监控
比如公司用的LNMP架构,Nginx自带Status模块、PHP也有相关的Status、MySQL的话可以通过Percona官方工具来进行监控。Redis这些通过自身的info获取信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容,以及报警和图形功能。
4、网络监控
如果是云主机又不是跨机房,那么可以选择不监控网络。当然你说我们是跨机房以及如何如何,推荐使用smokeping来做网络相关的监控,或者直接交给你们的网络工程师来做,因为术业有专攻。
5、安全监控
如果是云主机可以考虑使用自带的安全防护。当然也可以使用iptables。如果是硬件,那么推荐使用硬件防火墙。使用云可以购买防DDOS,避免出现故障导致down机一天。如果是系统,那么权限、密码、备份、恢复等基础方案要做好。Web同时也可以使用Nginx+Lua来实现一个Web层面的防火墙。当然也可以使用集成好的OpenResty。
6、Web监控
Web监控的话题其实还是很多。比如可以使用自带的Web监控来监控页面相关的延迟、js响应时间、下载时间、等等。这里我推荐使用专业的商业软件监控宝或听云来实现。毕竟人家全国各地都有机房(如果本身是多机房那就另说了)。
7、日志监控
如果是Web的话可以使用监控Nginx的50x、40x的错误日志,PHP的ERROR日志。其实这些需求无非是,收集、存储、查询、展示,我们其实可以使用开源的ELKStack来实现。Logstash(收集)、Elasticsearch(存储+搜索)、Kibana(展示)。
8、业务监控
上面做了那么多,其实最终还是保证业务的运行。这样我们做的监控才有意义。所以业务层面这块的监控需要和开发以及总监开会讨论,监控比较重要的业务指标,(需要开会确认)然后通过简单的脚本就可以实现,最后设置触发器即可 。
9、流量分析
平时我们分析日志都是拿awk sed xxx一堆工具来实现。这样对我们统计IP、PV、UV不是很方便。那么可以使用百度统计、Google统计、商业,让开发嵌入代码即可。为了避免隐私也可以使用Piwik来做相关的流量分析。
10、可视化
通过Screen以及引入一些第三方的库来美化界面,同时我们也需要知道,订单量突然增加、突然减少。或者说突然来了一大波流量,这流量从哪儿来,是不是推广了,还是被攻击了。可以结合监控平来梳理各个系统之间的业务关系。
11、自动化监控
如上我们做了那么多的工作,当然不能是一台一台的来加key实现。可以通过Zabbix的主动模式以及被动模式来实现。当然最好还是通过API来实现。
总结
真正想做到更完整的监控体系,目前的开源软件确实无法很好地满足,有条件的公司都开始自己开发自己的监控系统,比如小米开源的Open-Falcon。
也有比较好的开源的监控框架如Sensu等,再加上InfluxDB、Grafana可以用来定制符合自己企业的监控平台。
二、Zabbix配置文件详解
在zabbix服务(server)端、客户(agent)端、代理(proxy)端分别对应着一个配置文件。
- zabbix_server.conf(服务端)
- zabbix_agentd.conf(客户端)
- zabbix_proxy.conf (代理端)
1. zabbix_server.conf详解
1 | NodeID=0 #分布式节点id号,0代表是独立服务器,默认是被注释掉的,不强制配置 |
2、zabbix_agentd.conf详解
1 | PidFile=/tmp/zabbix_agentd.pid #pid文件的存放位置 |
3、zabbix_proxy.conf详解
1 | Server=192.168.70.133 #指定zabbix server的ip地址或主机名 |
三、Zabbix监控结合Grafana绘图
1. Zabbix概述
Zabbix是一个企业级的开源分布式监控解决方案,由C语言编写而成的底层架构(server端和agent端),由一个国外的团队持续维护更新,软件可以自由下载使用,运作团队靠提供收费的技术支持赢利。官方网站:http://www.zabbix.com
2. Zabbixj架构图
zabbix根据网络环境、监控规模等,分了三种架构: server-client 、server-proxy-client、master-node-client 三种 。
server-client架构
也是zabbix的最简单的架构,监控机和被监控机之间不经过任何代理 ,直接由zabbix server和zabbix agentd之间进行数据交互。适用于网络比较简单,设备比较少的监控环境 。
master-node-client架构
该架构是zabbix最复杂的监控架构,适用于跨网络、跨机房、设备较多的大型环境 。每个node同时也是一个server端,node下面可以接proxy,也可以直接接client 。node有自已的配置文件和数据库,其要做的是将配置信息和监控数据向master同步,master的故障或损坏对node其下架构的完整性。
server-proxy-client架构
其中proxy是server、client之间沟通的一个桥梁,proxy本身没有前端,本身也并不存放数据,只是将agentd发来的数据暂时存放,然后再提交给server ;该架构经常是和master-node-client架构做比较的架构 ,一般适用跨机房、跨网络的中型网络架构的监控。
Zabbix基本机构图如下
3. Zabbix的优劣势
优点
支持设备多
支持分布式集中管理
开源,无软件成本投入
开放式接口,扩展性强
Server对设备性能要求低(实际测试:2个CPU 1G内存,监控5台设备,CPU使用率保持在10%以下,内存剩余400M以上)
当监控的项目比较多 服务器队列比较大的时候可以采用被动状态,被监控客户端主动从server端去下载需要监控的项目然后取数据上传到server端。这种方式对服务器的负载比较小。
缺点
- 无厂家支持,出现问题解决比较麻烦
- 需在被监控主机上安装agent,所有数据都存在数据库里,产生的数据据很大,瓶颈主要在数据库。
4. Zabbix组件说明
1)zabbix server:负责接收agent发送的报告信息的核心组件,所有配置、统计数据及操作数据都由它组织进行;
2)database storage:专用于存储所有配置信息,以及由zabbix收集的数据;
3)web interface:zabbix的GUI接口;
4)proxy:可选组件,常用于监控节点很多的分布式环境中,代理server收集部分数据转发到server,可以减轻server的压力;
5)agent:部署在被监控的主机上,负责收集主机本地数据如cpu、内存、数据库等数据发往server端或proxy端;
5. Zabbix监控流程
agentd需要安装到被监控的主机上,它负责定期收集各项数据,并发送到zabbix server端,zabbix server将数据存储到数据库中,zabbix web根据数据在前端进行展现和绘图。
这里agentd收集数据分为主动和被动两种模式:
主动:agent请求server获取主动的监控项列表,并主动将监控项内需要检测的数据提交给server/proxy
被动:server向agent请求获取监控项的数据,agent返回数据。
6. 客户端守护进程
此进程收集客户端数据,例如cpu负载、内存、硬盘使用情况等。
zabbix_get
zabbix工具,单独使用的命令,通常在server或者proxy端执行获取远程客户端信息的命令。通常用户排错。例如在server端获取不到客户端的内存数据,我们可以使用zabbix_get获取客户端的内容的方式来做故障排查。
zabbix_sender
zabbix工具,用于发送数据给server或者proxy,通常用于耗时比较长的检查。很多检查非常耗时间,导致zabbix超时。于是我们在脚本执行完毕之后,使用sender主动提交数据。
zabbix_server
zabbix服务端守护进程。zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway的数据最终都是提交到server。(备注:当然不是数据都是主动提交给zabbix_server,也有的是server主动去取数据)
zabbix_proxy
zabbix代理守护进程。功能类似server,唯一不同的是它只是一个中转站,它需要把收集到的数据提交/被提交到server里。为什么要用代理?代理是做什么的?卖个关子,请继续关注运维生存时间zabbix教程系列。
zabbix_java_gateway
zabbix2.0之后引入的一个功能。顾名思义:Java网关,类似agentd,但是只用于Java方面。需要特别注意的是,它只能主动去获取数据,而不能被动获取数据。它的数据最终会给到server或者proxy。
7. Zabbix项目实战
环境:
主机 | 操作系统 | ip地址 | 主要软件 |
---|---|---|---|
server.zabbix | Centos 7.4.1708 64 | 192.168.2.1/24 | Lamp、mailx、zabbix-4.2.7、grafana-4.6.1-1 |
agent01.zabbix | Centos 7.4.1708 64 | 192.168.2.2/24 | zabbix-4.2.7 |
agent02.zabbix | Centos 7.4.1708 64 | 192.168.2.3/24 | zabbix-4.2.7 |
环境配置
修改三台主机名
1 | hostnamectl set-hostname server.zabbix && logout |
在 hosts文件里追加以下配置(配置相同)
1 | cat <<END>> /etc/hosts |
时间同步
1 | yum -y install ntpdate |
关闭防火墙 及 selinux配置
1 | systemctl stop firewalld |
实施步骤:
步骤 | 说明 |
---|---|
第一步 | 1.安装zabbix server服务端 |
第二步 | 2.配置优化zabbix服务的web页面 |
第三步 | 3.实现监控server.zabbix端自身的OS、mysql、httpd |
第四步 | 4.自定义Zabbix监控项(重点) |
第五步 | 5.实现Zabbix邮件报警功能 |
第六步 | 6.自动发现—自动添加服务器监控 |
第七步 | 7.Zabbix聚合图形 |
第八步 | 8.安装并配置Grafana的web界面(呈现效果) |
7.1 安装zabbix server服务端
上传Lamp和Zabbix相关依赖的软件包
配置 server 端的本地 lamp yum源
1 | [root@server ~]# cat <<END>> /etc/yum.repos.d/yum.repo |
server端上安装lamp和依赖包;注:最好多安几遍,包太多,可能安不全
1 | [root@server ~]# yum -y install net-snmp net-snmp-devel libxml2 libxml2-devel libcurl-devel libevent libevent libevent-devel curl curl-devel mysql-devel snmp perl-DBI php-xml php-bcmath php-mbstring php-ldap php-xmlrpc httpd php php-mysql php-common php-gd php-odbc php-pear gcc* net-snmp libssh2 libssh2-devel mariadb-server mariadb mariadb-devel |
启动 mariadb、httpd 服务 并 设置mariadb数据库密码
1 | [root@server ~]# for i in mariadb httpd;do systemctl start $i;done |
源码安装Zabbix服务端
1 | ## 创建zabbix运行用户 |
登陆数据库创建保存监控模板的数据库,并导入数据模板以及授权zabbix用户连接数据库
1 | [root@server ~]# mysql -uroot -p123123 |
修改服务zabbix_server.conf 端及客户端zabbix_agentd.conf的配置文件
zabbix_server.conf
1 | ## 备份 |
zabbix_agentd.conf
1 | ## 备份 |
启动server(监控端) 及 agent(被监控端)
1 | ## 加入开机启动项 |
将Zabbix自带的web页面添加到httpd的网页存放目录中,并修改php的配置文件,然后重启httpd服务
1 | ## 拷贝Zabbix自带的php页面到apache网站存放目录中 |
7.2 配置优化zabbix服务的web页面
登陆Zabbix页面并进行一些简单优化,默认用户名admin,密码zabbix
解决zabbix显示图像下边文字乱码情况:
1 | [root@server ~]# mv simkai.ttf /var/www/html/zabbix/assets/fonts/ |
7.3 实现监控server.zabbix端自身的OS、mysql、httpd
添加主机:配置—主机—创建主机
- 选择OS、mysql、httpd模板
这些模板都是官方默认提供的,里面包含了所有,比如:监控项、触发器、触发器、图形、自动发现等所有的配置,不需要再手动编写,但是一般在公司都是自己编写这些个配置。
勾选以下三个监控模板,点击选择按钮
他们的对应关系:
- 应用集 针对 监控项
- 监控项 针对 触发器
- 创建MySQL图形
选择监控项,点击选择
查看监控主机的图形;
但是意外出现了,关于Mysql数据库的所有监控项没有图形,如图所示;
经过查看,问题如下图,监控Mysql服务器的键值不支持
解决方案如下;
- 打开zabbix_server服务器,同时在此也是被监控端,设置MySQL监控项失效的键值
1 | ## 注意:下面标红的$1要手写进去,直接粘贴,粘不进去的!!! |
再次打开zabbix的web界面,查看mysql监控项界面
- 创建httpd服务的图形
这和MySQL的过程是一样的,而且它比MySQL还要省事,因为OS和HTTPD模板的键值默认就是支持的,不需要在取值了
7.4 自定义Zabbix监控项(重点)
以上关联的 Template OS Linux 模板基本涵盖了所有系统层面的监控,包括了我们最关注的几项:ping、load、cpu使用率、memory、disk、网卡流量等等,当然有些触发器的阀值可能需要根据服务器的自身情况进行修改。
下面添加自定义服务器内存使用检测项,在此配置一个监控项为:内存使用70M进行警告提醒:
修改客户端zabbix_agentd.conf配置文件,最后一行添加:
- UserParameter=memory_used,free -m|grep Mem|awk ‘{print $3}’
语法:UserParameter=key,shell command
- 监控key值:memory_userd,key值可以随意编写,但是一会需要在web页面创建监控项时指定key值
- Shell命令或脚本:free -m|grep Mem|awk ‘{print $3}’
注:在zabbix_server端可以使用zabbix_get -s agent端ip地址 -p 10050 -k key名通过此命令可以查看agent端key的监控值
在此之前,先将agent01.zabbix主机的zabbix客户端软件安装好,并加入至Linux Servers组中
1、安装并配置zabbix客户端,只安装agent端,不装server端
1 | ## 安装所需依赖包 |
2、将其agent01主机加入至Linux Servers组中,至于模板的话就选择一个Template OS Linux系统的就行了
自定义监控具体实现方式如下,在agent.zabbix主机的配置文件中来定义监控项
1 | ## 定义系统所用的物理内存大小 |
使用web界面添加此监控项
监控项添加完成后,创建触发器(根据条件进行触发某个告警操作)
插入后,手动修改表达式为 >200 作为条件,然后添加就行了
触发器创建完成后,创建监控显示的图形
查看这个图形
模拟内存使用超过200M触动触发器
[root@agent01 ~]# dd if=/dev/zero of=/opt/lemon.txt bs=1G count=5 &
7.5 实现Zabbix邮件报警功能
首先配置server.zabbix端的邮件
1 | ## 安装邮箱应用 |
配置zabbix_server.conf配置文件
1 | [root@server ~]# vim /usr/local/zabbix/etc/zabbix_server.conf |
配置zabbix web网站进行监控项的邮件报警,每一张图片后附带解释和注意事项,大体步骤分为 监控–创建报警媒介类型–更新用户使用的报警媒介类型–创建动作(根据触发器触发)–验证
创建报警媒介类型:
输入创建的报警媒介类型的名称,指定类型为脚本的方式,并且输入zabbix_server端/usr/local/zabbix/share/zabbix/alertscripts目录下的脚本名称,确保脚本的归属是zabbix,并且脚本的权限是777,下边设置脚本参数,也就是发送邮件的语法:脚本收件人标题内容,必须严格按照此标准填写;
脚本参数: {ALERT.SENDTO} {ALERT.SUBJECT} {ALERT.MESSAGE}
配置zabbix中的用户所使用的报警媒介类型以及接收邮件的邮箱
创建动作,也就是发送邮件的动作
输入动作名,动作名最好为英文,可以选择触发这个动作的条件(可以选择触发器=触发器的名称或者选择触发器似触发器名称),作为条件,如若如图不选择触发器的条件,那么任何消息都会提示到邮箱
添加报警动作,一旦此触发器添加触发,添加报警邮件的标题和内容,默认操作步骤持续时间(修改持续时间为60秒 (一分钟发送一次邮件)),添加操作(添加接收邮件的用户)
1 | 故障{TRIGGER.STATUS},服务器:{HOSTNAME1}发生: {TRIGGER.NAME}故障! |
添加恢复操作(指故障恢复之后发送邮件的动作),具体步骤和添加操作相同;
开始模拟内存使用超过200M后邮件报警
测试:agent01.zabbix主机测试邮件报警情况
[root@agent01 ~]# dd if=/dev/zero of=/opt/lemon.txt bs=1G count=10 &
这时会超过在上面表达式中写的200M,接着就会邮件警报、向lemon_row@163.com发送邮件警报信息,每隔60秒发送一次,直到故障修复完成
- 故障报警邮件
- 恢复报警邮件
7.6 自动发现—自动添加服务器监控
什么是自动发现?
- 会自动添加主机或监控项等等的规则动作
1、配置自动发现
配置–>自动发现–>创建发现规则
2、添加动作:发现主机后需要执行的操作
配置–>动作–>事件源选:自动发现–>创建动作:
3、在agent02.zabbix主机上安装zabbix.agentd
1 | ## 安装所需依赖包 |
4、耐心等待一段时间验证就OK了
7.7 Zabbix聚合图形
检测–>聚合图形–>创建聚合图形
7.8 安装并配置Grafana的web界面
Grafana简介
Grafana是一个可视化面板(Dashboard)有着非常漂亮的图表和布局展示,功能齐全的度量仪表盘和图形编辑器,支持Graphite、zabbix、InfluxDB、Prometheus和OpenTSDB作为数据源。以InfluxDB(由go语言编写,是一个开源,分布式,时间序列,事件,可度量和无外部依赖的数据库)作为底层数据库;
Grafana主要特性:灵活丰富的图形化选项;可以混合多种风格;支持白天和夜间模式;多个数据源。
1 | [root@server ~]# yum -y install fontconfig freetype* urw-fonts //安装grafana依赖 |
添加数据源
创建仪表盘
创建仪表盘时指定显示的图形
选择数据源和图中需要显示的主机和主机的监控项
创建完,保存此仪表盘,输入仪表盘的名称