ログ管理のベストプラクティス

概要

ログ管理は進化しています。何かが起きたときにだけ、アプ リケーションやインフラのログを生でダンプするのはもは や昔のことです。今ではログは、組織の業務、ビジネスイン テリジェンス、マーケティングに必要不可欠な役割を担って います。ログはオブザーバビリティの原動力です。構造化さ れたログは、組織が、システム全体の稼働状態を迅速かつ容 易に把握し、先手を打って問題を阻止することさえ可能にし ます。

ログを使用して効果的なオブザーバビリティを得るには、上 手くフォーマットされていない大量のログをデータベースや ファイルに単に落とし込む方法よりも、さらなる熟慮と注意 深さが求められます。どのようにログのプラクティスを変え れば、詳細なログを利用して、アプリケーションやインフラの インシデントをリアルタイムで関連づける能力を高め、異な るアプリケーションおよびツールを切り替える手間を省ける ようにできるようでしょうか?どのようにすれば、エンドツー エンドのオブザーバビリティをより良く実現できるでしょう か?組織がフルスタックオブザーバビリティの実現により近 づき、ビジネスに役立てるには、どうすればよいでしょうか?

ログの記録方法を変更することで、ログがフルスタックの観 測性を高めるようにすることは簡単です。このホワイトペー パーでは、モダンな組織のためのログのベストプラクティス について解説します。

従来のログ管理

従来、ログは他のシステムとは別に保管されたデータサイロ で行われていました。かつてオブザーバビリティは、アプリケ ーションパフォーマンスモニタリング(APM)とインフラモニ タリングに依存していました。モニタリングは重要ですが、 アプリケーションやインフラデバイスのログの中身を全体的 に把握することはできません。ばらばらで、サイロ化された モニタリング/ロギングツールはアプリケーション中心主義 であり、スタックのごく一部にしか焦点を当てておらず、何が 起きているのか、なぜそれが起きているのかを説明するた めの完全な情報を提供できません。市場化を加速し、顧客の 行動を深く洞察し、インシデントのレスポンスタイムを短縮 するために必要な情報を、チームが入手することが非常に 重要です。

多くの組織は、ログからきめ細かな詳細を取得することを選 択しておらず、問題の根本的な原因の特定に苦労するか、 あるいは別のツールを使用してログの詳細をエラーとトレ ースにマッピングしようとしているかのどちらかです。詳細 なログを別々のサイロで管理すると、全体像が見えなくな り、製品を市場に展開するためのコストと時間がかさみ、顧 客体験の可視性が低下し、平均復旧時間(MTTR)が増大し ます。

フルスタックオブザーバビリティ

顧客体験に影響を与える可能性のある技術スタック内の全 てを表示する機能は、フルスタックオブザーバビリティまた はエンドツーエンドのオブザーバビリティと呼ばれていま す。それは、全てのテレメトリデータ(メトリクス、イベント、ロ グ、トレース)の完全なビューに基づいています。

フルスタックオブザーバビリティは、理想的には単一の統合 されたソリューションによって複雑なアプリケーションやシ ステムの動作を完全に視覚化し、インシデントのトラブルシ ューティング、MTTRの短縮、顧客体験の理解を可能にし ます。

フルスタックオブザーバビリティにより、エンジニアや開発 者がデータをサンプリングしたり、技術スタックの可視性を 低下させたり、サイロ化されたデータをつなぎ合わせるのに 時間を無駄にしたりする必要がなくなります。代わりにエン ジニアや開発者は、彼らが好む、より優先度が高くビジネス に影響を与えるクリエイティブなコードディング作業に集中 できます。

フルスタックオブザーバビ リティのためのログ記録 

