統合監視 | Prometheus を使用して Memcached を監視するためのベストプラクティス

作者: ウェイウェイ

Memcached の概要

Memcached とは何ですか?

Memcached は、キーと値のペアの形式であらゆるデータ型のチャンクデータを保存することをサポートする、無料のオープンソースの高性能分散メモリオブジェクトキャッシングシステムです。 Memcached は基本的にすべてのアプリケーションに汎用的ですが、もともとは頻繁にアクセスされる静的データを保存し、データベースの負荷を軽減し、動的な Web アプリケーションを高速化するために使用されていました。

Memcached の機能

メモリストレージ

Memcached のすべてのデータはメモリに保存されます。PostgreSQL や MySQL などの永続データベースと比較して、ストアドプロセスはディスクへのラウンドトリップを繰り返す必要がないため、メモリレベルの応答時間 (<1ms) を実現し、1 回あたり 10 億のオペレーションを実行できます。 2番。
配布された

分散マルチスレッドアーキテクチャにより、拡張が容易になります。クラスターに新しいノードを追加することで、複数のノード間でのデータの分散をサポートし、容量を拡張します。さらに、Memcached はノードの複数のコアを指定し、マルチスレッドを使用して処理速度を向上させます。
キー値のストレージ

Memcached はあらゆる種類のデータを保存し、頻繁にアクセスされるすべてのデータの保存をサポートし、さまざまなアプリケーションシナリオに適しています。クエリ効率を向上させるために、結合クエリなどの複雑な操作はサポートされていません。
シンプルさと使いやすさ

Memcached は、Java、C/C++、Go などのさまざまな言語フレームワークでクライアントプログラムを提供します。

適用可能な典型的なシナリオ

該当シーン

キャッシュ

Memcached の最初の使用シナリオは、頻繁に読み取られ、めったに変更されない Web ページの静的データ (HTML、CSS、画像、セッションなど) を保存することです。ユーザーが Web ページにアクセスすると、最初にメモリ内の静的データを返すことができるため、Web サイトの応答速度が向上します。他のキャッシュと同様、Memcached はアクセスされるたびにデータの存在を保証しませんが、短期的にはアクセスを高速化する可能性を提供します。

データベースフロントエンド

Memcached は、クライアントとシステム内の永続データベースの間に配置される高性能メモリキャッシュとして使用でき、遅いデータベースへのアクセス数を減らし、バックエンドシステムの負荷を軽減します。基本的にはデータベースのコピーと同じです。データベースを読み込む場合は、まずMemcachedに存在するか確認し、存在しない場合はさらにデータベースにアクセスし、存在する場合は直接リターンします。データベースに書き込む場合は、Memcached への書き込み直後に戻り、アイドル時間中にデータベースに書き込みます。

例：ソーシャルアプリでは、「最新コメント」や「注目コメント」など、大量のデータ計算を必要とし、頻繁に呼び出される機能がよくあります。リレーショナルデータベースのみを使用する場合は、ディスクの読み取りと書き込みを頻繁に行う必要があります。このような操作を行う場合、データの多くが再利用されるため、データをメモリ内に短時間保持すると、プロセス全体が大幅に高速化されます。前回、上位のコメントが 1000 件のコメントに基づいて計算されたとき、800 件が再アクセスされ、Memcached に留まることができました。次回最も人気のあるコメントを計算するときは、データベースからさらに 200 個のコメントを取得するだけで済み、データベースの読み取りと書き込みの回数が 80% 節約されます。

大量のデータ、高頻度の読み取りおよび書き込みシナリオ

Memcached は純粋なメモリストレージデータベースであり、そのアクセス速度は他の永続性デバイスよりもはるかに高速です。さらに、分散データベースとして、Memcached は水平拡張をサポートし、高負荷のリクエストを複数のノードに分散し、高同時アクセスモードを提供します。

該当しないシナリオ

キャッシュオブジェクトが大きすぎます

