ログ管理には、ログの生成からアーカイブ、削除までのすべてが含まれます。しかし、多くの場合、チームが問題のトラブルシューティングを効果的に行う上でログを使用するためには、最初にログを集約する必要性があります。効率的なログ管理とは、ログデータが1か所に送信され、誰もが取得し、可視化し、必要に応じて他のサービスのデータとのコンテキストで分析できる状態を指します。Logs in Contextとは、アプリケーションとインフラストラクチャーのコンテキストを、ログを使用したトラブルシューティング作業に組み込むことです。
分散ソフトウェアアプリケーションのログ管理における主な課題には、ログの収集や、必要なときに必要なログを見つけることが含まれます。その他の課題には、アラートの管理やアラートノイズへの対処などがあります。ただし、コンテキストに基づくアプローチを提供するツールを使用すると、ログ管理が簡素化されます。
この投稿では、以下について説明します。
- Logs in Contextとコンテキストに基づくログの意味
- Logs in Context のユースケース
- Logs in Context のメリット
- Logs in Contextを使用したより適切なアラートの作成
- New Relicでの Logs in Contextの実装
Logs in Contextとは
コンテキストに基づくログと呼ばれることもあるLogs in Contextとは、アプリケーションやインフラストラクチャーの問題とともにログを表示することを指します。アプリとインフラストラクチャーに関する有用なデータはログイベントに追加され、関連するイベント全体で共有されるため、Logs in Contextを表示すると、システムのさまざまな部分のパターンや傾向を簡単に確認できます。
分類を要する分離されたログの代わりに、エラー、問題、問題の発生源のコンテキストを取得できます。簡単に移動して、エラーや問題をより詳細に確認できます。また、エラーや分散トレースから始める場合、そのトランザクションで作成されたログにリンクバックできます。
以下は、New RelicでLogs in Contextの使用例です。
- New Relic APMエージェントは、アプリケーションのパフォーマンス監視データをロギングフレームワークに提供し、このデータをアプリケーションログに含めます。
- New Relicは、アプリケーションから流入するデータに自動接続します。サービスのAPM概要ページに移動すると、関連データの下にエラーログがリストされ、重大度別に可視化された、選択した期間のログのチャートも表示されます。
- New Relicはログメッセージとデータを関連付けるため、関連するパターンや傾向を見つけることができます。New RelicのAPMページから、インフラストラクチャーやKubernetesからのデータだけでなく、エラーインボックスなどのログ、トレース、エラーの詳細を調べることができます。
New Relicではログデータを関連するアプリケーションのイベントやトレースと相互に関連付けるため、APMエラーと分散トレースを、各エラーまたはトレースと同じトランザクション中に作成されたログに直接リンクします。たとえば、「ホスト(インフラストラクチャー)」ビューでは、使用可能なログに直接リンクしています。
ホスト(インフラストラクチャ)のビューエクスペリエンスが利用可能なログにリンクされるようになる
- New Relicは、コンテキスト属性をログに追加することでログデータを強化します。つまり、スパンID、トレースID、アプリケーション名がログメッセージに挿入されます。そうすると、データの分析や接続の確立、問題がアプリケーションの健全性とパフォーマンスに影響を与える可能性のある他の領域を特定できるようになり、チームのトラブルシューティングが容易になります。メインのログUI ページから、すべてのログを表示しフィルタリングすると、特定のテキストと属性を含むログを表示できます。
コンテキストに基づくログソリューションでは、問題に関連するログを見つけて、すべてのログを1か所で確認するという課題に対処します。
Logs in Contextの使用は双方向に機能します。これは循環的なものと考えることができます。特定のログを確認することから始めて、次にサーバーにアクセスします。そして、サーバーのデータを確認することから始めて、適切なログの詳細に進むことができます。たとえば、New Relicのログ概要ビューでは、表示しているアプリケーションのレベルまでログの範囲を確認し、そのアプリケーションのログのパターンを確認できます。ただし、複数のアプリケーションとホストにまたがる分散トレースを表示している場合は、そこにLogs in Contextも表示されます。
Logs in Context の使用により適切なアラートの作成
使用しているオブザーバビリティツールや監視ツールが何であれ、アラートの目標は通常、アプリケーションに問題がある場合、またはビジネス目標にとって重要なアクティビティに問題がある場合に、適切な担当者やチームに自動通知することです。アラートの管理では、アラートをトリガーする適切なしきい値を設定することが困難な場合があります。アラートが多すぎる場合は、使用しているツール、または誰かがツールで設定したアラート方法により、大量のノイズが発生する場合があります。アラートを頻繁に受信していると、アラートに注意を払わなくなることに気づくでしょう。ただ無視するだけです。これはアラート疲れとして知られています。
他の種類のテレメトリーデータを使用してアラートを作成できますが、特にNew Relicのログに関連するヒントをいくつかご紹介します。
- ログデータから直接アラートを作成できます。
- アラート条件を作成するときは、 アラートのベストプラクティス に従ってください。たとえば、少量のログやバッチ処理されたログの影響を受ける可能性がある遅延/タイマーの設定を調整することを検討してください。
- New Relicのログパターンをアラート作成の基盤として使用することもできます。これは、データの変更頻度の変化時にアラートが必要な場合に便利です。ログパターンを使用してドロップルールを作成すると、不要な反復データを削除することもできます。
Logs in Context のユースケース
Logs in Context を使用した例をいくつかご紹介します。
- ログデータを分析して、ユーザーの行動、セキュリティの問題、システムパフォーマンスに関する洞察を取得します。まずは パターンを探し 、複数の時間枠にわたるログを分析します。
- エラーの種類や重大度でログをフィルタリングしたり、特定のサービスや特定のユーザーに関連するログを検索したりして、対象を絞り込みます。次に、ログの詳細を調べます。
- アプリケーションでエラーが発生したときにホストで何が起こっていたのかを確認して把握するには、エラーインボックスから、またはAPM > イベント > エラー分析を選択してエラーのトラブルシューティングを行うことができます。
- ログを他のデータソースと相関させることで、何が起きているのかをより完全に把握できます。たとえば、ログで特定のユーザートランザクションを追跡すると、複数のサービス間でそのトランザクションがどのように実行されるかを確認できます。分散トレースを使用して遅延のトラブルシューティングを行うと、パフォーマンス低下時にシステム内で起こっていた内容をより深く理解できます。
- ログで特定のエラーメッセージが見つかった場合、または特定のしきい値に達した場合にログイン試行の失敗がトリガーされる、というアラートを作成します 。
- ダッシュボードにログチャートを追加することで、ログで見つけた内容を他のユーザーと共有することもできます。
Logs in Context のメリット
コンテキストに基づくログアプローチの主な利点には以下があります。Logs in Context にアクセスできる場合、ログ管理は主に4つの方法で簡単になります。
インシデント対応時間の短縮
影響を受けるサービスやコンポーネント、生成されるエラーや警告、および問題が最初に発生したタイミングを確認できるため、対応作業に優先順位を付けて、問題の根本原因を特定して問題解決にかかる時間を短縮できます。
ログは、全員が同じ認識を持ち、同じ目標に向かって取り組むのに役立つ共通の情報源を提供します。また、問題への対応時に関与する必要があるユーザーを特定するのに役立ち、全員が問題解決に必要な情報にアクセスできるようにします。
チーム間の連携強化
Logs in Context は、共通の目標に向かって作業するために誰もがアクセスして使用できる共通の情報源です。チームはログを使用して情報や洞察を共有し、質問し、相互にフィードバックを提供できるため、全員が協力してより良い意思決定を行うことができます。
アラート疲れの軽減とチームの生産性の向上
ログはアラートの追加コンテキストを提供するため、誤検知を減らすのに役立ちます。トリガーされたアラートについては、コンテキストにより、チームで優先順位を付けて最も重要なアラートに重点を置くことができます。
アラートの信頼性と正確性の向上
Logs in Context を分析すると、通常の条件下でシステムの動作方法をより深く理解できます。これにより、特定の環境に合わせて調整された、誤検知が発生する可能性が低い、より正確なアラートを作成できます。実際の問題を特定する可能性が高くなる、より正確なアラートトリガーを作成できます。
Logs in Context の有効化
New Relicログを環境内のコンテキストに適用するための基本的な手順とヒントを以下に示します。
- APMまたはインフラストラクチャー監視のLogs in Context を設定します。ログデータをNew Relicに転送するには、いくつかのオプションがあります。
- アプリケーション言語に対応するAPMエージェントを使用して、Logs in Context を有効化してください。以下の各エージェントには固有の手順があります。
- New RelicナビゲーションでLogsを選択して、プラットフォーム全体のロギングデータを調べます。
- New Relic内のログにアクセスできる他のすべての場所を確認して、アプリケーションパフォーマンスのLogs in Context を確認してください。
- アラートを設定します。
- New Relicのロギングデータを最大限に活用するには、データのクエリを実行し、 ダッシュボードを作成します。
ログ管理全般に関するベストプラクティスとヒントについては、「ログ管理のベストプラクティス」を参照してください。Logs in Context に関する特定のトラブルシューティングのヒントについては、New Relicコミュニティのサポートフォーラムを確認してください。
結論
Logs in Contextを使用すると、トラブルシューティングが簡素化され、全体的なログ管理、アラート、インシデント対応時間、コラボレーションが向上するという利点を説明しました。
また、コンテキスト内でのNew Relicログの使用例をいくつか確認し、独自のデータを使用してコンテキストに基づくログの実装を開始する方法を理解しました。
Next steps
コンテキスト内のNew Relicログを使用してログ管理を改善する方法を引き続き学習するには、「Logs in Contextの概要」を参照してください。
独自のログデータを扱う準備はできていますか?アプリケーションのパフォーマンスに関するコンテキストを追加したログを使用することは、システムに関する洞察を得る優れた方法です。New Relicをまだ使用していない方は、 無料のアカウントに登録できます。無料アカウントには、毎月100GBのデータ取込み、1名のフルプラットフォームユーザー、および無制限の無料ベーシックユーザーが含まれます。
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.