当初の問題
昨年、あるサーバー上の不正なソフトウェアが中央の Graylog サーバーに大量のメッセージを送信し、他のアプリケーションに問題を引き起こすという問題が発生しました。
主な問題は、他のアプリケーションからの古い有用なメッセージが通常よりも早く削除され、インデックスが不正なアプリケーションからの役に立たないメッセージでいっぱいになることでした。
私が提案した修正方法は、各アプリケーションに独自のインデックスを与えて、どのアプリケーションも他のアプリケーションのログ ストレージ スペースを枯渇させないようにすることでした。これにより、アプリケーション自体に変更を加える必要はなく、Graylog 内の変更のみが必要になります。ただし、新しい Kubernetes ベースの Graylog ソリューションが計画されていたため、何も実行されませんでした。
私たちに提案された解決策
話を現在に進めると、現在、私たちは Graylog システムの代替システムの運用を開始しているところです。
当初、すべてのアプリケーションには独自の独立した graylog サーバー (ロード バランサー、gelf エンドポイント、graylog ノード、エラスティック検索クラスター) と graylog フロントエンド Web サイトがあると説明されました。
問題は、異なるアプリケーション間に複雑な関係があり、異なるアプリケーションのログを取得するために異なる graylog Web サーバーにアクセスする必要があり (単に graylog.site にアクセスするのではなく、application1 のログを取得するには graylog-application1.site、application2 のログを取得するには graylog-application2.site)、アプリケーション間の検索が非常に困難になることです。
修正された解決策
このことが指摘された後、アプリケーションを一緒に検索する必要がある可能性に応じてグループ化するソリューションが提案されました。そのため、現在はグループごとに個別の Graylog サーバー (アプリケーション 1 と 3 には application-group-a.site、アプリケーション 2、4、5 には application-group-b.site など) が提供される予定です。
しかし、これが本当に必要なのか、十分なのか疑問です。
これにより、多くのアプリケーション間検索は簡単に実行できるようになりますが、解決が最も難しいサポート問題の一部は、あまり明確ではないアプリケーションの境界を越える問題であり、これらの検索はそれほど簡単ではなくなってしまいます (どのアプリケーションが関係しているかがわからない場合は、実際には不可能になる可能性もあります)。
単一の中央グレーログ サーバーに個別のインデックスを配置するだけでは、アプリケーション グループ間の分離が不十分であると主張する人もいます。1 つのアプリケーションからのメッセージの入力が他のアプリケーションからのメッセージの入力に干渉しないようにする必要があるため、グループ間の完全な分離が必要です。
これに関して私が問題視しているのは、グループ内のアプリケーションが不正行為を起こしてグループの Graylog サーバーにスパム攻撃を仕掛けるのを防ぐことはできないということです。グループ内でサービス拒否攻撃を防ぐソリューションが見つかれば、単一の集中型 Graylog サービスに対するソリューションも見つかるでしょう。
数十台のグレーログ サーバーを持つよりも、負荷分散されたグレーログ ノード、エラスティック検索ノード、GELF エンドポイントなどをさらに追加して、単一の中央サービスを水平方向に拡張する方が優れたソリューションになると思います。
質問
すべてが同じ Kubernetes クラスターでホストされている場合、個別の graylog サーバーは実際に、人々が望んでいるレベルの分離 (サービス拒否の緩和) を提供するのでしょうか?
個別のグループ Graylog サーバーを使用する場合と同等またはそれ以上のレベルの分離を、単一の中央 Graylog サーバーで提供できますか?
他の組織では、多数のフロントエンド Web サイトを使用して Graylog をこのように使用していますか? それとも、すべてのログにアクセスするための単一の中央 Web サイトが期待されていますか?
本質的には、私は何も心配していないこと、そしてこの解決策は一般的であることを自分自身に納得させること、または私たちが検討していることはベストプラクティスに反しており、実際にはこれを行うべきではないことを人々に納得させるための議論を求めています。
誰にとっても有効な解決策を見つけたいと本当に思っていますが、現時点で提案されている解決策では、むしろ大切なものを無駄にしているように私には思えます。
答え1
Graylog セットアップのアーキテクチャに関する懸念や疑問は、もっともなものです。分離とリソース管理の必要性と、使いやすさや管理のしやすさのバランスが取れたソリューションを見つけることが重要です。Kris Kross のように分析してみましょう。
1. すべてが同じ Kubernetes クラスターでホストされている場合、個別の Graylog サーバーは実際に、人々が望んでいるレベルの分離 (サービス拒否の緩和) を提供しますか?
同じ Kubernetes クラスターで実行される個別の Graylog サーバーは、ある程度の分離を提供できますが、ネットワーク帯域幅、ストレージ、場合によっては CPU とメモリなど、クラスター レベルでリソースを共有していることを理解することが重要です。グループ内の 1 つのアプリケーションが不正行為を起こしてメッセージをスパムし始めると、リソースの競合により、同じクラスター上の他の Graylog サーバーのパフォーマンスに影響を及ぼす可能性があります。Kubernetes はリソース管理機能を提供しますが、リソース関連の問題を防ぐための万能薬ではありません。
2. 個別のグループ Graylog サーバーを使用する場合と同等またはそれ以上のレベルの分離を、単一の中央 Graylog サーバーで提供できますか?
単一の中央 Graylog サーバーは、個別のインデックスを使用してアプリケーション間の分離を提供できますが、おっしゃるとおり、不正なアプリケーションがサーバーを過負荷にし、他のアプリケーションに問題を引き起こすのを防ぐことはできない可能性があります。これを軽減するには、ログ メッセージを生成する入力またはソースに対して、より厳格なレート制限およびスロットリング ポリシーを実装することを検討してください。さらに、中央 Graylog サーバーを水平方向に拡張して、増加する負荷を処理することもできます。これは、複数の個別のサーバーを管理するよりもコスト効率が高くなります。
3. 他の組織では、多数のフロントエンド Web サイトを使用して Graylog をこのように使用していますか? それとも、すべてのログにアクセスするための単一の中央 Web サイトが期待されていますか?
異なる Graylog インスタンス用に複数のフロントエンド Web サイトを用意するか、単一の中央 Web サイトを用意するかの選択は、組織の特定のニーズと好みによって異なります。どちらのアプローチも有効であり、それぞれに利点とトレードオフがあります。
複数のフロントエンド Web サイト: このアプローチは、異なるチームまたはアプリケーションで、分離、制御、および組織化を向上させるために個別の Graylog インスタンスが必要な場合に適しています。アクセス制御を簡素化し、さまざまなチームに自律性を提供できます。ただし、アプリケーション間の検索では、ユーザーがさまざまなインターフェイスを切り替える必要がある場合があります。
単一の中央 Web サイト: すべてのログにアクセスするための単一の中央 Web サイトでは、ログ インフラストラクチャ全体の統一されたビューが提供され、アプリケーション間の検索が容易になります。このアプローチにより、ユーザー アクセスが簡素化されますが、異なるチームやアプリケーション間でデータを分離するには、より堅牢なアクセス制御と権限管理が必要になる場合があります。
最終的に、これらのアプローチの選択は、分離、使いやすさ、リソース管理、アプリケーションとチームの特定の要件に関する組織の優先順位によって決まります。
誰にとっても有効なバランスの取れた解決策を見つけるには、次の点を考慮してください。
- 不正なアプリケーションがシステムに過負荷をかけるのを防ぐために、各 Graylog インスタンス内に厳格なレート制限およびスロットリング ポリシーを実装します。
- すべての Graylog インスタンスのリソース使用状況とパフォーマンスを監視してアラートを出し、問題を積極的に検出して対処します。
- ログの管理と使用に関するベスト プラクティスを文書化し、すべてのチームに伝えます。
- 適切なリソーススケーリングとアクセス制御メカニズムを備えた集中型 Graylog ソリューションの可能性を継続的に探求します。
全体的に、最善のアプローチは組み合わせである可能性があります。ログ管理インフラストラクチャの全体的な安定性を確保するために、堅牢なリソース管理と監視プラクティスを実装しながら、アプリケーションの論理グループごとに個別の Graylog インスタンスを使用することになるかもしれません。また、選択したソリューションがニーズと期待に一致するように、さまざまなチームの関係者を意思決定プロセスに参加させることも重要です。これは、厄介な問題を回避するための単なる提案です。
答え2
Graylog（および類似製品）が提供する大きな利点は、ログを単独で保存することではなく、さまざまなログ ソースと記録されたイベント間の相関関係。それぞれ異なるソースを収集する複数の個別の Graylog サーバーを使用すると、複数ソースの相関関係の確立が非常に難しくなります。
単一のGraylogサーバー（または、単一ノードでは不十分な場合は、クラスター化されたマルチノード設定）と、異なる（適切な）ローテーションポリシーを持つ複数の特定のインデックスを使用することをお勧めします。これらのインデックスへのトラフィックは、適切なストリームルール（そして「デフォルト ストリームから一致を削除」を選択します）。