Cloud Insight 儀表盤上線 | 全面監控 Redis

OneAPM 做爲應用性能領域的新興領軍企業，近期發佈了重量級新產品—— Cloud Insight 數據管理平臺，用它可以監控全部基礎組件，並經過 tag 標籤對數據進行管理。

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

儀表盤

任意時間段數據查詢

默認只能顯示最近一小時的數據，而如今在儀表盤上能夠選取固定時間段查看數據，7天內，15天以內，還能夠自定義具體時間段，固然默認顯示的是30分鐘內的數據。

數據篩選

隨着如今業務的複雜，一個應用確定會在多臺服務器上部署，那就須要同時監控多臺服務器，那若是隻須要看某一臺服務器的某項指標，儀表盤就派上用場啦！一般儀表盤數據是多個服務器數據的集合，若是想看單個服務器數據，能夠根據主機名進行篩選。此外，裏面還有多條篩選條件，例如 device url tag 等， Docker 能夠選擇 image 等。稍後咱們會上線自定義儀表盤，經過 tag 標籤輕鬆實現對數據的聚合、過濾、檢索。

監控 Redis 指標

Cloud Insight 將監控 Redis 的如下指標

1  aof.last_rewrite_time      上次rewrite操做使用的時間(單位s)
2  aof.rewrite        rewrite 的次數
3  clients.biggest_input_buf     當前客戶端鏈接的最大輸入緩存
4  clients.blocked    被阻塞的客戶端數
5  clients.longest_output_list   當前客戶端鏈接的最大輸出列表    
6  cpu.sys       系統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  由於內存大小限制，而被驅逐出去的鍵的個數
12  keys.expired   自啓動起過時的key的總數
13  mem.fragmentation_ratio      used_memory_rss/used_memory比例，通常狀況下，used_memory_rss略高於used_memory，當內存碎片較多時，則mem_fragmentation_ratio會較大，能夠反映內存碎片是否不少
14  mem.lua   lua引擎使用的內存
15  mem.peak   內存使用的峯值大小
16  mem.rss   系統給redis分配的內存（即常駐內存）
17  mem.used   使用內存，單位B
18  net.clients            鏈接的客戶端數
19  net.commands     每秒運行命令數
20  net.rejected         由於最大客戶端鏈接數限制，而致使被拒絕鏈接的個數
21  net.slaves            鏈接的從庫數
22  perf.latest_fork_usec    上次的fork操做使用的時間（單位ms）
23  pubsub.channels      當前使用中的頻道數量／ 發佈/訂閱頻道數
24  pubsub.patterns       當前使用的模式的數量／ 發佈/訂閱模式數
25  rdb.bgsave          經過子進程來進行數據持久化
26  rdb.changes_since_last   自上次dump後rdb的改動
27  rdb.last_bgsave_time       上次save的時間戳
28  replication.master_repl_offs     全局的數據同步偏移量
29  stats.keyspace_hits      在main dictionary(todo)中成功查到的key個數
30  stats.keyspace_misses     在main dictionary(todo)中未查到的key的個數

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

性能指標 內存指標 基本活動指標 持久性指標 錯誤指標

性能指標

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

指標：latency

latency 是一個客戶端發送請求和實際的服務器響應之間的時間的指標。跟蹤延遲是檢測 Redis 性能變化的最直接的方式。因爲 Redis 單線程的性質，因此延遲分佈的異常值可能致使嚴重的瓶頸。由於一個請求的響應時間過長，就增長了全部後續請求的延遲。因此一旦肯定有延遲的問題，你就要採起一些措施來診斷和解決性能問題。

指標：instantaneous_ops_per_sec

跟蹤 Redis 實例命令處理的過程是診斷高延遲的關鍵。高延遲可能由如下問題引發，積壓的命令隊列，慢命令，網絡鏈接超時等。你能夠經過測量每秒處理的指令數來查看，若是它幾乎保持恆定，那就不是計算密集型的命令形成的；若是是一個或多個緩慢的命令致使的延遲問題，你會看到你的每秒降低或跌落的命令數。

把每秒處理命令的降低的數量和歷史數據相比，能夠做爲一個低命令量或慢命令阻塞系統的標誌。低的命令量多是正常的，也多是上游的問題。

