摘要：超過表明過度分散，即你的實例消耗了的物理內(nèi)存意味著需求大于你系統(tǒng)可用的內(nèi)存，從而導致交換。理想情況下，操作系統(tǒng)會在物理內(nèi)存中分配一個連續(xù)的段，其碎片率等于或稍大。

OneAPM 作為應用性能領域的新興領軍企業(yè)，近期發(fā)布了重量級新產(chǎn)品—— Cloud Insight 數(shù)據(jù)管理平臺，用它能夠監(jiān)控所有基礎組件，并通過 tag 標簽對數(shù)據(jù)進行管理。

近日，Cloud Insight (Ci) 探針儀表盤功能重磅上線，默認安裝了探針，配置平臺服務就會自動生成相應的儀表盤，而且儀表盤將包含所有數(shù)據(jù)。此外，本文也將重點介紹 Redis 的幾項監(jiān)控指標以及一些值得注意的部分，希望給使用 Redis 的讀者帶來一些幫助。

儀表盤

任意時間段數(shù)據(jù)查詢

默認只能顯示最近一小時的數(shù)據(jù)，而現(xiàn)在在儀表盤上可以選取固定時間段查看數(shù)據(jù)，7天內(nèi)，15天之內(nèi)，還可以自定義具體時間段，當然默認顯示的是30分鐘內(nèi)的數(shù)據(jù)。

數(shù)據(jù)篩選

隨著現(xiàn)在業(yè)務的復雜，一個應用肯定會在多臺服務器上部署，那就需要同時監(jiān)控多臺服務器，那如果只需要看某一臺服務器的某項指標，儀表盤就派上用場啦！通常儀表盤數(shù)據(jù)是多個服務器數(shù)據(jù)的集合，如果想看單個服務器數(shù)據(jù)，可以根據(jù)主機名進行篩選。此外，里面還有多條篩選條件，例如 device url tag 等， Docker 可以選擇 image 等。稍后我們會上線自定義儀表盤，通過 tag 標簽輕松實現(xiàn)對數(shù)據(jù)的聚合、過濾、檢索。

Cloud Insight 將監(jiān)控 Redis 的以下指標

1  aof.last_rewrite_time      上次rewrite操作使用的時間(單位s)
2  aof.rewrite        rewrite 的次數(shù)
3  clients.biggest_input_buf     當前客戶端連接的最大輸入緩存
4  clients.blocked    被阻塞的客戶端數(shù)
5  clients.longest_output_list   當前客戶端連接的最大輸出列表    
6  cpu.sys       系統(tǒng)cpu
7  cpu.sys_children    后臺進程的sys cpu使用率
8  cpu.user      redis server的user cpu使用率
9  cpu.user_children    后臺進程的user cpu使用率 
10 info.latency_ms    Redis 服務器響應延遲措施所花費的平均時間
11  keys.evicted  因為內(nèi)存大小限制，而被驅(qū)逐出去的鍵的個數(shù)
12  keys.expired   自啟動起過期的key的總數(shù)
13  mem.fragmentation_ratio      used_memory_rss/used_memory比例，一般情況下，used_memory_rss略高于used_memory，當內(nèi)存碎片較多時，則mem_fragmentation_ratio會較大，可以反映內(nèi)存碎片是否很多
14  mem.lua   lua引擎使用的內(nèi)存
15  mem.peak   內(nèi)存使用的峰值大小
16  mem.rss   系統(tǒng)給redis分配的內(nèi)存（即常駐內(nèi)存）
17  mem.used   使用內(nèi)存，單位B
18  net.clients            連接的客戶端數(shù)
19  net.commands     每秒運行命令數(shù)
20  net.rejected         因為最大客戶端連接數(shù)限制，而導致被拒絕連接的個數(shù)
21  net.slaves            連接的從庫數(shù)
22  perf.latest_fork_usec    上次的fork操作使用的時間（單位ms）
23  pubsub.channels      當前使用中的頻道數(shù)量／ 發(fā)布/訂閱頻道數(shù)
24  pubsub.patterns       當前使用的模式的數(shù)量／ 發(fā)布/訂閱模式數(shù)
25  rdb.bgsave          通過子進程來進行數(shù)據(jù)持久化
26  rdb.changes_since_last   自上次dump后rdb的改動
27  rdb.last_bgsave_time       上次save的時間戳
28  replication.master_repl_offs     全局的數(shù)據(jù)同步偏移量
29  stats.keyspace_hits      在main dictionary(todo)中成功查到的key個數(shù)
30  stats.keyspace_misses     在main dictionary(todo)中未查到的key的個數(shù)

