zabbix 生产环境遇到的问题

1)Zabbix监控界面报错Lack of free swap space on Zabbix server”解决

公司线上部署的zabbix3.0的监控界面首页报错说无交换内存主机“Lack of free swap space on Zabbix server”

解决此问题的步骤如下:

选择Configuration->Templates(模板),在模板界面中选择Template OS Linux右侧的Triggers(触发器),在触发器页面中打开Lack of free swap space on {HOST.NAME}项目,在新打开的触发器编辑页面中修改Expression(表达式)的内容,由原先的

{Template OS Linux:system.swap.size[,pfree].last(0)}<50

修改为

{Template OS Linux:system.swap.size[,pfree].last(0)}<50 and {Template OS Linux:system.swap.size[,free].last(0)}<>0

此处修改增加了“ and {Template OS Linux:system.swap.size[,free].last(0)}<>0”判断系统有交换空间,当系统无交换空间即{Template OS Linux:system.swap.size[,free].last(0)}的值为0时将不会时表达式不成立就不会触发错误提示。保存之后在下一个更新周期内Zabbix之前报告的“Lack of free swap space”问题就会被自动标记为Resolved(已解决)。

2)zabbix监控界出现“Zabbix poller processes more than 75% busy ”报警

线上部署的zabbix监控环境运行一段时间后,突然出现了报警“Zabbix poller processes more than 75% busy“

其实,Zabbix的监控警报有很多种,比较常见的几个莫过于内存耗尽,网络不通,IO太慢还有这个“Zabbix poller processes more than 75% busy”了。一开始的时候因为这个即不影响使用也持续一会儿就自行解决就没有多在意。然后随着数据库的增大,Zabbix消耗的内存可是越来越多,Poller processes(轮询)开始天天Busy了.

最后,发现解决这个问题很简单!

可以增加Zabbix Server启动时初始化的进程数量,但这样做直接增加了轮询的负载量,内存配置充足的情况下完全可以这么做。

具体编辑Zabbix Server的配置文件/etc/zabbix/zabbix_server.conf,找到配置StartPollers的段落:

### Option: StartPollers

# Number of pre-forked instances of pollers.

#

# Mandatory: no

# Range: 0-1000

# Default:

# StartPollers=5

取消StartPollers前的#号注释,修改5为10或者更大【由于线上机器内存64G的,我此处修改成60或80】

修改后,重启zabbix_server

#pkill -9 zabbix_server

#/usr/local/zabbix/sbin/zabbix-server

过一会儿就发现触发器里已经没有类似的警告了

当然,我们也可以额定时写个脚本来重启zabbix_server来降低负载

下面是脚本/root/zabbix-restart.sh

#!/bin/bash

/usr/bin/pkill zabbix_server

/usr/local/zabbix/sbin/zabbix_server

然后crontab做计划任务

0 3 * * * /bin/bash -x /root/zabbix-restart.sh > /dev/null 2>&1

3)zabbix Too many processes on

解决办法:将对应的触发器的阀值设置大点(默认是300,可以改到3000)

4)监控图里获取不到数据

可以先在服务端的命令行礼通过命令:

# /usr/local/zabbix/bin/zabbix_get -s 192.168.1.10 -p 10050 -k "mysql.status[Uptime]"

其中:

-s后面跟的是被监控机的ip地址;

-k后面跟的是监控项的键值,这个可以在zabbix页面里对应监控项里查到。

如果在服务端通过以上命令能获取到数据,那么在zabbix监控页面的图形里显示获取不到数据,可能就是web页面里的配置问题了。

5)内存溢出导致zabbix_server服务关闭

138401:20170630:172159.850 using configuration file: /data/zabbix/etc/zabbix_server.conf

138401:20170630:172159.854 current database version (mandatory/optional): 03020000/03020000

138401:20170630:172159.854 required mandatory version: 03020000

138401:20170630:172200.238 __mem_malloc: skipped 0 asked 48 skip_min 4294967295 skip_max 0

138401:20170630:172200.238 [file:strpool.c,line:53] zbx_mem_malloc(): out of memory (requested 42 bytes)

138401:20170630:172200.238 [file:strpool.c,line:53] zbx_mem_malloc(): please increase CacheSize configuration parameter

解决办法:

打开zabbix_server.conf 找到 Option: CacheSize

把原来的 # CacheSize=8M 前面的#注释去掉,将8M修改为1024,这个1024根据服务器性能修改。

# vim /data/zabbix/etc/zabbix_agentd.conf

......

CacheSize=1024M

然后重启zabbix_server即可

6)zabbix数据库连接数超额导致连接失败

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 152   |
+-----------------+-------+
1 row in set (0.00 sec)
 