指標：hit rate

當使用 Redis 做爲緩存時，監控緩存 hit rate 能夠告訴你緩存使用是否有效。低命中率意味着客戶正在尋找不存在的 key。Redis 不提供直接命中率指標，但咱們能夠這樣計算它：

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

低命中率可能由多種因素引發，包括數據過時和 Redis 分配給的內存不足（這可形成 key 驅逐）。低命中率可能會致使你的應用程序延遲增長，由於他們必須從一個更慢的替代資源處獲取數據。

內存指標

指標：used_memory

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

您能夠配置 Redis ，限定必定的內存量。在 redis.conf 文件裏面設置 maxmemory 指令，這樣就能夠直接控制 Redis 的內存使用量。maxmemory 配置一個驅逐政策肯定 Redis 應該如何釋放內存。

指標: mem_fragmentation_ratio

mem_fragmentation_ratio 指標代表了 Redis 給操做系統分配的內存使用率。

瞭解 mem_fragmentation_ratio 數據指標是瞭解你的 Redis 實例的性能的重要一步。fragmentation ratio 大於1表示碎片正在發生。超過1.5 代表過分分散，即你的 Redis 實例消耗了150%的物理內存；fragmentation ratio < 1 ,意味着 Redis 需求大於你係統可用的內存，從而致使交換。交換到磁盤將致使延遲增長顯著。理想狀況下，操做系統會在物理內存中分配一個連續的段，其碎片率等於1或稍大。

若是你的服務器 fragmentation ratio 在1.5以上，從新啓動你的 Redis 實例將容許操做系統恢復之前因爲破損而沒法使用的內存。

固然，若是你的 Redis 服務器 fragmentation ratio 低於1，你可能須要快速增長可用內存或減小內存使用。

指標：evicted_keys (只限內存)

若是你是使用 Redis 做緩存，你能夠配置它自動清除 keys 在其命中 maxmemory 限定後。若是你是使用 Redis 做爲一個數據庫或隊列，你可能更喜歡交換驅逐，在這種狀況下，你能夠跳過這個指標。

跟蹤刪除 key 是很重要的，由於 Redis 按順序處理每一個操做，因此大量的 key 將會致使較低的命中率，從而延長等待時間。若是你使用的是 TTL，你可能不須要刪除 key 。在這種狀況下，若是這個指標始終高於零，你極可能會在實例中會看到延遲增長。大多數其餘的配置不使用 TTL 最終會耗盡內存，並開始刪除 key 。若是你能接受這個響應時間，那麼相應的穩定的回收率也就能夠接受了。

您能夠經過命令行配置 key 過時策略：

redis-cli CONFIG SET maxmemory-policy <policy>

policy 位置，能夠輸入如下參數：

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 的變種。當源列表是非空的，命令正常執行。而當源列表是空的的時候，阻塞命令將等待源被填充纔會執行，或者達到一個超時時間纔會執行。

阻塞的客戶數量的增長多是一個麻煩的跡象，延遲或其餘問題會防止源列表被填充。雖然一個封閉的客戶端自己是不會引發警報，可是若是你看到一個持續的非零的值，這個指標你就應該注意了。

基本活動指標

指標：connected_clients

一般訪問 Redis 是由一個應用程序介入的（用戶通常不直接訪問數據庫），大多數應用，將對鏈接的客戶端的數量有合理的上限和下限。若是數值偏離正常範圍內，就代表有問題。若是過低，上游鏈接可能已丟失，若是太高，大量的併發客戶端鏈接可能會壓倒你的服務器處理請求的能力。

不管如何，客戶端鏈接的最大數值始終是由操做系統，Redis 的配置，和網絡的侷限性決定的。監控客戶端鏈接幫助確保你有足夠的可用資源用於新的客戶端鏈接或管理會話。

指標：connected_slaves

若是你的數據庫是隻讀的，繁重的，你極可能使用現有的 Redis 主從數據庫複製功能。在這種狀況下，監控鏈接從站的數量是很關鍵的。若是 slaves 鏈接改變和預計的不符，則說明可能主機 down 了或 slaves 實例有問題。

指標：master_last_io_seconds_ago