ストレージ設計により、キャッシュされたオブジェクトは 1MB を超えないようにすることが公式に推奨されています。Memcached 自体は、大きなマルチメディア (ラージメディア) や巨大なバイナリブロック (ストリーミング巨大 BLOB) を保存および処理するように設計されていません。

データをトラバースする必要がある

Memcached は、少数のコマンド (set、put、inc、dec、del、cas) のみをサポートするように設計されており、データへのトラバーサルアクセスはサポートしていません。 Memcached は一定時間内に読み取りと書き込みを完了する必要がありますが、データ量が増えるとデータの走査にかかる時間が長くなり、その過程で他のコマンドの実行速度に影響を及ぼし、速度が追いつきません。デザインコンセプトとともに。

高可用性と耐障害性

Memcached は、キャッシュされたデータが失われないことを保証するものではありませんが、逆に、Memcached にはヒット率、つまり予想されるデータ損失は許容されるという概念があります。データの災害復旧バックアップ、自動パーティショニング、フェイルオーバー、その他の機能を確保する必要がある場合は、MySQL などの永続データベースにデータを保存するのが最善です。

Memcached のコア概念

メモリ管理

次の図は、Memcached のメモリ管理方法を示しています。

スラブ

メモリの断片化の発生を防ぐために、memcached はスラブを使用して管理します。 memcached はメモリをスラブと呼ばれる複数の領域に分割します。データを保存するときは、データのサイズに基づいてスラブを選択し、各スラブは特定の範囲内のデータの保存のみを担当します。例: 図のスラブには 1001 ～ 2000 バイトの値のみが格納されます。デフォルトでは、次のスラブに対する Memcached の最大値は、前のスラブの 1.25 倍です。この増加率は、-f パラメーターを変更することで変更できます。
ページ

スラブはページで構成されており、ページの固定サイズは 1M で、起動時に -I パラメータで指定できます。メモリを適用する必要がある場合、Memcached は新しいページを分割し、必要なスラブ領域に割り当てます。ページが割り当てられると、再起動するまで再利用または再割り当てされることはありません。
かたまり

データを保存するとき、memcached はページ内に固定サイズのチャンクを割り当て、そのチャンクに値を挿入します。挿入されたデータのサイズに関係なく、チャンクのサイズは常に固定であることに注意してください。各データが破棄されると、排他的なチャンクが占有されます。同じチャンクに 2 つの小さなデータが格納されることはありません。かたまり。チャンクが十分でない場合は、次のスラブクラスのチャンクに転送して保存することしかできないため、スペースの無駄が発生します。

LRU

図に示すように、Memcached は改良された LRU メカニズムを使用してメモリ内の項目を管理します。

熱い

アイテムが強い時間的局所性を示したり、TTL (生存時間) が非常に短い場合があるためです。したがって、項目が HOT 内で移動することはありません。項目がキューの最後に達すると、アクティブ (3) であれば WARM に移動され、非アクティブ (5) であれば WARM に移動され、COLD に移動します。
暖かい

古い投稿を読み取る Web クローラーなど、ワークロードをスキャンするためのバッファーとして機能します。 2回攻撃されていないアイテムはWARMに入ることができません。 WARM アイテムは、ロック競合を軽減しながら、TTL を生き延びる可能性が高くなります。末尾の項目がアクティブな場合は、それを先頭に戻します (4)。それ以外の場合は、非アクティブなアイテムを COLD (7) に移動します。
寒い

アクティビティが最も少ないアイテムが含まれます。非アクティブなアイテムは、HOT (5)、WARM (7) から COLD に流れます。メモリがいっぱいになると、項目は COLD の末尾から移動されます。項目がアクティブな場合、その項目はキューに入れられ、非同期的に WARM に移動されます (6)。 COLD でバーストまたは多数のクリックが発生した場合、バッファキューがオーバーフローする可能性があり、アイテムは非アクティブなままになります。過負荷状況では、COLD からの移動はワーカースレッドをブロックすることなく確率的なイベントになります。
温度