默认是152的连接数。修改方法如下:
1)临时性修改
mysql> set GLOBAL max_connections=1024;
mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 1024  |
+-----------------+-------+
1 row in set (0.00 sec)

2)永久性修改

在my.cnf文件中配置:

[mysqld]                     //新添加一行如下参数

max_connections=1000

重启mysql服务即可

7)zabbix的web界面中的cpu监控图中显示的负载是0.002-0.0014,这显然是不对的,跟服务器上uptime现实的cpu负载不一致!

解决办法:

修改模板(Template OS Linux)--监控项--Processor load (1 min average per core)--键值:

把 system.cpu.load[percpu,avg1] 改为 system.cpu.load[all,avg1]

8)zabbix_server.log里出现如下报错:

zabbix_server.log里出现如下报错:
95213:20180101:154323.271 cannot send list of active checks to "10.0.8.20": host [jumpserver01.kevin.cn] not found
95212:20180101:154323.549 cannot send list of active checks to "10.0.56.21": host [cx-app02.kevin.cn] not found
95216:20180101:154324.768 cannot send list of active checks to "10.0.54.21": host [bl2-app02.kevin.cn] not found
95212:20180101:154325.072 cannot send list of active checks to "10.0.52.22": host [nc-app02.kevin.cn] not found

原因分析:

zabbix_agentd.conf文件中配置的Hostname内容和zabbix的web界面"配置"->"主机"的主机名称配置不一致导致的,修改成一致内容即可!

9)zabbix_server.log里出现如下报错:

95219:20180101:162139.869 fping failed: /usr/local/sbin/fping: can't create raw socket (must run as root?) : Operation not permitted
95219:20180101:162140.871 fping failed: /usr/local/sbin/fping: can't create raw socket (must run as root?) : Operation not permitted
95219:20180101:162141.874 fping failed: /usr/local/sbin/fping: can't create raw socket (must run as root?) : Operation not permitte

解决办法:

1)确保zabbix的agent客户机的zabbix有sudo权限

[[email protected] ~]# chattr -i /etc/sudoers
[[email protected] ~]# chmod 640 /etc/sudoers
[[email protected] ~]# echo "zabbix  ALL=(ALL)      NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# chmod 440 /etc/sudoers
[[email protected] ~]# chattr +i /etc/sudoers

2)修改zabbix的server服务器端fping的权限 ,这一步很重要!!

[[email protected] ~]# ll /usr/local/sbin/fping
-rwxr-xr-x 1 root root 67110 12月 11 17:18 /usr/local/sbin/fping
[[email protected] ~]# chmod u+s /usr/local/sbin/fping

然后切换到zabbix用户下进行测试

[[email protected] ~]# su - zabbix
[[email protected] ~]$ /usr/local/sbin/fping -s oa-mob01.kevin.cn
oa-mob01.kevin.cn is alive
 
       1 targets
       1 alive
       0 unreachable
       0 unknown addresses
 
       0 timeouts (waiting for response)
       1 ICMP Echos sent
       1 ICMP Echo Replies received
       0 other ICMP received
 
 0.58 ms (min round trip time)
 0.58 ms (avg round trip time)
 0.58 ms (max round trip time)
        0.001 sec (elapsed real time

如果返回 XX.XX.XX.XX is alive,那说明是OK的了!

10)问题说明:在一台zabbix被监控服务器上(64位centos6.8系统,64G内容)启动zabbix_agent,发现进程无法启动,10050端口没有起来!

启动zabbix_agent进程没有报错,但10050端口没有正常启动起来。

[[email protected] ~]# /usr/local/zabbix/sbin/zabbix_agentd
[[email protected] ~]# ps -ef|grep zabbix_agent
root 27506 27360 0 11:07 pts/5 00:00:00 grep --color zabbix
[[email protected] etc]# lsof -i:10050

查看/usr/local/zabbix/logs/zabbix_agentd.log日志,发现报错如下:

................

27667:20161027:111554.851 cannot allocate shared memory of size 657056: [28] No space left on device

27667:20161027:111554.851 cannot allocate shared memory for collector

..............

原因分析:

这是因为内核对share memory的限制造成的。

处理过程记录:

[[email protected] logs]# ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 1940588
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 100
semaphore max value = 32767
------ Messages: Limits --------
max queues system wide = 32768
max size of message (bytes) = 65536
default max size of queue (bytes) = 65536

从上面命令结果可以看到:

max total shared memory设置的是2M,max seg size设置的是8M,这显然不够allocate(分配)zabbix_agent启动所使用的内存。

查看目前的共享内存设置,

[[email protected] logs]# sysctl -a|grep shm
kernel.shmmax = 1987162112
kernel.shmall = 2097152
kernel.shmmni = 4096
kernel.shm_rmid_forced = 0
vm.hugetlb_shm_group = 0

