こんにちは！ Mackerel CREチームでカスタマーサクセスマネージャー（CSM）をやっている
id:chizniiです。
先日、Mackerelが現在パブリックベータとして提供しているラベル付きメトリック（OpenTelemetry対応）を、2024年11月1日に正式リリースすることを発表いたしました。
これまでMackerelは「SaaS型サーバー監視サービス」というコンセプトでサービスを提供してまいりましたが、今後は「オブザーバビリティにチームで取り組むための監視サービス」へと進化していきたいと考えています。 今回のラベル付きメトリックの正式対応の発表は、「Mackerelはオブザーバビリティに取り組んでいくぞ！」というメッセージを込めた、新しい第一歩とも言えるものです。
新しいMackerelへ進化するために、現在Mackerelチームでは様々なプロジェクトが立ち上がっています。 今回はその中の一つである、ラベル付きメトリック（OpenTelemetry対応）をお客様により便利に使っていただくために結成された「探索プロジェクト」をリードしているMackerel SREテックリードの 
id:heleeen にインタビューを行いました。
探索プロジェクトについて
どんなプロジェクトですか？
現在Mackerelで対応している「ラベル付きメトリック」というOpenTelemetryの仕様に準拠した機能を、より便利に活用していただくための企画や開発を行うプロジェクトです。
いまMackerelの画面上でラベル付きメトリックを触ることができるのは、監視ルールの作成とダッシュボードのクエリグラフのウィジェットのみです。これらの機能を使おうとした場合、OpenTelemetryやPromQLに慣れていないと中々難しい部分が多いかと思います。
現段階でラベル付きメトリックでできることは以下のエントリをご参照ください。
これまでMackerelが対応していなかった機能なので、Mackerelをメインで使っていただいていたお客様にとって、馴染みがないと感じる方が多いであろうと認識しています。まずは、実際に触れていただくためのハードルを下げる、併せて便利に使っていただけるような企画や機能開発を進めるプロジェクトです。
プロジェクトが立ち上がった背景を教えて下さい
先ほどお話ししたように、これまで馴染みのない方にはOpenTelemetryやPromQLへのハードルがあると思うので、まずはラベル付きメトリックをお客様に実際に触れていただきたい、便利に使っていただきたい。具体的には今のMackerelのホストとかサービス・ロールのように、日常的にどんどん使っていただきたいという部分が大前提としてあります。
加えて、ラベル付きメトリック機能があるだけではまだオブザーバリティを高めるために十分な機能が備わったとは言えません。ラベル付きメトリックを活用する機能を作っていく事で、Mackerelでオブザーバビリティを高められるんだぞ、という変化をどんどん出していきたい、といった強い想いが今回のプロジェクトが立ち上がった根幹にあるのかなと思っています。
「探索」という名前の由来は？
Mackerelで収集したラベル付きメトリックを試行錯誤して使う、というイメージから生まれました。例えば「検索」「絞り込み」「ドリルダウン」みたいな操作を行って、色々な試行錯誤を経て必要な情報にたどり着く、という状態を端的に表現したいな、と考えていた時に「探索」という言葉が降ってきました。
あらかじめ決められたものを探すのではなく、無数に広がっているものの中からまずラベル付きメトリックを収集して、そこから自分たちが使うものを見つけていく、というイメージですね。短くて呼びやすく機能の中身ともマッチしているのでチーム内でも浸透していて、そのままプロジェクト名になりました。
何ができるようになるか、どういうユーザー体験が生まれるか
探索プロジェクトでどんな事ができるようになりますか？
ドリルダウンや絞り込みをして、Mackerelで収集したラベル付きメトリックでの調査や分析ができるようになります。例えば障害対応を行う際、どこに障害の原因があるのか？どこに影響が発生しているのか？を調べることができます。障害が発生する前後のメトリックを探して比較したり、その障害が他のコンポーネントへ影響を及ぼしていないかを確認できたりする、というイメージです。
他には、「最近ちょっとサービスのパフォーマンスが劣化気味だな」と感じた時の調査にも使えると思っています。対象のコンポーネントやアプリケーションのメトリックをざっと眺めて、最近変化のあったメトリックから原因を探るヒントを得られると考えています。
これができると、どんなユーザー体験が生まれますか？
これまでのMackerelだとホストやサービス・ロールが中心になっていたと思うんですが、今後はメトリックが主体になっていく、という点が大きな変化だと考えています。現在の世の中のアーキテクチャとしてマイクロサービスなどがよく使われるようになった事もあり、ホストという単位があまり重要視されない世界観になってきました。サービス自体やサービスの各要素を表すメトリックに価値が出てくるので、そのメトリックをより利用しやすくなる、という点が最も大きな体験になってくるのかな、と思っています。
探索プロジェクトを通して、苦労したところはありますか？
探索に限らない話にはなりますが、Mackerelでラベル付きメトリック機能を便利に使っていただくには何が一番いいんだろう...？と悩んでいる時が一番苦労しました。
これまでのMackerelに無かった概念なので、方向性を決めるまでの過程のところは日々苦悩していました。色々考える中で、ラベル付きメトリックを見るための入口がないよね、という話になって、まずは入口を作るところ、メトリックが重要なんだ、と気づいていただくための段階を用意したいよね、と方向性が固まっていくまでの部分が苦労したなと思います。
探索プロジェクトの今後
今後のロードマップや取り組んでいきたい事を教えて下さい
探索の機能として一番最小限の機能の実装はほぼほぼ終わっています。 今はデザインやパフォーマンスの調整など、社内ドックフーディングに向けたブラッシュアップを行っています。ここが一段落したら、ドッグフーディングで見つかった課題への対処と社外公開に向けた準備も併せてやっていきます。
今後取り組んでいきたい内容としては、ラベルを利用してより手軽に運用が行えるようにするために、リソース検出やラベル付きメトリック向けのダッシュボードのテンプレートも作っていきたいな、と考えています。
先ほどもお話ししましたが、ラベル付きメトリック機能だけではオブザーバビリティを高めるために十分な機能が備わっているとは思っていません。探索プロジェクトによってMackerelをもっと便利に使っていただくための入口はできたので、その先を整えていく事も重要だと考えています。そのためにもっと色々な機能を考えて取り組んでいきたいと考えています。
終わりに
「オブザーバビリティにチームで取り組むための監視サービス」への第一歩として取り組んでいる探索プロジェクトについてご紹介しました。ラベル付きメトリック後のMackerelの世界が少しでも垣間見れたでしょうか。
Mackerelでは機能開発と併せて、オブザーバビリティについてのイベントも開催予定です。
オブザーバビリティの重要性を改めて再確認するとともに、Mackerelと一緒に学んでいきましょう！
