はじめに
こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。
オブザーバビリティで主要なシグナルとされるメトリクス・ログ・トレースはそれぞれ異なる特徴を持ったテレメトリーシグナル(監視データ)です。それぞれの目的・データ形式・運用上の課題・データ特性を考慮して、オブザーバビリティを拡大することが重要です。
今回はその中でも「ログの保管と転送」に焦点を当てて解説します。
解説ではオブザーバビリティの共通認識としてまとめられている CNCF Tag Observability の『Observability Whitepaper』、標準化の例として OpenTelemetry/FluentD・製品ベンダーの例として Datadog の公式ドキュメントを参考に解説を行います。
考慮事項
本投稿では以下の用途で表現を使い分けます。
- 監視情報: 後述のテレメトリーシグナルとそれから得られた分析情報などを含む、監視に関わる全てのデータ
- テレメトリーシグナル: 文脈上はシステム監視データと同義、人間や機械が知識を推測できるシステムの出力
- ログ: OS・アプリケーション・サーバー・デバイス内の使用パターン・アクティビティ・操作を説明する1つ以上の
text,json形式のエントリ - 構造化ログ: 主に
json形式で KeyValue で構造化されたログ
ログの特徴
「ログ」は広義には監視データ全体を指す場合もあります。ですが通常はテレメトリーシグナルの一つとして、何かしらの動作を記録するエントリーです。
ログは大きく text 形式で記録するテキストログと、json, xml形式で記録する構造化ログに分けられます。どちらもローカルファイルに出力し記録することが多く、.txt, .log ファイルとして保存されます。
ログは記録する内容に応じて、アプリケーションログ・セキュリティログ・システムログ・監査ログ・インフラストラクチャログなどの分類がされますが、これらのログとログの形式に直接的な関係はありません。
ログは様々な事象の発生を記録する場面で活用できます。例えば、メトリクスやトレースを取得する際もそれらが正しく出力されているかを確認するためにログは欠かせません。こうしたアプリケーションやシステムのすべてのイベントや操作を記録すると、特定の状況に至る経緯と履歴を確認し、再現性のあるアプリケーションやシステムが構築できます。
このような特性から、ログは障害発生時の状況把握やポストモーテム時の根本原因分析に非常に重要なテレメトリーシグナルとなります。
一方で従来のログ情報は自由形式のテキストが多く、その構造を知らないまま正しく意味を把握することは難しいです。ログには特定のスキーマを適用することが困難である一方で、その試みは行われてきました。Apache の Common Log Format や W3C の Extended Log Format はこうした標準化の一例です。
一方で、共通の要素を含めるプラクティスはある程度標準化されています。こうした経緯からも、ログレベル・重大度によってログ自体の重大度を表すことが広く定義されています。
| ログレベル | Syslog | Fluentd | Log4j | PSR-3 |
|---|---|---|---|---|
| Emergency | EMERGENCY | |||
| Alert | ALERT | |||
| Critical | fatal | FATAL | CRITICAL | |
| ERROR | Error | error | ERROR | ERROR |
| WARNING | Warning | warn | WARN | WARN |
| Notice | NOTICE | |||
| INFO | Informational | info | INFO | INFO |
| DEBUG | Debug | debug | DEBUG | DEBUG |
| trace | TRACE |
表のように、大きく2つの分け方があります。この違いは RFC 5424 を参照した Severity(重大度) に準拠しているか、慣習的に必要なトレースレベルを加えたログレベルを定めているかとなります。
こうした違いはありながらも、ログレベルに応じてログ自体の重要度を識別し、それらによって運用や対応を変更することが一般的です。
ログの保管と転送
ログは純粋なテキストデータを扱うため、エントリに対して最も情報量が多いテレメトリーシグナルです。そのため、当然データ量も大きくなります。オブザーバビリティの観点では調査の効率化のために、こうしたログをローカルストレージから一箇所に集約するアプローチが必要となります。
多数のサーバー上に保管されるはずだったログが集約されることで、大容量の保管ストレージが必要となります。すべてのログを一様に保管すると、保管コストに大きな影響を与えてしまいます。そのため、ログの種別や内容に合わせて保管期間と保管方法を適切に選択することが大切です。
Error 以上のログレベル・重大度を持つログの場合は即時通知と分析が必要かもしれません。分析を行う際は、前後のイベントや操作を把握する必要があるため、Info ログであっても数日間は分析可能な状態で保管されていることが望ましいでしょう。
一方で1ヶ月以上前のログは、特定のインシデントや調査時には必要となる可能性がありますが、常に分析可能な状態にしておく必要はありません。監査ログなど長期保管が必要とされるログは、確認されるタイミングが決まっていることも多く、長期的にコスト効率高く保管する方法が必要となります。
プラクティス
ログの保管コストが増加しすぎないためにも、いくつかの保管・転送方法を念頭にログを取り扱うことが推奨されます。コスト効率高くログを取り扱うために、ログの保管方法と外部転送についての考慮事項を検討しましょう。
異状検知・調査用途の保管
ログを常に検索可能なプラットフォームに保管し、頻繁にクエリし以上を検知したり調査を行う用途での保管方法です。これは Error のように重大度の高いログとその前後のログを、数日~数週間の短期間保持するのに適切な選択肢です。
特にオブザーバビリティプラットフォームのような豊富な機能とコンソールが提供されるサービスでは、データ量に応じて多大なコストが加算されるためこれらを限定することがコスト最適化の観点では重要となります。そのため、同一のデータソースであっても柔軟にログの内容や重大度に応じて柔軟に保管期間を選択できることが望ましいです。
オブザーバビリティプラットフォームではログの保管に複数のオプションを提供していることがほとんどです。Datadog の場合、Logging witout Limits™︎ によりログの内容・重大度
・送信元から柔軟に保管日数を設定し、コスト効率高くログを扱えます。
分析時に即時参照するための保管
日頃から分析に利用するとは限りませんが、必要な場合には長期間のログを分析用途で参照することも考えられます。こうしたログはネットワークログ・アクセスログ・セキュリティログなど、比較的大量のログを生成する一方で分析時には数ヶ月分のログを取り扱える必要があります。
そのため、検索可能な状態でありながら大量のログをコスト効率高く扱える選択肢が必要となります。従来のプラットフォームの場合、Syslog サーバーなど大量のログを専用サーバーに保管し分析時にはサーバー内で分析を行うことが一般的でした。
クラウドの利用が一般的になると、クラウドの特性を活かしたマネージドサービスにより、保管時のストレージコストと分析時のコンピューティグコストを分離して課金する方式が登場しました。これらのサービスにより、Syslog サーバーのように物理的な性能の上限値がある状況から、必要に応じて大容量のログ分析を素早くコスト効率高くできる選択肢が生まれました。
こうしたログ分析に最適なサービスは、Google Cloud の BigQuery が代表的ですが、近年は他のクラウドプラットフォームやサードパーティーの DWH ソリューションも選択肢に上がります。Datadog の場合、Flex Logs 機能により、保管時のコストを最小限に抑え高パフォーマンスな分析用のコンピューティングを扱うことができます。
監査証跡としての長期保管
監査証跡として数年間のログ保管が必要な場合は、最もコスト効率の高い方法を選択する必要があります。必要となる際に可読性が担保されながらも、コスト効率高く保管するためにログの圧縮と分析プラットフォームからの転送が必要です。
クラウドプラットフォーム上のアーカイブストレージは、物理的なデバイスを所有するよりも安価に長期の間、耐久性も高くログを保管できるため最適な選択肢となります。保管時には圧縮により容量を削減できることも重要です。
Datadog の場合、ログのアーカイブによりクラウドプラットフォームのオブジェクトストレージ・アーカイブストレージにログを成形後に圧縮し転送できます。
おわりに
情報量とともにデータ量も多くなってしまうログは、全てのデータを同じように保管することができません。ログの内容や用途から適切な保管方法を選択し、柔軟にログを扱えることが重要です。
システムやアプリケーションは様々な箇所でログが記録されるように設計されています。ログの特性を理解して、必要なログを適切に見つけ出し、効果的な分析をができるようにしていきましょう🐶
参考文献
- CNCF Tag Observability 『Observability Whitepaper』
- OpenTelemetry『OpenTelemetry Logging』
- Fluentd『Logging』
- Datadog『Getting Started with Logs』『Log Collection and Integrations』