新しいアイテムのキューとしては、その TTL は短い (2) (通常は数秒)。 TEMP 内の項目は置き換えられたり、他の LRU に流れたりしないため、CPU とロックの競合が節約されます。この機能は現在、デフォルトでは有効になっていません。

クロールは、同時に各クローラー項目を LRU を下から上に逆方向に走査します。クローラーは渡された各アイテムをチェックして有効期限が切れているかどうかを確認し、有効期限が切れている場合はリサイクルします。

メインバージョンの紹介

1.6.0: 外部フラッシュストレージ、より多くのプロトコル、ネットワークの最適化をサポート
1.5.0: LRU実装の最適化、ストレージの最適化
1.4.0: C、Java、およびその他のクライアント実装、バイナリプロトコルをサポート
最新の安定バージョンを使用することをお勧めします

主要な指標を監視する

次に、オープンソース Memcached を監視する Prometheus の重要な指標をいくつか紹介します。

システムインジケーター

稼働状況

起動ステータスは、Memcached を監視するための最も基本的なインジケーターであり、Memcached インスタンスが正常に実行されているかどうか、または再起動されているかどうかを示します。 Memcached がダウンしても、データへのアクセスは基盤となる永続データベースに送信されるため、システム全体の機能にはほとんど影響しない可能性がありますが、Memcached キャッシュが不足すると、システムの動作効率が少なくとも 1 桁低下します。。

Memcached の起動時間を確認すると、Memcached が再起動したかどうかを確認できます。 Memcached はすべてのデータをメモリに配置するため、Memcached を再起動すると、キャッシュされたデータはすべて失われます。このとき、Memcached のヒット率が急激に低下し、キャッシュ雪崩が発生し、基盤となるデータベースに大きな負荷がかかり、システム効率が低下します。

メモリ使用量

高性能キャッシュとして、Memcached はノードのハードウェアリソースを最大限に活用して、高速なデータストレージとクエリサービスを提供する必要があります。ノードのリソース使用量が予想を超えたり、制限に達したりすると、パフォーマンスの低下やシステムクラッシュが発生し、システムに影響を与える可能性があります。通常の業務運営です。 Memcached はデータをメモリに配置するため、メモリの使用量に注目する必要があります。

Memcached のメモリ使用量が高すぎると、ノードの他の実行中のタスクに影響を与える可能性があります。主要な設計が科学的であるかどうかを検討し、ハードウェアリソースを増やすなどの最適化ソリューションが必要です。

読み書き能力の指標

読み取りおよび書き込み速度

読み取りおよび書き込み速度は、Memcached クラスターのパフォーマンスを示す重要な指標です。読み取りおよび書き込みのレイテンシが高い場合、システムの応答時間の長さ、ノードの負荷の高さ、システムのボトルネックなどの問題が発生する可能性があります。読み取りおよび書き込みインジケータは、Memcached の動作効率の概要を表します。読み取りおよび書き込みの遅延が大きいことが判明した場合、運用および保守担当者は、問題のトラブルシューティングを行うために他の監視データに注意を払う必要がある場合があります。読み取りおよび書き込み速度が遅い場合は、ヒット率が低い、ノードリソースが不足しているなど、さまざまな理由が考えられます。パフォーマンスを向上させるには、問題が異なれば、さまざまなトラブルシューティングと最適化の措置を講じる必要があります。

コマンドレート

Memcached は、set、get、delete、CAS、incr などのさまざまなコマンドをサポートしています。各コマンドのレートを監視することで、Memcached のボトルネックを特定できます。特定のコマンドのレートが低く、全体的なレートが低い場合は、アイテムのストレージ戦略の調整、アクセス方法の変更などを検討して、Memcached のパフォーマンスを向上させることができます。。

ヒット率

