この記事は以下の「第一回：ログ分析基盤とAPMの違いとは？～目的・機能・製品を比較～」に続く記事になります。
第一回の記事では、可観測性（Observability）を支えるログ分析基盤とAPMについて比較を行いました。
第一回：ログ分析基盤とAPMの違いとは？～目的・機能・製品を比較～

第二回では第一回の記事の中で登場したMELTという言葉について、深堀りしていきます。

可観測性とは、メトリクス・イベント・ログ・トレース（MELT）の観点から、システム内部で何が起きているかを"外から"推論できる状態を指します。（第一回からの抜粋）

可観測性（Observability）の世界では、システム内部の状態を把握するために集めるデータを大きく4つに分類する考え方が一般的になっています。それが MELT です。

1. MELTとは何か？（概念と背景）

M: Metrics（メトリクス）
E: Events（イベント）
L: Logs（ログ）
T: Traces（トレース）

MELTは、単なる頭字語ではなく「どの情報をどのように扱うか」を整理するフレームワークです。これにより、運用チームは「何を集め」、「どの粒度で可視化し」、「どのデータから原因分析を始めるか」を計画的に考えられるようになります。

2. 自動販売機の例でMELTを理解する

「MELTが表すそれぞれの単語は聞いたことがあるけど、、どのような違いがあるのか分からない」という方は多いのではないでしょうか。
そんな時に日常生活で馴染みのあるものに紐づけると理解しやすくなります。最も一般的な例として挙げられるのが「自動販売機」です。

データ種別	どんなデータか	自動販売機でいうと、、
Metrics	「特定の期間」のデータの集計	・15:34:00～15:34:59まで合計2回の購入があり、合計で330円の売り上げでした
Events	「いつ何が起きたか」の記録	・15:34:10 コーヒーが購入された・15:34:40 コーラが購入された
Logs	「いつ何が起きたか」の詳細な記録	・ユーザがBボタンを押したユーザが9ボタンを押した・間違ったコードB9がユーザにより入力された・購入処理が不完全に失敗したため、待受け状態に戻る
Traces	異なるコンポーネントにおけるイベントの因果関係の記録	・自動販売機の処理 30秒・自動販売機のバックエンド処理 5秒・クレジットカードの処理 15秒・銀行の処理 10秒

MELTのそれぞれのデータが完全に独立しているわけではなく、EventsがMetricsの元になったり、LogsやTracesからEventsが抽出されたりするように、発生事象のとらえ方の違いになります。
このように、MELTはMetrics、Eventsの「異常の検知」から、Logs、Tracesを利用した「原因究明」までの道筋を整える役割を果たします。

3. MELTのIT運用での活用

自動販売機の例でMELTのイメージをつかめたところで、実際のIT運用に当てはめた場合にどのように活用されているかを整理します。

データ種別	特徴	具体例
Metrics	主に時系列の推移を記録した数値データ	・サーバCPU使用率・Webサイトへのアクセス数
Events	障害アラート、起動停止やTakeOverなどの操作を記録したデータ	・VMの起動/停止・Windows Eventlog
Logs	ソフトウェアの動作を記録したデータ	・ロードバランサーやWebサーバーのアクセスログ・Javaアプリケーションがlogger経由で出力するログ
Traces	主に問題判別のためにソフトウェアの詳細な動作を記録したデータ	・Ruby stack trace (スタック・トレース) ・Datadog java trace (分散トレース)

現在は単体のサーバやアプリケーションが出力するLogsだけでは不十分になりつつあります。特にクラウドネイティブ環境では、マイクロサービスの複雑化やサーバレスの普及に伴い、時間の幅を持つMetricsや複数コンポーネントにまたがるTracesの重要性が高まっています。

4. 分散トレーシングとサービス検出の技術要素

重要性が高まっているTracesを活用するための基盤技術として、分散トレーシングとサービス検出があります。
クラウドネイティブなマイクロサービス環境では、1つのユーザーリクエストが複数のサービスをまたいで処理されるため、問題の特定が難しくなります。ここで役立つのが分散トレーシングとサービス検出です。

分散トレーシングとは

分散トレーシングは、アプリケーションで1つのユーザーリクエストがバックエンドサービスやデータベースで処理されるまでの一連のライフサイクルをエンドツーエンドで追跡する仕組みです。
各サービス呼び出しに共通の「Trace ID」や「Span ID」を付与することで、複数のサービスやコンテナ、関数を横断して処理の流れを再構築できます。
分散トレーシングにより、次のようなことが可能になります：

どのサービスで遅延が発生しているか特定する
失敗しているAPIコールやDBクエリを突き止める
SLA/SLOを満たしているか可視化する
分散トレーシングを含む可観測性の標準としてOpenTelemetryがあります。
参考：OpenTelemetryとは

分散トレーシングのイメージ

サービス検出とは

サービス検出は、Webアプリケーションやミドルウェア間の通信をキャプチャして、サービスとサービス間の依存関係を検出・自動更新する機能です。
マイクロサービスやサーバレスでは頻繁にコンテナやインスタンスの入替が発生するため、サービス検出機能は、運用負荷を減らす観点で有用です。
サービス検出によって、次のような運用が可能になります：

動的に変わるマイクロサービスのエンドポイントを自動認識
新しいインスタンスやコンテナが起動したら即座に監視対象へ追加
トレースやメトリクスと紐づけて、システム全体のトポロジーを可視化
例としてDatadogではeBPF技術を利用しています。

サービス検出のイメージ

5. まとめと次回予告

MELTは、単なるデータ分類ではなく、複雑化するクラウドネイティブ環境において、「どの情報からどの順番で問題を切り分けるか」を整理するフレームワークです。

Metrics → まず異常を検知
Events → 何がトリガーになったか把握
Logs → 詳細な事象を調べる
Traces → サービス間の流れを解析

次回は、APM活用事例からを取り上げ、MELTの活用がどのようにアプリ品質や開発者体験の向上につながるかを具体的に見ていきます。

関連記事

第一回：ログ分析基盤とAPMの違いとは？～目的・機能・製品を比較～
第三回：APM活用事例で見るアプリ品質向上と開発者支援
第四回：ログ分析基盤の実践活用～可観測性・セキュリティ・ビジネス分析～