對于上述各項 Redis 指標，在這篇文章中我們將重點介紹幾項，分類如下：

性能指標 內(nèi)存指標 基本活動指標 持久性指標 錯誤指標

低錯誤率，良好的性能是系統(tǒng)健康的頂級指標之一。

指標：latency

latency 是一個客戶端發(fā)送請求和實際的服務器響應之間的時間的指標。跟蹤延遲是檢測 Redis 性能變化的最直接的方式。由于 Redis 單線程的性質(zhì)，所以延遲分布的異常值可能導致嚴重的瓶頸。因為一個請求的響應時間過長，就增加了所有后續(xù)請求的延遲。所以一旦確定有延遲的問題，你就要采取一些措施來診斷和解決性能問題。

指標：instantaneous_ops_per_sec

跟蹤 Redis 實例命令處理的過程是診斷高延遲的關鍵。高延遲可能由以下問題引起，積壓的命令隊列，慢命令，網(wǎng)絡連接超時等。你可以通過測量每秒處理的指令數(shù)來查看，如果它幾乎保持恒定，那就不是計算密集型的命令造成的；如果是一個或多個緩慢的命令導致的延遲問題，你會看到你的每秒下降或跌落的命令數(shù)。

把每秒處理命令的下降的數(shù)量和歷史數(shù)據(jù)相比，可以作為一個低命令量或慢命令阻塞系統(tǒng)的標志。低的命令量可能是正常的，也可能是上游的問題。

指標：hit rate

當使用 Redis 作為緩存時，監(jiān)控緩存 hit rate 可以告訴你緩存使用是否有效。低命中率意味著客戶正在尋找不存在的 key。Redis 不提供直接命中率指標，但我們可以這樣計算它：

keyspace_misses 指標在錯誤指標部分討論。

低命中率可能由多種因素引起，包括數(shù)據(jù)過期和 Redis 分配給的內(nèi)存不足（這可造成 key 驅(qū)逐）。低命中率可能會導致你的應用程序延遲增加，因為他們必須從一個更慢的替代資源處獲取數(shù)據(jù)。

指標：used_memory

內(nèi)存的使用是 Redis 性能的一個關鍵組成部分。如果 used_memory 超過總的系統(tǒng)可用內(nèi)存，操作系統(tǒng)將開始交換舊的或未使用的部分內(nèi)存。每一次把交換部分寫入磁盤，都會嚴重影響性能。從磁盤讀寫的速度，達到5個數(shù)量級（100000x！），遠比從內(nèi)存讀寫慢（0.1μ的記憶與10毫秒磁盤)。

您可以配置 Redis ，限定一定的內(nèi)存量。在 redis.conf 文件里面設置 maxmemory 指令，這樣就可以直接控制 Redis 的內(nèi)存使用量。maxmemory 配置一個驅(qū)逐政策確定 Redis 應該如何釋放內(nèi)存。

指標: mem_fragmentation_ratio

mem_fragmentation_ratio 指標表明了 Redis 給操作系統(tǒng)分配的內(nèi)存使用率。

了解 mem_fragmentation_ratio 數(shù)據(jù)指標是了解你的 Redis 實例的性能的重要一步。fragmentation ratio 大于1表示碎片正在發(fā)生。超過1.5 表明過度分散，即你的 Redis 實例消耗了150%的物理內(nèi)存；fragmentation ratio < 1 ,意味著 Redis 需求大于你系統(tǒng)可用的內(nèi)存，從而導致交換。交換到磁盤將導致延遲增加顯著。理想情況下，操作系統(tǒng)會在物理內(nèi)存中分配一個連續(xù)的段，其碎片率等于1或稍大。

如果你的服務器 fragmentation ratio 在1.5以上，重新啟動你的 Redis 實例將允許操作系統(tǒng)恢復以前由于破損而無法使用的內(nèi)存。

當然，如果你的 Redis 服務器 fragmentation ratio 低于1，你可能需要快速增加可用內(nèi)存或減少內(nèi)存使用。

指標：evicted_keys (只限內(nèi)存)

如果你是使用 Redis 作緩存，你可以配置它自動清除 keys 在其命中 maxmemory 限定后。如果你是使用 Redis 作為一個數(shù)據(jù)庫或隊列，你可能更喜歡交換驅(qū)逐，在這種情況下，你可以跳過這個指標。

