簡述 上篇文章介紹瞭如何搭建 prometheus 監控體系，監控 linux 伺服器，這篇文章跟大家介紹如何監控 redis，以及我們要關註的指標都有哪些 監控 redis 需要關註什麼指標 在《聊聊監控》這篇文章，介紹了 google 提出的監控四個黃金指標（沒看過的朋友可以看看這篇文章），下麵 ...
簡述
上篇文章介紹瞭如何搭建 prometheus 監控體系，監控 linux 伺服器，這篇文章跟大家介紹如何監控 redis，以及我們要關註的指標都有哪些
監控 redis 需要關註什麼指標
在《聊聊監控》這篇文章，介紹了 google 提出的監控四個黃金指標（沒看過的朋友可以看看這篇文章），下麵我們就分別通過延遲、流量、錯誤、飽和度四方面，來看看對應到 redis 中，我們要監控哪些數據指標（metrics）
延遲
redis-cli 提供了--latency命令，可以很方面的讓我們獲取到 redis 執行命令的延遲，其原理是用 redis-cli 連接到 redis-server 上，然後不斷發送ping命令，統計ping命令的耗時
> redis-cli --latency -h 127.0.0.1 -p 6379
min: 0, max: 1, avg: 0.13 (412 samples)可以看到這裡的延遲是0.13ms，因為我是在 redis-server 所在機器執行的--latency命令，下麵看看我在另外一臺機器執行--latnecy命令的結果
> redis-cli -h 192.168.57.140 -p 6379 --latency
min: 0, max: 3, avg: 1.21 (199 samples)可以看到，現在的延遲為1.21ms，證明有大概1.08ms花費在了網路 I/O 上
到這裡可能有些人會說，ping 命令很簡單，是不是不能反饋出真實的命令執行延遲呢？其實，我們都知道，redis 是單線程模型的，如果有一條命令執行的慢，那麼其後面的命令都得等著，所以我們是可以使用 ping 命令的執行耗時來作為 redis 命令執行耗時的指標的
--latency命令只能知道 redis 在什麼時間點延遲比較高，並不知道延遲高是什麼原因造成的，或者說不知道是哪條命令執行比較耗時，導致 redis 延遲高。跟 mysql 一樣，redis 也提供了慢查詢的功能，使用slowlog get [count]可以查看最近執行的慢查詢命令（慢查詢時間通過slowlog-log-slower-than配置指定）
127.0.0.1:6379> SLOWLOG get 1
1) 1) (integer) 47
2) (integer) 1668743666
3) (integer) 13168
4) 1) "hset"
2) "/idents/Default"
3) "tt-fc-dev01.nj"
4) "1668743666"
5) "127.0.0.1:43172"
6) ""流量
在 redis 的流量監控中，我們一般關註的是 redis 每秒的請求數（即執行了多少次操作）、每秒接受跟返回的數據量。這些指標在都可以通過info all命令獲取
> redis-cli -h 127.0.0.1 -p 6379 info all | grep instantaneous
instantaneous_ops_per_sec:0
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00-
instantaneous_ops_per_sec: 每秒執行了多少次操作 -
instantaneous_input_kbps: 每秒接受多少 KiB 的數據 -
instantaneous_output_kbps: 每秒返回多少 KiB 的數據
如果將 redis 作為緩存使用的話，還要關註緩存的命中率，同樣的，可以使用info all命令查詢
> redis-cli -h 127.0.0.1 -p 6379 info all | grep keyspace
keyspace_hits:0
keyspace_misses:1-
keyspace_hits: 自 redis 啟動以來，查詢命令的命中數量 -
keyspace_misses: 自 redis 啟動以來，未命中的數量
有了這兩個指標，就可以通過keyspace_hits / (keyspace_hits + keyspace_misses)計算出緩存的命中率
錯誤
因為 redis 都是記憶體操作，基本不會出現什麼錯誤，有錯誤的話一般是命令寫錯導致的，這一般在開發的時候就解決了，所以不用對錯誤做什麼特殊的監控
飽和度
飽和度指的是 redis 有多“滿”，在 redis 中有兩個數據可以反映出 redis 究竟有多“滿”，一個是記憶體使用率，另外一個是記憶體的碎片率
記憶體使用率可以通過info memory命令查看
> info memory
# Memory
used_memory:1227384
used_memory_human:1.17M
used_memory_rss:4308992
used_memory_rss_human:4.11M
...
maxmemory:134217728
maxmemory_human:128.00M
...
mem_fragmentation_ratio:3.51
...-
used_memory: 使用了多少記憶體 -
used_memory_rss: 操作系統分配了多少記憶體給 redis -
mem_fragmentation_ratio: 即記憶體碎片率，根據use_memory_rss/use_memory計算得出，正常來講，操作系統在分配記憶體的時候，有最小分配單位的限制（不同操作系統不一樣，有 8byte、16byte 等），所以記憶體碎片率稍大於 1 是正常的，如果記憶體碎片率過高，可能就需要考慮對記憶體碎片進行清理了
redis-exporter 安裝使用
redis 本身不通過 prometheus 協議暴露自身的各種數據指標，與node-exporter一樣，我們可以運行通過redis-exporter，將 redis 的指標暴露給 pormetheus
redis-exporter下載地址：https://github.com/oliver006/redis_exporter/releases，目前最新的版本是 1.52.0
$ wget https://github.com/oliver006/redis_exporter/releases/download/v1.52.0/redis_exporter-v1.52.0.linux-amd64.tar.gz
$ tar -zxvf redis_exporter-v1.52.0.linux-amd64.tar.gz
$ mv redis_exporter-v1.52.0
$ cd redis_exporter-v1.52.0
$ ./redis_exporter &redis-exporter暴露的埠是9121，可以通過訪問 9121 查看採集的所有指標
prometheus 配置
在 prometheus 配置文件中加入如下配置
- job_name: 'redis-exporter'
static_configs:
- targets: ['localhost:9121']向 prometheus 發送 HUP 信號，讓 prometheus 重新讀取配置文件
$ kill -HUP `pidof prometheus`prometheus 與 grafana 的安裝，在我上篇文章有講，還不清楚怎麼搭建的同學可以翻閱我上篇文章——《如何搭建 Linux 伺服器監控系統》
grafana 配置
redis 控制面板，我這裡用的是11835這個面板，一樣通過 dashboard ID 的方式導入
監控面板如下
可以看到，面板除了展示了我們上面所講到的指標外（如記憶體使用率、緩存命中數等），還展示了客戶端連接數、redis 正常運行時間等
另外需要註意的是：如果你像下麵一樣不展示記憶體使用率的話
可能是讀取不到redis_memory_max_bytes指標，那是因為沒配置 redis 的最大記憶體，可以在 redis 配置文件中添加maxmemory配置，或者使用config rewrite命令進行修改
127.0.0.1:6379> config set maxmemory 128mb
OK
127.0.0.1:6379> config rewrite
8110:M 07 Aug 2023 09:21:53.983 # CONFIG REWRITE executed with success.
OK總結
本篇文章講了 redis 監控需要關註的指標。並通過redis-exporter的方式，將 redis 的監控納入到 prometheus 體系中來，如果覺得我的文章對你有幫助的話，可以點個關註或者在看哦，你的支持是我寫作的動力。
作者|huangxy
本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/How-to-monitor-Redis.html
