こんにちは。Mackerelチームでサブディレクターを務め、プロダクトマネジメントを担当している 
id:RyuGoo です。
MackerelはOpenTelemetry形式のメトリックやトレースを取り扱うことができます。さらにオブザーバビリティを強化すべく、これらに加えてログを扱える新機能の開発を、2026年夏〜秋頃の公開を目指して現在進めています。
この記事では現在開発中の「Mackerelログ機能」について、その背景にある思いをお伝えしたいと思います。
どのような人のためのログ機能なのか
ひとくちに「ログ」といっても、その種類はさまざまです。監査やセキュリティのために長期間・完全な形で保存しておきたいものもあれば、システムやアプリケーションで発生したイベントをテキストとして記録したいものもあります。
これまでもMackerelへのログ対応を求める声は多数いただいていました。ログに対する多様なリクエストをいただく中で、どのニーズから応えていくべきかを決めるのに時間がかかっていました。
そこで立ち返ったのが、オブザーバビリティの考え方です。問題がなぜ発生したのかを、システムの出力から推定できるようにする。そのための力をMackerelを通して届けたいという思いが、今回のログ機能の方針を定める軸となりました。
チームのためのログ
システムで発生した問題を特定したい場面といえば、障害対応です。私たちはまず、障害対応においてログがどのように使われているのか、そしてチームがどのような課題を抱えているのかを、社内外のインフラエンジニアやソフトウェアエンジニアにインタビューすることから始めました。
調査の結果、見えてきたのは次の3点です。
- 問題が発生したとき、まずログを見て「何が起きているのか」の当たりをつける人が多い
- 一方で、どこにどんなログがあるのかを把握すること自体が難しく、人によって知識が偏ってしまう
- その結果、ログを使った障害対応がチーム内で属人化してしまう
これらを見て思い出したのが、Mackerelの特徴のひとつである「育てる監視」という考え方です。チームで使いやすく、わかりやすいログ機能をMackerelらしい形で体験を提供できれば、障害対応の課題を改善できるのではないか。そのように考えました。
チームで使える、チームで再現できる
インタビューを通じてわかったことは、「とりあえずログを見る」という行為がアプリケーション・インフラを問わず、障害対応でエンジニアがまず取る行動のひとつになっているという事実です。一方で、「どこを見ればいいのか」「何を見ればいいのか」という肝心の情報が整理されていなかったり、特定のメンバーに偏っていたりして、組織全体での活用が進まないケースが多いことも明らかになりました。
特に、ログの活用が特定のメンバーに偏ってしまうことは大きな課題と言えます。熟練者が無意識のうちに持っている「どこを、どう見るか」という知識は、ドキュメント化されることなく暗黙知として留まりがちです。
その結果、同じ問題が起きても、対応できる人とできない人の差が縮まらないままになってしまいます。また、頼られる側の熟練者にとっても、障害対応のたびに対応を期待される状況は、負荷になります。知見が個人に集中している状態は、チームとして持続可能な運用体制とは言いにくいものです。
そこで、Mackerelではログを「チームで活用できる体験」として提供したいと考えています。そのためのコンセプトとして設定したのが、「熟練者の操作を、チームで再現できる」というものです。
具体的には、熟練者がログから必要な情報を得るために行っている検索やフィルタリングの操作を、チームで共有・再現できる仕組みを提供します。さらに、検索条件を共有するだけでなく、「どのような状況でその検索を使うのか」という文脈もあわせて残せるようにします。これにより、システムにまだ詳しくないメンバーが学びを深めていく手がかりにもなります。
Mackerelログ機能が目指すのは、単に不慣れな人でも使いやすいツールではありません。熟練者の知見をチーム全体で再現・蓄積できる仕組みを通じて、組織としてログを活用できる状態をつくることです。
最初に提供しようと考えている体験と機能
障害対応の現場では、アラートを検知してから原因を特定するまでの間に、複数のツールやログファイルを行き来する場面が多くあります。Mackerelログ機能では、この「検知から調査」の流れをできる限りMackerelの中でスムーズに進められる体験を目指しています。最初のリリースで提供する2つの体験もその考え方を起点に設計しつつ、チームで使えることを意識しています。
また、私たちはシステムのオブザーバビリティを高めるために、OpenTelemetryというオブザーバビリティの業界標準に準拠する形で、メトリックとトレースへの対応を行いました。ログについても同様に、OpenTelemetryで定められている形で対応します。
サービス単位でログが見える
例えば、cronの実行ログ、データベースのログ、アプリケーションのログのように、個別のコンポーネントごとにバラバラに見るのではなく、「サービス単位」でログを横断的に見られるようにしたいと考えています。cron・データベース・アプリケーションなど、ひとつの役割を担う一連のシステムをサービスとしてまとめることで、それぞれのログの場所を意識することなく、サービスという単位で状況を把握できるようになります。
これはMackerel APMが提供している体験とも自然につながります。Mackerel APMもサービス単位でトレース情報を扱う設計を採用しており、ログも同じ粒度で見られることで一貫した視点で行き来できるようになります。
障害対応の場面を例にとると、特定のサービスでアラートが発生したとき、そのサービスに紐づくログをすぐに参照できるというのは、状況把握のスピードに直結します。どのホストのどのパスにログがあるかを探し回る必要がなくなり「このサービスで何が起きているのか」という問いに、素直に向き合える状態をつくることができると考えています。
保存された過去のフィルタ条件を参考にして、フィルタできる
サービス単位でログを見られるようになったとしても、そのサービスにどんなログが出力されているのか、そして障害対応の際にどこを見れば効率よく問題を把握できるのかは、経験によって培われる知識です。その結果、熟練者とそうでないメンバーの間に差が生まれ、障害対応の負荷が熟練者に集中してしまいがちです。
この課題に対してMackerelログ機能が提供するのが、「熟練者の操作を再現できる」仕組みです。体験としてはシンプルで、検索条件をメモとあわせて保存しておき、オーガニゼーションのメンバーが一覧から選ぶだけで同じ検索条件をすぐに呼び出せるというものです。
これにより、熟練者は障害対応でよく使う検索条件を、背景や使いどころを添えて残しておくことができます。そして熟練者が不在の場面でも、チームのメンバーは保存された条件をもとにすぐログの探索に入ることができます。属人化しがちなログ活用の知見を、チームの共有資産として蓄積していく。それがMackerelログ機能の目指すところです。
これからの道のり
今回紹介した「サービス単位でログが見える」「保存された過去のフィルタ条件を参考にして、フィルタできる」という2つの体験だけでなく、ログをさらに活用した体験も見据えています。例えば、ログからアラートを生成したり、アラートが発生した時刻のログをすぐに参照できたり、Mackerel APMのトレース情報と行き来しながら問題の原因を絞り込んだりできるようになれば、障害対応の流れがより一貫したものになります。メトリックで異常を検知し、トレースで処理の流れを追い、ログで詳細を確認する。こうした一連の調査をMackerelの中で、チームの誰でも完結できる状態が、私たちの目指すオブザーバビリティの姿です。
また、より長期的な展望としてAIを活用したログ活用の体験も検討しています。大量のログの中から問題に関連する情報を絞り込んだり、エラーの原因として考えられる仮説を提示したりといった形で、AIがログ調査の入り口を助けてくれる体験です。
とりあえずログを見る、という行為の次に何をすべきかをAIが手がかりとして示してくれることで、熟練者でなくても調査の糸口を掴みやすくなります。検索条件の保存・再現という仕組みと組み合わせることで、問題の調査から解決までをチームで素早く対応できるようになるはずです。
ログ機能の提供としては、Mackerelは後発にあたります。しかし、機能数を闇雲に追いかけるのではなく、Mackerelらしさを大切にしながら、実際に使っていただける体験を丁寧につくっていきたいと考えています。
今年の夏から秋頃を目標に、鋭意開発を進めています。進捗はお伝えできるタイミングで随時発信していきますので、引き続きご期待ください。
【Mackerelに登録すると、最新情報をメールで受け取れます】
Mackerelでは、サービスに関する様々な情報をメールにてお届けしています。ログ機能に関する進捗状況も随時発信していきますので、Mackerelのアカウントをお持ちでない方は、ぜひこの機会にご登録をお願いいたします。
また、Mackerelの公式Xアカウント（@mackerelio_jp）でも、お手軽に最新情報をチェックできます。こちらもどうぞご活用ください。
