現在 Mackerel では、ラベル付きメトリックに対応するための開発を進めています。ラベル付きメトリックは、OpenTelemetry の仕様に準拠した Mackerel の新しい機能の名称であり、クエリを引く際には PromQL を使用できるといった特徴があります。
本日、この「ラベル付きメトリック機能」ベータ版テストの参加募集を開始します。詳細については後述いたしますので、まずはこの機能の背景についてご一読いただければと思います。
OpenTelemetry とは、メトリック・ログ・トレースなどのテレメトリーデータを収集し、任意のバックエンドへエクスポートすることを目指して標準規格を定めたオープンソースのプロジェクトです。詳しくは OpenTelemetry のドキュメントをご覧ください。
ホストやサービスのメトリックを収集するために、Mackerel では現在、ホストに mackerel-agent をインストールする方法と、クラウドインテグレーションを利用する方法の 2 種類を用意しています。特に、クラウドインテグレーションによる手法は複雑なインストール手順を必要とせず、簡単にクラウドのマネージドサービスのメトリックを収集できるため、多くのユーザーさまに愛用されています。
これらの従来の手法と比較して、ラベル付きメトリックは、どのような点で優れているのでしょうか。この記事ではラベル付きメトリックの特徴と利点を紹介するとともに、Mackerel では今後どのようにラベル付きメトリックを扱うことになるかについて説明します。
なぜラベル付きメトリックが必要なのか
現状の mackerel-agent で取得しているようなホストメトリックをそのままラベル付きメトリックに乗り換えるだけでは、同じデータを取得するだけなので、あまり意味がありません。
それでは、ラベル付きメトリックの価値とは何であり、どのような利用方法であればそれが発揮されるのでしょうか。私たちは Mackerel においてラベル付きメトリックを使用することで、以下のようなメリットが得られると考えています。
- OpenTelemetry の標準規格に基いた多くのツールやコンテナからメトリックを収集できる
- メタ情報をもとに多次元的にメトリックを探索できる
- PromQL のクエリが使える
OpenTelemetry の標準規格に基いた多くのツールやコンテナからメトリックを収集できる
ラベル付きメトリックは OpenTelemetry の標準規格に則っているため、Mackerel に依存しない形でメトリックの収集を実装できます。OpenTelemetry では、OpenTelemetry コレクターに一度情報を集約し（Receivers）、その後コレクターからバックエンドにデータを送信する（Exporters）という仕組みが使われています。
この仕組みに則っている場合、Mackerel にテレメトリーデータを送信するのはとても簡単です。すでに Prometheus や Jaeger を利用している場合には、エクスポータとして Mackerel 向けの設定を 1 つ追加するだけで、Mackerel にデータを送信できます。
また、OpenTelemetry は現在非常に活発なプロジェクトであり、さまざまなサービス向けのプラグインも多く開発されています。プラグインを自作せずとも、OpenTelemetry の既存のエコシステムに乗ることで素早く監視を開始できるのは、大きなメリットと言えるでしょう。
そのほか、OpenTelemetry の標準規格に則ることで実現される例の 1 つとして、Kubernetes のようなコンテナオーケストレーションでのメトリックの収集が容易になるという点があげられます。
Mackerel ではサービス・ロール・ホストという 3 つの概念を持っています。「サービス」とは監視対象となるシステムやサービスを構成している 1 つ以上のホスト群をグルーピングするための単位、「ロール」とは「サービス」に属する 1 つ以上のホスト群をさらに細かくグルーピングするための単位です。この考え方は、ホストメトリックの収集においては非常に有効です。しかし、Mackerel では Kubernetes の環境においてサービス・ロール・ホストをアドホックに変更できないという問題があります。Kubernetes では以下の分類が曖昧なため、Mackerel では事前に決めておかなければなりません。
- ホストは Pod か Container か？
- ロールは Service か Deployment か？
- サービスは Namespace か Service か？
また、現状の Mackerel では Control Plane を監視する機能を提供していないという課題もありました。
業界標準の OpenTelemetry に対応することで、Mackerel でもマイクロサービスのような現代のシステムに対応できるようになります。
例えば Kubernetes に対しては、 OpenTelemetry Operator というライブラリをクラスターにインストールすることで、自動で計装を開始できます。
メタ情報をもとに多次元的にメトリックを探索できる
1 分単位で集計されたアクセス数を取得する access_num というメトリックがあるとします。たいていの場合、単にアクセス数を取得するだけでは不十分です。例えば HTTP ステータスコード別にアクセス数を取得したい欲求があるのではないでしょうか？
現状の Mackerel のメトリックでは、 access_num.2xx_count, access_num.3xx_count, ……のように HTTP ステータスコードもメトリック名に含めることで分類しています。
このようにメトリックに対してさらに補足情報（メタデータ）を含めて分類・集計したい、という欲求が出てくるのは当然でしょう。ステータスコードに限った分類をしたいだけならば、現状のようにメトリック名に含める運用でも十分です。しかし、ここからさらに別の軸で集計を行いたくなった場合はどうでしょうか？
例えば「ホスト名ごと」「AZ ごと」「ログインしているユーザーか否か」といった分類がさらに必要となるかもしれません。このような探索的な集計を行いたい状況に対して、「メトリック名」という次元しか持たないのでは、実現は困難です。例えば access_num.*.*.*.2xx_count のようなグラフは現在の Mackerel では実現できませんし、メトリック数が掛け算式に増えて制御不能になってしまいます。
「ホスト名ごと」「AZ ごと」「ログインしているユーザーか否か」のように探索的な集計ができる状態、つまりシステムの現在の状態を出力から推定できる特性のことを「Observability（可観測性）」と言います。ラベル付きメトリックを使用すれば、以下のようにメタデータをラベルとして持たせることができます。
※ここで「ラベル」という用語を使用していますが、OpenTelemetry の仕様では「属性（Attribute）」と呼んでいます。
access_num{status="200", role="proxyprod", host="proxy06"} 7832 2023-08-05 10:08:00
access_num{status="404", role="proxyprod", host="proxy06"} 66 2023-08-05 10:08:00
access_num{status="200", role="proxyprod", host="proxy06"} 8117 2023-08-05 10:09:00
access_num{status="404", role="proxyprod", host="proxy06"} 74 2023-08-05 10:09:00
access_num{status="200", role="proxyprod", host="proxy06"} 8644 2023-08-05 10:10:00
そして、メトリックを参照するときに以下のようにクエリを書くことで、メタデータに基づく集計が可能になります。
# ステータスコードが 200 のアクセス数かつ、ホスト名が proxy06 のアクセス数
access_num{status="200", host="proxy06"}
PromQL のクエリが使える
Prometheus で使われており OpenTelemetry メトリックを探索する際のほぼ標準となっているクエリ言語「PromQL」をサポートしています。
これまで Mackerel でカスタマイズしたグラフを表示するには、式グラフを使うのが一般的でした。式グラフでは、メトリックの値を加工したり、複数のメトリックを組み合わせたりできます。しかし、他のツールとの互換性がなく、Mackerel の独自の式についての習熟が必要でした。
グラフを描画するクエリを PromQL で記述できることで、すでに PromQL に慣れ親しんでいるユーザーにとっては、少ない学習コストで Mackerel での監視を開始できます。また PromQL は多くのユーザーに使われており、インターネット上に多くの情報があるので、クエリの書き方に詰まった場合でも問題を解決するのは容易でしょう。
まとめ
ここまでラベル付きメトリックの特徴、メリット、そして Mackerel との関係について説明してきました。ラベル付きメトリックは、ベンダーに依存しない標準規格である、メタデータにより Observability をより高められる、今までの Mackerel ではメトリックの収集が難しかった Kubernetes などのコンテナオーケストレーションでのメトリックの収集が容易になるという点が大きなメリットと言えるでしょう。
ただし、何も用意のない状態からラベル付きメトリックを収集してグラフを表示するまでの過程は、従来の mackerel-agent をホストにインストールする方法や、各種クラウドインテグレーションと比較すると、少々複雑なように感じるかもしれません。Mackerel では「手軽に監視を導入できる」という点を何よりも大切にしておりますので、この点は改善を進めていく予定です。
次回の記事では、実際に OpenTelemetry のラベル付きメトリックを Mackerel で収集する方法についてチュートリアル形式でご紹介します。
「ラベル付きメトリック機能」ベータ版テスト参加募集開始のお知らせ
ここまで Mackerel に新しく加わる予定のラベル付きメトリック機能についてご紹介してきましたが、このベータ版テストの参加募集を開始いたします！
下記のフォームに進み、内容にご同意いただけましたらベータ版テストへぜひご参加ください。
