クラウドネイティブ革命によってもたらされたログ管理の課題にどう対処すればよいでしょうか?

以前は、ログ管理は比較的単純でした。ログの数、種類、構造はシンプルで管理しやすいです。

しかし、ここ数年で、こうしたシンプルさはすべて失われてしまいました。クラウドネイティブ テクノロジー (疎結合サービス、マイクロサービス アーキテクチャ、コンテナーや Kubernetes などのテクノロジーなど) への移行により、従来のログ管理戦略ではもはや十分ではありません。クラウドネイティブの世界でログをうまく管理するには、ログの集約、分析などの方法を根本的に変更する必要があります。

ここでは、クラウド ネイティブ革命によってログ管理の性質がどのように変化したか、また IT チームと DevOps チームがログを効果的に管理し続けるために何ができるかについて説明します。

[[330310]]

クラウドネイティブログの特徴

一見すると、クラウドネイティブ環境でのログ管理は、通常のログ記録と変わらないように見えるかもしれません。クラウド ネイティブ インフラストラクチャとアプリケーションは引き続きログを生成し、ログ管理プロセスの基本的な手順 (収集、集約、分析、ローテーション) も引き続き適用されます。

ただし、クラウド ネイティブ環境を監視し始めると、ログを効果的に管理することがはるかに困難であることがすぐにわかります。理由は4つあります。

1. ログの追加

まず、最も単純なのは、処理するログが増えることです。

クラウド ネイティブ時代以前は、ほとんどのアプリケーションは単一のサーバー上で実行されるモノリシック コンポーネントでした。通常、各アプリケーションは 1 つのログのみを生成します (独自のログを作成する場合。アプリケーションが Syslog にデータを記録する場合もあります)。各サーバーは通常、主に Syslog と auth の少量のログのみを生成します。したがって、環境全体のログを管理するには、いくつかのログだけを処理する必要があります。

対照的に、クラウド ネイティブ環境では、通常、マイクロサービス アーキテクチャを使用します。12 個以上の異なるサービスが実行され、それぞれがアプリケーション全体を構成するために必要なさまざまな機能を提供します。各マイクロサービスは独自のログを生成できます。

それだけでなく、インフラストラクチャ層もさらに存在します。そして、その結果、ログもさらに増えます。基盤となるホスト サーバーとそれが生成するログだけでなく、アプリケーションとインフラストラクチャ (使用方法に応じて Docker や Kubernetes など、またはその両方) の間にある抽象化レイヤーによって作成されるログもあります。

つまり、クラウド ネイティブへの移行は、IT チームがサポートされるアプリケーションごとに少数のログをめぐって競争する状態から、12 個以上のログをめぐって競争する状態に移行したことを意味します。

2. ログの種類が増える

ログの総数が増えただけでなく、ログの種類も増えました。サーバー ログやアプリケーション ログだけでなく、クラウド インフラストラクチャのログ、Kubernetes または Docker のログ、認証ログ、Windows と Linux のログ (最近では同じ職場で両方の種類のオペレーティング システムを使用するのが一般的になっているため) なども存在します。

この多様性により、管理するログ データの種類が増えるだけでなく、ログの種類が異なる形式になることが多いため、複雑さが増します。その結果、正規表現マッチングやその他の種類の汎用クエリを使用してすべてのログを一度に解析することが難しくなります。

3. 多様な記録アーキテクチャ

ログの数と種類が増加するにつれて、アプリケーション環境でログ データが公開される方法はより複雑かつ多様化しています。

Kubernetes は良い例です。 Kubernetes には、ノード レベルでログを収集するための組み込み機能がいくつか用意されています。収集が行われる正確な方法は環境変数によって異なります。たとえば、systemd がインストールされているシステムにログオンしますが、/var/log 内の .log ファイルに直接書き込みます。

さらに複雑なことに、Kubernetes にはクラスター レベルのログ記録に対するネイティブ サポートがありませんが、それを実行する方法はあります。各 Kubernetes ノードで実行されるログ エージェントを使用してクラスターのログ データを生成したり、サイドカー コンテナーでログ エージェントを実行したりできます。あるいは、クラスターのアーキテクチャとアプリケーションによってこれが実行可能であれば、アプリケーションから直接クラスター全体のログ データを生成してみることもできます。