スタック全体のログを記録する作業には労力がかかりま す 。エ ン ジ ニ ア や 開 発 者 は 、何 を 記 録 す る の か 、ど の 程 度 の詳細を含めるのか、データ量が大き過ぎると経費がかさ むのではないか、など疑問をお持ちのことでしょう。異なる プ ラ ッ ト フ ォ ー ム で の ロ グ 管 理 を 一 元 化 す る た め に 、多 く の企業が高いコストをかけており、最終的には、パフォーマ ンスとコスト次第で送信するログデータの量を制限せざる を得なくなっています。こうしたデータサンプリングがビジ ネスにもたらす可視性と価値は限定的です。以上のことを 念頭に、フルスタックオブザーバビリティを実現するための ログ管理のベストプラクティスをいくつか見ていきます。

必要なものを記録する

ログは、標準的なアウトプットまたはファイルにテキストを書 き込むことによって生成されます。最も重要な判断は、何を ログに含めるかを選別することです。ログには、調査する際 にイベントと根本原因の特定に役立つ全ての必要なメタデ ータを含めるべきです。ログのメタデータの構成要素には、 エラーメッセージまたはスタックトレースと、それらに関連す る値、メトリクス、イベントなどが含まれる場合があります。

組織のログの全てのデータには、目的を持たせるべきで す。データは、使用率であれ、ユーザーイベントであれ、アプ リケーションのエラーと例外であれ、チームにとって価値が あるべきです。ログデータ情報の要件:

• 何らかの形ですぐに役立つ
• 根底にある原因を理解し、判断を下すために必要な詳細情報を提供する

共通のシナリオを予想する 

ログは、インシデントに対応するためだけのものではありま せん。業績のプロファイリングや統計データの収集など、ビ ジネスにも役立つことがあります。

共通のシナリオを幾つか念頭にログ記録を取ることによ り、ログは組織に直接的な価値をもたらすようになります。たとえばユーザー同士の行動に関するログは、顧客体験に 関する重要な洞察をもたらします。システムログにより、問 題やハードウェア障害を監視できます。アプリケーションに 関する詳細なログは、パフォーマンスとメモリリークなどの 潜在的な問題への洞察をもたらすことがあります。これらは 全て、ビジネス上の意思決定を行う上で重要なものとなり得 ます。

有意義なメッセージを記録する

ログメッセージは、それが伝える情報やコンテクストと同じ だけの価値があります。十分な詳細情報を追加して理解しや すい形に加工することで、チームはログを効果的に活用で きます。サードパーティのインフラが必要な詳細情報を捕捉 する傾向があります。それでもチームは、社内で作成された アプリケーションについて、エラー/イベントが発生した理由 を診断、特定し、ビジネスに影響を与える必要なアクション を実行できるように、常にログの詳細を記録する必要があり ます。

アプリケーションエラーの場合、メッセージはその命令行で 何が起こっているかを伝える必要があります。たとえば、トラ ンザクション失敗というエラーメッセージは、トランザクション 失敗:ユーザー ${path/to/file:line-number}を作成でき ませんでしたというエラーメッセージほど有効ではありませ ん。トランザクションに関するデータを含むログは、トランザ クションが失敗した理由を開発者やエンジニアが確認する のに役立ちます。

通常、プログラム中のエラーコードまたはステータスコード は、アプリケーションの問題の種類を示すことができます。エ ラーコードのテキストや番号を出力するだけでなく、ログに 簡潔な説明を加えると、トラブルシューティングの際に他の 開発者やエンジニアの時間と労力を節約できます。

ログは、組織にとって必要不可欠な情報を提供すべきで す。開発者とエンジニアは、チームの限られたメンバーにし か理解できない意味不明のあるメッセージや分かりにくい メッセージを記録しないようにすべきです。

ログは常にシンプルで簡潔にする

ログに十分な情報を含めることは非常に大切ですが、その 逆もまた然りです。過剰で不必要なデータをメッセージに含 めると、ログのストレージサイズとコストが膨れあがり、ログ の検索が遅くなり、本質的な問題から遠ざかり、デバッグが いっそう面倒なものになります。

チームは、ログの簡潔さを維持して最も重要な情報のみを 取得すべきです。ログには、不要なノイズを避けつつ、エラ ーが発生した理由を含めるべきです。

