Zabbix5.0监控Redis
1.什么是Redis

(18条消息) Zabbix5.0监控Redis_^全村的希望的博客-CSDN博客_zabbix监控redis
​ Redis是一个开源的高性能NoSQL数据库,可称为远程字典服务。

基于内存运行，性能高效
支持分布式，理论上可以无限扩展
key-value存储系统
使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API
1.1 基础概念普及
1.1.1 应用场景
​ 缓存系统（“热点”数据：高频读、低频写）、计数器、消息队列系统、排行榜、社交网络和实时系统。

1.1.2 数据类型
​ 和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。

1.1.3 操作命令
1.1.3.1 字符串类型string
它是一个二进制安全的字符串，不仅可以存储字符串，还能存储图片、视频等多种类型。

GET/MGET
SET/SETEX/MSET/MSETNX
INCR/DECR
GETSET
DEL
1.1.3.2 哈希类型hash
该类型就是key和value组的Hash表。

HGET/HMGET/HGETALL
HSET/HMSET/HSETNX
HEXISTS/HLEN
HKEYS/HDEL
HVALS
1.1.3.3 列表类型list
该类型是基于双链表实现，是按插入顺序排序的字符串集合。

LPUSH/LPUSHX/LPOP/RPUSH/RPUSHX/RPOP/LINSERT/LSET
LINDEX/LRANGE
LLEN/LTRIM
1.1.3.4 集合类型set
set类型和list类型的最大区别是:元素是唯一的且元素没有顺序，底层是基于哈希表不是双链表。

SADD/SPOP/SMOVE/SCARD
SINTER/SDIFF/SDIFFSTORE/SUNION
1.1.3.4 顺序集合类型zset
ZSet是一种有序集合类型，每个元素都会关联一个分数权值，通过权值来为集合中的成员进行从小到大的排序。

ZADD/ZPOP/ZMOVE/ZCARD/ZCOUNT
ZINTER/ZDIFF/ZDIFFSTORE/ZUNION
1.1.4 持久化机制
redis是一个内存数据库，数据保存在内存中，但是我们都知道内存的数据变化是很快的，也容易发生丢失。幸好Redis还为我们提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)。

1.1.4.1 RDB 机制
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

①、优势

（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

②、劣势

RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

1.1.4.2 AOF 机制
全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

①、优势

（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒执行一次fsync操作，最多丢失1秒钟的数据。

（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。

（3）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

②、劣势

（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。

（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。

（3）AOF可能存在bug，出现过不能恢复一模一样的数据的情况。

1.2 常见的问题
1.2.1 击穿问题
​ 在Redis获取某一key时, 由于key不存在, 而必须向DB发起一次请求的行为, 称为“Redis击穿”。

 

引发击穿的原因：恶意访问不存在的key、Key过期

改善的方案：对某些高频访问的Key，设置合理的TTL或永不过期、标准化key的命名后可以拦截不规范的key

1.2.2 雪崩问题
​ Redis缓存层由于某种原因宕机后，所有的请求会涌向存储层，短时间内的高并发请求可能会导致存储层挂机，称之为“Redis雪崩”。

改善的方案：限流、使用Redis集群

2.如何监控Redis
2.1 使用zabbix5.0监控
zabbix5.0提供了一个redis的监控模板，专业和实用，我们选择这个自带的模板（Template DB Redis）进行监控redis就行，该模板提供了64个监控项和13个触发器，非常详细。

2.1.1 前置条件
安装有Redis-server服务，可以运行redis-cli命令
在Redis-server服务器上安装zabbix-agent2
2.1.2 配置Redis模板
使用zabbix5.0自带的模板监控Redis非常方便，三步搞定。

第一步，选择要监控的主机（该主机上部署有Redis服务），点击模板选项卡并选择。

 

第二步，选择主机群主Templates，再找到模板【Template DB Redis】点选择，然后点击更新，就绑定关联了。

 

第三步，查看最新数据，如果有数据，就说明可以正常监控Redis。

 

2.1.3 监控原理
该方案数据采集原理是通过客户端agent调用redis-cli采集的。

#通过执行以下命令info采集监控数据：
redis-cli -h 166.8.50.* -p 端口号 -a 'password' info
#通过读取redis安装目录下的redis.conf文件内容
redis 127.0.0.1:6379> CONFIG GET *
1
2
3
4
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pJrOzMmm-1631701376129)(C:\Users\Test\Desktop\Zabbix5.0监控Redis.assets\图片1.png)]