跟蹤刪除 key 是很重要的，因為 Redis 按順序處理每個操作，所以大量的 key 將會導致較低的命中率，從而延長等待時間。如果你使用的是 TTL，你可能不需要刪除 key 。在這種情況下，如果這個指標始終高于零，你很可能會在實例中會看到延遲增加。大多數(shù)其他的配置不使用 TTL 最終會耗盡內(nèi)存，并開始刪除 key 。如果你能接受這個響應時間，那么相應的穩(wěn)定的回收率也就可以接受了。

您可以通過命令行配置 key 過期策略：

redis-cli CONFIG SET maxmemory-policy 

policy 位置，可以輸入以下參數(shù)：

volatile-lru     刪除最新使用的key之間的到期集
volatile-ttl     用最短的時間移除一個key，用一個過期集來存活
volatile-random  刪除一個隨機key之間的到期集。
allkeys-lru      從所有key的集合中刪除最近使用的key
allkeys-random   從所有key的集合中移除一個隨機key 

指標：blocked_clients

Redis 提供了大量的阻塞命令來操作列表，BLPOP, BRPOP,和 BRPOPLPUSH 分別是 LPOP, RPOP, 和 RPOPLPUSH 的變種。當源列表是非空的，命令正常執(zhí)行。而當源列表是空的的時候，阻塞命令將等待源被填充才會執(zhí)行，或者達到一個超時時間才會執(zhí)行。

阻塞的客戶數(shù)量的增加可能是一個麻煩的跡象，延遲或其他問題會防止源列表被填充。雖然一個封閉的客戶端本身是不會引起警報，但是如果你看到一個持續(xù)的非零的值，這個指標你就應該注意了。

指標：connected_clients

通常訪問 Redis 是由一個應用程序介入的（用戶一般不直接訪問數(shù)據(jù)庫），大多數(shù)應用，將對連接的客戶端的數(shù)量有合理的上限和下限。如果數(shù)值偏離正常范圍內(nèi)，就表明有問題。如果太低，上游連接可能已丟失，如果過高，大量的并發(fā)客戶端連接可能會壓倒你的服務器處理請求的能力。

無論如何，客戶端連接的最大數(shù)值始終是由操作系統(tǒng)，Redis 的配置，和網(wǎng)絡的局限性決定的。監(jiān)控客戶端連接幫助確保你有足夠的可用資源用于新的客戶端連接或管理會話。

指標：connected_slaves

如果你的數(shù)據(jù)庫是只讀的，繁重的，你很可能使用現(xiàn)有的 Redis 主從數(shù)據(jù)庫復制功能。在這種情況下，監(jiān)控連接從站的數(shù)量是很關鍵的。如果 slaves 連接改變和預計的不符，則說明可能主機 down 了或 slaves 實例有問題。

指標：master_last_io_seconds_ago

當使用 Redis 的的復制功能時，slaves 實例定期檢查與他們的 master 通信時間。沒有通信的時間間隔很長，則問題可能出現(xiàn)在主 Redis 的服務器上，或在從服務器上，或介于兩者之間。由于 Redis 執(zhí)行同步的方式,會有運行 slaves 提供的舊數(shù)據(jù)風險，因此最大限度地減少主從通信中斷是非常關鍵的。當從機連接到主機時，無論是否是首次或重新連接，它都會發(fā)送一個 SYNC 命令。SYNC 命令會使主器件立即開始一個后臺進程來保存數(shù)據(jù)庫到磁盤，同時緩沖所有新命令接收將修改數(shù)據(jù)集。數(shù)據(jù)被發(fā)送到客戶端連同當背景保存完成緩沖的命令。每次從機執(zhí)行同步，都可能會在 master 實例上導致顯著延遲。

指標：keyspace

保持追蹤數(shù)據(jù)庫的 key 數(shù)量也是一個好主意。作為內(nèi)存數(shù)據(jù)存儲器，鍵空間越大，Redis 就需要越多的物理內(nèi)存以確保最佳性能，這樣 Redis 將繼續(xù)增加 key ，直到它到達 maxmemory 限制，此時就會開始和增加 key 相同的速率刪除 key ，這將出現(xiàn)一個 「平行」 圖。

如果您正在使用 Redis 作為緩存，看看低命中率的圖表，你客戶端也許在請求舊的數(shù)據(jù)或被刪除的數(shù)據(jù)。跟蹤你的 keyspace_misses 的數(shù)量一段時間后會幫你查明原因。