キャッシュによりクエリのパフォーマンスと効率が向上し、ディスク読み取りの数が減少するため、システムの応答速度とスループットが向上します。ヒット率は Memcached の最も重要な指標であり、ヒットとは、上位層のアプリケーションが特定のデータを取得するときに、基礎となるデータベースにアクセスせずに Memcached からデータを取得できることを意味します。ヒット率が高い場合、ほとんどのデータがメモリ内でアクセスされていることを示します。

キャッシュを使用するシステムでは、キャッシュ雪崩、キャッシュペネトレーション、キャッシュ破壊などが発生し、一定時間内にヒット率が非常に低下することがあります。アクセスはすべてディスクに落ち、基盤となるデータベースは大きな負荷にさらされました。 Memcached がシステム内で適切な役割を確実に果たせるように、ヒット率の変化に常に注意を払う必要があります。例：ある時間帯に突然Webサイトのレスポンスが非常に遅くなり、その間のヒット率が非常に低いことが分かり、再度ログを確認したところ、あるページが突然以前の状態から変化していることが分かりました。業務の変化により、低頻度のアクセスが高頻度のアクセスに変化した結果、キャッシュの侵入が検出されました。ヒット率が低いという問題を解決するには、以下のスラブインジケーターなどの他のインジケーターと組み合わせて分析する必要があります。

スラブインジケーター

キー/値データベースとして、Memcached はメモリ内のキー値のペアをアイテムと呼びます。 Memcached 内のアイテムの保存状況を理解することで、メモリ使用効率を最適化し、ヒット率を向上させることができます。

アイテム保管庫

通常、アイテムの保管ステータスは、Memcached によって保管されるアイテムの総量、リサイクルされるアイテムの総量、および追い出されるアイテムの総量など、監視されます。アイテムの総数の傾向を観察することで、Memcached ストレージへの負荷と、Memcached を使用するアプリケーションのストレージパターンを確認できます。

エビクションとリサイクルの違いは、アイテムをエビクトする必要がある場合、Memcached は LRU 末尾の周囲のいくつかのアイテムを調べ、リサイクル可能な有効期限切れのアイテムを探し、実際の末尾をエビクトする代わりにそのメモリ領域を再利用することです。

スラブの使用法

Memcached の設計思想によれば、各スラブに格納されるアイテムのサイズは同じであり、各アイテムは専用のチャンクを占有するため、メモリ使用率が向上します。ただし、使用中には、この設計には最適化の余地がまだあります。

Memcached の石灰化は一般的な問題です。メモリが Memcached の制限に達すると、サービスプロセスは一連のメモリリサイクルプランを実行しますが、メモリリサイクルプランがどのようなものであっても、リサイクルの大前提は 1 つだけあります。それは、データと一致するデータのみをリサイクルすることです。書き込もうとしているブロック。

例: 以前は 64Kb のサイズの多数のアイテムを保存していましたが、現在は 128Kb のサイズの多数のアイテムを保存する必要があります。メモリ割り当てが十分ではなく、これらの 128Kb アイテムが常に更新される場合、Memcached は新しいデータを保存するために他の 128Kb アイテムを削除することしか選択できません。元の 64Kb アイテムは削除されず、有効期限が切れるまでメモリ領域を占有し続け、その結果、領域が無駄になり、最終的にヒット率が低下することがわかりました。

石灰化の問題を解決するには、各スラブ内のアイテムの分布指標を理解する必要があります。スラブ間で保管されているアイテムの数の比較を観察するために、この種のモニタリングを提供します。特定のスラブに保管されているアイテムの数が他のスラブよりもはるかに多いことが判明した場合は、各スラブのサイズを調整することを検討できます。デフォルトのスラブサイズ増加係数は 1.25 です。つまり、各スラブの容量は前のスラブの 1.25 倍です。成長係数を下げ、アイテムが各スラブに均等に分散されるようにスラブの開始サイズを設定することで、石灰化の問題を効果的に軽減し、メモリ使用効率を向上させることができます。

LRUインジケーター

エリア項目数

