Redis監控技巧

本文來自 Bugsnag 的聯合創始人 Simon Maynard 的系列文章，作者根據幾年來對 Redis 的使用經曆，對 Redis 監控方法進行了系統性的總結，乾貨很多，值得一看。
 
原文連結：Redis Masterclass – Part 2, Monitoring
 
Redis 監控最直接的方法當然就是使用系統提供的 info 命令來做了，你只需要執行下面一條命令，就能獲得 Redis 系統的狀態報表。
 redis-cli info
記憶體使用量
 
如果 Redis 使用的記憶體超出了可用的實體記憶體大小，那麼 Redis 很可能系統會被 OOM Killer 殺掉。針對這一點，你可以通過 info 命令對 used_memory 和 used_memory_peak 進行監控，為使用記憶體量設定閾值，並設定相應的警示機制。當然，警示只是手段，重要的是你得預先計劃好，當記憶體使用量量過大後，你應該做些什麼，是清除一些沒用的冷資料，還是把 Redis 遷移到更強大的機器上去。
 
持久化
 
如果因為你的機器或 Redis 本身的問題導致 Redis 崩潰了，那麼你唯一的救命稻草可能就是 dump 出來的 rdb檔案了，所以，對 Redis dump 檔案進行監控也是很重要的。你可以通過對 rdb_last_save_time 進行監控，瞭解你最近一次 dump 資料操作的時間，還可以通過對 rdb_changes_since_last_save 進行監控來知道如果這時候出現故障，你會丟失多少資料。
 
主從複製
 
如果你設定了主從複製模式，那麼你最好對複製的情況是否正常做一些監控，主要是對 info 輸出中的 master_link_status 進行監控，如果這個值是 up，那麼說明同步正常，如果是 down，那麼你就要注意一下輸出的其它一些診斷資訊了。比如下面這些：
 role:slave
master_host:192.168.1.128
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
master_link_down_since_seconds:1356900595
Fork 效能
 
當 Redis 持久化資料到磁碟上時，它會進行一次 fork 操作，通過 fork 對記憶體的 copy on write 機制最廉價的實現記憶體鏡像。但是雖然記憶體是 copy on write 的，但是虛擬記憶體表是在 fork 的瞬間就需要分配，所以 fork 會造成主線程短時間的卡頓（停止所有讀寫操作），這個卡頓時間和當前 Redis 的記憶體使用量量有關。通常 GB 量級的 Redis 進行 fork 操作的時間在毫秒級。你可以通過對 info 輸出的 latest_fork_usec 進行監控來瞭解最近一次 fork 操作導致了多少時間的卡頓。
 
配置一致
 
Redis 支援使用 CONFIG SET 操作來實現運行實的配置修改，這很方便，但同時也會導致一個問題。就是通過這個命令動態修改的配置，是不會同步到你的設定檔中去的。所以當你因為某些原因重啟 Redis 時，你使用 CONFIG SET 做的配置修改就會丟失掉，所以我們最好保證在每次使用 CONFIG SET 修改配置時，也把設定檔一起相應地改掉。為了防止人為的失誤，所以我們最好對配置進行監控，使用 CONFIG GET 命令來擷取當前運行時的配置，並與 redis.conf 中的配置值進行對比，如果發現兩邊對不上，就啟動警示。
 
慢日誌
 
Redis 提供了 SLOWLOG 指令來擷取最近的慢日誌，Redis 的慢日誌是直接存在記憶體中的，所以它的慢日誌開銷並不大，在實際應用中，我們通過 crontab 任務執行 SLOWLOG 命令來擷取慢日誌，然後將慢日誌存到檔案中，並用 Kibana 產生即時的效能圖表來實現效能監控。
 
值得一提的是，Redis 的慢日誌記錄的時間，僅僅包括 Redis 自身對一條命令的執行時間，不包括 IO 的時間，比如接收用戶端資料和發送用戶端資料這些時間。另外，Redis 的慢日誌和其它資料庫的慢日誌有一點不同，其它資料庫偶爾出現 100ms 的慢日誌可能都比較正常，因為一般資料庫都是多線程並發執行，某個線程執行某個命令的效能可能並不能代表整體效能，但是對 Redis 來說，它是單線程的，一旦出現慢日誌，可能就需要馬上得到重視，最好去查一下具體是什麼原因了。

1 2 下一頁