其中kernel.shmall代表总共能分配的共享内存,这里是2G,kernel.shmax代表单个段能allocate的内存(以字节为单位),这里是2M,所以肯定有问题!

然后查看/etc/sysctl.conf

[[email protected] logs]# cat /etc/sysctl.conf
........
kernel.shmall = 2097152
kernel.shmmax = 1987162112

显然在sysctl.conf文件里设置的kernel.shamll和kernel.shmmax参数的值小了。

--------------------------------------------------------------------------------------------------------------------------------------------------

本机是64位的centos 6.8系统,64G内存,查看其它同系统的被监控服务器发现:

[[email protected] ~]# cat /etc/sysctl.conf 
........
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
[[email protected] logs]# ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 67108864
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 100
semaphore max value = 32767
------ Messages: Limits --------
max queues system wide = 32768
max size of message (bytes) = 65536
default max size of queue (bytes) = 65536

即64位的centos6系统(64G)的上面两个参数的默认值是64G和4G,设置的都是系统能识别的最大内存。

---------------------------------------------------------------------------------------------------------------------------------------------------

现在只需要在本机调大这两个参数值即可解决问题!

[[email protected] logs]# cat /etc/sysctl.conf
........
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.msgmnb = 65536 
kernel.msgmax = 65536
执行sysctl -p生效
[[email protected] logs]# sysctl -p

再次查看发现已经修改成功了!

[[email protected] logs]# sysctl -a|grep shm
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.shm_rmid_forced = 0
vm.hugetlb_shm_group = 0
[[email protected] logs]# ipcs -l

------ Shared Memory Limits --------

max number of segments = 4096

max seg size (kbytes) = 67108864

max total shared memory (kbytes) = 17179869184

min seg size (bytes) = 1

------ Semaphore Limits --------

max number of arrays = 128

max semaphores per array = 250

max semaphores system wide = 32000

max ops per semop call = 100

semaphore max value = 32767

------ Messages: Limits --------

max queues system wide = 32768

max size of message (bytes) = 65536

default max size of queue (bytes) = 65536

最后重新启动zabbix,发现10050端口顺利启动了:

[[email protected] ~]# /usr/local/zabbix/sbin/zabbix_agentd
[[email protected] logs]# ps -ef|grep zabbix
zabbix 27776 1 0 11:22 ? 00:00:00 /usr/local/zabbix/sbin/zabbix_agentd
zabbix 27777 27776 0 11:22 ? 00:00:00 /usr/local/zabbix/sbin/zabbix_agentd: collector [idle 1 sec]
zabbix 27778 27776 0 11:22 ? 00:00:00 /usr/local/zabbix/sbin/zabbix_agentd: listener #1 [waiting for connection]
zabbix 27779 27776 0 11:22 ? 00:00:00 /usr/local/zabbix/sbin/zabbix_agentd: listener #2 [waiting for connection]
zabbix 27780 27776 0 11:22 ? 00:00:00 /usr/local/zabbix/sbin/zabbix_agentd: listener #3 [waiting for connection]
zabbix 27781 27776 0 11:22 ? 00:00:00 /usr/local/zabbix/sbin/zabbix_agentd: active checks #1 [idle 1 sec]
root 28188 27360 0 11:48 pts/5 00:00:00 grep --color zabbix
[[email protected] logs]# lsof -i:10050
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
zabbix_ag 27776 zabbix 4u IPv4 112357384 0t0 TCP *:zabbix-agent (LISTEN)
zabbix_ag 27777 zabbix 4u IPv4 112357384 0t0 TCP *:zabbix-agent (LISTEN)
zabbix_ag 27778 zabbix 4u IPv4 112357384 0t0 TCP *:zabbix-agent (LISTEN)
zabbix_ag 27779 zabbix 4u IPv4 112357384 0t0 TCP *:zabbix-agent (LISTEN)
zabbix_ag 27780 zabbix 4u IPv4 112357384 0t0 TCP *:zabbix-agent (LISTEN)
zabbix_ag 27781 zabbix 4u IPv4 112357384 0t0 TCP *:zabbix-agent (LISTEN)

原文地址:http://blog.51cto.com/hsuing/2112621

时间: 2024-10-06 13:47:23

zabbix 生产环境遇到的问题的相关文章

zabbix生产环境上监控配置

目前生产环直要监控指标 1.zabbix_agentd.conf UserParameter=system1.uname,/bin/uname -r ###Recv-q #UserParameter=recv-q,ss -nl|awk '{print $2}'|grep -v "Recv-Q"|awk '{if($1>0) {print 1}}'|wc -l ####memory UserParameter=master.memtotal,echo "scale=2;`

