Zabbix5.0監(jiān)控Redis

1.什么是Redis

? Redis是一個開源的高性能NoSQL數(shù)據(jù)庫,可稱為遠(yuǎn)程字典服務(wù)。

• 基于內(nèi)存運(yùn)行，性能高效
• 支持分布式，理論上可以無限擴(kuò)展
• key-value存儲系統(tǒng)
• 使用ANSI C語言編寫、遵守BSD協(xié)議、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API

1.1 基礎(chǔ)概念普及

1.1.1 應(yīng)用場景

? 緩存系統(tǒng)（“熱點”數(shù)據(jù)：高頻讀、低頻寫）、計數(shù)器、消息隊列系統(tǒng)、排行榜、社交網(wǎng)絡(luò)和實時系統(tǒng)。

1.1.2 數(shù)據(jù)類型

? 和Memcached類似，它支持存儲的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。

1.1.3 操作命令

1.1.3.1 字符串類型string

它是一個二進(jìn)制安全的字符串，不僅可以存儲字符串，還能存儲圖片、視頻等多種類型。

• 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

該類型是基于雙鏈表實現(xiàn)，是按插入順序排序的字符串集合。

• LPUSH/LPUSHX/LPOP/RPUSH/RPUSHX/RPOP/LINSERT/LSET
• LINDEX/LRANGE
• LLEN/LTRIM

1.1.3.4 集合類型set

set類型和list類型的最大區(qū)別是:元素是唯一的且元素沒有順序，底層是基于哈希表不是雙鏈表。

• SADD/SPOP/SMOVE/SCARD
• SINTER/SDIFF/SDIFFSTORE/SUNION

1.1.3.4 順序集合類型zset

ZSet是一種有序集合類型，每個元素都會關(guān)聯(lián)一個分?jǐn)?shù)權(quán)值，通過權(quán)值來為集合中的成員進(jìn)行從小到大的排序。

• ZADD/ZPOP/ZMOVE/ZCARD/ZCOUNT
• ZINTER/ZDIFF/ZDIFFSTORE/ZUNION

1.1.4 持久化機(jī)制

redis是一個內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)保存在內(nèi)存中，但是我們都知道內(nèi)存的數(shù)據(jù)變化是很快的，也容易發(fā)生丟失。幸好Redis還為我們提供了持久化的機(jī)制，分別是RDB(Redis DataBase)和AOF(Append Only File)。

1.1.4.1 RDB 機(jī)制

RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。也是默認(rèn)的持久化方式，這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到二進(jìn)制文件中,默認(rèn)的文件名為dump.rdb。

①、優(yōu)勢

（1）RDB文件緊湊，全量備份，非常適合用于進(jìn)行備份和災(zāi)難恢復(fù)。

（2）生成RDB文件的時候，redis主進(jìn)程會fork()一個子進(jìn)程來處理所有保存工作，主進(jìn)程不需要進(jìn)行任何磁盤IO操作。

（3）RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快。

②、劣勢

RDB快照是一次全量備份，存儲的是內(nèi)存數(shù)據(jù)的二進(jìn)制序列化形式，存儲上非常緊湊。當(dāng)進(jìn)行快照持久化時，會開啟一個子進(jìn)程專門負(fù)責(zé)快照持久化，子進(jìn)程會擁有父進(jìn)程的內(nèi)存數(shù)據(jù)，父進(jìn)程修改內(nèi)存子進(jìn)程不會反應(yīng)出來，所以在快照持久化期間修改的數(shù)據(jù)不會被保存，可能丟失數(shù)據(jù)。

1.1.4.2 AOF 機(jī)制

全量備份總是耗時的，有時候我們提供一種更加高效的方式AOF，工作機(jī)制很簡單，redis會將每一個收到的寫命令都通過write函數(shù)追加到文件中。通俗的理解就是日志記錄。

①、優(yōu)勢

（1）AOF可以更好的保護(hù)數(shù)據(jù)不丟失，一般AOF會每隔1秒執(zhí)行一次fsync操作，最多丟失1秒鐘的數(shù)據(jù)。

（2）AOF日志文件沒有任何磁盤尋址的開銷，寫入性能非常高，文件不容易破損。