その場合、環境に関する詳細情報は含めず、エラーの根本原 因に関する情報を提供すべきです。たとえば、アプリケーシ ョンが内部APIに接続できずデータを取得できなかった場 合、APIからのエラーメッセージまたは環境のネットワーク 状態に関する情報をログに記録すると役立つことがありま す。アプリケーションが使用するメモリの量や実行中のアプ リケーションの数を含める必要はないと考えられます。

忘れずに時刻の記録を行う 

チームは、ログのタイムスタンプを含める必要があります。 当然のことと思われるかもしれませんが、日時を自動的に記 録するデータベースにログを書くことに慣れている開発者と エンジニアは、ログメッセージにタイムスタンプを含めるこ とを考慮しない場合があります。その中で、納得のいく最も 細かいレベルを選択し、ログに出力する必要があります。高 頻度のタスクには、ミリ秒単位まで時間を追跡する必要があ りますが、低頻度のタスクであれば分単位か、日単位でも十 分かもしれません。大切なのは単なる細かさではなく、組織 全体にわたり一貫性のある基準を適用することです。

もう1つの潜在的に明白かつ重要な注意点は、全てのシステ ムを同時に同期させ、オブザーバビリティプラットフォーム がタイムスタンプを使用して、ログイベントを他のテレメトリ データと関連付けられるようにすることです。

解析可能なログフォーマットを使用 する

ログからデータを抽出できないオブザーバビリティプラッ トフォームは、あまり役に立ちません。チームは、開発者と エンジニアが解析して一貫性のあるログ構造を維持できる ログフォーマットを使用して、収集と集計を容易にすべきで す。New Relicログ管理機能を使用すると、カスタムログ解 析ルール1を簡単に定義できますが、ログデータが分かりに くいと解析ルールは魔法のような効果を発揮できません。

解析されていないログフォーマットの良い例は、非構造化テ キストを含むデフォルトのNGINXアクセスログです。検索に は便利ですが、それ以外はあまり役に立ちません。解析され ていないフォーマットの場合、チームは大半の質問に答える ために全文検索を行う必要があります。典型的な命令行の 例を以下に示します:

127.180.71.3 - - [10/May/2022:08:05:32 +0000] "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"

解析されたログはレスポンスコードやリクエストURLなどの属 性に整理されます。解析可能なログフォーマットを使用した 同じログ情報の例を以下に示します:

{
  "remote_addr":"93.180.71.3",
  "time":"1586514731",
  "method":"GET",
  "path":"/downloads/product_1",
  "version":"HTTP/1.1",
  "response":"304",
  "bytesSent": 0,
  "user_agent": "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"
}

フ ォ ー マ ッ ト が 完 全 に カ ス タ ム 化 さ れ て い る 場 合 、ロ グ の 種類を設定するとユーザー定義の解析ルールが起動され ます。

組織が共通目的に役に立つアプリケーションを複数持つ場 合、チームは全てのアプリケーションでログフォーマットを 標準化することに注力すべきです。これにより、各アプリケー ションに関与するチームが異なる属性を可視化したい場合 も、より簡単にオブザーバビリティプラットフォームへのデー タの取り込みができるようになります。

ログフォーマットの詳細

テキストを構造化する方法には、一貫性のある3つのフォー マットカテゴリーがあります。いずれもログ集計ツールがデ ータを収集した後の使い勝手に影響します。3つのフォーマ ットカテゴリーは以下のとおりです:

