ログから最大値を抽出する方法

ロギングはおそらく、可観測性ソリューションの最も重要な要素です。ログは、システムの動作に関する基本的で豊富な情報を提供します。理想的な世界では、ロギングに関するすべての決定をユーザーが行い、システム全体に一貫したアプローチを実装することになります。

ただし、現実の世界では、レガシー ソフトウェアを使用したり、ロギング用に独自の形式と構造を持つさまざまなプログラミング言語、フレームワーク、オープンソース パッケージを使用したりすることがあります。

システム全体のログ形式がこれほど多様である場合、すべてのログから最大限の価値を引き出すにはどのような手順を実行できるでしょうか?この投稿ではそれについて説明します。

ログの設計方法、大規模システムでのログ記録の課題と解決策、ログベースのメトリクスと長期保存についてどのように考えるかについて見ていきます。

ログのレベルと形式を見てみましょう。

ロギング設計

ログの設計には多くの考慮事項が考慮されますが、最も重要な 2 つの側面は、ログ レベルの使用と、構造化ログ形式と非構造化ログ形式のどちらを使用するかです。

ログレベル

ログ レベルは、重大度に基づいてログ メッセージを分類するために使用されます。使用される特定のログ レベルは、ログ フレームワークまたはシステムによって異なる場合があります。ただし、一般的に使用されるログ レベルは次のとおりです (詳細度の高い順に)。

• TRACE : 包括的な記録を再構築し、状態変化を考慮するために、システムが実行するすべてのアクションをキャプチャします。

• DEBUG : デバッグ目的で詳細情報を取得します。これらのメッセージは通常、開発中にのみ関連するため、運用環境では有効にすべきではありません。

• INFO : システムの実行における重要なイベントやマイルストーンを伝えるために、システムの動作に関する一般的な情報を提供します。

• 警告: 注意が必要な可能性のある潜在的な問題または状況を示します。これらのメッセージは重要ではありませんが、必要に応じてメモし、調査する必要があります。

• ERROR : システムの実行中に発生したエラーを示します。これらのメッセージは通常、対処する必要があり、システムの機能に影響を与える可能性がある問題を強調します。

適切なレベルでログを記録すると、システムの動作の理解、問題の特定、問題のトラブルシューティングを効果的に行うのに役立ちます。

構築するシステム コンポーネントに関しては、有用なログ レベルのセットの定義に時間を割くことをお勧めします。各ログ レベルでメッセージにどのような種類の情報を含めるべきかを理解し、一貫したログ レベルを使用してください。

後で、ログ レベルを制御できないサードパーティ アプリケーションに対処する方法について説明します。また、ユーザーが管理しているものの、拡張性が高すぎて標準のログ レベルに移行できないレガシー アプリケーションについても見ていきます。

構造化ログと非構造化ログ

構造化ログのエントリは、通常はキーと値のペアまたは JSON オブジェクトとして、明確に定義された形式を持っています。これにより、一貫性のある機械可読なログ エントリが可能になり、プログラムによるログ データの解析と分析が容易になります。

構造化ログにより、高度なログのクエリと分析が可能になり、大規模システムで特に役立ちます。

一方、非構造化 (自由形式) ログでは、事前に定義された構造を持たず、より人間が判読可能な形式でメッセージがキャプチャされます。このアプローチにより、開発者はより自然かつ柔軟にメッセージをログに記録できるようになります。

ただし、結果として得られるログからプログラムを使用して特定の情報を抽出するのは非常に困難な場合があります。

構造化ログと非構造化ログのどちらを選択するかは、特定のニーズとシステムの要件と制約によって異なります。高度なログ分析またはログ分析ツールとの統合の必要性が予想される場合、構造化ログは大きな利点をもたらします。

ただし、単純さと読みやすさだけが必要な場合は、非構造化ログで十分な場合があります。

場合によっては、重要なイベントには構造化ログを使用し、より一般的なメッセージには非構造化ログを使用するハイブリッド アプローチも使用できます。

大規模システムの場合は、可能な限り構造化ログを使用する必要がありますが、これにより計画に別の側面が追加されることに注意してください。構造化されたログ メッセージでは、同じフィールドのセットがシステム コンポーネント間で一貫して使用されることが期待されています。これには戦略的な計画が必要になります。

ロギングの課題

複数のコンポーネントで構成されるシステムでは、各コンポーネントがログを管理するための独自のモデルを持つ可能性が高くなります。これがもたらす課題を見てみましょう。

異なる目的地

コンポーネントは、ファイル、システム ログ、stdout、または stderr などのさまざまな宛先にログを記録します。分散システムでは、このような散在したログを収集して有効活用するのは大変です。

