Redis監控方案

標籤：style   blog   http   io   os   使用   ar   strong   for   

Redis介紹

Redis是一種進階key-value資料庫。它跟memcached類似，不過資料可以持久化，而且支援的資料類型很豐富。有字串，鏈表、雜湊、集合和有序集合5種。支援在伺服器端計算集合的並、交和補集(difference)等，還支援多種排序功能。所以Redis也可以被看成是一個資料結構伺服器。Redis的所有資料都是儲存在記憶體中，然後不週期性通過非同步方式儲存到磁碟上(這稱為“半持久化模式”)；也可以把每一次資料變化都寫入到一個append only file(aof)裡面(這稱為“全持久化模式”)。

Redis監控

首先判斷用戶端和伺服器串連是否正常

# 用戶端和伺服器串連正常，返回PONGredis> PINGPONG# 用戶端和伺服器串連不正常(網路不正常或伺服器未能正常運行)，返回串連異常redis 127.0.0.1:6379> PINGCould not connect to Redis at 127.0.0.1:6379: Connection refused

Redis 監控最直接的方法就是使用系統提供的 info 命令，只需要執行下面一條命令，就能獲得 Redis 系統的狀態報表。

redis-cli info

結果會返回 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Keyspace 8個部分。從info大返回結果中提取相關資訊，就可以達到有效監控的目的。

先解釋下各個參數含義

# Serverredis_version:2.8.8                     # Redis 的版本redis_git_sha1:00000000redis_git_dirty:0redis_build_id:bf5d1747be5380fredis_mode:standaloneos:Linux 2.6.32-220.7.1.el6.x86_64 x86_64arch_bits:64multiplexing_api:epollgcc_version:4.4.7                       #gcc版本process_id:49324                        # 當前 Redis 伺服器處理序idrun_id:bbd7b17efcf108fdde285d8987e50392f6a38f48tcp_port:6379uptime_in_seconds:1739082               # 已耗用時間(秒)uptime_in_days:20                       # 已耗用時間(天)hz:10lru_clock:1734729config_file:/home/s/apps/RedisMulti_video_so/conf/zzz.conf# Clientsconnected_clients:1                     #串連的用戶端數量client_longest_output_list:0client_biggest_input_buf:0blocked_clients:0# Memoryused_memory:821848                       #Redis分配的記憶體總量              used_memory_human:802.59Kused_memory_rss:85532672                 #Redis分配的記憶體總量(包括記憶體片段) used_memory_peak:178987632used_memory_peak_human:170.70M           #Redis所用記憶體的高峰值used_memory_lua:33792mem_fragmentation_ratio:104.07           #記憶體片段比率mem_allocator:tcmalloc-2.0# Persistenceloading:0rdb_changes_since_last_save:0            #上次儲存資料庫之後，執行命令的次數rdb_bgsave_in_progress:0                 #後台進行中的 save 操作的數量rdb_last_save_time:1410848505            #最後一次成功儲存的時間點，以 UNIX 時間戳記格式顯示rdb_last_bgsave_status:okrdb_last_bgsave_time_sec:0rdb_current_bgsave_time_sec:-1aof_enabled:0                            #redis是否開啟了aofaof_rewrite_in_progress:0aof_rewrite_scheduled:0aof_last_rewrite_time_sec:-1aof_current_rewrite_time_sec:-1aof_last_bgrewrite_status:okaof_last_write_status:ok# Statstotal_connections_received:5705          #運行以來串連過的用戶端的總數量total_commands_processed:204013          # 運行以來執行過的命令的總數量instantaneous_ops_per_sec:0rejected_connections:0sync_full:0sync_partial_ok:0sync_partial_err:0expired_keys:34401                       #運行以來到期的 key 的數量evicted_keys:0                           #運行以來刪除過的key的數量keyspace_hits:2129                       #命中key 的次數keyspace_misses:3148                     #沒命中key 的次數pubsub_channels:0                        #當前使用中的頻道數量pubsub_patterns:0                        #當前使用中的模式數量latest_fork_usec:4391# Replicationrole:master                              #當前執行個體的角色master還是slaveconnected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0# CPUused_cpu_sys:1551.61used_cpu_user:1083.37used_cpu_sys_children:2.52used_cpu_user_children:16.79# Keyspacedb0:keys=3,expires=0,avg_ttl=0             #各個資料庫的 key 的數量，以及帶有生存期的 key 的數量   

記憶體使用量

如果 Redis 使用的記憶體超出了可用的實體記憶體大小，那麼 Redis 很可能系統會被殺掉。針對這一點，你可以通過 info 命令對 used_memory 和 used_memory_peak 進行監控，為使用記憶體量設定閥值，並設定相應的警示機制。當然，警示只是手段，重要的是你得預先計劃好，當記憶體使用量量過大後，你應該做些什麼，是清除一些沒用的冷資料，還是把 Redis 遷移到更強大的機器上去。

持久化

如果因為你的機器或 Redis 本身的問題導致 Redis 崩潰了，那麼你唯一的救命稻草可能就是 dump 出來的rdb檔案了，所以，對 Redis dump 檔案進行監控也是很重要的。可以通過對rdb_last_save_time 進行監控，瞭解最近一次 dump 資料操作的時間，還可以通過對rdb_changes_since_last_save進行監控來獲得如果這時候出現故障，會丟失（即已改變）多少資料。

Keys

通過擷取Keyspace中的結果得到各個資料庫中key的數量

QPS

即每分鐘執行的命令個數，即：(total_commands_processed2-total_commands_processed1)/span，為了即時得到QPS，可以設定指令碼在後台運行，記錄過去幾分鐘的total_commands_processed。在計算QPS時，利用過去的資訊和當前的資訊得出QPS的估計值。

參考

redis info命令中各個參數的含義

ping

Redis監控方案