Zabbix监控平台(三)生产环境案例

Zabbix监控平台(三)生产环境案例 一,Zabbix生产环境监测案例概述 1.1 项目规划 1.2 SNMP监控流程 1.3 IPMI 1.4 JMX(使用Zabbix Java Gateway代理) 1.5 实战监控Nginx,Apache,MySQL,PHP-fpm 1.6 Zabbix的Web监测 二,Zabbix监控MySQL数据库操作实战 2.1 编写监控脚本 2.2 在zabbix-agent端创建自定义键值配置文件 2.3 在zabbix-server端测试键值 2.4 在za

TokuDB在生产环境的应用场景(zabbix也可以)

一 .背景介绍 近年来,TokuDB作为MySQL的大数据(Big Data)存储引擎受到人们的普遍关注.其架构的核心基于一种新的叫做分形树(Fractal Trees)的索引数据结构,该结构是缓存无关的,即使索引数据大小超过内存性能也不会下降,也即没有内存生命周期和碎片的问题.特别引人注意的是,TokuDB拥有很高的压缩比(官方称最大可达25倍),可以在很大的数据上创建大量的索引,并保持性能不下降.同时,TokuDB支持ACID和MVCC,还有在线修改表结构(Live Schema Modif

Docker适合生产环境了吗?

之所以称为生产环境就是因为它可以为企业创造利润.所以答案非常清晰:视情况而定. Docker.是现今最前沿的科技. 同时,它也是近10年最具挑战性的技术,原因在于它革新了软件开发.运维.系统架构.测试以及常规做法. Dokcer至今才诞生仅两年时间.你会用一个仅发展两年左右的数据库技术吗?亦或是一个操作系统?向前兼容性很差,升级会造成对先前软件的不兼容,这是Docker存在的问题,但请不要因这个事实丧失尝试的勇气. 同时,也还有一些大的碎片问题围绕在持续部署,网络及认证管理上.对于生产环境而言,

生产环境中部署:zabbix3.2.1 (ubuntu系统)

一.配置 角色 IP 主机名 虚拟IP Zabbixserver主节点 10.36.1.55 Compute51 10.36.1.101 Zabbixserver从节点 10.36.1.56 Compute52 mysql数据库主节点 10.36.1.1 Controller1 10.36.1.100 mysql数据库从节点 10.36.1.17 Controller2 二.安装 本次部署完全是参照zabbix官方文档进行部署 https://www.zabbix.com/documentati

Zabbix3.0入门到生产环境应用实战

套视频是应大多数从业运维朋友的强烈要求,综合市场现有zabbix教程的精华推出,结合生产环境从简单系统自带的模板监控到自定义监控讲解,结合现在流行的saltstack自动化工具以及zabbix自动化监控进行应用各方面监控和讲解,其功能可以做到批量部署,批量监控,细化到进程以及URL的监控,涵盖了硬件监控,系统监控,应用监控,安全监控 技术要点:1.实现一整套企业级zabbix监控,从零开始去一步步实现生产环境的监控2.zabbix 强大内置key讲解,了解linux oskey要点,了解和使用内

Liu Junqiao:生产环境中shell脚本实例

在生产环境中,我们时常要注意主机的各种硬件状态,如果是规模较大的服务集群zabbix等健康工具当然好用,如果只是一些小规模的服务主机,shell就会表现的更灵活,也更适用,今天就和大家分享一个系统巡检脚本! 1 #!/bin/bash 2 3 function system(){ 4 echo "#########################系统信息#########################" 5 OS_TYPE=`uname` 6 OS_VER=`cat /etc/red

redis的单机安装与配置以及生产环境启动方案

简单介绍一下redis的单机安装与配置,方便自己记录安装步骤的同时方便他人获取知识. 首先,从官网下载最新版的(稳定版)的redis安装包.官网地址如下:https://redis.io/download 下载源码包后,redis需要编译安装.需要安装gcc和tcl,gcc用于编译tcl用于测试. 使用命令安装gcc,yum install gcc,一路选择yes,gcc就可以安装成功. 接下来安装tcl,首先获取tcl源码包(见百度云盘)或者使用命令:wget http://downloads

Beego生产环境返回状态码的bug

项目用的是Beego的1.4.2.但是最近发现cdn会把项目中的40x或者50x的页面缓存住. 研究了下Beego的源码,然后经过测试后发现,在生产环境下,当请求的页面出错时,返回的页面的状态码40x或者50x会被统一改为200. 这个是因为开发者谢大将写入response的状态码的那行给注释了. 要是用Beego的同僚注意了,这个地方得自己处理下. 如下处理即可: 在main.go中: package main import ( "github.com/astaxie/beego"