Nginx 監視
設定不要で、Nginxのパフォーマンス、アクティブな接続数、リクエストのスループット、およびアップストリームの状態をリアルタイムで監視できます。
なぜ監視するのか Nginx?
Nginxは世界で最も普及しているリバースプロキシおよびWebサーバーであり、インターネット上で毎日数十億件ものリクエストを処理しています。Nginxの監視は、高速な応答時間の確保、アップストリームの障害の検出、および高可用性の維持において極めて重要です。XitoringのNginx統合機能は、stub_statusモジュールを介して、サーバーの接続状態、リクエストレート、およびパフォーマンス指標に関する詳細な可視性を提供します。
Nginx 監視を、 解説
Nginx 監視は、ドロップされた接続、アップストリーム障害、ワーカープール枯渇を、下流の停止にカスケードする前に検知します。Nginx はユーザーとスタックの他のすべての層との間に位置するため、Nginx を適切に監視することは通常、本番インシデントの大半をエントリ ポイントで検知することを意味します — アプリ サーバーから逆向きにデバッグする代わりに。Xitoring は stub_status（および Nginx Plus API）が公開するすべてのメトリクスを 1 分の可視性で提供し、Slack、PagerDuty、Telegram、その他既存のオンコール ローテーションにアラートを送信します。
私たちが 監視するもの
アクティブ接続
待機中の接続を含む、現在アクティブなクライアント接続数。
受信
サーバー起動以降に受け入れられたクライアント接続の総数。
処理済み
処理された接続の総数。リソース上限に達しない限りacceptsと等しい。
リクエスト
サーバーが処理したクライアントリクエストの総数。
読み取り中
Nginxがリクエストヘッダーを読み取り中の接続数。
書き込み中
Nginxがクライアントに応答を書き込み中の接続数。
待機中
次のリクエストを待機しているkeep-alive接続数。
1秒あたりのリクエスト数
総リクエスト数から計算された受信リクエストレート。
1秒あたりの接続数
サーバーが受け入れる新規接続のレート。
応答時間
クライアントリクエストの処理と応答にかかる平均時間。
オープン ファイル ディスクリプタ
現在開いている fd 数とワーカーごとの上限。上限に近づくと、低い `worker_connections` と同じドロップされた接続の症状を引き起こします。
ワーカー プロセス数
アクティブな Nginx ワーカー プロセス。ワーカーのチャーンや予期しない再起動回数は、リクエスト メトリクスからは見えない OOM イベントやセグフォルトを可視化します。
設定可能 アラートのトリガー
ダッシュボードでカスタムトリガーを設定し、Nginxのメトリクスが定義した閾値を超えた瞬間に通知を受け取れるようにします。
アクティブ接続
警告アクティブ接続数が閾値を超えたときに発動。サーバーの高負荷を示します。
Waiting接続
警告Waiting (keep-alive) 接続が閾値を超えたときに発動。遅いクライアントや上流の遅延を示す可能性。
1秒あたりのリクエスト数
重要なリクエストレートが通常のベースラインを超えたときにアラート。トラフィック急増やDDoSパターンの検出に有用。
Writing接続
警告Writing状態の接続が多すぎるときに発動。応答ボトルネックの可能性を示します。
破棄された接続
重要なacceptsとhandledの差が増加したときに発動。リソース枯渇を示します。
応答時間
重要な平均応答時間が定義した制限を超えたときにアラート。パフォーマンス低下を示します。
の重要性： Nginx監視
Nginxは世界のウェブサーバーの35%以上を支え、現代のマイクロサービスアーキテクチャの基盤となっています。適切な監視がないと、接続飽和、上流障害、パフォーマンス低下が見過ごされる可能性があります。
- ユーザーがタイムアウトを経験する前に接続飽和を検出
- 上流サーバーの障害や遅いバックエンドを特定
- リバースプロキシ構成での連鎖障害を防止
- リアルタイムのパフォーマンス可視化でSLA遵守を維持
- 接続状態分析でロードバランシングを最適化
なぜ選ぶべきか： Xitoring
XitoringはゼロコンフィグでエンタープライズグレードのNginx監視を提供します。軽量エージェントがNginxインスタンスを自動検出し、60秒以内にメトリクス収集を開始、既存の通知チャネルと統合します。
- ワンコマンドインストール — 複雑なYAMLや設定ファイルは不要
- 低遅延チェックのための15以上のグローバル監視ノード
- サーバー、サービス、稼働率を統合したダッシュボード
- Slack、PagerDuty、Telegramなどによる柔軟なアラート
- キャパシティプランニングと監査のための履歴データ保持
よくある Nginx 監視 シナリオ
Nginxが今日一般的に実行されている場所 — そして誰も監視していない場合に何が問題になる可能性があるか。
アプリの前面にあるウェブサーバー
Nginxは通常、訪問者が最初に通信するものであり、その背後にあるアプリが実際の作業が行われる場所です。サイトが遅いと感じるとき、その遅さがNginxにあるのか、それともアプリにあるのかが重要です。私たちはこの2つを分離し、適切なチームが適切な問題を修正できるようにします。
Kubernetesアプリのエントリポイント
Kubernetesでは、Nginxはしばしばアプリ全体への入り口となります。そこでの誤り — 不適切な設定のプッシュ、期限切れの証明書、失敗したロールアウト — は、一時的にすべてをオフラインにする可能性があります。私たちは早期に警告の兆候を捉え、日常的なデプロイが顧客に可視な停止に変わらないようにします。
複数のアプリサーバーへのトラフィック分散
Nginxが多くのサーバーにトラフィックを分散させるとき、1つの苦戦しているサーバーが、一部のユーザーのエクスペリエンスを静かに悪化させる可能性があります。私たちは故障しているサーバーを早期に捕捉し、より多くの訪問者が影響を受ける前にローテーションから削除されるようにします。
Nginx の 前提条件
これらが揃っていることを確認してください — 揃っていれば、ほとんどの導入は 60 秒で完了します。
- http_stub_status_module がコンパイルされた Nginx（
nginx -V 2>&1 | grep stub_statusで確認） - location /nginx-status ブロックが有効で localhost からアクセス可能であること
- Nginx 設定とログへの読み取りアクセス
はじめに 議事録
Xitogent をサーバーにインストール
まだの場合は、軽量な Xitogent 監視エージェントをサーバーにインストールしてください。
curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEYNginx で stub_status を有効化
Nginx 設定に `/nginx-status` location ブロックを追加し、`stub_status;` を有効化、アクセスを localhost に制限します。Nginx を再読み込みし、`curl http://127.0.0.1/nginx-status` で確認してください。
# In your Nginx server block:
location /nginx-status {
stub_status;
access_log off;
server_tokens on;
allow 127.0.0.1;
deny all;
}Nginx 連携を有効化
Xitoring ダッシュボードまたは CLI から Nginx 連携を有効化してください。Xitogent が Nginx インスタンスを自動検出します。
sudo xitogent integrateアラートしきい値を設定（オプション）
アクティブ接続数、リクエストレート、応答時間などのメトリクスにカスタムしきい値を設定し、注意が必要なときに通知を受け取れるようにします。
動作確認
サーバー上でこのコマンドを実行して、Xitogent が連携を認識していることを確認してください。約 30 秒以内に新しいメトリクスがダッシュボードに流れ始めます。
sudo xitogent status代替ツールを 検討中ですか？
Nginx 監視の代替ツールと比べて Xitoring がどう優れているかをご覧ください — 定額料金、より深い統合、そしてスタック全体をカバーする 1 つのエージェント。
