ご挨拶！
この記事では、nginxの新しいモジュールについて説明します。このモジュールの目的は、バックエンドへのサーバーアクセスに関する統計を収集してユーザーに提供することです。 カットの下-詳細、使用例、スクリーンショット、リンク、および作成の履歴。
物語
少し前に、当社のサーバーサポート部門は、何かを変更する時が来たという結論に達しました。 より正確には、増加した負荷の分散に関する問題を解決する必要がありました-私たちの前線は困難に彼らのタスクに対処し始めました。
JMeterの助けを借りて、スタンドでnginx、HAProxy、Brocade Server Iron ADX 1000、および他の多くのバランサーを運転しました。 主な選択基準は、ピーク時に約5万の同時SSLセッションを終了する能力でした。 長期間のテストの後、さまざまな理由で、nginxと鉄の競合他社であるBrocade Serverを除くすべてのオプションがなくなり、最終的には最初のオプションのみが残りました。 他の条件が同じで、おそらくnginxを支持する決定的な要因は、その構成の柔軟性と軽さでした。
問題
以前は、一部の面でHAProxyをバランサーとして使用していました。 nginxに切り替えた後、バックエンドでの作業に関する有益な統計情報がないことが明らかになりました。 実際、同じHAProxyにはそのような統計があり、その助けを借りて、バックエンドで発生する問題を追跡し、それらに迅速に対応しました。 新しいバランサーでは、これらの統計なしで、手なしで終わった。 stub_statusおよび同様のモジュールは、私たちに適していない、なぜなら それらの機能は、個別のアップストリームのコンテキストではなく、サーバー全体の統計を表示することです。 アップストリーム/バックエンドごとに、各バックエンドへ
の呼び出し数
やHTTPエラー499/500/503およびTCPの
数などのパラメーターに関するデータが必要であり、後でこのリストが拡張されました。
解決策
問題に対する既成の解決策が見つからなかったため、必要な情報を視覚的な形式で提供するモジュールを作成しようとしました。 この試みは成功したようで、作業の結果は
ustats （
アップストリーム統計 ）モジュールでした。
統計とは何ですか？
ustatsを使用すると、次のようなバックエンドメトリックに関する統計を保持できます。
- リクエストの数 。
- エラーの数は499/500/503です。
- HTTP読み取りおよび書き込みタイムアウトの数 。
- TCP接続エラーの数 。
- 失敗タイマー（fail_timeout） nginxでは、このパラメーターは同じ名前のディレクティブによって構成され、バックエンドへの呼び出しが連続して失敗する期間を決定します（正確な数はmax_failsディレクティブによって指定されます）。その後、バックエンドはブラックリストに登録され、呼び出しは行われません時間fail_timeout。 通常、管理者自身が自分のサーバー構成にタイムアウトが書き込まれていることを知っていますが、それでも私たちの目の前でタイムアウトにすることをお勧めします。
- バックエンドの操作に失敗した回数（失敗回数） 。 nginx内では、各バックエンドについて、失敗した試行のカウンターが保持されます。 この数値は、失敗タイムアウトの間にnginxがバックエンドをノックしようとして失敗した回数を示します（失敗と見なすもの、proxy_passディレクティブの説明を参照）。 カウンターの動作原理は非常に簡単です。 nginxがリクエストをリダイレクトしようとすると、最初にどのバックエンドが次に並んでいるかを調べ（ラウンドロビンのバランスについて話している場合）、そのステータスをチェックし（ブラックリストに登録されているかどうか） 。 それ以降、fail_timeout時間がすでに経過している場合、バックエンドの失敗した試行のカウンターがリセットされ、リクエストが送信されます。 バックエンドがブラックリストに含まれていなかった場合、リクエストはすぐに送信され、最初の失敗した呼び出しから経過した時間に応じてカウンターがリセットされる場合があります。
- 失敗した呼び出しの最大数（max_fails） 。 バックエンドが一定の期間ブラックリストに登録されると、バックエンドでの動作の失敗回数のしきい値を定義します。 このパラメーターはnginx構成でも指定され、わかりやすくするために統計に表示を追加しました。
- バックエンドへの最後の失敗した呼び出しの時間 。 その目的は、前の段落から明らかになるはずです:)
追加機能
また、ustatsは、ブラックリストに現在含まれているバックエンドを表示できます。 バックエンドは、serverディレクティブによってnginx configで指定されたものとしてではなく、ディレクティブで指定された名前が解決されるアドレスとして直接理解されることに注意してください。 DNSで1つの名前の下に複数のアドレスがリストされている場合、モジュールはそれらのアドレスを別々のバックエンドとして表示します（それらがどの名前から来たかを忘れずに）。
ブラックリストからバックエンドを強調表示することに加えて、ustatsはサーバー、つまり nginx configで
...
サーバーsome.server.name down;
...
そして最後に、モジュールを使用して、Webインターフェースを介して、操作中にnginxトポロジーからサーバーを直接オンおよびオフにできます。 変更は構成に保存されず、それらの実装を容易にするように設計されています。 バックエンドの一時的な切断を伴う作業。 警告したい：ustatsはこのアクションの不正実行に対する保護を提供しないため、ランダムな人があなたのサイトのバックエンドの半分を仕事から除外しないようにする必要があります:)
ユースケース
それらの2つがあります。 最初に、モジュールはすべての統計情報を表付きのWebページの形式で提供します。表はstub_statusなどの任意の場所に表示できます。
場所/ ustats {
ustats on;
...
}
ページは自動的に更新され、更新間隔（ミリ秒単位）は構成で構成できます。
...
ustats_refresh_interval 7000
...
2番目のシナリオでは、モジュールを他の監視ユーティリティのデータソースとして使用します。 この場合、それに対応する要求が行われ、それに応じて、必要な情報を含む通常のxmlが返されます。 1つのアップストリームまたは1つのバックエンドのデータを要求できます。 たとえば、リクエスト
/ ustats？u =オフライン
アップストリームのすべてのバックエンドのデータを
オフラインで返し、リクエストに応じて
/ ustats？u =ブレーク＆b = the_mold
アップストリーム
ブレークの the_mold
バックエンドのデータが返されます。 アップストリームまたはバックエンドが見つからない場合、応答xmlはこれを示します。
いくつかの写真
根拠にならないように、モジュールの結果ページのスクリーンショットをいくつか提供します。 最初のスナップショットからのnginxでは、2つのアップストリームが構成され、すべてのサーバーはローカルで、wwwサーバーを除き、同じnginxで発生します。Yandexアドレスに解決されます。
写真では、灰色の線を見ることができます-これらは、nginx構成で「ダウン」とマークされているか、モジュールページでオフになっているバックエンドです。 これまでのところ、数字はありません。
2番目のスクリーンショットでは、最初のアップストリームからの3つのバックエンドが赤い線で強調表示されており、ブラックリストに含まれていたため、リクエストが送信されませんでした。
さらに3つのバックエンドがオフになったという事実と併せて、残りの1つだけが負荷をかけました。
最後に、最後のショットは、私たちのサイトから作業中のフロントエンドで撮影されました。
写真は、私がまだ言及していない別の機能を示しています。 下部からの上流はわずかに明るくなっています-これは、設定で暗黙的に定義されていることを示しています。 そうではない
アップストリームgive_me_a_name {
...
}
など
場所/ whereami {
...
proxy_pass http://192.168.0.75:8080
...
}
まとめ
Google Codeページにモジュールのソースコードを
投稿しました 。 リポジトリには、ソース+構成ファイルを含むnginxのパッチファイルが含まれています。 モジュールのページにはインストール手順があり、追加の構成ディレクティブも記載されています。 モジュールの現在のバージョンは、Chrome、Firefox、Operaでnginxバージョン0.8.53でテストされています。 最後に、ustatsは、バックエンドでの作業に関するデータを表示するための最も基本的なメカニズムをnginxに追加するための試みにすぎないことを言わなければなりません。 将来的には、メインサーバーブランチで、たとえばヘルスチェックバックエンドの前など、このような役に立たないモジュールを期待しています。