zabbix系列(五)zabbix3.0.4 探索主机Discovery自动发现agent主机和zabbix-agent自动注册详细图文教程

Zabbix 自动发现(Discovery)功能使用 随着监控主机不断增多,有的时候需要添加一批机器,特别是刚用zabbix的运维人员需要将公司的所有服务器添加到zabbix,如果使用传统办法去单个添加设备、分组、项目、图像…..结果应该是让人吐的结果。 鉴于这个问题我们可以好好利用下Zabbix的一个发现(Discovery)模块,进而来实现自动刚发现主机、自动将主机添加到主机组、自动加载模板、自动创建项目(item)、自动创建图像,下面我们来看看这个模块如何使用。 一、Zabbix 创建发现规则创建发现规则Configuration —- discovery —- Create discovery rule 配置基本信息  配置Checks  添加完checks之后 点击最下面的add添加保存即可 OK 规则已经创建完毕了 下面开始让他自动加入到组自动创建图形吧 二、主机自动加入主机组并关联模板 上面我们了解了如何自动发现主机,那么发现主机之后我们要做什么呢? 将主机加入主机组、并关联相应的模板!这样一整个流程就完善了,那么如何做呢?我们上面已经发现了主机 接下来要对主机做操作 所以需要一个action (动作)来执行一些列的操作,下面我们来看具体操作。 2.1、为discovery(发现)创建action(动作)Configuration —- Actions —- Event source(选择Discovery) —- Create action 2.1.1、输入 Action 名字 2.1.2、添加触发Action的条件  这里添加了三个条件 分别是 “ip地址范围”、“服务类型” 和 “Discovery 状态” 2.2、创建操作  2.2.1、“Add host ”添加主机 “Add to host group” 将主机添加到主机组、选择要添加到的主机组 “Link to template” 链接到模板、选择相应的模板  这里我定义了 发现主机就 “添加主机(Add…

Read More

zabbix执行远程命令(41)

概述 监控,有的人只把他当做报警使用,出现问题之后打开跑回家打开电脑,巴拉巴拉的处理掉,大多数时候都是一些小问题,为何不让zabbix帮你把这些事情处理掉呢?和朋友具体,收到xx硬盘空间慢了、xx服务器高负载等问题,你要回家处理?多扫兴 瞧瞧zabbix远程执行命令可以做些什么吧: 重启应用(Apache、nginx、MySQL等等) 使用IPMI接口重启服务器 自动释放磁盘空间(删除老文件,清除/tmp目录等等) CPU过载时讲一个虚拟机迁移到另外一台物理服务器 云环境下,一台服务器CPU\硬盘\内存\其他硬件资源不足的情况下,可以自动添加过去 创建一个报警,记得使用邮件报警吗?呵呵,实际上,我们把发送邮件的操作改成执行远程命令就行了 备注:zabbix代理不支持远程命令 远程命令最大长度为255字符,同时支持多个远程命令,如需要执行多条命令,只需要另起一行写命令即可,还有,远程命令可以使用宏变量。 接下来我将一步一步告诉大家如何设置远程命令 配置 首先我们需要在zabbix客户配置文件开启对远程命令的支持,编辑zabbix_agentd.conf,修改 1 EnableRemoteCommands = 1 重启客户端 备注:Aive zabbix不支持远程命令 然后配置action,Configuration->Actions,选择Operation选项卡,operation type改成Remote Command,选择远程命令类似 (IPMI, Custom script, SSH, Telnet, Global script),输入远命令 配置Action 在Operations选显卡中选择Remote command 选择远程命令类型(IPMI, Custom script, SSH, Telnet, Global script) 写上远程命令 示例: 1 sudo /etc/init.d/apache restart 上面例子用来在出现状况的情况下重启Apache,务必全包zabbix agent能够执行这个命令. 备注: 1.sudo不用多说了,zabbix用户没有运行某些命令的权限,必须加上. 2.远程命令,自然是在远程的主机后台运行。 Conditions选项卡定义了什么条件下,这个远程命令会被执行,其实这个和前面说的action真没什么区别,大家都能看懂。下图的意思是,在非维护时间Apache应用出现状况,并且严重性级别为Disaster。满足条件之后,就开始执行命令了。 访问权限 确保你的zabbix用户有执行权限,如果某些命令需要root权限,那么请使用sudo 1 # visudo 编辑sudoer文件,zabbix用户便可以执行Apache restart命令了…

Read More

zabbix从听说到学会

一、zabbix简介 zabbix(音同 zæbix)是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。 zabbix能监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。 zabbix由2部分构成,zabbix server与可选组件zabbix agent。 zabbix server可以通过SNMP,zabbix agent,ping,端口监视等方法提供对远程服务器/网络状态的监视,数据收集等功能,它可以运行在Linux,Solaris,HP-UX,AIX,Free BSD,Open BSD,OS X等平台上。 二、zabbix安装使用 zabbix agent需要安装在被监视的目标服务器上,它主要完成对硬件信息或与操作系统有关的内存,CPU等信息的收集。zabbix agent可以运行在Linux,Solaris,HP-UX,AIX,Free BSD,Open BSD, OS X, Tru64/OSF1, Windows NT4.0, Windows (2000/2003/XP/Vista)等系统之上。 zabbix server可以单独监视远程服务器的服务状态;同时也可以与zabbix agent配合,可以轮询zabbix agent主动接收监视数据(agent方式),同时还可被动接收zabbix agent发送的数据(trapping方式)。 另外zabbix server还支持SNMP (v1,v2),可以与SNMP软件(例如:net-snmp)等配合使用。 2.1 zabbix安装 2.1.1 zabbix WEB环境搭建 zabbix的安装需要LAMP或者LNMP环境。 需要其它的软件包 yum install mysql-dev gcc net-snmp-devel curl-devel perl-DBI php-gd php-mysql php-bcmath php-mbstring php-xm 2.1.2 zabbix 数据库设置 zabbix数据库可以和zabbix服务器分离,采用用专门的mysql服务器存储数据,此时要给zabbix数据库受相应的权限。 grant all privileges…

Read More

分布式监控Zabbix初入

Why Moniter 首先我们聊聊为什么需要监控? 在SRE Google运维解密中指出,监控一个系统有多个原因: 分析长期的趋势,如每日活动用户的数量增长的速度 跨时间范围的比较/或是观察实验组和控制组的区别,如随着新系统的上线,memcache的缓存率是否增加?网站是否比上周的速度慢 报警,这个很容易理解,如我们的物理内存即将耗尽,到达50%发送一个级别较低的告警信息,当内存只剩下20%发送一个级别更高的告警信息 构建监控台页面,更加方便的对系统问题直观考察 临时性的回溯分析/在线调试 众所周知,无论公司有多大,我们都需要一套监控系统来保障业务的正常运行,快速发现问题并解决问题是运维存在的价值,只有在问题出现之前将问题提前解决,才能体现出运维的更高的价值,这就需要一个完整的监控系统。 监控系统说白了最重要的是让我们透过现象看本质,所谓现象就是什么东西故障了或存在故障的可能性,以及为什么出现故障。 比如,现象:服务器响应很慢?本质:CPU被某个复杂度很高的程序跑满,数据库/web连接数过大典型如TIME-WAIT 一个好的监控系统就像信道一样,要有很高的信噪比才行,我们要更多的可用有价值的信息,才能帮助我们进行故障排查,运维不背锅 介绍 Zabbix是由Alexei Vladishev开发的一种网络监视、管理系统,和常用的其他软件架构类似,其是一种基于C/S(client/server)结构的开源软件 Zabbix是一种可以监控系统/网络等基础设施的服务软件,其可以采集一些性能指标数据,它不仅为运维人员原生提供了一系列科学通用的监控选项,也支持ops自定义我们更加感兴趣的一些性能指标。也就是说,zabbix可以解放我们自己动手去关注采集一系列的信息,从而降低了运维成本,针对不同的业务环境,zabbix官方也提供了对应的推荐的模板可供使用 zabbix server可以将我们感兴趣的数据进行采集并存储到RDBMS中,如常用的MySQL。这些数据可以供我们后期对业务数据进行分析,便于后期的故障回溯、容量规划等考量 zabbix server也提供了便捷的WEB GUI从而方便运维人员对监控系统进行配置、数据展示,我们也可以定义graph、screen等更加全局的对我们系统的性能有个直观的了解 zabbix server还提供了报警功能,我们可以针对某个性能指标定义当其超过一定的阈值,便触发相应的动作,如实现我们的告警,当然也可以自动去执行某些命令 zabbix自身是一个分布式监控解决方案,zabbix server可以指定代理来实现主机的发现和数据采集,当zabbix client和zabbix server不在一个防火墙区域,则我们可以让另外的zabbix proxy来对主机进行数据收集之后再将数据交由给我们的zabbix server,在防火墙上也只需要配置放行proxy<–>server之间的流量即可,这就意味着我们的监控系统的扩展性更强。 <!– more –> zabbix架构和安装 架构 一个完整的监控系统至少应该具备下面四个组件: 数据采集 SNMP,对于不能安装agent的设备,如路由器/交换机等,可以使用SNMP协议进行监控 Agent,对于不同的操作系统,Zabbix提供了不同平台的agent程序 Agent-less 形如ICMP/SSH/IPMI 数据存储 Database(ZABBIX) 数据展示(Web) 采用对应的web平台,Zabbix自带了默认自带php页面 报警 当监控的指标触发阈值发送EMAIL/SMS等 zabbix的部署可以常见的有两种方式,集中式监控和分布式监控。本篇先讨论集中式监控,zabbix server通过SNMP/Zabbix-agent等方式来对设备进行监控。一张图来说是这样的: 工欲善其事必先利其器,首先我们先安装好zabbix,之后再看看zabbix的web GUI里面有什么,之后再聊聊它的架构,这样会更加直观一点 安装 由于zabbix是一个c/s结构的服务程序,先不考虑分布式的监控,所以其一般分为server和agent两个部分,所以需要分别对C/S进行安装 这里的agent其实就是一个安装在被监控端的客户端程序,它负责收集一些信息,并交给zabbix server。注意的是zabbix server除了自身的组件还需要对从agent获取的数据进行存储,这里选择MySQL。 也就是说,我们需要三台CentOS 6.5 Linux主机,一台安装zabbix…

Read More

mysql优化,导致查询不走索引的原因总结

最近公司让我做SQL优化的工作(MySql),用explain发了一些问题。常见的像OR ,IN,>= ,或者是嵌套等导致索引失效,导致查询性能降低的问题在这里就不做陈述了,网上的文章一搜一 大片。我只是写点个人工作中遇到的,网上不好搜索的,但是不保证所有的场景都试用,后续我还会更新。 1、order by 和 limit 结合使用,如果where 字段,order by字段都是索引,那么有limit索引会使用order by字段所在的索引。没有limit会使用where 条件的索引。遇到此类状况可以考虑用子查询将order by 和 limit 分开。这种情况主要发生在你用了多个索引,那么你需要注意了。它可能不执行你希望的走索引。(我觉得mysql会自动计算索引) 2、DATE_FORMAT()格式化时间,格式化后的时间再去比较,可能会导致索引失效。 3、子查询中order by的索引会失效,同时可能导致子查询中的where条件索引都不能用。 4、字符集的使用导致不走索引,有时你会发现用一个SQL 条件值不同可能会有天的差别(我之前遇到的 两个不同的ID号,一个查询80s,一个不到1s) 5、like语句 6、列类型为字符串类型,查询时没有用单引号引起来 7、在where查询语句中使用表达式 8、在where查询语句中对字段进行NULL值判断 9、在where查询中使用了or关键字, myisam表能用到索引, innodb不行;(用UNION替换OR,可以使用索引) 10、全表扫描快于索引扫描(数据量小时) 先说这几条.如果查看执行计划不理想的话,我建议在启动数据库时加上两个启动参数,会看的更清楚(每个表的执行次数和执行时间) –log-slow-queries     (查询日志) –log-queries-not-using-indexes   (查询未使用索引日志) 最后的优化方式就是测试,因为业务的不同优化理论不可能总是可以带来很高的效率,利用explain或desc查看,然后再真的某个查询或表做改进吧。

一个月的艰辛稳定服务过程

业务大了成本问题更加的凸显,最重要的之一就是带宽,为了更好的优化资源,我们决定将目前 BGP 全线的流量切换一部分到双线上去。说白了很简单,网络方面不需要动什么大手脚,全网 10G 的链路半年之前就全部升级完毕,剩下的就是加前端,10G 服务器,LVS(nat), Keepalived,Nginx。接下来就是小流量的上线测试,从 10M 到 50M 到 100M 再到 300M 前后大概有一周的观察时间,整体还是很稳定的,当然也遇到了一些小问题,比如 10G 网卡不规则的出现了一些 rx_crc_errors/rx_missed_errors,通过优化一些硬件设备基本得到了解决,虽然后期还会时不时的冒出一些,但是从各个服务以及业务的监控方面没有看到潜在的影响,暂时略过。 正所谓稳定压倒一切,从开始小流量切换到正式全量上线的这一个月,为了稳定,充满了坎坷,下面是这一段时间遇到的一些比较有挑战的事件, 「很不幸的是」,全部是人为原因。 4xx 错误飙升 一周之后的某个早上收到报警,4xx, 5xx 的错误上升了大概一倍的样子: 可以确认的是这段时间没有任何的变更,从到后端的请求来看,这段时间的异常并没有对其有很大的影响,但是本着负责任的态度还是把当时的 log 归档拿出来分析了下详情: 可以看到,这段时间的 return code 主要是由 499 以及 500 错误引起,并且 499 的错误占了大部分的,那就从 499 的分析开始。G 了一番,发现这个 code 并非是一个标准的 RFC,唯一可以确认的就是是客户端主动的关闭了链接,至于是什么原因让客户端主动关闭的,原因就太多了。除此之外,还有一部分的稳定的 408 错误,这个比较好理解,对于由于 Nginx 读取客户端发来的请求会造成超时而返回 408。 看了上面的解释,基本得不到很明确的答案。接下来,至少还可以从 debug log 以及 error log 入手,看看能否得到一些信息。 首先看看 error log,关于 Nginx 的…

Read More

nginx 负载均衡集群解决方案 healthcheck_nginx_upstreams (一)

该文章来源于互联网,目前找不到原作者,放在这里的目的是记录healthcheck_nginx_upstreams 的安装过程和相关配置,在起初安装成功后不能够正常运行healthcheck_nginx_upstreams,后通过阅读源码和调试,能够正常运行。 不过信息如下: [html] view plain copy *26 no live upstreams while connecting to upstream   Nginx是一个免费的,开源的,高性能的服务器和反向代理服务器软件,同时它也可以为IMAP和POP3服务器代理,以其高性能,稳定性,丰富的功能,结构简单,低资源消耗的特性换来广大运维者所喜爱。 Nginx与传统的服务器不同,不依赖线程来处理请求。相反,它使用一个更可扩展事件驱动架构(异步)。这种结构资源消耗较小,但更重要的是,可以承受较大的请求负荷。即使你不希望处理成千上万的请求,你仍然可以受益于Nginx的高性能和小的内存占用,以及其丰富的功能。 Nginx的反向代理: 反向代理指以代理服务器来接受Internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给Internet上请求连接到客户端,此时代理服务器对外就表现为一个服务器,而此种工作模式类似于LVS-NET模型。 反向代理也可以理解为web服务器加速,它是一种通过在繁忙的web服务器和外部网络之间增加的 一个高速web缓冲服务器,用来降低实际的web服务器的负载的一种技术。反向代理是针对web服务器提高加速功能,所有外部网络要访问服务器时的所有请求都要通过它,这样反向代理服务器负责接收客户端的请求,然后到源服务器上获取内容,把内容返回给用户,并把内容保存在本地,以便日后再收到同样的信息请求时,它会将本地缓存里的内容直接发给用户,已减少后端web服务器的压力,提高响应速度。因此Nginx还具有缓存功能。 反向代理的工作流程: 1)用户通过域名发出访问请求,该域名被解析为反向代理服务器的IP地址; 2)反向代理服务器接收用户的请求; 3)反向代理服务器在本地缓存查找是否存在当前用户所请求的内容,找到则直接把内容返回给用户; 4)如果本地没有用户请求的内容,反向代理服务器会以自己的身份去后端服务器请求同样的信息内容,并把信息内容发给用户,如果信息内容是可以被缓存的,则会将该内容缓存在代理服务器的本地缓存中。 反向代理的好处: 1)解决了网站服务器对外可见的问题,提高了网站服务器的安全性; 2)节约了有限的IP地址资源,后端服务器均可使用私有IP地址与代理服务器进行通信; 3)加速了网站的访问速度,减轻了真是web服务器的负荷。 (一)、调度算法 Nginx的upstream指令用于指定proxy_pass和fastcgi_pass所使用的后端服务器,即nginx的反向代理功能,因此可以将两者结合起来使用以达到负载均衡的目的,而Nginx也支持多种调度算法: 1、轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,则会跳过该服务器分配至下一个监控的服务器。并且它无需记录当前所有连接的状态,所以它是一种无状态调度。 2、weight 指定在轮询的基础上加上权重,weight和访问比率成正比,即用于表明后端服务器的性能好坏,若后端服务器性能较好则可将大部分请求分配给它,已实现其力所能及。 例如: 我后端服务器172.23.136.148配置:E5520*2 CPU,8G内存 后端服务器172.23.136.148配置:Xeon(TM)2.80GHz * 2,4G内存 我希望在有30个请求到达前端时,其中20个请求交给172.23.136.148处理,剩余10个请求交给172.23.136.149处理,就可做如下配置 upstream web_poll { server 172.23.136.148 weight=10; server 172.23.136.149 weight=5; } 3、ip_hash 每个请求按访问ip的hash结果分配,当新的请求到达时,先将其客户端IP通过哈希算法进行哈希出一个值,在随后的请求客户端IP的哈希值只要相同,就会被分配至同一个后端服务器,该调度算法可以解决session的问题,但有时会导致分配不均即无法保证负载均衡。 例如: upstream web_pool { ip_hash; server 172.23.136.148:80; server 172.23.136.149:80; } 4、fair(第三方) 按后端服务器的响应时间来分配请求,响应时间短的优先分配。 upstream web_pool…

