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) 探針儀表盤功能重磅上線，默認(rèn)安裝了探針残邀，配置平臺(tái)服務(wù)就會(huì)自動(dòng)生成相應(yīng)的儀表盤皆辽，而且儀表盤將包含所有數(shù)據(jù)柑蛇。此外，本文也將重點(diǎn)介紹 Redis 的幾項(xiàng)監(jiān)控指標(biāo)以及一些值得注意的部分驱闷，希望給使用 Redis 的讀者帶來(lái)一些幫助唯蝶。
儀表盤
任意時(shí)間段數(shù)據(jù)查詢
默認(rèn)只能顯示最近一小時(shí)的數(shù)據(jù)，而現(xià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)畅厢，儀表盤就派上用場(chǎng)啦冯痢！通常儀表盤數(shù)據(jù)是多個(gè)服務(wù)器數(shù)據(jù)的集合，如果想看單個(gè)服務(wù)器數(shù)據(jù)框杜，可以根據(jù)主機(jī)名進(jìn)行篩選浦楣。此外，里面還有多條篩選條件咪辱，例如 device url tag 等振劳， Docker 可以選擇 image 等。稍后我們會(huì)上線自定義儀表盤油狂，通過(guò) tag 標(biāo)簽輕松實(shí)現(xiàn)對(duì)數(shù)據(jù)的聚合历恐、過(guò)濾、檢索专筷。
監(jiān)控 Redis 指標(biāo)
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)
性能指標(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ù)。
內(nèi)存指標(biāo)
指標(biāo)：used_memory
內(nèi)存的使用是 Redis 性能的一個(gè)關(guān)鍵組成部分悼嫉。如果 used_memory 超過(guò)總的系統(tǒng)可用內(nèi)存艇潭，操作系統(tǒng)將開始交換舊的或未使用的部分內(nèi)存。每一次把交換部分寫入磁盤戏蔑，都會(huì)嚴(yán)重影響性能蹋凝。從磁盤讀寫的速度，達(dá)到5個(gè)數(shù)量級(jí)（100000xＷ芸谩）鳍寂，遠(yuǎn)比從內(nèi)存讀寫慢（0.1μ的記憶與10毫秒磁盤)。
您可以配置 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)致交換粱玲。交換到磁盤將導(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)存樱报，并開始刪除 key 葬项。如果你能接受這個(gè)響應(yīng)時(shí)間，那么相應(yīng)的穩(wěn)定的回收率也就可以接受了迹蛤。
您可以通過(guò)命令行配置 key 過(guò)期策略：
redis-cli CONFIG SET maxmemory-policy <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)該注意了。
基本活動(dòng)指標(biāo)
指標(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ì)使主器件立即開始一個(gè)后臺(tái)進(jìn)程來(lái)保存數(shù)據(jù)庫(kù)到磁盤撮弧，同時(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ì)開始和增加 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)。寫入磁盤時(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)有太大的改變阀蒂，那么寫入磁盤時(shí)過(guò)長(zhǎng)的時(shí)間間隔就不是一個(gè)問(wèn)題该窗。跟蹤這兩個(gè)指標(biāo)弟蚀，在給定時(shí)間點(diǎn)可以了解有多少數(shù)據(jù)已經(jīng)丟失。
錯(cuò)誤指標(biāo)
指標(biāo)：rejected_connections
Redis 能夠處理多個(gè)活動(dòng)連接酗失，默認(rèn)可與10000可用的客戶端連接义钉，你可以設(shè)置不同的最大連接數(shù)，通過(guò)執(zhí)行 redis.conf 的 maxclient 的指令级零。如果你的 Redis 的實(shí)例已經(jīng)是最大連接數(shù)断医，那么任何新的連接嘗試都會(huì)被斷開。
注意奏纪，您的系統(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 增加牛哺。
安裝監(jiān)控 Redis
安裝探針，配置 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 等之后重啟探針到涂，就可以看見 Redis 的性能監(jiān)控的具體數(shù)據(jù)啦脊框。
修改完配置文件颁督，重啟探針，此時(shí)就完成了對(duì) Redis 的監(jiān)控浇雹，現(xiàn)在看看具體的數(shù)據(jù)指標(biāo)沉御，了解 Redis 的健康情況。
圖中顯示的指標(biāo)就是本文開頭介紹的各項(xiàng)指標(biāo)昭灵，針對(duì)部分指標(biāo)吠裆，本文也做了相應(yīng)的說(shuō)明。
下一個(gè)功能烂完，等您來(lái)點(diǎn)亮试疙！
目前，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 工程師編譯整理漓拾。OneAPM 是應(yīng)用性能管理領(lǐng)域的新興領(lǐng)軍企業(yè)，Cloud Insight 能幫助企業(yè)用戶和開發(fā)者輕松實(shí)現(xiàn)：監(jiān)控各項(xiàng)基礎(chǔ)組件以及對(duì)數(shù)據(jù)進(jìn)行聚合长赞、過(guò)濾和篩選的功能晦攒，致力于打造一個(gè)更為強(qiáng)大的數(shù)據(jù)管理平臺(tái)闽撤。想閱讀更多技術(shù)文章得哆，請(qǐng)?jiān)L問(wèn) OneAPM 官方博客。