Memcached の LRU では、各領域に異なる機能があります。 HOT のアイテムは最新の保管アイテム、WARM のアイテムは人気のアイテム、COLD のアイテムは有効期限が近づいているアイテムです。各領域のアイテムの数を知ることで、Memcached のステータスをより深く理解し、チューニングソリューションを提供できます。ここではいくつかの例を示します。

HOT エリアではアイテムが少なく、他のエリアではアイテムが増えています。これは、新しく作成される項目が少なく、Memcached 内のデータがほとんど更新されず、システム内のデータの読み取りが主であることを示します。逆にＨＯＴ領域の項目が多く、新規に作成された項目が多いことを示しており、この時点では主に書き込みが行われている。

COLD エリアよりも WARM エリアの方がアイテムの数が多くなります。このとき、アイテムがヒットする頻度が高くなり、理想的な状況になります。逆にヒット率は低く、最適化を考慮する必要があります。

アイテムの数を移動します

項目がヒットしたかどうかは、その項目がどの LRU 領域にあるかに影響します。 LRUの設計思想に基づき、LRU領域内のアイテムの移動を監視することで、データアクセスの状況を把握できます。ここではいくつかの例を示します。

COLDエリアからWARMエリアへ移動するアイテム数が増加します。期限切れ間近のアイテムがヒットしたことを示し、値が大きすぎると不人気なデータが突然ホットデータになることを示します。命中率の低下を防ぐためには、このような状況にも注意する必要があります。

HOT エリアから COLD エリアに移動されるアイテムの数が多くなります。これは、挿入後にアクセスされなくなったアイテムが多数あることを示しています。このデータはキャッシュする必要がない可能性があります。メモリ負荷を軽減するために、基礎となるデータベースに直接保存することを検討してください。

WARMエリアのアイテム数は豊富です。これは、挿入後に大量のアイテムがアクセスされることを示しており、この状態が理想的であり、Memcached に格納されているデータは頻繁にアクセスされ、このときのヒット率は高くなります。

接続メトリクス

接続ステータス

Memcached はイベントベースのアーキテクチャを使用しているため、通常、多数のクライアントによって速度が低下することはありません。 Memcached は、ユーザーが数十万のクライアントを接続している場合にも機能します。ただし、現在のユーザー接続数を監視すると、Memcached の動作ステータスの概要を把握できます。

接続エラー

Memcached は、単一のクライアント接続がイベントごとに実行できるリクエストの数を制限します。これは、有効になっている場合は -R パラメーターで決定されます。クライアントがこの値を超えると、サーバーは他のクライアントを優先してから、元のクライアント要求を続行します。クライアントが Memcached を正常に使用していることを確認するには、このような状況が発生するかどうかを常に監視する必要があります。 Memcached のデフォルトの最大接続数は 1024 です。運用および保守担当者は、接続数が制限を超えて機能の通常の使用に影響を与えないように、接続数を監視する必要があります。

指標の詳細な定義

システムインジケーター

インジケーター名	インジケーターの説明
memcached_process_system_cpu_秒_合計	プロセスのシステム CPU 使用時間
memcached_process_user_cpu_秒_合計	ユーザープロセスのCPU使用時間
memcached_limit_bytes	収納サイズ
memcached_time_秒	現在の時刻
memcached_up	始めるかどうか
memcached_uptime_秒	始まる時間
memcached_version	バージョン

読み書き能力の指標

インジケーター名	インジケーターの説明
memcached_read_bytes_total	サーバー内の読み取りデータの合計サイズ
memcached_write_bytes_total	サーバー内の送信データの合計サイズ
memcached_commands_total	コマンドごとに分類されたサーバー内のすべてのリクエストの合計数
memcached_slab_commands_total	スラブクラスのコマンドごとに分類された全リクエストの合計数

ストレージメトリクス

スラブストレージインデックス