Read More

记一次压测引起的nginx负载均衡性能调优

这边有个性能要求极高的api要上线,这个服务端是golang http模块实现的。在上线之前我们理所当然的要做压力测试。起初是 “小白同学” 起头进行压力测试,但当我看到那压力测试的结果时,我也是逗乐了。   现象是,直接访问Golang http api是每秒可以到3.5W的访问,  为了理论承受更强的QPS,多开了几个go http api进程端口,又在这前面加了层nginx负载均衡,结果往nginx压测的结果是每秒才可以解决1.5w的访问量。 这结果让高级黑 “小白” 把nginx又给鄙视了。 该文章写的有些乱,欢迎来喷 ! 另外文章后续不断更新中,请到原文地址查看更新. http://xiaorui.cc/?p=3495   虽然哥平时开发任务很饱和,又因为带几个新人的原因,有点心累。 但哥还是抽出宝贵的时间来解决nginx在压力测试下性能上不去的问题。 哈哈,这里肯定有人要打我了。  说实话,做运维虽然能时常碰一些负载均衡调度器,但由于很多时候配置都标准化了,新开一个业务线,把配置一scp,然后选择性的修改域名及location就可以了,还真是没遇到过这次的问题。 我们在寻找性能瓶颈的是时候,会频繁的使用后面的工具进行监控,推荐大家使用tmux或者screen开启多个终端监控,用top可以看到nginx及go api的cpu占用率,load值,run数,各个cpu核心的百分比,处理网络的中断。用dstat可以看到流量及上下文切换的测试。  ss + netstat 查看连接数。 首先是压力测试的方法问题 以前做运维的时候,我们一般不会用简单的ab来进行压测,这样会造成压力源过热的情况,正常的针对服务端测试的方法是,分布式压力测试,一个主机压测的结果很是不准,当然前提是 服务端的性能够高,别尼玛整个python django就用分布式压测,随便找个webbench,ab , boom这类的http压测就可以了。 关于客户端压测过热的情况有几个元素,最主要的元素是端口占用情况。首先我们需要明确几个点, 作为服务端只是消耗fd而已,但是客户端是需要占用端口来发起请求。 如果你自己同时作为服务端和客户端,会被受限于65535-1024的限制,1024内一般是常规的系统保留端口。   如果你按照65535-1024计算的话,你可以占用64511端口数,但如果你是自己压力测试nginx,然后nginx又反向代理几个golang http api。  那么这端口被严重的缩水了。   当你压测的数目才6w以上,很明显报错,不想报错,那么只能进行排队阻塞,好让客户端完成该请求。 另外一点是nginx 配置问题。 这一点很重要,也是最基本的要求,如果nginx worker连接数过少的化,你的请求连接就算没有被阻塞到backlog队列外,nginx worker也会因为过载保护不会处理新的请求。nginx的最大连接数是worker num *worker_connections, 默认worker_connections是1024, 直接干到10w就可以了。 在我们配置调整之后,访问的速度有明显的提升,但还是没有达到我们的预期。 接着通过lsof追了下进程,发现nginx 跟 后端创建了大量的连接。  这很明显是没有使用http1.1长连接导致的,使用tcpdump抓包分析了下,果然是http1.0短链接,虽然我们在sysctl内核里做了一些网络tcp回收的优化,但那也赶不上压力测试带来的频繁创建tcp的消耗。   果然在upstream加了keepalive。 1…