• 構造化—ログ記録の最も一般的な構造化フォーマットの 1つがJSONです。JSONの解析を迅速に行えるツールは 多数あります。JSONは柔軟性に富み、軽量です。理想的 には、生成される全てのログが構造化フォーマットになっ ていることです。JSONは階層データの体系化に貢献し ます。カンマ区切り値(CSV)やタブ区切り値(TSV)など、 他の共通フォーマットも構造化ログデータの例です。 
• 共通化—共通フォーマットは構造化されていませんが、よ く知られており、定義され、一貫性があります。ログにアク セスするためのApacheという共通ログフォーマットはそ の一例です。共通フォーマットの利点は、多くのツールが「 追加設定なし」でデータを解析できることです。 
• カスタム—アプリケーションがログ記録を構造化フォーマ ットや共通フォーマットで行っていない場合、そのアプリ ケーションはカスタムフォーマットでログを記録していま す。ログの転送中に個々のログ行の始まりと終わりを識別 するため、チームは解析を行う必要がある場合がありま す。顧客定義の構文解析規則を作成すると、データの価値 をいっそう高める一助となります。

ログのカテゴリー化とグループ化

ログのデータモデルを指定すると、検索がより効果的に行え るようになります。チームは可能な限りいつでも属性を定義 して含め、それに応じてログをカテゴリー化およびグループ 化する必要があります。

New Relicを含む業界リーダーが集まって策定したログに関 するOpenTelemetry標準は、命名規則やフィールド値の定 義など多くの要素をカバーしています² 。これらの標準に正 確にフォーマットされたログは、すべてのフレームワークに よってネイティブにサポートされているわけではありません が、ガイドラインとして使用できます。

ログのデータモデルに含めると便利な共通属性には、リソー ス、コンテクスト化されたログ、およびログレベルなどがあり ます。

リソース

リソースは以下のようなログの時期と出所を明確にします。

• 日時 
• マシン、ホスト名、または識別子 
• アプリケーション名またはサービス名 

環境に名前があるクラシックなホストベースのアプリケーシ ョンでは、ホスト名はログの中で意味を持ちます。ポッドID やコンテナIDは、コンテナ化された環境や組織化された環 境からのログの体系化を改善します。

多くの場合、組織化された環境またはサービスとしてのプラ ットフォーム(PaaS)環境では、ログに大量のメタデータが 自動的に入力されます。これは組織にとっては素晴らしいこ とですが、製品バージョン番号、ステージング環境と運用環 境、テストブランチ、A/Bテストバージョンなど、システムが 認識できない有用な修飾語句でログに注釈を付けることも 重要です。ログ集計とは、複数ソースから採取した全てのロ グを同じシステム上に集めることです。チームは、正しいメタ データがなければ、テストランを行う中で失敗となったトラ ンザクションと、運用環境における真のエラーログとを識別 できません。

チームによるログソースの識別に役立つもう一つのリソー スがログ転送です。たとえば、New Relicが提供するほとん どのログ転送ソリューションでは、データの搬出に使用した ツールのタイプとバージョンを注釈としてデータに自動的に 添付します。

Logs in context 

チームにとって、アプリケーションの問題に関するコンテクスト化されたロ グは有益です。たとえばNew Relic logs in contextの機能は、ログにアプリケ ーション情報を自動的に追加できます。New Relic APMエージェントは、ロ ギングフレームワークにアプリケーションパフォーマンス管理データを提供 し、アプリケーションログに包含します。その結果、コンテクスト化されたロ グが関連アプリケーションイベントとトレースにログデータを自動的に関連 付けます。APMエラーと分散トレーシングは、エラーやトレースと同じトラ ンザクション中に生成されたログに直接リンクされます。コンテクスト化さ れたログは、ログメッセージにスパンID、トレースID、アプリケーション名を 挿入することにより、こうした関連付けを行います。これによりチームはアプ リケーションとログデータを一体化して、トラブルシューティングをより迅速 に行うことができます。

ログレベル 

開発者、DevOps担当者、マネージャーは、重大性の度合い に従ってログのレベルを参照することがあります。ログのレ ベルは、イベントの相対的重要性を説明し(デバッグ、情報、 警告、エラー、致命的などの観点で)、ロギングフレームワー クから得た情報の密度も説明してくれます。重要度に関する 属性は、さほど重要でない情報をフィルタリングしたり排除 したりするのに役立ち、チームが重大なエラーだけに専念 できるようにします。

