every Tech Blog

株式会社エブリーのTech Blogです。

Grafana LGTMスタックをローカルで検証してみた

Grafana LGTMスタックをローカルで検証してみた

はじめに

こんにちは!デリッシュキッチンで主にバックエンドの開発を担当している秋山です。

オブザーバビリティの向上に向けてGrafanaやその関連ツールを検証する一環で、Grafana LGTMスタックをローカルに構築し実際に触ったので、そのあたりを紹介します。

オブザーバビリティについて

本題に入る前にオブザーバビリティについて簡単に説明できればと思います。

オブザーバビリティとは、システムの内部で起きていることを外部から把握する能力のことです。 日々のパフォーマンス確認/改善やエラー発生時の調査などに役立ちます。 システムの複雑性が増す中で必要性が高まっています。

オブザーバビリティの主要シグナルとしてメトリクス、トレース、ログが存在します。

メトリクス

システムの健康状態を数値で表すデータです。

  • CPU使用率
  • メモリ使用量
  • レイテンシー
  • エラーレート

など

トレース

1つのリクエストに対する一連の処理を可視化するデータです。リクエストが通過するマイクロサービスやデータストアへのアクセスなど、処理の流れ全体を追跡できます。

ログ

システムやアプリケーションが出力する記録です。

  • アプリケーションログ
  • セキュリティログ
  • システムログ
  • 監査ログ

など

LGTMスタックとは

LGTMスタックは、Grafana Labsが提供するオブザーバビリティ(可観測性)を実現するための統合スタックです。以下の4つのコンポーネントの頭文字から名付けられています:

  • L (Loki): ログを扱うツール
  • G (Grafana): メトリクス、ログ、トレースを統合的に可視化するダッシュボード
  • T (Tempo): 分散トレースを扱うツール
  • M (Mimir+Prometheus): メトリクスを扱うツール

これら4つを組み合わせることで、オブザーバビリティの主要シグナルであるメトリクス・トレース・ログを統合的に扱うことができます。

https://grafana.com/docs/opentelemetry/docker-lgtm/ より

今回は、これらのツールをローカル環境で構築し、実際にどのように連携するのかを検証してみました。

Opentelemtryとは

検証ではdocker-otel-lgtmを使用するのですが、その中でOpenTelemetry Collectorを使用しているため、Opentelemtryについて先んじて簡単に説明させていただきます。

Opentelemtryとは、アプリケーションからメトリクス・ログ・トレースといったテレメトリー(観測)データを統一的に収集・送信するためのOSSです。

アプリケーションを言語、インフラ、ランタイム環境に関係なく簡単に計装できることを目的としています。

ベンダーに依存することなくテレメトリーデータを扱えるメリットがあります。データの送信先としてOTLP(OpenTelemetry Protocol)対応しているツールであれば連携が可能です

上で紹介した図中のOpenTelemetry collectorはアプリケーションからテレメトリーデータを受け取り、各ツールに送信する役割を担っています。

ローカル検証

docker-otel-lgtmを使って検証しました。

docker-otel-lgtmはLGTMスタック+OpenTelemetry collectorを1つのdockerにまとめてくれている公式のプロジェクトです。 そのため、このdocker imageを使って起動するだけで即座にLGTM+OpenTelemetry collectorの環境を用意し、各ツールの機能検証を簡単に開始することができます。

1 . LGTM+OpenTelemetry collectorを起動する

起動はとてもシンプルで、下記のコマンドを実行するだけです。

# Unix/Linuxの場合
./run-lgtm.sh

2 . 起動したOtel collectorに向けて観測データを送信する

docker-otel-lgtmが起動すると、OpenTelemetry Collectorがポート4317(gRPC)と4318(HTTP)でリクエストを受け付けます。 そのため、アプリケーションからのデータ送信はgRPCかHTTPのどちらかの通信方法を選択できますが、今回の検証ではHTTPを使っています。

exampleのサーバーを使ってテレメトリデータを送信する場合

Grafana全体の使用感をサクッと知りたい時は既に用意されたexampleのサーバーを使うことができます。

Go,Java,Pythonなどを使ったexampleがあったので、今回はGoで試してみました。

cd examples/go
# 起動
./run.sh

サイコロを振るアプリケーションサーバーが起動します。 goの場合は8081ポートに立つので、curl http://127.0.0.1:8081/rolldiceのようにリクエストすれば、サイコロの数字が返ってきます。

リクエスト後、Grafana( http://127.0.0.1:3000 )にアクセスすると送られてきたテレメトリデータを使った情報を閲覧することができます。

デフォルトでは下記のようなダッシュボードがいくつか用意されていました。

ダッシュボード

また、ExploreページからTempoを使ったトレースデータの確認などもできました。

Exploreページ

自前のアプリケーションサーバーを使って観測データを送信する場合

自分が普段触っているサーバーで検証したい事もあると思います。

その場合も、起動したOtel Collectorに向けてデータを送信するだけです。

既にOpenTelemetryを使用して計装を行っている場合は、 送信先をローカルで起動したOtel Collector(httpであれば http://localhost::4318 )に変更するだけで済みます。

未計装の場合、まずは公式の記事を参考に計装を進めていただければと思います。

Goの場合は下記の記事が参考になりますが、試してみたところ案外すんなり計装できました。

opentelemetry.io

下記は実際に開発しているアプリケーションのトレースをしてみた画面です。

実際のトレース画面

他マイクロサービスやDBへのアクセスも含めたトレースを確認できました。

所感

検証の環境について

簡単に検証するためのプロジェクトを公式が用意してくれているのは非常に助かりました。

Grafana LGTMスタックについて

今回使用したdocker-otel-lgtmは検証用の環境を作るものなので簡単に構築できましたが、実運用では可用性やセキュリティ面などを考慮したサーバー構成やツールの設定が必要です。 トレース・メトリクス・ログを統合的に扱うために複数のツールを導入する必要があることを踏まえると、全部自前で用意する場合運用の難しさがありそうだなと思いました。

また、ツールごとの使用方法も理解する必要があるため学習コストが気になりましたが、AIを使うことによって一定の負荷は軽減できそうでした。

下記はAIに作ってもらったダッシュボードの画像です。 ダッシュボードの内容をJSONとして定義できるため、AIの活用が簡単にできます。

ダッシュボード

参考文献

関連記事

tech.every.tv