（3）AOF日志文件的命令通過非常可讀的方式進(jìn)行記錄，這個特性非常適合做災(zāi)難性的誤刪除的緊急恢復(fù)。比如某人不小心用flushall命令清空了所有數(shù)據(jù)，只要這個時候后臺rewrite還沒有發(fā)生，那么就可以立即拷貝AOF文件，將最后一條flushall命令給刪了，然后再將該AOF文件放回去，就可以通過恢復(fù)機(jī)制，自動恢復(fù)所有數(shù)據(jù)

②、劣勢

（1）對于同一份數(shù)據(jù)來說，AOF日志文件通常比RDB數(shù)據(jù)快照文件更大。

（2）AOF開啟后，支持的寫QPS會比RDB支持的寫QPS低，因為AOF一般會配置成每秒fsync一次日志文件，當(dāng)然，每秒一次fsync，性能也還是很高的。

（3）AOF可能存在bug，出現(xiàn)過不能恢復(fù)一模一樣的數(shù)據(jù)的情況。

1.2 常見的問題

1.2.1 擊穿問題

? 在Redis獲取某一key時, 由于key不存在, 而必須向DB發(fā)起一次請求的行為, 稱為“Redis擊穿”。

引發(fā)擊穿的原因：惡意訪問不存在的key、Key過期

改善的方案：對某些高頻訪問的Key，設(shè)置合理的TTL或永不過期、標(biāo)準(zhǔn)化key的命名后可以攔截不規(guī)范的key

1.2.2 雪崩問題

? Redis緩存層由于某種原因宕機(jī)后，所有的請求會涌向存儲層，短時間內(nèi)的高并發(fā)請求可能會導(dǎo)致存儲層掛機(jī)，稱之為“Redis雪崩”。

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

2.如何監(jiān)控Redis

2.1 使用zabbix5.0監(jiān)控

zabbix5.0提供了一個redis的監(jiān)控模板，專業(yè)和實用，我們選擇這個自帶的模板（Template DB Redis）進(jìn)行監(jiān)控redis就行，該模板提供了64個監(jiān)控項和13個觸發(fā)器，非常詳細(xì)。

2.1.1 前置條件

• 安裝有Redis-server服務(wù)，可以運(yùn)行redis-cli命令
• 在Redis-server服務(wù)器上安裝zabbix-agent2

2.1.2 配置Redis模板

使用zabbix5.0自帶的模板監(jiān)控Redis非常方便，三步搞定。

第一步，選擇要監(jiān)控的主機(jī)（該主機(jī)上部署有Redis服務(wù)），點擊模板選項卡并選擇。

第二步，選擇主機(jī)群主Templates，再找到模板【Template DB Redis】點選擇，然后點擊更新，就綁定關(guān)聯(lián)了。

第三步，查看最新數(shù)據(jù)，如果有數(shù)據(jù)，就說明可以正常監(jiān)控Redis。

2.1.3 監(jiān)控原理

該方案數(shù)據(jù)采集原理是通過客戶端agent調(diào)用redis-cli采集的。

#通過執(zhí)行以下命令info采集監(jiān)控數(shù)據(jù)： redis-cli -h 166.8.50.* -p 端口號 -a 'password' info #通過讀取redis安裝目錄下的redis.conf文件內(nèi)容 redis 127.0.0.1:6379> CONFIG GET *

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-pJrOzMmm-1631701376129)(C:\Users\Test\Desktop\Zabbix5.0監(jiān)控Redis.assets\圖片1.png)]

默認(rèn)采集地址是{$REDIS.CONN.URI} 6379端口

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-E9y01hig-1631701376130)(C:\Users\Test\Desktop\Zabbix5.0監(jiān)控Redis.assets\圖片2.png)]

從上面的提示可以看出，Template DB Redis的宏配置是默認(rèn)Server端不設(shè)置密碼的，如果Redis-server設(shè)置了密碼，需要額外配置，否則會報如下錯誤：

Redis.ping[“{KaTex parse error:Expected ‘EOF’ , got ‘}’ at position 15: REDIS.CONN.URI}”,”{REDIS.AUTH}”]

添加下面的宏就可以解決上述問題

{$REDIS.AUTH}=<password>

2.2 模板監(jiān)控指標(biāo)介紹

1.3.1 性能指標(biāo) Performance