このためには、インストールされたコレクタや Sumo Logic のホストされたコレクタを使用するなど、ログ収集に対する多様なアプローチが必要になります。

さまざまなフォーマット

一部のコンポーネントは、特定の形式に従わない、構造化されていない自由形式のログを使用します。一方、構造化ログはより組織化されている可能性がありますが、構造化ログを持つコンポーネントはまったく異なるフィールドのセットを使用する可能性があります。

多様なログや形式から得られる情報を統合するには、適切なツールが必要です。

一貫性のないログレベル

システム内のコンポーネントは、異なる範囲のログ レベルを使用する場合があります。すべてのログ メッセージを集中ログ システムに統合したとしても (当然のことですが)、すべてのログ レベルの統合に対処する必要があります。

発生する 1 つの課題は、異なるログ レベルを同じように扱う必要がある場合です。たとえば、あるコンポーネントの ERROR が別のコンポーネントの CRITICAL と同じである可能性があり、即時のエスカレーションが必要です。

異なるコンポーネントで同じログ レベルが異なる意味を持つ場合は、逆の課題に直面します。たとえば、あるコンポーネントの INFO メッセージはシステム状態を理解するために不可欠である一方で、別のコンポーネントでは冗長すぎる可能性があります。

ログストレージコスト

大規模な分散システムでは、大量のログが蓄積されます。これらのログを収集して保存するのは決して安くありません。クラウドのログ関連コストは、システムの総コストのかなりの部分を占める可能性があります。

これらの課題に対処する

大規模な分散システムにログインする場合の課題は重大ですが、次のいくつかの実践を通じて解決策を見つけることができます。

ログを集約する

分散システムを実行する場合は、集中ログ ソリューションを使用する必要があります。システム内の各マシンでログ収集エージェントを実行すると、これらのコレクターはすべてのログを中央の可観測性プラットフォームに送信します。

Sumo Logic は常にログ管理と分析に重点を置いており、ログ集約に関してはクラス最高です。

統一フォーマットへの移行

アプリケーションやコンポーネント間で分析やトラブルシューティングのためにログ データを関連付けたい場合、さまざまな形式のログを処理することは大きな問題になります。解決策の 1 つは、さまざまなログを統一フォーマットに変換することです。

このタスクの作業レベルは高くなる可能性があるため、最も重要なコンポーネントから始めて、段階的に実行することを検討してください。

アプリケーション全体でログ標準を確立する

独自のアプリケーションでは、均一なログ レベルのセット、単一の構造化されたログ形式、および一貫したセマンティクスを採用する標準的なログ アプローチの確立に取り組んでください。

レガシー アプリケーションも所有している場合は、標準に準拠するためにそれらを移行することに関連するリスクとコストのレベルを評価します。

移行が不可能な場合は、レガシー アプリケーションをサードパーティ アプリケーションと同様に扱ってください。

サードパーティのソースからのログを強化する

サードパーティ ソースからのログを強化するには、外部システムまたはサービスからのコンテキスト情報を使用してログ データを強化する必要があります。これにより、ログ イベントの理解が深まり、トラブルシューティング、分析、アクティビティの監視に役立ちます。

ログを充実させるために、外部システム (API やメッセージ キューなど) を統合して、ログ イベントに関連する補足データ (ユーザー情報、顧客の詳細、システム メトリックなど) を取得できます。

ログの量、頻度、保存期間を管理する

ログの量、頻度、保存期間を慎重に管理することは、効率的なログの管理と保管のために重要です。

• ボリューム: 生成されたログのボリュームを監視すると、リソースの消費とパフォーマンスへの影響を制御するのに役立ちます。

• 頻度: イベントの重要性と必要な監視レベルに基づいて、ログを記録する頻度を決定します。

• 保持: コンプライアンス要件、運用上のニーズ、および利用可能なストレージに適したログ保持ポリシーを定義します。

• ローテーション: ログ ファイルのサイズを効果的に管理するために、古いログ ファイルを定期的にアーカイブまたはパージします。

• 圧縮: ログ ファイルを圧縮してストレージ要件を削減します。

ログベースのメトリクス

ログ データの分析から得られるメトリックは、システムの動作とパフォーマンスに関する洞察を提供します。ログベースのメトリクスの動作には利点と課題があります。

利点

• 粒度の高い洞察: ログベースのメトリクスにより、システム イベントに対する詳細かつ粒度の高い洞察が提供され、パターン、異常、潜在的な問題を特定できます。

• 包括的な監視: ログベースのメトリクスを活用することで、システムを包括的に監視し、可用性、パフォーマンス、ユーザー エクスペリエンスに関連する重要なメトリクスを可視化できます。