Read More

线上nginx的一次“no live upstreams while connecting to upstream ”分析

先描述一下环境,前段的负载均衡转发给nginx,nginx再转发给后端的应用服务器。 nginx配置文件如下: upstream ads {         server ap1:8888 max_fails=1 fail_timeout=60s;         server ap2:8888 max_fails=1 fail_timeout=60s; } 出现的现象是: 日志里面每隔一两分钟就会记录一条类似 *379803415 no live upstreams while connecting to upstream  的日志, 此外,还有大量的“upstream prematurely closed connection while reading response header from upstream”的日志。 我们先看“no live upstreams”的问题。 看字面意思是nginx发现没有存活的后端了,但是很奇怪的事情是,这段时间一直访问都正常,并且用wireshark看到的也是有进来的,也有返回的。 现在只能从nginx源码的角度来看了。 因为是upstream有关的报错,所以在ngx_http_upstream.c中查找“no live upstreams”的关键字,可以找到如下代码(其实,你会发现,如果在nginx全局代码中找的话,也只有这个文件里面有这个关键字):  在这里可以看出,当rc等于NGX_BUSY的时候,就会记录“no live upstreams”的错误。 往上看1328行,可以发现rc的值又是ngx_event_connect_peer这个函数返回的。 ngx_event_connect_peer是在event/ngx_event_connect.c中实现的。这个函数中,只有这个地方会返回NGX_BUSY,其他地方都是NGX_OK或者NGX_ERROR或者NGX_AGAIN之类的。  rc = pc->get(pc, pc->data);…

Read More

MySQL错误: could not retrieve transation read-only status server

问题描述: java代码在开始事务后,先做了一个查询,再insert,此时会报:         java.sql.SQLException: could not retrieve transation read-only status server 解决过程: 查看mysql的事物隔离级别 SHOW VARIABLES LIKE ‘%iso%’; 返回结果: REPEATABLE-READ 把这个改成:READ-COMMITTED 就好了: SET GLOBAL tx_isolation=’READ-COMMITTED’; (记得java重启应用,要永久生效的就改my.ini配置文件) 问题分析: 当数据库隔离级别为REPEATABLE-READ时,查询一个select语句也算是事物的开始,而且在hibernate里会把以select语句开头的事务标记为只读事务,此时在这个事务里再执行insert、update、delete等DML语句就会报错。 http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_tx_read_only