インジケーター名	インジケーターの説明
memcached_items_total	収納アイテムの総数
memcached_items_evicted_total	追い出されたアイテムの数
memcached_slab_items_reclaimed_total	スラブごとに分類された期限切れアイテムの数
memcached_items_reclaimed_total	期限切れアイテムの総数
memcached_current_items	現在のインスタンス内のアイテムの数
memcached_malloced_bytes	スラブページサイズ
memcached_slab_chunk_size_bytes	チャンクサイズ
memcached_slab_chunks_free	空きチャンクの数
memcached_slab_chunks_used	非空きチャンクの数
memcached_slab_chunks_free_end	最新ページの空きチャンク数
memcached_slab_chunks_per_page	ページ内のチャンクの数
memcached_slab_current_chunks	スラブクラスのチャンクの数
memcached_slab_current_items	slab class中item数
memcached_slab_current_pages	slab class中page数
memcached_slab_items_age_秒	スラブクラスの最新の項目が最後にアクセスされてからの秒数
memcached_current_bytes	アイテムの実際の占有サイズ
memcached_slab_items_outofmemory_total	メモリ不足エラーを引き起こす項目の数
memcached_slab_mem_requested_bytes	スラブ内のアイテム保管サイズ

LRU ストレージのメトリクス

インジケーター名	インジケーターの説明
memcached_lru_crawler_enabled	LRU クローラーは有効になっていますか?
memcached_lru_crawler_hot_max_factor	HOT LRU が WARM LRU に変わるまでのアイドル期間を設定します
memcached_lru_crawler_warm_max_factor	WARM LRU が COLD LRU に変換されるまでのアイドル期間を設定します
memcached_lru_crawler_hot_percent	HOT LRU用に予約されているスラブの割合
memcached_lru_crawler_warm_percent	WARM LRU 用に予約されているスラブの割合
memcached_lru_crawler_items_checked_total	LRU クローラーによってチェックされたアイテムの数
memcached_lru_crawler_maintainer_thread	分割 LRU モードとバックグラウンドスレッド
memcached_lru_crawler_moves_to_cold_total	COLD LRU に移動されたアイテムの数
memcached_lru_crawler_moves_to_warm_total	WARM LRU に移動されたアイテムの数
memcached_slab_items_moves_to_cold	COLD LRU に移動されたアイテムの数 (スラブごとに分類)
memcached_slab_items_moves_to_warm	WARM LRU に移動されたアイテムの数 (スラブごとに分類)
memcached_lru_crawler_moves_within_lru_total	クローラーによって処理され、HOT および WARM LRU でスクランブルされたアイテムの数
memcached_slab_items_moves_within_lru	ヒットによりHOTとWARMの間で交換されるアイテムの数
memcached_lru_crawler_reclaimed_total	LRU クローラーによってクリーニングされた LRU 内のアイテムの数
memcached_slab_items_crawler_reclaimed_total	スラブ内の LRU クローラーによってクリーニングされたアイテムの数
memcached_lru_crawler_sleep	LRU クローラー間隔
memcached_lru_crawler_starts_total	LRUの起動時間
memcached_lru_crawler_to_crawl	各スラブによってクロールされるアイテムの最大数
memcached_slab_cold_items	COLD LRU の項目数
memcached_slab_hot_items	HOT LRUのアイテム数
memcached_slab_hot_age_秒	HOT LRU の最も古いアイテムの年齢
memcached_slab_cold_age_秒	COLD LRU 内の最も古いアイテムの経過時間
memcached_slab_warm_age_秒	WARM LRU の最も古いアイテムの年齢
memcached_slab_items_evicted_nonzero_total	有効期限が明示的に設定されている項目が、有効期限が切れる前に LRU から削除する必要がある合計回数
memcached_slab_items_evicted_total	排除されたが取得されなかったアイテムの総数
memcached_slab_items_evicted_unfetched_total	期限切れでまだ取得されていないアイテムの総数
memcached_slab_items_tailrepairs_total	特定の ID を持つアイテムを取得する必要がある合計回数
memcached_slab_lru_hits_total	LRU ヒットの総数
memcached_slab_items_evicted_time_秒	このスラブ内の最後に削除された項目に最後にアクセスしてからの秒数。
memcached_slab_warm_items	WARM中的item数，以slab分类

