對運行狀態的Redis實例進行監控是運維管理中非常重要的內容，包括：監控Redis的內存、監控Redis的吞吐量、監控Redis的運行時信息和監控Redis的延時。通過Redis提供的監控命令便能非常方便地實現對各項指標的監控。
一、監控Redis的內存
視頻講解如下：
https://www.bilibili.com/video/BV1mi28YXE14/?aid=113294358616...
Redis監控內存最直接的方法當然就是使用系統提供的info命令來做了。只需要執行下面一條命令，就能獲得Redis關於內存的狀態報告。
bin/redis-cli info |grep mem
輸出的信息如下：
used_memory:873720 Redis分配的總內存量。
used_memory_human:853.24K 以可讀方式展示Redis分配的總內存量。
used_memory_rss:9809920 Redis總佔用內存量。
used_memory_rss_human:9.36M 可讀方式展示Redis總佔用內存量。
used_memory_peak:931792 內存使用量的峯值。
used_memory_peak_human:909.95K 可讀方式展示內存使用量的峯值。
used_memory_peak_perc:93.77% 內存使用量峯值的百分比。
used_memory_overhead:810000 緩衝區等佔用的內存。
used_memory_startup:809992 啓動Redis實例時消耗的內存。
used_memory_dataset:63720 Redis數據所佔用的內存。
used_memory_dataset_perc:99.99% Redis數據所佔用內存的百分比。
total_system_memory:4126871552 操作系統總內存。
total_system_memory_human:3.84G 可讀方式展示操作系統總內存。
used_memory_lua:37888 LUA腳本消耗的內存。
used_memory_lua_human:37.00K 可讀方式展示LUA腳本消耗的內存。
used_memory_scripts:0
used_memory_scripts_human:0B
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:12.11 內存的碎片率。
mem_fragmentation_bytes:8999912 內存碎片的大小。
mem_not_counted_for_evict:4
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:0
mem_aof_buffer:8
mem_allocator:jemalloc-5.1.0 Redis內存分配器版本。二、監控Redis的吞吐量
視頻講解如下：
https://www.bilibili.com/video/BV1Po2iYeE7e/?aid=113299056302...
通過執行下面命令可以監控Redis的吞吐量。
127.0.0.1:6379 > info stats
輸出的信息如下：
# Stats
total_connections_received:1 總的連接數請求。
total_commands_processed:1 從Redis啓動以來總計處理的命令數。
instantaneous_ops_per_sec:0 當前Redis實例的OPS。
total_net_input_bytes:42 網絡總入量。
total_net_output_bytes:20324 網絡總出量。
instantaneous_input_kbps:0.00 每秒輸入量，單位是kb/s。
instantaneous_output_kbps:0.00 每秒輸出量，單位是kb/s。
rejected_connections:0 被拒絕的連接數。
......三、監控Redis的運行時信息
視頻講解如下：
https://www.bilibili.com/video/BV12f26YmEGs/?aid=113300633294...
Redis提供的info命令不僅能夠查看實時的吞吐量(ops/sec)，還能看到一些有用的運行時信息。下面用grep過濾出一些比較重要的實時信息，比如已連接的和在阻塞的客户端、已用內存、拒絕連接、實時的tps和數據流量等。執行下面的命令：
bin/redis-cli info | \
grep -e "connected_clients" \
-e "blocked_clients" \
-e "used_memory_human" \
-e "used_memory_peak_human" \
-e "rejected_connections" \
-e "evicted_keys" \
-e "instantaneous"
輸出的信息如下：
connected_clients:2 已連接的客户端數。
blocked_clients:0 已阻塞的客户端數
used_memory_human:2.41G 已使用的內存大小。
used_memory_peak_human:2.41G 已使用內存大小的峯值。
instantaneous_ops_per_sec:0 每秒處理的指令數。
instantaneous_input_kbps:0.00 每秒讀取的字節數。
instantaneous_output_kbps:0.00 每秒寫入的字節數
rejected_connections:0 被拒絕的連接數。
evicted_keys:0 Redis實例啓動以來被刪除的鍵的數量。四、監控Redis的延時
視頻講解如下：
https://www.bilibili.com/video/BV1fr2dYLEtH/?aid=113310313815...
Redis中的延時可以通過客户端進行手動的監控，也可以由服務器內部進行自動的延遲監控。從客户端可以監控Redis的延遲，利用Redis提供的PING命令，不斷PING服務端，記錄服務端響應PONG的時間。下面開兩個終端，一個監控延遲，一個監視服務端收到的命令。如果我們故意用DEBUG命令製造延遲，就能看到一些輸出上的變化。
服務端內部的延遲監控稍微麻煩一些，因為延遲記錄的默認閾值是0。儘管空間和時間耗費很小，Redis為了高性能還是默認關閉了它。所以首先我們要開啓它，設置一個合理的閾值
下面通過具體的示例來進行演示。
（1）執行下面的命令使用Redis客户端進行手動監控。
bin/redis-cli --latency
輸出的信息如下：
min: 0, max: 1, avg: 0.22 (211 samples)
提示：此時會發現Redis一直在執行延時監控，並將結果輸出到屏幕上。（2）新開啓一個Redis客户端，通過debug命令手動觸發一個延時。
127.0.0.1:6379 > debug sleep 2（3）觀察第（1）步中輸出的信息。
min: 0, max: 1991, avg: 0.40 (7557 samples)
提示：這時候可以看出Redis監控到目前產生的最大演示是1991毫秒，即2秒左右。（4）查看服務器內部監控的閾值設定。
127.0.0.1:6379> config get latency-monitor-threshold
輸出的信息如下：
1) "latency-monitor-threshold"
2) "0"
提示：在默認情況下，Redis關閉了延遲的服務器內部監控機制。（5）設置服務器內部監控閾值是100毫秒。
127.0.0.1:6379> config set latency-monitor-threshold 100（6）手動觸發一些延遲。
127.0.0.1:6379 > debug sleep 2
127.0.0.1:6379 > debug sleep .15
127.0.0.1:6379 > debug sleep .5（7）使用latency命令查看產生的延遲信息。
# 查看最近一次產生的延遲。
127.0.0.1:6379> latency latest
1) 1) "command"
2) (integer) 1650195297
3) (integer) 501
4) (integer) 2000
# 查看延遲的時間序列。
127.0.0.1:6379 > latency history command
1) 1) (integer) 1650195290
2) (integer) 2000
2) 1) (integer) 1650195292
2) (integer) 152
3) 1) (integer) 1650195297
2) (integer) 501
# 以圖形化的方式顯示延遲。
127.0.0.1:6379 > latency graph command
command - high 2000 ms, low 152 ms (all time high 2000 ms)
----------------------------------------------------------
#
|
|
|_#
115
mm5
s（8）使用Redis提供的優化延遲指導。
127.0.0.1:6379 > latency doctor
輸出的信息如下：
Dave, I have observed latency spikes in this Redis instance. You don't mind talking about it, do you Dave?
1. command: 3 latency spikes (average 884ms, mean deviation 743ms, period 92.67 sec). Worst all time event 2000ms.
I have a few advices for you:
- Check your Slow Log to understand what are the commands you are running which are too slow to execute. Please check https://redis.io/commands/slowlog for more information.
- Deleting, expiring or evicting (because of maxmemory policy) large objects is a blocking operation. If you have very large objects that are often deleted, expired, or evicted, try to fragment those objects into multiple smaller objects.
- I detected a non zero amount of anonymous huge pages used by your process. This creates very serious latency events in different conditions, especially when Redis is persisting on disk. To disable THP support use the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled', make sure to also add it into /etc/rc.local so that the command will be executed again after a reboot. Note that even if you have already disabled THP, you still need to restart the Redis process to get rid of the huge pages already created.
提示：Redis提供的延遲指導可以幫助定位延遲產生的原因，並提供了一些解決的方案。從上面的輸出中可以看出，doctor命令給出了三點優化的建議。（9）使用Redis延遲度量的基線。
bin/redis-cli --intrinsic-latency 100
提示：度量是指一段時間內，某一性能指標的累計值。延遲中的一部分是來自環境的，比如操作系統內核、虛擬化環境等等。Redis提供了度量這一部分延遲基線的方法。
輸出的信息如下：
Max latency so far: 1 microseconds.
Max latency so far: 16 microseconds.
Max latency so far: 17 microseconds.
Max latency so far: 82 microseconds.
Max latency so far: 116 microseconds.
Max latency so far: 169 microseconds.
Max latency so far: 388 microseconds.
Max latency so far: 1488 microseconds.
Max latency so far: 6807 microseconds.
Max latency so far: 10914 microseconds.
Max latency so far: 13091 microseconds.
Max latency so far: 14162 microseconds.
1594254423 total runs (avg latency: 0.0627 microseconds / 62.73 nanoseconds per run).
Worst run took 225778x longer than the average latency.