默认采集地址是{$REDIS.CONN.URI} 6379端口

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E9y01hig-1631701376130)(C:\Users\Test\Desktop\Zabbix5.0监控Redis.assets\图片2.png)]

从上面的提示可以看出，Template DB Redis的宏配置是默认Server端不设置密码的，如果Redis-server设置了密码，需要额外配置，否则会报如下错误：

Redis.ping[“{KaTex parse error:Expected ‘EOF’ , got ‘}’ at position 15:
REDIS.CONN.URI}”,”{REDIS.AUTH}”]
1
2
添加下面的宏就可以解决上述问题

{$REDIS.AUTH}=<password>
1
2.2 模板监控指标介绍
1.3.1 性能指标 Performance
# redis-cli info
instantaneous_ops_per_sec:0 #平均每秒处理请求总数
instantaneous_input_bytes:0.01 #输入带宽(单位字节)
instantaneous_output_bytes:0.00 #输出带宽(单位字节)
total_commands_processed:642719 #Redis服务处理命令的总数(字段的值是递增的)
1
2
3
4
5
1.3.2 内存指标 Memory
# redis-cli info
used_memory:831391096 #由 Redis分配器分配的内存总量（以字节为单位）
used_memory_rss:888795136 #从操作系统的角度，返回 Redis 已分配的内存总量（ top 输出一致）
used_memory_peak:833008000 #Redis 的内存消耗峰值（以字节为单位）
used_memory_lua:37888 #Lua 引擎所使用的内存大小（以字节为单位）
mem_fragmentation_ratio:1.07 #内存碎片比率
1
2
3
4
5
6
1.3.3 基本活动指标 Basic activity
包括Client连接数和key指标。

# redis-cli info
connected_clients:2 #已连接客户端的数量（不包括通过从属服务器连接的客户端）
connected_slaves:0 #通过从属服务器连接的客户端
blocked_clients:0 #由于BLPOP,BRPOP or BRPOP,LPUSH而阻塞的客户端
evicted_keys:0 #由于最大内存限制被移除的key的数量
expired_keys:0 #因为过期而被自动删除的数据库键数量
keyspace_hits:1 #查找数据库键成功的次数
keyspace_misses:0 #查找数据库键失败的次数
keyspace_hit_ratio #keyspace_hits/(keyspace_hits+keyspace_misses)
rejected_connections:0 # redis连接个数达到maxclients限制，拒绝新连接的个数
total_connections_received:6 #新创建连接个数
# CONFIG GET *
maxclients:4064 #最大可同时连接的客户端数量
1
2
3
4
5
6
7
8
9
10
11
12
13
1.3.4 持久性指标 Persistence
​ 持久化指标主要是体现RDB和AOF的工作状态。

# redis-cli info
rdb_changes_since_last_save:7358 #距离最近一次成功创建持久化文件之后，经过了多少秒
rdb_bgsave_in_progress:0 #一个标志值，记录了服务器是否正在创建 RDB 文件
rdb_last_save_time:1505285008 #最近一次成功创建 RDB 文件的 UNIX 时间戳
rdb_last_bgsave_status:ok #一个标志值，记录了最近一次创建 RDB 文件的结果是成功还是失败
rdb_last_bgsave_time_sec:10 #记录了最近一次创建 RDB 文件耗费的秒数
rdb_current_bgsave_time_sec:-1 #如果服务器正在创建 RDB 文件，那么这个值记录的就是当前的创建操作已经耗费的秒数
aof_enabled:1 #redis是否开启了aof
aof_rewrite_in_progress:0 #一个标志值，记录了服务器是否正在创建 AOF 文件
aof_rewrite_scheduled:0 #一个标志值，记录了在 RDB 文件创建完毕后，是否需要执行预约的 AOF 重写操作
aof_last_rewrite_time_sec:4 #最近一次创建 AOF 文件耗费的时长
aof_current_rewrite_time_sec:-1 #如果服务器正在创建 AOF文件，当前的创建操作已经耗费的秒数
aof_last_bgrewrite_status:ok #一个标志值，记录了最近一次创建 AOF 文件的结果是成功还是失败
aof_last_write_status:ok
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2.3 zabbix监控触发器

————————————————
版权声明：本文为CSDN博主「^全村的希望」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_43091761/article/details/120314353

发表评论

邮箱地址不会被公开。 必填项已用*标注