如何監控Redis性能指標（譯）

Redis給人的印象是簡單、很快，可是不表明它不須要關注它的性能指標，此文簡單地介紹了一部分Redis性能指標.
翻譯過程當中加入了本身延伸的一些疑問信息，仍然還有一些東西沒有徹底弄明白。
原文中Metric to watch *** 和 Metric to alert on ***這裏翻譯爲須要觀察的指標和須要告警的指標，不知道合不合適。

原文出處：https://www.datadoghq.com/blog/how-to-monitor-redis-performance-metrics/

 

如下爲部分譯文：

監控Redis能夠幫助解決兩個方面的問題：Redis自己的資源問題，以及基礎架構中其餘方面出現的問題。 在本文中，咱們將介紹如下每一個類別中最重要的Redis指標：

性能指標：　　　　Performance metrics
內存指標：　　　　Memory metrics
基本活動指標：　　Basic activity metrics
持久性指標：　　　Persistence metrics
錯誤指標：　　　　Error metrics

1．性能指標：Performance metrics

除錯誤率低外，良好的性能是系統健康情況的最佳頂級指標之一。性能不佳一般是由內存問題引發的，如內存部分所述。

Name	Description	Type
latency	Redis響應一個請求的時間 Average time for the Redis server to respond to a request	Performance
instantaneous_ops_per_sec	平均每秒處理請求總數 Total number of commands processed per second	Throughput
hit rate (calculated)	緩存命中率（計算出來的） keyspace_hits / (keyspace_hits + keyspace_misses)	Success

1.1須要告警的指標: latency（延遲） 

延遲是客戶端請求與實際服務器響應之間的時間的度量。跟蹤延遲是檢測Redis性能變化的最直接方法。
因爲Redis的單線程特性，異常狀況下的延遲可能會致使嚴重的瓶頸。一個請求的長響應時間會增長全部後續請求的延遲。
一旦肯定延遲是一個問題，您能夠採起一些措施來診斷和解決性能問題。請參閱白皮書「瞭解前5個Redis性能指標」中的第14頁的「使用延遲命令提升性能」一節。

 

譯者注：哪些因素會引發延遲？

1，slowlog 慢查詢引發的延遲

slowlog-log-slower-than： 慢查詢時間閾值，超過這個閾值的查詢將會被記錄，默認值10000，可是微妙，也即10毫秒。

slowlog-max-len：慢查詢日誌最大條數，默認值128，先進先出的隊列的形式記錄在內存中。

slowlog-get n：獲取前n條慢查詢日誌

2，網絡延遲

redis-cli --latency 命令用來檢測網絡延遲，輸出的時間單位爲毫秒，它經過Redis PING命令測量Redis服務器響應的時間(以毫秒爲單位)來實現這一點。
redis-cli --latency -h 127.0.0.1 -p

對於以上返回信息的含義，參考：https://stackoverflow.com/questions/27735411/understanding-latency-using-redis-cli
在此上下文中，延遲是客戶機發出命令到客戶機接收到對命令的響應之間的最大延遲。一般Redis處理時間很是低，在亞微秒範圍內，可是有一些條件會致使更高的延遲數字。
What's (1815samples)? 這是redis-cli記錄發出PING命令並接收響應的次數。換句話說，這是採樣數據。在當前示例中，記錄了1815個請求和響應。
What's min: 0? 最小值表示CLI發出PING的時間到收到回覆的時間之間的最小延遲。換句話說，這是來自採樣數據的最佳響應時間。
What's max: 15? 最大值表示CLI發出PING信號到收到命令的響應之間的最大延遲。這是來自採樣數據的最長響應時間。在咱們1815個示例中，最長的事務花費了1ms。
What's avg: 0.12? avg值是全部採樣數據的平均響應時間(以毫秒爲單位)。平均而言，個個樣本的響應時間是0.12毫秒。
redis-cli --latency-history，以分段的形式展示Redis延遲

redis-cli --latency-dist，以圖表的形式展示Redis延遲，這個圖表的結果看不怎麼懂

3，Intrinsic latency 固有延遲
顧名思義，任何請求響應都要通過代碼的處理，必然有延遲，Intrinsic latency是Redis自身處理指令須要消耗的時間，這部分時間耗費沒法避免。
固然Intrinsic latency的延遲很是低，在微妙級別