• 履歴分析: ログベースのメトリクスは、傾向分析、容量計画、パフォーマンスの最適化に使用できる履歴データを提供します。長期にわたるログの傾向を調査することで、データに基づいた意思決定を行い、効率と拡張性を向上させることができます。

• 柔軟性とカスタマイズ: ニーズにとって最も意味のあるイベントとデータ ポイントに焦点を当て、アプリケーションやシステムに合わせてログベースのメトリクスの抽出を調整できます。

課題

• 意味のあるメトリクスの定義: すべてのコンポーネントにわたって利用できるメトリクスのセットは信じられないほど膨大であり、すべてをキャプチャすることには意味がないため、どのメトリクスをキャプチャしてログから抽出するかを特定することは複雑な作業になる可能性があります。

  
  

  この識別には、システムの動作を深く理解し、ビジネス目標と緊密に連携する必要があります。

• データの抽出と解析: ログを解析して有用なメトリクスを抽出するには、特殊なツールまたはカスタム パーサーが必要な場合があります。これは、ログが構造化されていない場合、またはコンポーネント間でフォーマットが一貫していない場合に特に当てはまります。

  
  

  この設定には時間がかかる場合があり、ログ形式の変更や新しいログ ソースの出現に応じてメンテナンスが必要になる場合があります。

• リアルタイム分析の必要性: ログベースのメトリクスの処理が遅れると、メトリクスが古くなったり、無関係になったりする可能性があります。ほとんどの状況で、ログベースのメトリクスを効果的に活用するには、受信データを高速にリアルタイムで処理できるプラットフォームが必要です。

• パフォーマンスへの影響: コンポーネント プロファイリング メトリクスを継続的に取得すると、システム リソースにさらなる負担がかかります。十分なログベースのメトリクスを取得することと、適切なシステム パフォーマンスを維持することとの間で適切なバランスを見つける必要があります。

• データのノイズと無関係: ログ データには多くの場合、意味のあるメトリクスに寄与しない、大量のノイズと無関係な情報が含まれます。関連するイベントに焦点を当ててデータを収集するには、慎重なログのフィルタリングと正規化が必要です。

ログの長期保存

集中システムでのログ集約に移行した後も、長期的なログ保持ポリシーを考慮する必要があります。この分野に関する重要な質問について説明しましょう。

ログはどのくらいの期間保存しておく必要がありますか?

ログをどのくらいの期間保存しておくべきかは、次のようないくつかの要因によって決まります。

• ログの種類: 一部のログ (アクセス ログなど) は短期間で削除されます。他のログ (エラー ログなど) は、トラブルシューティングに必要な場合に備えて、長期間保存する必要がある場合があります。

• 規制要件: 医療や金融などの業界には、ログを一定期間、場合によっては数年間保存することを組織に義務付ける規制があります。

• 会社のポリシー: 会社には、ログの保存期間を規定するポリシーがある場合があります。

• ログ サイズ: ログが大きい場合は、ログをローテーションするか、より頻繁に削除する必要がある場合があります。

• ストレージ コスト: ログをどこに保存するか (オンプレミスかクラウドか) に関係なく、ストレージのコストを考慮する必要があります。

古いログの詳細レベルとコストを削減するにはどうすればよいですか?

もちろん、古いログを削除するのが、ストレージ コストを削減する最も簡単な方法です。ただし、これは少し手間がかかるため、古いログの情報を保持しておきたい場合もあります。

古いログの情報を保持したいが、コスト効率も高くしたい場合は、次のような対策を検討してください。

• ログのダウンサンプリング: 多数の反復的なログ ステートメントを生成するコンポーネントの場合、ステートメントのサブセットのみ (たとえば、10 個に 1 個) を取り込む可能性があります。

• ログのトリミング: 大きなメッセージを含むログの場合は、一部のフィールドを破棄する場合があります。たとえば、エラー ログにエラー コードとエラーの説明が含まれている場合、エラー コードのみを保存しておけば、必要な情報がすべて得られる可能性があります。

• 圧縮とアーカイブ: 古いログを圧縮し、安価でアクセスしにくいストレージ (特にクラウド) に移動できます。これは、法規制遵守要件を満たすために何年も保存する必要があるログにとって優れたソリューションです。

結論

この記事では、大規模システムでのログインを最大限に活用する方法について説明しました。

これらのシステムへのログインには特有の一連の課題が伴いますが、ログの集約、ログの統一形式への変換、サードパーティ ソースからのデータによるログの強化など、これらの課題に対する潜在的な解決策を検討してきました。

ロギングは可観測性の重要な部分です。この記事で説明する実践方法に従うことで、ログが効果的に管理され、問題のトラブルシューティング、問題の特定、システムの動作に関する洞察の取得が可能になります。

また、ロギングコストを抑えながらこれを行うことができます。

ここでも公開されています