當使用 Redis 的的複製功能時，slaves 實例按期檢查與他們的 master 通訊時間。沒有通訊的時間間隔很長，則問題可能出如今主 Redis 的服務器上，或在從服務器上，或介於二者之間。因爲 Redis 執行同步的方式,會有運行 slaves 提供的舊數據風險，所以最大限度地減小主從通訊中斷是很是關鍵的。當從機鏈接到主機時，不管是不是首次或從新鏈接，它都會發送一個 SYNC 命令。SYNC 命令會使主器件當即開始一個後臺進程來保存數據庫到磁盤，同時緩衝全部新命令接收將修改數據集。數據被髮送到客戶端連同當背景保存完成緩衝的命令。每次從機執行同步，均可能會在 master 實例上致使顯著延遲。

指標：keyspace

保持追蹤數據庫的 key 數量也是一個好主意。做爲內存數據存儲器，鍵空間越大，Redis 就須要越多的物理內存以確保最佳性能，這樣 Redis 將繼續增長 key ，直到它到達 maxmemory 限制，此時就會開始和增長 key 相同的速率刪除 key ，這將出現一個 「平行」 圖。

若是您正在使用 Redis 做爲緩存，看看低命中率的圖表，你客戶端也許在請求舊的數據或被刪除的數據。跟蹤你的 keyspace_misses 的數量一段時間後會幫你查明緣由。

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

指標：rdb_last_save_time 和 rdb_changes_since_last_save

一般狀況下，它要留意你的數據集的波動。寫入磁盤時過長的時間間隔可能會致使在服務器故障的狀況下數據丟失。最後保存時間和故障時間之間的數據集所作的任何更改將丟失。
監測 rdb_changes_since_last_save 讓你更深刻地瞭解你的數據的波動性。若是你的數據集在一段區間內並無太大的改變，那麼寫入磁盤時過長的時間間隔就不是一個問題。跟蹤這兩個指標，在給定時間點能夠了解有多少數據已經丟失。

錯誤指標

指標：rejected_connections

Redis 可以處理多個活動鏈接，默承認與10000可用的客戶端鏈接，你能夠設置不一樣的最大鏈接數，經過執行 redis.conf 的 maxclient 的指令。若是你的 Redis 的實例已是最大鏈接數，那麼任何新的鏈接嘗試都會被斷開。

注意，您的系統可能不支持您請求的 maxclient 指令的鏈接數量。Redis 檢查內核，以肯定可用的文件描述符的數量。若是可用的文件描述符的數量小於maxclient+32（Redis 的保留32文件描述符供本身使用），則該 maxclient 的指令被忽略並可用文件描述符的數量被使用。

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

指標：keyspace_misses

每次 Redis 查找 key，只有兩種可能的結果：該鍵值存在，或者該鍵值不存在。找了一個不存在的 key 會致使 keyspace_misses 遞增。若是該指標一直是非零值，意味着客戶端試圖查找數據庫的鍵不存在。若是您不使用 Redis 做爲緩存，keyspace_misses 應達到或接近零。須要注意的是任何一個阻塞操做（BLPOP，BRPOP 和 BRPOPLPUSH ）的空鍵響應將致使 keyspace_misses 增長。

安裝監控 Redis

安裝探針，配置 Redis

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

默認應用的名稱是主機名，也能夠本身在/etc/oneapm-ci-agent/oneapm-ci-agent.conf 裏面進行配置。

以後在 web 端就有這個主機應用的數據啦。

安裝好平臺監控，接下來就是實現 Redis 監控啦，只須要經過簡單配置，複製redis.yaml.example 模版，修改下圖，密碼 tag 等以後重啓探針，就能夠看見 Redis 的性能監控的具體數據啦。

修改完配置文件，重啓探針，此時就完成了對 Redis 的監控，如今看看具體的數據指標，瞭解 Redis 的健康狀況。

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

下一個功能，等您來點亮！

目前，Cloud Insight 能夠監控 Ubuntu、Mac OS X、Fedora、CentOS 和 RedHat 的主機監控。

在平臺服務支持上，Cloud Insight 已經支持 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 都是在用戶提的需求中提早增長支持的，所以咱們歡迎您和咱們一塊兒打造更完美的數據管理平臺，期待您的參與！

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