　　如何檢測延遲？
　　參考：https://blog.csdn.net/dc_726/article/details/47699739，http://www.redis.cn/topics/latency-monitor.html
　　 CONFIG SET latency-monitor-threshold 100
　　延遲檢測模式是關閉的，能夠經過配置打開延遲監控

　　打開延遲監控後，人爲製造一個產生高延遲的save操做指令，經過latency latest觀測延遲信息
　　latency latest：四列分別表示事件名、最近延遲的Unix時間戳、最近的延遲（毫秒）、最大延遲（毫秒）。

　　

latency 能夠經過如下參數檢測延遲信息
LATEST：四列分別表示事件名、最近延遲的Unix時間戳、最近的延遲、最大延遲。
HISTORY：延遲的時間序列。可用來產生圖形化顯示或報表。
GRAPH：以圖形化的方式顯示。最下面以豎行顯示的是指延遲在多久之前發生。
RESET：清除延遲記錄。

1.2須要觀察的指標：instantaneous_ops_per_sec

跟蹤處理的命令吞吐量對於診斷Redis實例中的高延遲緣由相當重要。
高延遲多是由許多問題引發的，從積壓命令隊列到慢速命令，再到網絡過分使用。
能夠經過測量每秒處理的命令數來進行診斷 - 若是它相對比較平穩，則緣由不是計算密集型命令（Redis自己引發的）。
若是一個或多個慢速命令致使延遲問題，您將看到每秒的命令數量徹底降低或中止。
與歷史基線相比，每秒處理的命令數量的降低多是低命令量或阻塞系統的慢命令的標誌。
1．OPS較低多是正常的，或者它可能表示上游存在問題（譯者注：表示Redis自己被負載量較低）。
2．有關慢速命令的詳細信息，請參閱第2部分，瞭解有關收集Redis指標的信息。

譯者注：如何獲取Redis的OPS

1.3Metric to watch: hit rate

使用Redis做爲緩存時，監視緩存命中率能夠告訴您緩存是否被有效使用。命中率低意味着客戶端正在尋找再也不存在（Redis內存中）的Key值。
Redis不直接提供命中率指標。咱們仍然能夠像這樣計算：
HitRate=keyspace_hits/(keyspace_hits+keyspace_misses)
低緩存命中率可能由許多因素引發，包括數據到期和分配給Redis的內存不足（這可能致使key值被清除）。
低命中率可能會致使應用程序延遲增長，由於它們必須從較慢的備用資源中獲取數據。

譯者注：如何獲取Redis的keyspace_hits+keyspace_misses，一樣是info stats

2.Memory metrics

Name	Description	Type
used_memory	已使用內存 Amount of memory (in bytes) used by Redis	Utilization
mem_fragmentation_ratio	內存碎片率 Ratio of memory allocated by the operating system to memory requested by Redis	Saturation
evicted_keys	因爲最大內存限制被移除的key的數量 Number of keys removed due to reaching the maxmemory limit	Saturation
blocked_clients	因爲BLPOP, BRPOP, or BRPOPLPUSH而備阻塞的客戶端 Number of keys removed due to reaching the maxmemory limit	Other

2.1須要注意的指標: used_memory

內存使用是Redis性能的關鍵組成部分。
若是實例超過可用內存(used_memory > total available memory)，操做系統將開始交換老的/未使用的部份內存(pages)，將該部分pages寫入磁盤，爲較新/活動頁騰出內存空間。
每一個交換的部分都寫入磁盤，嚴重影響性能。從磁盤寫入或讀取速度比寫入或從存儲器讀取速度慢5個數量級（100,000）（內存爲0.1μs，磁盤爲10 ms）。
能夠將Redis配置爲僅限於指定的內存量。在redis.conf文件中設置maxmemory指令能夠直接控制Redis的內存使用狀況。
啓用maxmemory須要您爲Redis配置驅逐（過時）策略以肯定它應如何釋放內存。
當Redis用做緩存時，這種「扁平線」模式很常見;消耗掉全部可用內存，並以與插入新數據相同的速率清理舊數據。

　　譯者注：關於Redis的內存參數 info memory
　　used_memory和used_memory_human都是Redis使用到的內存，used_memory_human是一更加可讀性的方式展現Redis的內存使用
　　used_memory_rss和used_memory_rss_human 表示操做系統爲Redis進程分配的內存總量，二者的含義相似如上。
　　爲何會出現Redis使用的內存大於操做系統給Redis分配的內存，參考https://stackoverflow.com/questions/44385820/redis-used-memory-is-largger-than-used-memory-rss
　　used_memory being < used_memory_rss意味着內存碎片的存在。
　　used_memory > used_memory_rss 意味着物理內存不足，發生了內存swap。

