[OpenTelemetry 検証3] Grafana × Loki を使用してログを見てみる
はじめに
[OpenTelemetry検証2] Grafana × Alloy × Tempo を使用してテレメトリデータを収集しトレース情報を見てみる の続きです。
内容
早速見ていきます。
前回に続き、次は Loki に保存したログを見ていきます。
最初は以下のような表示になっているかと思います。ここから、指定したログを検索してみたいと思います。
これは好みですが、私は「Builder」形式よりも Code 形式 (LogQL) で探索する方を好むため、以下のように検索したいと思います。
検索対象のラベル名=検索文字列 のような形式で query 入力フォームに入力します。
※今回は {service="article-server"} で検索します
この状態でクエリを実行すると以下のように合致したログが一覧として出力されます。
より詳細を確認してみたいので、試しにいくつかログを選択してみます。まずは INFO ログから。
詳細な内容を確認でき、さらに前回見た trace などの情報もここから辿ることができます。
※ 「リンク」という項目の View Trace から遷移できます
次にERROR ログも見てみます。アプリケーション側で発生したエラーが構造化された状態でログとして出力されていることがわかります。
また、こちらも同じように View Trace から Trace に遷移できます。
Tips
障害時などである程度どのログが原因かどうかまでわかってくると、だいたい trace_id なんかを控えておいて、それをチーム内で共有したりします。
エラーが発生した trace_id: bdf59bd63b9024c1571ab5c663055f24
また、本番のシステムの場合、AWS であれば S3 などにログを保存することが多いかと思うのですが、ライフサイクルルールなどを用いて自動的に階層を移動させたりします。
※例: 最初は S3 (Standard) に保存しつつ、14日経過したら S3 (Standard-IA) に移行
Trace から Log へのアクセス
今は Log -> Trace にアクセスしてみましたが、逆のパターン（Trace -> Log）可能です。
先ほどの Trace から、 最上位の span である http-server のセクションで、 Logs for this span を選択すると、画面右側にログの詳細が出力されます。
ほか、Tips として、この状態で「クエリ検査」を実行することで、任意の出力形式に変換できます。※csvダウンロードも可能です
この構成にしておくことのメリット
Trace は基本的には、「どの処理に何秒かかったのか」、「どこでエラーが発生したのか」などを特定する際に利用します。
一方 Log は例えばエラーが発生した際に、「どのようなメッセージが出たのか」、「どんなデータが渡ったのか」などの何が起きたのかを特定する際に使用します。
つまり、どちらか一方だけでは不完全であり、trace_id などを用いて相互で探索できる状態にしておくことで、問題の切り分けがしやすくなったりします。
また、複数のツールを行き来することなく、1つの画面内で原因調査まで行えるようになると運用的にはかなり楽であり、これが OpenTelemetry + Grafana スタックを利用する上での利点なのかなと思っていたりします。
おわりに
今回は Grafana と Loki を使用して Log 周りについて見ていきました。
また、Loki 単体だけでなく、Tempo と組み合わせた双方向遷移なども確認していきました。
次回は Prometheus UI を使用して、メトリクス周りを見ていきたいと思います。