如何配置服务器自动监控并报警
Posted 精神食粮每天需要
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何配置服务器自动监控并报警相关的知识,希望对你有一定的参考价值。
作者:一个懂技术的运营链接:https://www.zhihu.com/question/21073555/answer/106131463
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
如果是初创型公司,机器规模和工作流转没有那么复杂的情况下。运维监控和报警,都利用 Zabbix 和一些报警聚合服务。
先来说说,我们公司如何利用 Zabbix 监控和报警的吧。
Zabbix 配置报警
其实线上的教程很多: Zabbix 的图文安装教程 。
下面自己 Zabbix 在添加服务器监控以及监控报警方面总结下心得体会吧。
Zabbix 默认的语言是英语如果觉得使用不习惯可以自己汉化下,同样网上有相关的解决方法这里就不多说了。接下就先介绍下添加主机监控的流程。
一、 系统配置--->主机--->Create host
二、设置主机名字--->监控主机所属组--->监控主机IP地址--->所属模板
自此在 Zabbix 中就成功添加了一台新的服务器。下面介绍下 Zabbix 如何配置监控报警。
在告警这块 Zabbix 默认只支持邮件,如果需要短信告警还需要进行短信网关对接,复杂度较高。同时我认为短信的告警并非是一个好的方式,虽然发送了告警信息,同样会存在疏漏的情况,而且这种情况发生的概率并不是很低。所以这里就以邮件配置为例来介绍下。
一:添加报警的处理方法
1、打开zabbix的管理--->处理方法--->create media type
这里为了方便就以脚本发邮件的方式来报警,脚本名字为mail.py。这里需要重点关注一下的是脚本存放位置,我的脚本是放在/usr/local/zabbix/bin/目录下面,这里偷下懒 就不写绝对路径了,脚本的路径设置是在zabbix服务器端的配置文件中设置的,在zabbix_server.conf配置文件中设置:AlertScriptsPath=/usr/local/zabbix/bin/
二:添加zabbix用户和组,设置其邮箱地址等信息
1、打开zabbix的管理--->用户--->选择用户组下拉--->create user group:
这里主要就是写下组名,设置自己需要的权限然后保存就可以了。
2、打开zabbix的管理--->用户--->选择用户下拉--->create user:
设置好组与用户后就要添加报警介质,其实就是报警方式,由于设置的是报警,所以 “信息" 那项就不用勾选,信息一般就是服务器信息发生变化时报警,这个一般没有什么意义,所以不勾选。
三、报警触发器触发的动作设置
此步操作的意义是,当监控项中的触发器达到你设置的报警值之后,需要执行操作来发送邮件等动作。具体操作如下。
1、打开zabbix的系统配置--->操作--->选择事件源为触发器--->create action:
2、配置出发条件
3、详细操作设置
即满足触发条件之后执行的动作,这里一般设置为发邮件之类的,设置收邮件的用户时,建议每个组对应一个用户,这样发邮件的时候容易设置发送对象。
到这里告警的设置工作就完成了。
说了这么多 Zabbix 监控和告警的配置,我想聊一下在使用 Zabbix 过程中的一些感受吧。
Zabbix 功能特点:
- 自动发现服务器和网络设备
- 分布式监控网络,集中式管理(agent 、server 分开)
- 监控指标模版丰富
- 可灵活地分配用户权限
Zabbix 不足
- 安装配置相对比较复杂,后期维护成本高
- 数据是只读的、不能对监控数据进行聚合
- 告警机制不够灵活 :不同的指标需要不同的脚本;告警渠道单一
- 不同的监控需求,需要不同的脚本来完成
使用报警聚合工具,聚合报警
如果机器数量成长到一定规模的时候,会发现根本来不及处理报警。人力部门又不给力,迟迟找不上来人。
好在国外有一些报警聚合服务, pagerduty、 bigpanda 等等。
这类工具主要功能是实现了在一个平台中接收所有监控系统的告警,从而实现报警聚合的服务,让运维人员集中处理IT事件,避免多平台切换,提升运维效率。同时只需要少于 15分钟的时间就可以将Nagios、Zabbix等主流监控平台的告警自动整合进来,而无需其它配置。以Bigpanda为例我们可以看下他集成的监控平台
与此同时 bigpanda 会将大量重复的告警事件压缩为一条有真正意义的告警。而后通过机器学习等算法把相关的告警合并起来,为运维人员提供分析、甄选之后的最重要的告警。
从这些角度来看,国外在监控领域的发展已经从 Zabbix 这种 1.0 时代 ,进入一体化监控解决方案 的 2.0 时代。他们开始选择基于 StatsD 技术的监控工具或解决方案。例如 Datadog 、 Boundary 等第三方监控服务提供商。
这些公司的理念就是为了提供一个一体化的解决方案:如何集成不同的操作系统、数据库、中间件监控的问题,你不需要担心;用就行了。
监控聚合 + 报警聚合
由于 Zabbix 的监控是针对每一台主机的某一项指标来设置报警,并通过模板来快速创建报警。如果想要将一组机器的 CPU 利用率,或者管理集群来报警,就得自己写脚本了。
有没有聚合数据来监控,从而报警自然而然也是聚合的方案呢?
就国内来说我试用过的 Cloudinsight 产品还是不错的,它是利用 Statsd 和 OpenTSDB 实现的一个一体化的监控解决方案。由于其利用到了时间序列数据库,所以数据不再是只读的可以进行聚合分组等功能,这样一来就从不同的数据源中聚合数据,转交给报警处理引擎;引擎根据报警策略中设置的报警条件,对某一固定时间窗口内,对数值进行检查。当引擎检查时间窗口内的数值满足条件时,触发报警事件的生成;并流送至 Cloudinsight 事件流、邮件、 OneAlert 等不同的渠道,进行分发,通知用户。
楼主提出的这个问题,我认为可能是刚刚开始接触运维监控这个领域,所以不妨试一下 CloudInsight 。由于其安装简便,一切就只有两步,安装探针,查看仪表盘。这样就可以进行快速的试错,同时Cloudinsight 集成了数十种互联网流行基础组件的监控,只需要进行最小化的配置就可以实现复杂的基础组件监控, 免除了传统基础组件监控中的复杂流程。这样就可以看看新的技术发展是否能够更好地满足自己的需求。
由于平时比较喜欢新鲜事物所以就试用了下,它的可视化效果还是不错的,下面给大家截几张图看看。
总结一下吧,我认为随着现在云计算的不断发展,服务的模式一定会是未来发展的趋势吧,就像云主机一样以 IaaS 服务代替了一部分传统物理主机与 IDC 的市场份额。照这样的形式来看在监控领域像 Datadog、Boundary、Cloudinsight这种 SaaS 监控服务也会是未来的一种风向标吧。
以上是关于如何配置服务器自动监控并报警的主要内容,如果未能解决你的问题,请参考以下文章