另外，如果你使用 Redis 的數(shù)據(jù)庫或隊列，刪除 key 可能不是一個好的選擇。隨著你的鍵值空間的增長，你可能需要考慮增加內(nèi)存到你的機器或在主機之間來分割數(shù)據(jù)集。添加更多存儲器是一種簡單而有效的解決方案。當需要更多的資源而一個服務器不能提供時，你可以整合多臺計算機來分區(qū)或分片存儲數(shù)據(jù)。Redis 可以實現(xiàn)分區(qū)分片存儲而不需要遷離或交換更多的鍵值。

指標：rdb_last_save_time 和 rdb_changes_since_last_save

通常情況下，它要留意你的數(shù)據(jù)集的波動。寫入磁盤時過長的時間間隔可能會導致在服務器故障的情況下數(shù)據(jù)丟失。最后保存時間和故障時間之間的數(shù)據(jù)集所做的任何更改將丟失。
監(jiān)測 rdb_changes_since_last_save 讓你更深入地了解你的數(shù)據(jù)的波動性。如果你的數(shù)據(jù)集在一段區(qū)間內(nèi)并沒有太大的改變，那么寫入磁盤時過長的時間間隔就不是一個問題。跟蹤這兩個指標，在給定時間點可以了解有多少數(shù)據(jù)已經(jīng)丟失。

指標：rejected_connections

Redis 能夠處理多個活動連接，默認可與10000可用的客戶端連接，你可以設置不同的最大連接數(shù)，通過執(zhí)行 redis.conf 的 maxclient 的指令。如果你的 Redis 的實例已經(jīng)是最大連接數(shù)，那么任何新的連接嘗試都會被斷開。

注意，您的系統(tǒng)可能不支持您請求的 maxclient 指令的連接數(shù)量。Redis 檢查內(nèi)核，以確定可用的文件描述符的數(shù)量。如果可用的文件描述符的數(shù)量小于maxclient+32（Redis 的保留32文件描述符供自己使用），則該 maxclient 的指令被忽略并可用文件描述符的數(shù)量被使用。

請參閱有關 redis.io 的文檔上 Redis 如何處理客戶端連接的詳細信息。

指標：keyspace_misses

每次 Redis 查找 key，只有兩種可能的結(jié)果：該鍵值存在，或者該鍵值不存在。找了一個不存在的 key 會導致 keyspace_misses 遞增。如果該指標一直是非零值，意味著客戶端試圖查找數(shù)據(jù)庫的鍵不存在。如果您不使用 Redis 作為緩存，keyspace_misses 應達到或接近零。需要注意的是任何一個阻塞操作（BLPOP，BRPOP 和 BRPOPLPUSH ）的空鍵響應將導致 keyspace_misses 增加。

安裝探針，配置 Redis

說了那么多的干貨，是時候安裝 Cloud Insight 看看具體能顯示出什么東東來了，首先是一鍵安裝，直接在服務器命令行復制就好。

默認應用的名稱是主機名，也可以自己在/etc/oneapm-ci-agent/oneapm-ci-agent.conf 里面進行配置。

之后在 web 端就有這個主機應用的數(shù)據(jù)啦。

安裝好平臺監(jiān)控，接下來就是實現(xiàn) Redis 監(jiān)控啦，只需要通過簡單配置，復制redis.yaml.example 模版，修改下圖，密碼 tag 等之后重啟探針，就可以看見 Redis 的性能監(jiān)控的具體數(shù)據(jù)啦。

修改完配置文件，重啟探針，此時就完成了對 Redis 的監(jiān)控，現(xiàn)在看看具體的數(shù)據(jù)指標，了解 Redis 的健康情況。

圖中顯示的指標就是本文開頭介紹的各項指標，針對部分指標，本文也做了相應的說明。

目前，Cloud Insight 可以監(jiān)控 Ubuntu、Mac OS X、Fedora、CentOS 和 RedHat 的主機監(jiān)控。

在平臺服務支持上，Cloud Insight 已經(jīng)支持 ActiveMQ Apache Apache Tomcat Apache Kafka Cassandra Couchbase CouchDB Docker Elastic Search Memcached MongoDB MySQL Nginx PostgreSQL PHP-FPM Redis RabbitMQ 17種服務，其中涉及的 Docker，PHP-FPM 都是在用戶提的需求中提前增加支持的，因此我們歡迎您和我們一起打造更完美的數(shù)據(jù)管理平臺，期待您的參與！

本文系 OneAPM 工程師編譯整理。想閱讀更多技術(shù)文章，請訪問 OneAPM 官方博客。