2.2 須要告警的指標: mem_fragmentation_ratio

mem_fragmentation_ratio度量標準給出了操做系統看到的內存與Redis分配的內存的比率。
MemoryFragmentationRatio =Used_Memory_RSS（Used_Memory）
操做系統負責爲每一個進程分配物理內存。操做系統的虛擬內存管理器處理由內存分配器調解的實際映射。
若是Redis實例的內存佔用爲1GB，內存分配器將首先嚐試找到一個連續內存段來存儲數據。若是沒有找到連續的段，分配器必須將進程的數據劃分爲多個段，從而致使內存開銷的增長。
跟蹤碎片比率對於瞭解Redis實例的性能很是重要。
碎裂率大於1表示發生碎片。比率超過1.5表示碎片過多，Redis實例佔用了所請求的物理內存的150％。
碎片率低於1會告訴您Redis須要的內存比系統上可用的內存多，這會致使交換。交換到磁盤將致使延遲顯着增長（請參閱已用內存）。
理想狀況下，操做系統會在物理內存中分配一個連續的段，碎片比率等於1或稍大一些。
1，若是您的服務器的碎片率高於1.5，則從新啓動Redis實例將容許操做系統恢復之前因碎片而沒法使用的內存。在這種狀況下，做爲通知的警報可能就足夠了。
2，若是Redis服務器的碎片比率低於1，則可能須要以發出告警，以便快速增長可用內存或減小內存使用量。
從Redis 4開始，當Redis配置爲使用包含的jemalloc副本時，可使用新的活動碎片整理功能。
能夠將此工具配置爲在碎片達到特定級別時啓動，並開始將值複製到連續的內存區域並釋放舊副本，從而減小服務器運行時的碎片。

譯者注，info memory能夠查看內存碎片信息

配置文件中增長activedefrag yes選項，不用重啓的方式自動重整內存碎片。

2.3須要告警的指標：evicted_keys（僅限緩存）

若是您使用Redis做爲緩存，可能將其配置爲在達到maxmemory限制時（按照某種方式）自動清除key值。
若是您使用Redis做爲數據庫或隊列，可能須要交換而不是清除key值，在這種狀況下，所以能夠跳過此指標。
跟蹤key值清理指標很是重要，由於Redis按順序處理每一個操做，這意味着驅逐大量key能夠下降命中率，從而增長延遲時間。
若是您使用TTL，您可能不會指望清理key值。在這種狀況下，若是此指標始終高於零，您可能會看到實例中的延遲增長。
大多數不使用TTL的其餘配置最終會耗盡內存並開始清理key值。只要您的響應時間能夠接受，就能夠接受穩定的清除率。
您可使用如下命令配置key值過時策略：
config set maxmemory-policy = ***

其中policy是如下之一：
noeviction-----------------------當達到內存限制而且用戶嘗試添加其餘鍵時，將返回錯誤（也就是說達到內存限制以後不容許寫入）
volatile-lru-----------------------在已過時的key值中，刪除最近最少使用的key值
volatile-ttl------------------------在已過時的key值中，刪除最短過時時間的key值
volatile-random-----------------在已過時的key值中，隨機刪除key值
allkeys-lru-----------------------從全部key值中刪除最近最少使用的key
allkeys-random-----------------從全部key值中隨機刪除
volatile-lfu-----------------------在Redis 4中新增選項，在已過時的key值中，「最近最不經常使用」的key值
allkeys-lfu-----------------------在Redis 4中新增選項，從全部key值中，刪除「最近最不經常使用」的key值

注意：出於性能緣由，當使用LRU，TTL或Redis 4的LFU策略時，Redis實際上不會從整個key值集進行採樣。
Redis首先對key值集的隨機子集進行採樣，而後對樣本應用清理策略。
一般，Redis的較新（> = 3）版本採用LRU採樣策略，該策略更接近真實LRU。
例如，能夠經過設置必須通過多少時間而無需訪問項目在排名中向下移動來調整LFU策略。有關更多詳細信息，請參閱Redis的文檔。