# redis-cli info instantaneous_ops_per_sec:0 #平均每秒處理請求總數(shù) instantaneous_input_bytes:0.01 #輸入帶寬(單位字節(jié)) instantaneous_output_bytes:0.00 #輸出帶寬(單位字節(jié)) total_commands_processed:642719 #Redis服務(wù)處理命令的總數(shù)(字段的值是遞增的)

1.3.2 內(nèi)存指標(biāo) Memory

# redis-cli info used_memory:831391096 #由 Redis分配器分配的內(nèi)存總量（以字節(jié)為單位） used_memory_rss:888795136 #從操作系統(tǒng)的角度，返回 Redis 已分配的內(nèi)存總量（ top 輸出一致） used_memory_peak:833008000 #Redis 的內(nèi)存消耗峰值（以字節(jié)為單位） used_memory_lua:37888 #Lua 引擎所使用的內(nèi)存大小（以字節(jié)為單位） mem_fragmentation_ratio:1.07 #內(nèi)存碎片比率

1.3.3 基本活動指標(biāo) Basic activity

包括Client連接數(shù)和key指標(biāo)。

# redis-cli info connected_clients:2 #已連接客戶端的數(shù)量（不包括通過從屬服務(wù)器連接的客戶端） connected_slaves:0 #通過從屬服務(wù)器連接的客戶端 blocked_clients:0 #由于BLPOP,BRPOP or BRPOP,LPUSH而阻塞的客戶端 evicted_keys:0 #由于最大內(nèi)存限制被移除的key的數(shù)量 expired_keys:0 #因為過期而被自動刪除的數(shù)據(jù)庫鍵數(shù)量 keyspace_hits:1 #查找數(shù)據(jù)庫鍵成功的次數(shù) keyspace_misses:0 #查找數(shù)據(jù)庫鍵失敗的次數(shù) keyspace_hit_ratio #keyspace_hits/(keyspace_hits+keyspace_misses) rejected_connections:0 # redis連接個數(shù)達(dá)到maxclients限制，拒絕新連接的個數(shù) total_connections_received:6 #新創(chuàng)建連接個數(shù) # CONFIG GET * maxclients:4064 #最大可同時連接的客戶端數(shù)量

1.3.4 持久性指標(biāo) Persistence

? 持久化指標(biāo)主要是體現(xiàn)RDB和AOF的工作狀態(tài)。

# redis-cli info rdb_changes_since_last_save:7358 #距離最近一次成功創(chuàng)建持久化文件之后，經(jīng)過了多少秒 rdb_bgsave_in_progress:0 #一個標(biāo)志值，記錄了服務(wù)器是否正在創(chuàng)建 RDB 文件 rdb_last_save_time:1505285008 #最近一次成功創(chuàng)建 RDB 文件的 UNIX 時間戳 rdb_last_bgsave_status:ok #一個標(biāo)志值，記錄了最近一次創(chuàng)建 RDB 文件的結(jié)果是成功還是失敗 rdb_last_bgsave_time_sec:10 #記錄了最近一次創(chuàng)建 RDB 文件耗費(fèi)的秒數(shù) rdb_current_bgsave_time_sec:-1 #如果服務(wù)器正在創(chuàng)建 RDB 文件，那么這個值記錄的就是當(dāng)前的創(chuàng)建操作已經(jīng)耗費(fèi)的秒數(shù) aof_enabled:1 #redis是否開啟了aof aof_rewrite_in_progress:0 #一個標(biāo)志值，記錄了服務(wù)器是否正在創(chuàng)建 AOF 文件 aof_rewrite_scheduled:0 #一個標(biāo)志值，記錄了在 RDB 文件創(chuàng)建完畢后，是否需要執(zhí)行預(yù)約的 AOF 重寫操作 aof_last_rewrite_time_sec:4 #最近一次創(chuàng)建 AOF 文件耗費(fèi)的時長 aof_current_rewrite_time_sec:-1 #如果服務(wù)器正在創(chuàng)建 AOF文件，當(dāng)前的創(chuàng)建操作已經(jīng)耗費(fèi)的秒數(shù) aof_last_bgrewrite_status:ok #一個標(biāo)志值，記錄了最近一次創(chuàng)建 AOF 文件的結(jié)果是成功還是失敗 aof_last_write_status:ok

2.3 zabbix監(jiān)控觸發(fā)器

總結(jié)

以上是生活随笔為你收集整理的Zabbix5.0监控Redis的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。