连接指标

指标名	指标说明
memcached_connections_total	接受连接总数
memcached_connections_yielded_total	因触及 memcached -R 限制而运行的连接总数。
memcached_current_connections	打开连接数
memcached_connections_listener_disabled_total	触及限制的连接总数
memcached_connections_rejected_total	拒绝连接数，触发memcached -c 限制
memcached_max_connections	client限制大小

监控大盘

我们默认提供了 Memcached Overview 大盘。

总览

在该 panel 能看到Memcached运行时需要重点关注的指标，在检查 Memcached 状态时，首先查看总览中是否有异常状态，再检查具体的指标。

启动状态：绿色代表正常运行，即能查询到 Memcached 运行指标；红色表示 Memcached 异常
内存使用率：使用红黄绿颜色提示，内存使用率在 80% 以下时为绿色，80%～90% 为黄色，90% 以上为红色
命中率：使用红黄绿颜色提示，在 10% 以下为红色，10%～30% 为黄色，30% 以上为绿色

性能

在以下 panel 能看到 Memcached 的运行速度，分为以下三类。

QPS：每秒能处理所有命令的总数
命令速率：每秒能处理命令的数量，分为 set、get 等 Memcached 命令
读/写速率：每秒能速写的数据量

命中率

命中率是需要重点关注的指标，通过以下三个 panel 能详细了解 Memcached 的命中状态。

总命中率：整体的命中率趋势
命令命中率：各命令的命中率趋势，一般重点关注 get 的命中率
命中 slab 区域：命中的 slab 在哪个区域

item

item 表示 Memcached 的存储状态，通过以下 panel 检查 Memcached 的内存使用状态。

item 总数：Memcached 存储 item 的趋势
各 slab 的 item 数：不同 slab 的 item 存储数量变化
slab 使用率、slab 大小：各 slab 的使用状态以及对应大小，能通过这些指标检查钙化问题
LRU 间 item 移动速率：通过检查 item 的移动情况，检查 Memcached 的热点、命中率问题
回收、过期、驱逐 item 数：当内存不足时，必须有 item 要移出 Memcached

内存

内存是 Memcached 的重点关注硬件资源，通过该 panel 能了解 Memcached 的内存使用情况：

最大内存：提供内存整体状态
内存使用率/使用量：分析内存使用的趋势
OOM 次数：检查是否因为内存不足造成 OOM

网络

尽管 Memcached 提供高并发无损耗的支持，但网络资源不是无限的，需要随时关注：

最大连接数以及连接使用率：查看趋势以及仪表盘检查连接数是否符合预期
拒绝连接数：检查是否发生过拒绝连接的情况，保证客户端正常运行
请求过多连接数：检查该趋势以保证没有异常客户端

句柄

句柄是系统指标，涉及到网络连接等资源。

关键告警项规则

在对 Memcached 进行告警规则配置时，我们推荐基于以上采集得到的指标，从以下几个方面进行告警规则的配置，分别是运行情况、资源使用情况、连接使用情况。一般来说，我们默认生成影响 Memcached 正常使用的告警规则，优先级较高。读写速率等与业务相关的告警则由用户自定义。以下是一些推荐的告警规则。

运行情况

Memcached 停机

Memcached 停机是 0/1 阈值的告警规则。一般来说，部署在 ACK 等阿里云环境的 Memcached 服务具有高可用的能力，当一个 Memcached 实例停止，其他的实例会继续工作。有可能出现程序错误，导致 Memcached 实例无法重新部署，这是非常严重的情况。我们默认设定 5 分钟内 Memcached 无法恢复的告警。

Memcached 重启

对于其他的服务，实例重启不算问题。然而 Memcached 是典型的有状态服务，它的主要数据都存储在内存中。当实例被重启，缓存的数据将全部丢失，此时命中率下降，导致系统性能很差。因此我们推荐监控 Memcached 的重启告警，当重启发生后找到对应问题，防止该情况再次出现。

