1,524 測定値

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

に Alvin Lee9m2023/08/25

長すぎる; 読むには

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

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

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

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

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

ロギング設計

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

ログレベル

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ロギングの課題

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

異なる目的地

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

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

さまざまなフォーマット

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

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

一貫性のないログレベル

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

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

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

ログストレージコスト

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

これらの課題に対処する

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

ログを集約する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ログベースのメトリクス

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

利点

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

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

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

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

課題

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

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

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

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