ログレベルを有効活用すれば、データ量を制限し、集中ログ 管理ツールの使用コストを節約し、検索が迅速になります。 場合によっては、アプリケーションのログ生成方法を管理で きないことがあるかもしれませんが、理想的な状況ではログ 管理システムによって不要なデータを排除できます。New Relicでは、チームは、たとえばログレベルに基づく機械学習 パターンを利用して異常値を抽出できます。カラーコード化 されたログレベルにより、インジケーターを視覚化して、最 も重要な領域に注力することができます。

チームはログレベル、特にデバッグログレベルを注意して使 用すべきです。特定の動作に伴う冗長なメッセージを取得 するのにデバッグは大いに役立ちます。しかし不必要なデバ ッグは膨大な量のログをもたらし、付加価値を提供すること なくログの取り込みと検索機能の速度を低下させます。より 規模の大きなチームとプロジェクトは、一貫性のあるグルー プ化、カテゴリー化、およびログ記録方法に関するログレベ ルの基準から恩恵を受けることがあります。

ロギングツールとフレームワークの 使用 

ロギングソリューションを一から導入して時間やリソースを 費やす代わりに、十分にテストされた実績のあるロギングツ ールとフレームワークを使うことで、チームは時間を節約し トラブルを回避できます。たとえば、New RelicのAPM言語 エージェントは、必要なメタデータをログに付加し、自動的なlogs-in-context機能と転送ログへのアクセスを提供しま す。サードパーティのソフトウェアをインストール、管理する 必要はありません。

一貫性のあるロギングフレームワークを使用すると、エンジ ニアチームによる導入が簡素化され、ログ出力が正常化さ れます。コンテクストに応じたログを一様に表示することが できます。ロギングフレームワークの導入に際しては、新し いコードを導入する場合と同様に、慎重を期し、パフォーマ ンスの影響をテストすべきです。

大量のデータは保存場所の参照に とどめ、ログに含めない

状況によっては、ログから大量のデータを取得してより深い コンテクストを提供する必要に迫られることもあります。そう したデータには、たとえばメモリダンプや一連のファイルや 画像などがあります。このようなデータは別途保存するか、 指定されたサーバーにアップロードし、ログそのものには含 めず、保存場所を参照するにとどめるのが得策です。ログの データ容量はできるだけ小さくし、データには別途アクセス するようにします。

有用なビュー、クエリ、アラートを 共有する

チームは、組織の現在の状態に関する幅広い洞察を提供 し、チーム間の可視性とコミュニケーションを向上させるた め、ログの標準的な視覚化、クエリ、アラートを作成して共有 する必要があります。これがフルスタックオブザーバビリテ ィのパワーです。

ログに加えるべきでないもの

役に立つものやすべてを記録したくなりがちですが、いくつ かの例外や落とし穴を避ける必要があります。

機密情報

機密情報は慎重に取り扱う必要があります。個人識別情報 (PII)およびクレジットカード番号などの規制データは、欧 州連合の一般データ保護規則(GDPR)3および米国の医療 保険ポータビリティおよび説明責任法(HIPAA)などの規制 法に従って保護することが不可欠です。.⁴

オープン・ウェブ・アプリケーション・セキュリティ・プロジェク ト(OWASP)のロギングガイドラインには、記録すべきでな いものが記載されています。例えば、アクセス用トークン、パ スワード、機密情報、個人が明かしたくない情報などです。⁵

プライベートサーバーやデータベースに保管されたログの 場合、氏名やメールアドレスなどのPIIを偶発的に簡単に記 録してしまうことがあります。特定のユーザーの行動または イベントの追跡に際しては、匿名の識別子を使用する必要 があります。ログデータはNew Relicなどのオブザーバビリ ティプラットフォームに安全に保管されますが、PIIを組織 外に送信する場合は細心の注意を払う必要があります。

ソースコードと占有データ 

規制およびコンプライアンス情報に加え、アプリケーション のソースコードや組織内の保護されたデータなど、その他 の機密情報をログに保存することを避けたい場合がありま す。