さらに、同じプラットフォーム内でも、ログ記録アーキテクチャの設定方法にはさまざまなバリエーションがあります。その結果、サポートが必要なすべてのアプリケーションやプラットフォームで一貫して機能する、クラウドネイティブ環境での統合ログ管理プロセスを設計することがますます困難になります。

4. 非永続的なログ保存

クラウド ネイティブ ロギングの最後の課題は、一部のクラウド ネイティブ アプリケーションに永続的なデータ ストレージがないことです。コンテナが最も良い例です。

コンテナ インスタンスの実行が停止すると、コンテナに保存されているすべてのデータが完全に破棄されます。したがって、ログ データがコンテナー内に保存されている場合 (通常はデフォルトで保存されます)、コンテナーとともに消えてしまいます。コンテナは一時的なものであるため、インスタンスは一時停止および削除され、新しいインスタンスが自動的に起動されます。そのため、コンテナがシャットダウンされる前に管理者はログ データを保存するかどうかを尋ねられません。事前にデータを別の場所に移動していない限り、ログ データとともに閉じられ、削除されます。

ログ データをリアルタイムで処理することだけが重要な場合は、この一時的な性質は問題ないかもしれません。ただし、履歴ログを一定期間利用できるようにしておく必要がある場合、コンテナの実行が停止したときにログ データが失われることは許容されません。

クラウドネイティブログ管理のベストプラクティス

クラウド ネイティブ環境におけるこれらの課題に対処するために、チームは次のガイドラインを使用できます。

1. 統合ログ収集と集約

サポートして記憶する必要があるログ形式とスキーマの種類が非常に多いため、各システムのログを個別に管理することは現実的ではありません。代わりに、環境のあらゆる部分からデータを自動的に収集し、 1 つの場所に集約する、統合された集中ログ管理ソリューションを実装します。

2. 柔軟なログ管理ソリューションを採用する

ログ管理ツールとプロセスは、環境を再構成することなく、あらゆるタイプの環境をサポートできる必要があります。たとえば、ある方法でログデータを公開する Kubernetes クラスターと、別の方法でログを記録する別のクラスターがある場合、どちらのクラスターの動作も変更せずに、両方のクラスターからログを収集して分析できる必要があります。ログ。同様に、あるアプリケーションを 1 つのパブリック クラウドで実行し、別のアプリケーションを別のクラウドで実行している場合、ログを一元的に管理するために、どちらのクラウド環境のデフォルトのログ記録動作も変更する必要はありません。

3. ログをリアルタイムで収集する

永続的なストレージのない環境でログが消失しないようにする 1 つの方法は、ログ データをリアルタイムで収集し、別の場所に集約することです。この方法では、ログ データは生成されるとすぐに永続ログ マネージャーに保存され、コンテナーがシャットダウンされても引き続き利用可能になります。このアプローチは、一定期間のみコンテナ内からログ データを収集しようとするよりも適しています。一定期間のみコンテナ内からログ データを収集しようとすると、コンテナが予想よりも早くシャットダウンした場合に一部のログが失われる可能性があります。

4. カスタムログパーサーを使用する

通常の分析ツールではサポートできない方法で構造化されたログを無視するだけでなく、カスタム ログ パーサーを活用して任意の形式のデータを処理することもできます。こうすることで、非標準のログから重要な洞察を見逃すリスクがなくなります。

結論は

クラウドネイティブのログ管理は、通常のモノリシック アプリケーションのログ データの管理とは根本的に異なります。ログ データのサイズは増加しているだけでなく (増加していますが)、ログ データの記録、構造化、公開の方法も多様化しています。これらの課題に直面して、ログを効果的に管理するには、サポートするすべてのシステムからのログ データを完全に一元化および統合するとともに、非標準のログ タイプから洞察を得る機能も提供するログ管理ソリューションが必要です。