譯者注：
關於LRU和LFU，分別是最近最少使用和最近最不頻繁使用，LFU理論上是比LRU更加合理的算法，清理key的時候，LFU認爲「最近最不頻繁」使用要比「最近最少」使用更加合理。
LRU和LFU的區別：
LRU是最近最少使用頁面置換算法(Least Recently Used),也就是首先淘汰最長時間未被使用的頁面!
LFU是最近最不經常使用頁面置換算法(Least Frequently Used),也就是淘汰必定時期內被訪問次數最少的頁!

2.4 須要注意的指標: blocked_clients 

Redis提供了許多在List上運行的阻塞命令。
BLPOP，BRPOP和BRPOPLPUSH分別是命令LPOP，RPOP和RPOPLPUSH的阻塞變體。
當List非空時，命令按預期執行。可是，當List爲空時，阻塞命令將一直等到源被填充或達到超時。
等待數據的被阻止客戶端數量的增長多是一個麻煩的跡象。
延遲或其餘問題可能會阻止源列表被填充。雖然被阻止的客戶端自己不會引發警報，但若是您看到此指標的值始終爲非零值，則應該引發注意。

3. 基本活動指標

Name	Description	Type
connected_clients	客戶端鏈接數 Number of clients connected to Redis	Utilization
connected_slaves	Slave數量 Number of slaves connected to current master instance	Other
master_last_io_seconds_ago	最近一次主從交互以後的秒數 Number of slaves connected to current master instance	Other
keyspace	數據庫中的key值總數 Total number of keys in your database	Utilization

 3.1 須要告警的指標: connected_clients

因爲對Redis的訪問一般由應用程序發起（用戶一般不直接訪問數據庫），所以對於大多數場景，鏈接客戶端的數量將有合理的上限和下限。
若是數字偏離正常範圍，這表示可能存在問題。
若是它過低，表示客戶端鏈接可能已經丟失，若是它過高，大量的併發客戶端鏈接可能會打垮服務器處理請求的能力。
不管如何，客戶端鏈接始終是有限的資源 - 不管是經過操做系統，Redis的配置仍是網絡限制。
監視客戶端鏈接可幫助您確保有足夠的可用資源用於新客戶端或管理會話。

譯者注：查看Redis的最大鏈接數，這個配置至關於MySQL的變量（show variables ***），是一個不隨Redis服務負載改變的值，所以不在info中查看。

 

3.2須要告警的指標: connected_slaves

若是您的數據庫是大量讀取的，那麼您可能正在使用Redis中提供的主從數據庫複製功能。
在這種狀況下，監控鏈接的從站數量是關鍵。若是鏈接的從站數量意外更改，則可能表示主機已關閉或從站實例出現問題。

注意：在上圖中，Redis Master將顯示它有兩個鏈接的slave，而且每一個slave都有兩個slave。
因爲slave的slave不直接鏈接到Redis Master，所以它們不包含在Redis Master的connected_slaves中。

3.3須要告警的指標: master_last_io_seconds_ago

使用Redis的複製功能時，slave會按期檢查其主服務器。主從長時間沒有通訊的可能表示主從Redis實例之間存在問題。而且冒着slave中數據在master中已經發生了變化危險。
因爲Redis執行同步的方式，最大限度地減小主從通訊的中斷相當重要。當從設備在中斷後從新鏈接到master時，它會發送PSYNC命令以嘗試僅同步中斷期間丟失的命令。
若是沒法作到這一點，則從站將請求完整的SYNC，這會迫使master當即開始執行background save命令，同時新增長的命令會被緩衝起來。
當background save命令執行完成時，數據與緩衝的命令一塊兒發送到客戶端。每次從機執行SYNC時，都會致使主實例上的延遲顯着增長。

3.4須要注意的指標: keyspace

跟蹤數據庫中的鍵數一般是個好主意。做爲內存數據存儲，key值集合空間越大，爲了確保性能，Redis須要的物理內存越多。
Redis將繼續添加key值，直到它達到maxmemory limit，而後它開始以相同的速率清理key值。這會產生一個「扁平線」圖，如上圖所示。
若是您使用Redis做爲緩存並查看key值空間飽和度 - 如上圖所示 - 加上命中率較低，您可能會讓客戶端請求舊的或已逐出的數據。隨着時間的推移跟蹤keyspace_misses數量將幫助您查明緣由。
或者，若是使用Redis做爲數據庫或隊列，則可能不選擇volatile策略。
隨着key值空間的增加，若是可能的話，您可能須要考慮在添加物理內存或在主機之間拆分數據集。
添加更多內存是一種簡單有效的解決方案。若是單機資源有限，則對數據進行分區或分片能夠合併許多計算機的資源。
有了分區計劃，Redis能夠存儲更多key值集合而無需清理或swap。可是，分片比增長內存要困可貴多。
值得慶幸的是，Redis文檔中有一個關於使用Redis實例實現分區方案的重要部分，請在此處閱讀更多內容。

 　　譯者注：Redis的keyspace信息

 