资源使用情况

内存使用率

当内存使用率过高，Memcached 无法正常运行。我们设定的内存使用阈值为：危险值 80%，告警值 90%。当内存使用率为 80% 时，节点高负荷运转，但一般不影响正常使用。当内存长时间使用率为 90% 时，将发出告警，提示运维资源紧缺，尽早处理。

item 触发 OOM

当内存使用量超过节点总内存时，内存不足 (OOM) 情况可能会导致数据完全缓存刷新，从而中断您的应用程序和业务。当节点内存利用率指标接近 100% 时，实例更有可能遇到 OOM 情况。我们设置了 0/1 阈值的告警，一旦出现 OOM 则立刻告警。

连接使用情况

拒绝连接

一般情况下连接数的增多不影响 Memcached 的运行，除非突破了最大连接数限制，此时客户端无法正常获取 Memcached 服务。我们设置了 0/1 阈值的告警，一旦出现拒绝连接的情况，立刻告警，保证客户端正常运行。

连接请求数过多

我们设置了 0/1 阈值的告警，一旦出现连接请求数过多的情况，立刻告警，保证客户端正常运行。在这样的情况下，Memcached 暂时不接受该连接的命令。

监控体系搭建

自建 Prometheus 监控 Memcached 的痛点：

通常我们当前的 Memcached 都是部署在 ECS 上，因此自建 Prometheus 监控 Memcached 时，我们将面临的典型问题有：

由于安全、组织管理等因素，用户业务通常部署在多个相互隔离的 VPC，需要在多个 VPC 内都重复、独立部署 Prometheus，导致部署和运维成本高。
每套完整的自建监控系统都需要安装并配置 Prometheus、Grafana、AlertManager 等，过程复杂、实施周期长。
缺少与阿里云 ECS 无缝集成的服务发现（ServiceDiscovery）机制，无法根据 ECS 标签来灵活定义抓取 targets。如果自行实现类似功能，则需要使用 Golang 语言开发代码（调用阿里云 ECS POP 接口）、集成进开源 Prometheus 代码、编译打包后部署，实现门槛高、过程复杂、版本升级困难。
常用开源 Grafana Memcached 大盘不够专业，缺少结合 MSSQL 原理/特征和最佳实践进行深入优化。
缺少 Memcached 告警指标模板，需要用户自行研究、配置告警项，工作量大。

用阿里云 Prometheus 进行自建 Memcached 的监控：

登录 ARMS 控制台 [ 1] 。
在左侧导航栏选择 Prometheus监控 > Prometheus 实例列表，进入可观测监控 Prometheus 版的实例列表页面。
单击目标 Prometheus 实例名称，进入集成中心页面。
单击 Memcached 卡片的安装。

配置相关参数，并单击确定，完成组件接入。

已接入的组件会显示在集成中心页面的已安装区域。单击该组件卡片，在弹出的面板中可以查看 Targets、指标、大盘、告警、服务发现配置、Exporter 等信息。

如下图所示，您可以看到目前可观测监控 Prometheus 版提供的关键告警指标：

您可以在大盘页签，单击大盘缩略图，查看对应 Grafana 大盘。

您可以面板中单击告警页签，查看 Memcached 的 Prometheus 告警。您还可以根据业务需求新增告警规则。创建 Prometheus 告警规则的具体操作，请参见 Prometheus 告警规则 [ 2] 。

自建 Prometheus 与阿里云可观测监控 Prometheus 版监控 Memcached 优劣对比：

参考链接：

[1] https://memcached.org/about

[2] https://memcached.org/blog/modern-lru/

[3] https://www.scaler.com/topics/aws-memcached/

相关链接：

[1] ARMS 控制台

https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Farms.console.aliyun.com%2F#/home

[2] Prometheus 告警规则

https://help.aliyun.com/zh/arms/prometheus-monitoring/create-alert-rules-for-prometheus-instances#task-2121615