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

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

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

儀表盤(pán)

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

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

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

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

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

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

對(duì)于上述各項(xiàng) Redis 指標(biāo)，在這篇文章中我們將重點(diǎn)介紹幾項(xiàng)，分類如下：

性能指標(biāo) 內(nèi)存指標(biāo) 基本活動(dòng)指標(biāo) 持久性指標(biāo) 錯(cuò)誤指標(biāo)

低錯(cuò)誤率，良好的性能是系統(tǒng)健康的頂級(jí)指標(biāo)之一。

指標(biāo)：latency

latency 是一個(gè)客戶端發(fā)送請(qǐng)求和實(shí)際的服務(wù)器響應(yīng)之間的時(shí)間的指標(biāo)。跟蹤延遲是檢測(cè) Redis 性能變化的最直接的方式。由于 Redis 單線程的性質(zhì)，所以延遲分布的異常值可能導(dǎo)致嚴(yán)重的瓶頸。因?yàn)橐粋€(gè)請(qǐng)求的響應(yīng)時(shí)間過(guò)長(zhǎng)，就增加了所有后續(xù)請(qǐng)求的延遲。所以一旦確定有延遲的問(wèn)題，你就要采取一些措施來(lái)診斷和解決性能問(wèn)題。

指標(biāo)：instantaneous_ops_per_sec

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

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

指標(biāo)：hit rate

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

keyspace_misses 指標(biāo)在錯(cuò)誤指標(biāo)部分討論。

低命中率可能由多種因素引起，包括數(shù)據(jù)過(guò)期和 Redis 分配給的內(nèi)存不足（這可造成 key 驅(qū)逐）。低命中率可能會(huì)導(dǎo)致你的應(yīng)用程序延遲增加，因?yàn)樗麄儽仨殢囊粋€(gè)更慢的替代資源處獲取數(shù)據(jù)。

指標(biāo)：used_memory

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

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

指標(biāo): mem_fragmentation_ratio

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

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

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

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

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

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

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

您可以通過(guò)命令行配置 key 過(guò)期策略：

redis-cli CONFIG SET maxmemory-policy 

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

volatile-lru     刪除最新使用的key之間的到期集
volatile-ttl     用最短的時(shí)間移除一個(gè)key，用一個(gè)過(guò)期集來(lái)存活
volatile-random  刪除一個(gè)隨機(jī)key之間的到期集。
allkeys-lru      從所有key的集合中刪除最近使用的key
allkeys-random   從所有key的集合中移除一個(gè)隨機(jī)key 

指標(biāo)：blocked_clients

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

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

指標(biāo)：connected_clients

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

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

指標(biāo)：connected_slaves

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

指標(biāo)：master_last_io_seconds_ago

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

指標(biāo)：keyspace

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

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

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

指標(biāo)：rdb_last_save_time 和 rdb_changes_since_last_save

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

指標(biāo)：rejected_connections

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

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

請(qǐng)參閱有關(guān) redis.io 的文檔上 Redis 如何處理客戶端連接的詳細(xì)信息。

指標(biāo)：keyspace_misses

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

安裝探針，配置 Redis

說(shuō)了那么多的干貨，是時(shí)候安裝 Cloud Insight 看看具體能顯示出什么東東來(lái)了，首先是一鍵安裝，直接在服務(wù)器命令行復(fù)制就好。

默認(rèn)應(yīng)用的名稱是主機(jī)名，也可以自己在/etc/oneapm-ci-agent/oneapm-ci-agent.conf 里面進(jìn)行配置。

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

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

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

圖中顯示的指標(biāo)就是本文開(kāi)頭介紹的各項(xiàng)指標(biāo)，針對(duì)部分指標(biāo)，本文也做了相應(yīng)的說(shuō)明。

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

在平臺(tái)服務(wù)支持上，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種服務(wù)，其中涉及的 Docker，PHP-FPM 都是在用戶提的需求中提前增加支持的，因此我們歡迎您和我們一起打造更完美的數(shù)據(jù)管理平臺(tái)，期待您的參與！

本文系 OneAPM 工程師編譯整理。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問(wèn) OneAPM 官方博客。