4.持久化指標

Redis須要啓用持久性配置，尤爲是在使用Redis的複製功能時。
若是您使用Redis做爲緩存，或者在數據丟失可有可無的用例中，則可能不須要持久性。

Name	description	Type
rdb_last_save_time	最後一次持久化保存到磁盤的Unix時間戳 Unix timestamp of last save to disk	other
rdb_changes_since_last_save	自最後一次持久化以來數據庫的更改數	other

 4.1 須要注意的指標: rdb_last_save_time and rdb_changes_since_last_save

一般，關注數據集的波動性是個好主意。寫入磁盤之間的時間間隔過長可能會在服務器發生故障時致使數據丟失。
在上次保存時間和故障時間之間對數據集所作的任何更改都將丟失。
監控rdb_changes_since_last_save可以讓您更深刻地瞭解數據的波動性。若是您的數據集在該間隔內沒有太大變化，則寫入之間的長時間間隔不是問題。
跟蹤這兩個指標可讓您清楚地瞭解在給定時間點發生故障時您將丟失多少數據。

譯者注：如何查看Redis的rdb_last_save_time and rdb_changes_since_last_save

info Persistence

5．Error metrics

Redis錯誤指標能夠提醒您注意異常狀況。如下指標可跟蹤常見錯誤：

Name	Description	Type
rejected_connections	因爲達到maxclient限制而被拒絕的鏈接數 number of connections rejected due to hitting maxclient limit	Saturation
keyspace_misses	Key值查找失敗（沒有命中）次數 number of failed lookups of keys	Errors / Other
master_link_down_since_seconds	主從斷開的持續時間（以秒爲單位） time in seconds of the link between master and slave being down	Errors

5.1須要告警的指標: rejected_connections

Redis可以處理許多活動鏈接，默認狀況下可使用10,000個客戶端鏈接。
能夠經過更改redis.conf中的maxclient指令將最大鏈接數設置爲不一樣的值。
若是您的Redis實例當前處於其最大鏈接數，則將斷開任何新的鏈接嘗試。

請注意，Redis可能不支持使用maxclient指令請求的鏈接數。
Redis檢查內核以肯定可用文件描述符的數量。若是可用文件描述符的數量小於maxclient + 32（Redis爲其本身使用保留32個文件描述符），則忽略maxclient指令並使用可用文件描述符的數量。
有關Redis如何處理客戶端鏈接的更多信息，請參閱有關redis.io的文檔。

譯者注：rejected_connections能夠經過查看Info stat

5.2須要告警的指標: keyspace_misses

每次Redis查找key時，只有兩種可能的結果：key存在，或key不存在。
查找不存在的鍵會致使keyspace_misses計數器遞增，所以keyspace_misses意味着客戶端嘗試在數據庫中查找不存在的密key。
若是您不使用Redis做爲緩存，則keyspace_misses應該爲零或接近零。請注意，調用阻塞的任何阻塞操做（BLPOP，BRPOP和BRPOPLPUSH）都將致使keyspace_misses遞增。

譯者注：keyspace_misses能夠經過查看Info stat

5.3須要告警的指標: master_link_down_since_seconds

該指標僅在主從之間的鏈接丟失時可用。
理想狀況下，此值不該超過零-主從之間保持持續通訊，以確保slave不提供過期數據。
應該解決鏈接之間的大的時間間隔。請記住，從新鏈接後，您的主Redis實例將須要投入資源來更新從站上的數據，這可能會致使延遲增長。

總結

在這篇文章中，咱們提到了一些最有用的指標，您能夠監控這些指標以密切關注您的Redis服務器。若是您剛剛開始使用Redis，那麼監控下面列表中的指標將提供對數據庫基礎結構的運行情況和性能的良好可見性：Number of commands processed per secondLatencyMemory fragmentation ratioEvictionsRejected clients最終，您將認識到與您本身的設備和用例特其餘指標。固然，您監控的內容取決於您擁有的工具和可用的指標。有關收集Redis指標的分步說明，請參閱隨附文章。