著者:ルカ・ヴィンターガースト、デヴィッド・ホープ、バーフバリ・シェティ
今日の急速なソフトウェア開発プロセスでは、拡大し続ける複雑なインフラストラクチャとアプリケーション コンポーネントが必要となり、運用チームと開発チームの仕事は増大し、多面化しています。可観測性はテレメトリ データの管理と分析に役立ち、アプリケーションとインフラストラクチャのパフォーマンスと信頼性を確保するための鍵となります。特に、ログは開発者が有効にする主要なデフォルト信号であり、デバッグ、パフォーマンス分析、セキュリティ、およびコンプライアンス管理のための豊富な詳細情報を提供します。では、ログを最大限に活用するための戦略をどのように定義すればよいでしょうか?
このブログ投稿では、以下について説明します。
- ロギング、収集のレビュー、ログの処理と強化、分析と合理化の旅
- 管理ログの構造化データと非構造化データの違い
- トレースをロギングに置き換えるべきかどうか
- 変換時間の短縮方法、集中型ログストレージと分散型ログストレージの比較、より少ないコンテンツをいつどのように保存するかを理解することで、ログの運用効率を向上させます。
これらのトピックをより深く理解することで、ログを効果的に管理し、アプリケーションとインフラストラクチャの信頼性、パフォーマンス、セキュリティを確保できるようになります。
ジャーナリングの旅
ログ記録プロセスには、次の 3 つの基本的な手順が含まれます。
ログを収集して取り込む方法、適切な解析と処理とは何か、ログを分析して合理化する方法について説明します。さらに、アプリケーション パフォーマンス監視 (APM)、メトリクス、セキュリティ イベントを使用してこの取り組みを強化する方法についても説明します。
ログ収集
ログ記録の最初のステップは、すべてのログを 1 つの中央の場所に収集することです。これには、すべてのアプリケーションとシステムを識別し、それらのログを収集することが含まれます。
ログ収集の重要な側面は、すべてのアプリケーションとインフラストラクチャにわたる最大限の標準化です。共通の意味パターンを持つことは非常に重要です。Elastic は、Elastic Common Schema (ECS) を OpenTelemetry (OTel) に提供し、OTel ベースの可観測性とセキュリティの導入を促進します。これにより、ログ (メトリクスやトレースを含む) を定義および取り込むためのより規範的な方法に移行します。
ログ収集のもう 1 つの重要な側面は、低コストで適切な取り込み容量を確保することです。この評価を行う場合、カーディナリティの高いデータに対して複数の料金を請求するソリューションには注意する必要があるかもしれません。一部の可観測性ソリューションではこれに追加料金がかかるため、このステップでのスケーリング機能とコストを理解することが重要です。
ログを処理して強化する
ログを収集した後、ログ ファイルの処理を開始し、それらを共通スキーマに配置できます。これにより、ログを標準化し、最も重要な情報をより簡単に集約することができます。標準化されたスキーマにより、ソース間でのデータの関連付けも容易になります。ログ データを正規化されたスキーマに処理する場合は、次の点を考慮する必要があります。
- ほとんどの可観測性ツールには、データを特定の既知のパターンに変換するためのすぐに使える統合機能が備わっています。すぐに使用できる統合が利用できない場合は、正規表現または同様の方法を使用して情報を解析できます。
- 管理ログの処理は通常、何らかの取り込みパイプラインで行われます。Kafka、Azure Service Bus、または Pulsar を使用したストリーミング データ パイプラインを含むスケーラブルで複雑なアーキテクチャを使用したり、Logstash や Kafka Streams などの処理フレームワークを使用したりすることもできます。正解も不正解もありませんが、ここで複雑になりすぎないように注意することをお勧めします。ここにストリーミング データ処理ステップを追加すると、最終的に数か月に及ぶプロジェクトと大量のコードを保守することになる危険性があります。
Elastic は、取り込み (AWS Kensis Data Firehose など) と処理 (非構造化ログの解析、ログの強化、さらにはそれらの正確な分類) を行うための複数の方法を提供します。
データが取り込まれたら、抽出して強化する必要がある場合があり、ログ ファイル内のデータに基づいてメトリクスを作成する必要がある場合があります。これを行うには多くの方法があります。
- 一部の可観測性ダッシュボード機能は、実行時変換を実行して、解析されていないソースからフィールドを動的に抽出できます。これは、読み取り時間モードと呼ばれることがよくあります。これは、標準化された形式でデータを記録できない可能性があるレガシー システムまたはカスタム アプリケーションを扱う場合に役立ちます。ただし、実行時の解析は、特に大量のデータの場合、非常に時間とリソースを大量に消費する可能性があります。
- 一方、ライトオンライト モードでは、パフォーマンスが向上し、データの制御が強化されます。スキーマは事前定義されており、データは書き込まれるときに構築および検証されます。これにより、データの処理と分析が高速化され、エンリッチメントに役立ちます。
ログ分析
検索、パターンマッチング、ダッシュボード
論理的かつ伝統的な次のステップは、ダッシュボードを構築し、ログをリアルタイムで監視できるようにアラートを設定することです。ダッシュボードはログを視覚的に表現するため、パターンや異常を簡単に特定できます。特定のイベントが発生するとアラートで通知されるため、迅速に行動を起こすことができます。全文検索の機能を活用して、ログからメトリクスを簡単に作成します。たとえば、「error」という用語を検索すると、検索機能によってすべてのソースで一致するエントリがすべて検索されます。その後、結果を表示したり警告したりできます。さらに、ダッシュボード上でログを検索し、パターンを探します。
その後、機械学習を使用してログを分析し、手動分析では見えない可能性のあるパターンを特定できます。機械学習を使用すると、異常なトラフィックやエラーなどのログの異常を検出できます。さらに、インデックス付けされているログ データの種類を自動的に追跡し、そのパターンの変化を検出するログ分類機能などの機能も役立つ場合があります。これは、アプリケーションの新しい動作や見逃している可能性のあるその他の興味深いイベントを検出するために使用できます。
機械学習 - ログ ファイルに潜む未知の情報を明らかにする
組織は、ログ ファイル内の未知のものを効果的に発見できる可能性を高めるために、さまざまな機械学習アルゴリズムと技術を使用することをお勧めします。
重大度に基づくレート制御アラートによるリアルタイム データの異常検出には、クラスタリング (X 平均法、BIRCH)、時系列分解、ベイズ推論、相関分析などの教師なし機械学習アルゴリズムを採用する必要があります。
インフルエンサーを自動的に識別することで、ユーザーは自動根本原因分析 (RCA) のための貴重なコンテキスト情報を得ることができます。ログ パターン分析は非構造化ログを分類し、ログ レート分析と変化点検出はログ データのスパイクの根本原因を特定するのに役立ちます。これらの方法を組み合わせることで、ログ ファイル内の隠れた洞察や問題を明らかにする強力な方法が提供されます。
RCA を支援し、未知の部分を明らかにし、トラブルシューティングを改善することに加えて、組織は将来のニーズを予測し、ビジネス目標を調整するのに役立つ予測機能にも注目する必要があります。
旅をさらに豊かにする
最後に、ログを収集するときに、メトリクスまたは APM データも収集したい場合があります。メトリックによって、CPU 使用率、メモリ使用量、ネットワーク トラフィックなどのシステムのパフォーマンスに関する洞察が得られます。一方、APM は、応答時間の遅さやエラーなど、アプリケーションの問題を特定するのに役立ちます。必須ではありませんが、特にメトリクス データはログ データと連動しており、セットアップが非常に簡単です。すでにシステムからログを収集している場合、追加のメトリックの収集には通常、数分もかかりません。運用担当者は、展開のセキュリティだけでなく、誰が、何を展開しているのかも常に追跡しているため、APM とメトリクスを通じてセキュリティ イベントを追加および使用すると、全体像を把握するのに役立ちます。
構造化ログと非構造化ログ?
ロギング プロセスにおける一般的な課題は、非構造化ログと構造化ログの管理、特に取り込み中の解析です。
既知のパターンを使用してログを管理する
幸いなことに、一部のツールは、Apache、Nginx、Docker、Kubernetes などの一般的なソースに対する広範な組み込み統合を提供します。これらの統合により、カスタム解析ルールやダッシュボードの構築に時間を費やすことなく、さまざまなソースからログを簡単に収集できるようになります。これにより、時間と労力が節約され、チームはログの解析や視覚化ではなく、ログの分析に集中できるようになります。
一般的なソースからのログ (カスタム ログなど) がない場合は、独自の解析ルールを定義する必要がある場合があります。多くの可観測性ロギング ツールは、この機能を提供します。
したがって、構造化ログは、より多くの価値を提供し、使いやすいため、一般に非構造化ログよりも優れています。構造化ログには、情報の抽出と分析の実行を容易にする事前定義された形式とフィールドがあります。
非構造化ログについてはどうですか?
可観測性ツールの全文検索機能は、非構造化ログの潜在的な制限に関する懸念を軽減するのに役立ちます。全文検索は、非構造化ログにインデックスを付けることで、そのログから意味のある情報を抽出できる強力なツールです。全文検索を使用すると、ログが解析されない場合でも、ユーザーは特定のキーワードや語句を検索できます。
デフォルトでログにインデックスを作成する主な利点の 1 つは、ログを効率的に検索できることです。事前にインデックスを作成しておくと、大量のデータでもすぐに検索して、探している特定の情報を見つけることができます。これにより、ログを分析する際の時間と労力が節約され、問題をより迅速に特定できるようになります。すべてにインデックスが付けられ検索可能になっているため、正規表現を作成したり、複雑なクエリ言語を学習したり、検索が完了するまで長時間待つ必要はありません。
ログを追跡に移動する必要がありますか?
ロギングは長い間、アプリケーションの監視とデバッグの基礎となってきました。ただし、ログはあらゆる監視戦略に不可欠な部分ですが、利用可能な唯一のオプションではありません。
たとえば、トレースはログへの貴重な追加であり、特定のトランザクションまたはリクエスト パスについてのより深い洞察を提供します。実際、正しく実装されていれば、特にクラウドネイティブ環境では、トレースはアプリケーション (インフラストラクチャではなく) の追加計測としてロギングを補完できます。トレースは、より多くのコンテキスト情報を提供することができ、特に環境内の依存関係の追跡に優れています。個々のインタラクションはサービス全体でエンドツーエンドで追跡されるため、ログ データよりも追跡データの方が波及効果を確認しやすくなります。
追跡にはさまざまな利点がありますが、追跡の使用による制限を考慮することも重要です。実装の追跡は、所有するアプリケーションに対してのみ機能し、インフラストラクチャの追跡は依然としてアプリケーションのみであるため、取得できません。すべての開発者が、ロギングの代わりにトレースを使用することに完全に同意しているわけではありません。多くの開発者は依然としてデフォルトでログを主な検出手段として使用しているため、監視戦略としてトレースを完全に採用することが困難になっています。
したがって、ロギングとトレースを組み合わせた戦略を採用することが重要です。トレースは新しいインスツルメンテーション アプリケーションをカバーでき、ロギングはソース コードを所有していないことを理解した上で、ソース コードを所有していないレガシー アプリケーションとシステムをサポートします。システムのステータス。
ログ運用効率の向上
ログを管理する場合、主に次の 3 つの側面が業務効率を低下させます。
- ログの変換に時間がかかる
- ログ情報の保存と取得を管理する
- いつ削除するか、ログから何を削除するか
これらの問題を管理するための戦略については、以下で説明します。
データの変換にかかる時間を削減する
構造化されていないログであっても、さまざまなスキーマ セットを持つ大量のログがある場合、組織は問題の理解、根本原因の分析、運用の最適化よりも、不必要なデータ変換により多くの時間を費やす可能性があります。
共通のパターンに従ってデータを構造化することで、運用チームは平均解決時間 (MTTR) を短縮しながら、問題の特定、解決、防止に集中できるようになります。また、重複データがなくなり、標準化のためにデータを処理する必要がなくなるため、運用コストも削減できます。
業界は、ログ、メトリクス、トレース、セキュリティ イベントの共通パターンの実装を試みる OpenTelemetry Semantic Convention プロジェクトを通じてこの標準化を達成しています。Elastic Common Schema (ECS) の OpenTelemetry への最近の貢献のおかげで、ロギングは特に強力です。これは、共通スキーマの取り組みを強化するのに役立ちます。
簡単な例としては、クライアントの IP アドレスが、クライアントに関するテレメトリ データを監視または管理する複数のソースから送信される場合があります。
src:10.42.42.42
client_ip:10.42.42.42
apache2.access.remote_ip: 10.42.42.42
context.user.ip:10.42.42.42
src_ip:10.42.42.42IP アドレスを複数の方法で表すと、潜在的な問題の分析や問題の特定が複雑になる場合があります。
ユニバーサル スキーマを使用すると、すべての受信データは標準化された形式になります。上記の例を使用すると、各ソースは同じ方法でクライアントの IP アドレスを識別します。
source.ip:10.42.42.42これにより、データの変換に時間を費やす必要性が軽減されます。
集中型ログ ストレージと分散型ログ ストレージ
データの局所性は、ログ データを管理する際の重要な考慮事項です。大量のログ データを送受信する場合、特にクラウド プロバイダーとやり取りする場合、コストが非常に高くなる可能性があります。
ゾーン冗長性要件がなければ、組織にはすべてのログ データを中央の場所に送信する説得力のある理由がない可能性があります。ログ ソリューションは、組織がログ データを生成されたデータ センターのローカルに保存できる方法を提供する必要があります。このアプローチは、ネットワーク上での大量のデータの送信に関連する受信コストと送信コストを削減するのに役立ちます。
クラスター間 (またはデプロイメント間) 検索機能を使用すると、ユーザーは複数のログ クラスターを同時に検索できます。これは、ネットワーク上で転送する必要があるデータの量を減らすのに役立ちます。
組織が災害発生時にビジネス継続性を維持する必要がある場合、クラスター間レプリケーションも検討すべき便利な機能です。クラスタ間レプリケーションを使用すると、データ センターの 1 つで障害が発生した場合でも、組織はデータを 2 番目の宛先に自動的にレプリケートすることで、データを確実に利用できるようになります。通常、このアプローチは最も重要なデータに対してのみ使用され、最大のデータ ソースに対しては前述のデータの局所性が活用されます。
考慮に値するもう 1 つの関連トピックは、ベンダー ロックインです。一部のロギング ソリューションはデータを取得した後にロックするため、組織がベンダーを切り替えたい場合にデータを抽出することが困難または不可能になります。
これはすべてのベンダーに当てはまるわけではないため、組織は常にすべての生データに完全にアクセスできることを確認する必要があります。この柔軟性は、独自のログ ソリューションに縛られることなくベンダーを切り替えたい組織にとって非常に重要です。
大量のログ データの処理 – すべてをログに記録するか、すべてを破棄するか、それとも使用量を減らすか?
特にシステムやアプリケーションによって生成されるデータの量が増え続けるにつれて、大量のログ データの処理は困難な作業になる可能性があります。さらに、コンプライアンス要件により特定のデータのログ記録が義務付けられる場合があり、場合によっては、すべてのシステムのログ記録が制御できない場合があります。データ量を減らすことは現実的ではないように思えるかもしれませんが、役立つ最適化がいくつかあります。
1) すべてを収集しますが、ログ削除ポリシーを作成します。組織は、どのようなデータがいつ収集されるかを評価したい場合があります。ソースのデータを破棄すると、後でトラブルシューティングや分析にデータが必要になった場合に問題が発生する可能性があります。データをいつ削除するかを評価します。可能であれば、古いデータを自動的に削除するポリシーを設定して、ログを手動で削除する必要性と、まだ必要なログを誤って削除するリスクを軽減します。
DEBUG ログや INFO ログもできるだけ早く破棄し、開発環境とステージング環境のログをできるだけ早く削除することをお勧めします。使用する製品に応じて、各ログ ソースの保存期間を柔軟に設定できます。たとえば、ステージング ログを 7 日間、開発ログを 1 日間、本番ログを 1 年間保持できます。さらに一歩進んで、アプリケーションまたはその他の属性ごとに分割することもできます。
2) さらなる最適化は、同じログ行の短いウィンドウを集約することです。これは、TCP セキュリティ イベント ログに特に役立ちます。同じログ行を集計し、カウントと開始および終了のタイムスタンプを生成するだけです。これは、十分な忠実度を提供し、多くのストレージ スペースを節約する方法で簡単に拡張できます。これを行うには、前処理ツールを使用できます。
3) 管理するアプリケーションやコードについては、一部のログをトレースに移動することを検討すると、ログの量を減らすことができます。ただし、トレースは依然として追加データを構成します。
一緒に置く
この記事では、ロギング プロセスの概要と、この記事で考慮すべきいくつかの課題について説明します。収集と取り込み、解析と処理、分析と合理化という 3 つの基本的なステップを含むロギング プロセスを導入するにあたり、次の点を強調しました。
- ログ収集フェーズ中にインフラストラクチャに死角がないことを確認し、ソースで構造化されたログを生成することに重点を置くことが重要です。
- データの抽出とログの強化は、読み取りパターンまたは書き込みパターンの方法によって実現でき、機械学習を使用してログを分析し、手動分析では見えない可能性のあるパターンを特定できます。
- 組織は、ロギングの取り組みを強化するために、メトリクスまたは APM データも収集する必要があります。
私たちはいくつかの重要な課題について話し合いました。
- 構造化ログは使いやすく、より多くの価値を提供しますが、非構造化ログは全文検索機能を使用して管理できます。
- トレースは特定のトランザクションと依存関係についてより深い洞察を提供し、主要な検出手段としてロギングに取って代わる可能性がありますが、制限と開発者の導入のため、ロギングとトレースを組み合わせた戦略が重要です。
- 組織は、データの変換にかかる時間を短縮し、集中型または分散型のログ ストレージを選択し、ログ削除ポリシーを実装し、同一のログ行の短いウィンドウを集約することで大量のログ データを処理することに重点を置くことで、ログ運用を改善できます。