ログを安全に保管することに加えて、ログへのアクセスも安 全に行うことが重要です。取引上の秘密や、未公表または未 発表のプロジェクトや機能を明らかにする可能性のある情 報は、ログの中に含めることはできません。特にサードパー ティのサービスにログを外部保存する場合は、ログからこう した情報を削除する必要があります。

情報の複製

複製した情報をログに追加しても問題はありません。また情 報は多いに越したことはありません。ただし、複製された情 報を含めると不必要なログが増え、目的は達成されずにコ ストがかさむことになりかねません。

結論

ログを利用してフルスタックオブザーバビリティを強化すると、ビジネスに インパクトを与えるリアルタイムの意志決定が下せるようになり、開発者や エンジニアのデバッグやインシデント対応時間が短縮され、その時間を有 効活用できます。

このようなベストプラクティスを導入すると、顧客向けの業務を円滑に進め るための必要情報をログから得られ、スタック全体の視覚化が改善され、 問題を速やかに解決し、開発スピードを上げることができます。

New Relicオブザーバビリティ プラットフォーム

New Relicは、詳細なログを含むすべてのテレメトリデー タのための単一の統一されたプラットフォームを提供しま す。New Relicのオブザーバビリティプラットフォームに は、ログ管理、APM、インフラストラクチャーの監視、サー バーレスモニタリング、モバイルモニタリング、ブラウザの監 視、合成モニタリング、分散トレース、Kubernetesモニタリ ングなどが組み込まれています。これらの機能により、組織 はソフトウェアスタック全体を視覚化、分析、トラブルシュー ティングを行うことができます。このプラットフォームの一部 であるNew Relicログ管理を使用すると、組織はロギングデ ータとアプリケーションおよびインフラストラクチャーのモ ニタリングデータを組み合わせることができ、強力なオール インワンの観測可能なプラットフォームが実現されます。

New Relicは、AIOps(IT運用のための人工知能)と統合さ れたソフトウェアスタック全体の指標、イベント、ログ、トレー スをつなぎ合わせます。これにより、組織はより迅速にログ を検索でき、異なるレガシーソリューションを使用するより も手頃な価格で利用できます。開発者とエンジニアは、スタ ックの異なる部分に別々のツールを使用する代わりにNew Relicを使用することで、特定のエラーに関する詳細なログ を全て容易に把握することができます。

レガシーなログ記録ソリューションでは、スピードとスケー ラビリティに問題があり、遅延データの実行に数分、または 数時間もかかるため、詳細なログへのクエリが厄介になりま す。これに対して、New Relicのログ管理検索はわずか数秒 しかかかりません。したがって、ソフトウェアのフルスタック におけるインシデントの調査と対応が可能な限り速く行うこ とができます。

New Relicのオブザーバビリティプラットフォームには、ログ 管理、データ量の少ない顧客のための無料ティア、チームが 必要な詳細なログをすべて取り込むことができる、GBあた りの抑制された価格が含まれています。

参考資料

European Commission. n.d. “EU data protection rules.” European Commission. Accessed July 19, 2022. https://ec.europa.eu/info/law/law-topic/data-protection/eu-data-protection-rules_en.

New Relic, Inc. n.d. “Parsing log data.” New Relic Documentation. Accessed July 28, 2022. https://docs.newrelic.com/docs/logs/ui-data/parsing/#custom-parsing.

OpenTelemetry. n.d. “OpenTelemetry Logging Overview.” OpenTelemetry. Accessed July 18, 2022. https://opentelemetry.io/docs/reference/specification/logs/overview/.

Open Web Application Security Project (OWASP). n.d. “OWASP Logging Guide.” https://owasp.org/www-pdf-archive/OWASP_Logging_Guide.pdf.

U.S. Department of Health and Human Services (HHS). n.d. “Summary of the HIPAA Security Rule.” HHS.gov. Accessed July 19, 2022. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html.