Zabbix5.0監控Redis

1.什么是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 *

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(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}”]

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

{$REDIS.AUTH}=<password>

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.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.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.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

2.3 zabbix監控觸發器

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。