比較的大規模な生産では、遅かれ早かれ、ログの集中収集と表示の問題が生じます。 現在、オープンソース、有料、オンライン、およびオンプレミスのソリューションの膨大な選択があります。 特定のケースでの選択プロセスの概要を説明します。
このレビュー記事では、Graylog2の主な機能について説明し、その理由と、それを選択した理由と操作方法について説明します。
インフラストラクチャについて少し（ ここでもう少し読むことができます ）：世界中に7つのデータセンター、約500の運用サーバー、ログを収集する数百の異なる種類のアプリケーションを使用しています。 これらはすべてLinuxとWindowsの両方で実行されており、異種サービスがトップで回転しています。 すべてのサービスには独自のログ形式がありますが、独特なStackTraceを持つJavaもあります。
要件と結果として得たいもの
プログラマーと関心のあるすべての人にとって、ログの要件は簡単でした。
- ログ送信エージェントはシステムに大きな負荷をかけるべきではありません。
- 任意のサーバー上で、いつでもカスタムフィールドを追加する機能。
- 検索、並べ替えなど。
- 要求などのPOSTログを送信する機能（モバイルデバイスなどからログを送信するため）。
ここでは複雑なことは何もありません。すべてが普通です。 しかし、この場合、サービスを提供するために次の要件を満たす必要がありました。
- openLDAPでの認証（この場合、 FreeIPAです ）;
- 権利の便利な描写;
- クライアントの便利な構成（できれば1つの場所から）。
- 使用されているすべてのシステムオプションにエージェントを自動的にインストールする機能。
- サービスの保守性と必要なメトリックの両方を便利に監視する機能。
- コミュニティとドキュメントの存在、または商用サポート。
- シンプルなスケーリング。
この要件のセットは非常に重要であったため、新しいサービスが既存のインフラストラクチャに完全に適合し、自動化、権利の分配の特性を考慮し、時間がかかりすぎる黒人の羊ではありません。 このサービスは、エンドユーザーにとって便利であり、要件を満たす必要があります。
この段階では、いくつかの商用ソリューションとオープンソースのGraylog2しか持っていないことに気付きました。
ログとロードの数を数える方法
要するに、方法はありません。 したがって、ここでは、この問題で私たちを助けた主なアプローチとニュアンスを指摘します。
最初は、フォーカスサーバーグループのログの数を取得して調べ、2週間にわたる変更のダイナミクスを測定しました。 結果の数にサーバーの数を掛けました。 その結果、ログの平均数は1日あたり約1TBでした。 これらのログは、2週間から3か月間保存する必要がありました。
この段階では、商用ソリューションと独自のインフラストラクチャを計算するときに、Graylog2を使用することが決定されました。 実際の負荷を計算する最良の方法は、prodトラフィックの一部をテストサーバーに取得することであると判断したため、1つのGraylog2ノードを展開し、そこに特定のフォーカスグループからトラフィックを送信しました。
約1週間で、1秒あたり1万から2万メッセージの負荷が発生し、一般的に、戦闘クラスターを展開する際にこれらの数値を使用する準備ができていました。 しかし、ある時点でサーバーで何かが壊れ、ログの数がほぼ10倍に増加し、1つのサーバーで1秒あたり最大10万件のメッセージが急増しました。 同時に、JavaアプリケーションのStackTraceの一部が、許可されたログサイズに収まりませんでした。 この時点で、ログはこのような重大な状況での便利な作業のためにのみ必要であり、以前の計算はすべて通常の状態でのみ実行されることに気付きました。
主な調査結果：
- 通常の状態でのログカウントでは、事故の場合に何が起こっているかを把握できません。 これらの状況の運用ソリューションには、ログのコレクションが正確に必要です。
- さまざまなサービスと言語が独自の方法でメッセージを作成し、そのような状況を事前に考慮する必要があります。
- クラスターのパフォーマンスでは、通常の負荷からのメッセージを数倍処理できるはずです。
Graylog2の機能の簡単な説明
選択した主な理由：
- 実績のある製品。 優れたドキュメントと主要な問題のカバレッジ。
- コレクターを介してWebインターフェースを介してエージェントを構成する機能。
- グループ同期を含む、OpenLDAPとのシンプルで機能的な統合。
- 便利な水平スケーリング。
- ログを取得するための入力のさまざまなバリエーションの膨大な選択。
- プラグインと拡張機能の存在。
- かなりシンプルで便利なクエリおよびサンプリング言語。
- ダッシュボードの存在と通知の可能性。
この機能は、ほとんどすべてのニーズを満たし、寿命を大幅に短縮しました。 疑わしい未来のテストサービスからわずか数か月で、それはかなり重要なビジネスクリティカルなユニットに変わり、6か月間、タスクで非常にうまく機能しました。
もちろん、このようなソリューションの導入は、最も透過的なプロセスではありません。 初期設定時とその後の運用中の両方で、かなりの数のニュアンスと落とし穴に直面しました。 次の記事では、Graylog2とそのコンポーネント（MongoDBやElasticsearchなど）をどのように調整および調整したかを正確に説明します。