Varnish 監視
設定不要で、Varnishキャッシュのヒット率、バックエンドの稼働状況、オブジェクトストレージ、およびリクエストのスループットをリアルタイムで監視できます。
なぜ監視するのか Varnish?
Varnish Cacheは、Webアプリケーションの処理速度を劇的に向上させる強力なHTTPアクセラレータです。Varnishを監視することは、高いキャッシュヒット率を確保し、バックエンドの障害を検知し、オブジェクトのエヴィクションを追跡し、コンテンツ配信のパフォーマンスを最適な状態に維持するために不可欠です。
Varnish 監視を、 解説
Varnish 監視は、キャッシュヒット率の低下、バックエンドのヘルス障害、スレッドプールの枯渇を、ユーザーが感じるレイテンシや障害になる前に捉えます。Varnish は通常 WordPress、Magento、またはオリジン層の前に位置するため、Varnish の問題は通常サイト全体の問題になります — Varnish をうまく監視することは、ほとんどのキャッシュ層インシデントを最初の 1 分で捉えることを意味します。Xitoring は Varnish を自動検出し、varnishstat から読み取り、Slack、PagerDuty、Telegram、または既存のオンコールにアラートをルーティングします。
私たちが 監視するもの
キャッシュヒット率
キャッシュから提供されたリクエストの割合。
バックエンドの健全性
オリジンサーバーのヘルスステータス。
オブジェクトエビクション
キャッシュから退避されたオブジェクトのレート。
リクエスト/秒
総リクエストスループット。
スレッドプール使用状況
アクティブスレッドと利用可能スレッド。
バックエンド接続
オリジンサーバーへの接続。
キャッシュサイズ
現在のキャッシュオブジェクトストレージ使用量。
バンリスト長
アクティブなキャッシュバン数。
MAIN.n_object
現在キャッシュ内にあるオブジェクト。オブジェクトオーバーヘッドに関するキャッシュチューニングの洞察のために、`n_objectcore` / `n_objecthead` と比較して追跡します。
SMA.s0.g_bytes / g_space
デフォルトのストレージバックエンドで使用中対利用可能なストレージ。`g_bytes / (g_bytes + g_space)` が 100% に近づくと、Varnish はエビクションを開始します。
MAIN.s_pipe / s_pass
パイプされた（TCP トンネル）リクエストと、パスされた（オリジン直行、キャッシュなし）リクエスト。高い `s_pass` レートは、しばしば VCL の `return(hash)` であるべき `return(pass)` ルールを浮き彫りにします。
Ban List Length
まだエビクションされていないアクティブな VCL バン。バンリストの増加はキャッシュルックアップを遅くします — ban-lurker スレッドがバンされたオブジェクトをエビクションするにつれて、ゼロに近づくはずです。
設定可能 アラートのトリガー
ダッシュボードでカスタムトリガーを設定し、Varnishのメトリクスが定義した閾値を超えた瞬間に通知を受け取れるようにします。
キャッシュヒット率
警告ヒット率が閾値を下回ったときに発動。
バックエンドダウン
重要なバックエンドサーバーがヘルスチェックに失敗したときにアラート。
オブジェクトエビクション
警告キャッシュ圧迫を示す高エビクションレートで発動。
スレッドプール
重要なスレッドプールが枯渇したときに発動。
リクエストレート
警告通常と異なるリクエストスループットでアラート。
の重要性： Varnish監視
Varnish Cacheはオリジンサーバーより300倍速くコンテンツを配信できます。監視がないと、キャッシュミスやバックエンド障害がこのメリットを帳消しにします。
- 最適な速度のためにキャッシュヒット率を高く維持
- バックエンド障害を即座に検出
- キャッシュストレージを正しくサイジングするためにエビクションを追跡
- リクエスト損失を防ぐためにスレッドプールを監視
なぜ選ぶべきか： Xitoring
ゼロコンフィグセットアップでエンタープライズグレードのVarnish監視。
- ワンコマンドインストール
- 15以上のグローバル監視ノード
- 統合ダッシュボード
- マルチチャネルアラート
- 履歴データ保持
Varnish 監視の一般的な シナリオ
Varnishが今日一般的に実行されている場所 — そして誰も監視していない場合に何が問題になる可能性があるか。
WordPressとコンテンツサイトの高速化
Varnishは、完了したページを記憶することで、コンテンツサイトをほぼ瞬時に読み込みます。その効果が機能しなくなると、サイトは静かに遅くなり、検索ランキングが下がり始めます。私たちはその低下が発生した瞬間にそれを検知し、トラフィックとSEOが静かに損なわれないようにします。
チェックアウト時のオンラインストア
オンラインストアは、トラフィックが急増しても、顧客が購入するまさにその瞬間に高速性を維持する必要があります。ストアが急なアクセス増加に対応できるかを示すシグナルを監視し、プロモーションやセールが収益損失につながらないようにします。
APIとマイクロサービス向けキャッシング
Varnishが内部APIの結果をキャッシュすると、基盤となるアプリが繰り返しのリクエストで過負荷になるのを防ぎます。バースト負荷でVarnishが苦戦し始める瞬間を監視し、その背後にあるアプリが障害を起こし始める前にキャパシティを増強できるようにします。
Varnish の 前提条件
これらが揃っていることを確認してください — 揃っていれば、ほとんどの導入は 60 秒で完了します。
- Varnish Cache 6.x 以上
- varnishstat バイナリがシステム PATH 上で利用可能であること
- Varnish 共有メモリログ（/var/lib/varnish — root にはデフォルトで許可）への読み取りアクセス
はじめに 議事録
Varnish ホストに Xitogent をインストール
Varnish Cache が稼働しているホストに軽量な Xitogent 監視エージェントをインストールします。Xitogent は root で動作するため、追加のグループメンバーシップなしで Varnish の共有メモリを直接読み取れます。
curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEYvarnishstat が利用可能であることを確認
`varnishstat` バイナリが PATH 上にありカウンターを返すことを確認してください。ホスト上で `varnishstat -1` を実行すると、キャッシュ、バックエンド、セッションのメトリクスのスナップショットが表示されます。
varnishstat -1Varnish 連携を有効化
`sudo xitogent integrate` を実行して Varnish を選択します。Xitogent が接続をテストし、Varnish インスタンスと設定済みのバックエンドを自動検出します — 残りは自動的にセットアップされます。
sudo xitogent integrateアラートしきい値を設定（オプション）
キャッシュヒット率、Backend Down イベント、オブジェクトエビクションにカスタムしきい値を設定し、ユーザーがキャッシュ未使用の応答を見る前にキャッシュ劣化や容量問題を検知できるようにします。
動作確認
サーバー上でこのコマンドを実行して、Xitogent が連携を認識していることを確認してください。約 30 秒以内に新しいメトリクスがダッシュボードに流れ始めます。
sudo xitogent status代替ツールを 検討中ですか？
Varnish 監視の代替ツールと比べて Xitoring がどう優れているかをご覧ください — 定額料金、より深い統合、そしてスタック全体をカバーする 1 つのエージェント。
