こんにちは！Mackerel CREチームの 
id:yohfee です。12月1日から始まったMackerel Advent Calendar 2025、たくさんの方にご参加いただき、無事完走しました！記事をご投稿いただいた皆さま、読んでくださった皆さま、ありがとうございました！
今年もMackerelチームのメンバーだけでなく、はてな社内で利用しているスタッフ、そして初参加を含むユーザーの皆さまからもご参加いただき、バラエティ豊かなエントリーに触れ、最後まで飽きることのない非常にエキサイティングな期間となりました。
本記事では、Mackerel CREチームによる Mackerel Advent Calendar 2025 の感想戦をお送りします。 まだ読んでない記事がもしあれば、これを機にお読みいただき、感想戦のひとことコメントと照らし合わせながらお楽しみください。
感想戦
12月1日 
id:kikuchi_et_al
カレンダー初日は、今年新たに Mackerel アンバサダーに就任いただいた菊池さんの記事です。国産サービスへの想いや Mackerel の魅力、アンバサダーとしての抱負を熱く語っていただきました！またイベントなどでご一緒させていただくことを楽しみにしています！（
id:KGA）
12月2日 
id:msksgm
1日目を受けて、msksgmさんからは『国産サービスで実践するオブザーバビリティ入門［第二弾］』の読書感想記事をお寄せいただきました！ 「国産サービスである、さくらのクラウドと Mackerel を応援したいため」というお声もありがたいです。(
id:kmuto)
12月3日 
id:arthur-1
カスタムダッシュボード機能、便利なのですがまずどこから着手したらいいのかわからず、とまどってしまうということもあるかと思います。そんな場面の解決手段として、3層構造Webサービスを想定した「カスタムダッシュボードおまかせ生成機能」は生まれましたが、その開発における要件定義とPoCの裏話が綴られています。(id:kmuto)
12月4日 id:KGA
今年はAPMをリリースしたこともあり、O11y関連イベント以外にもGoやJavaなど開発言語系のカンファレンスにも参加しました。各イベントのブースでは毎回、O11yやAPMをテーマにしたアンケートパネルを展示していましたが、各コミュニティでの関心の高さを実感しました。回答にはコミュニティごとの特性が表れていて、その違いが非常に興味深かったです。ぜひ記事内にリンクされているレポート記事もあわせて読んでみてください。（
id:missasan)
12月5日 id:missasan
実際に運用中のプロダクトの監視を検討しようとするとさまざまなニーズや制約があって考えるのが難しいこともありますが、本エントリのように個人の気になりをまずは進めていくことで、その中で得られた経験が監視設計に転用できそうで良いなぁ...って読んでいたら、最後に全くその通りのまとめが出てきました。なお、グラフ定義での差分値設定は、Mackerel上に投稿されている前回のメトリックとの差分を表示する機能です。（
id:do-su-0805)
12月6日 
id:momochi29
AI を使うことで現実的な課題をどれくらい解けるのかなーと妄想したりしていましたが、想像以上にちゃんと解けていてすごい！isucon-solver-log.mdは一見の価値ありです。Mackerel に足りない部分も明らかになってきたのでサービス改善にも活かせそうですね。（id:KGA）
12月7日 
id:ikeda-masashi
dbt - Qiita Advent Calendar 2025 - Qiita との連動記事として寄稿いただきました。testdata/olte.jsonl のようなログからトレースを実際に送信する例をご紹介いただいております。仮想的にモデル／テストをHTTP属性に寄せて、MackerelのAPM機能で見やすくする工夫についてもご紹介いただきました。（id:do-su-0805）
12月8日 id:kikuchi_et_al
Mackerelには日々多種多様なメトリックが投稿されていますが、この度kikulaboさんより、ついに「人間のメトリック」が届きました！『Mackerelを「生活の一部」レベルで使いたい』という嬉しいお言葉を体現した、自分自身のオブザーバビリティを可視化する面白い取り組みです。その後の暮らしや、アラートやグラフアノテーションを活用するような続編が読みたくて仕方ない！(id:yohfee)
12月9日 id:yohfee
シナリオを想定してあたかも本物のリクエストのようなダミーのトレースデータを作成し、「良い感じ」に見せようというチャレンジの記事です。代表的な機能を網羅しつつお客さまが自分事に置き換えてイメージしやすいデモは私もずっと悩んでいたので（拙作のAPMデモアプリケーション）、来年には宣言的管理ができる素敵なものを期待しちゃいますね！(id:kmuto)
12月10日 
id:sfujiwara
fujiwaraさんからご寄稿いただきました。既存のPrometheus資産を活かし、OpenTelemetry Collectorをハブとして、Mackerelへ移行する実践的なノウハウです。両者の「サービス」概念の差を考慮した的確なマッピングには、非常に納得感がありました。(id:yohfee)
12月11日 id:do-su-0805
do-su-dairyquestions.hatenablog.com
知る人ぞ知るな機能の代表格であるメタデータ機能。100KBの空間、80万の0と1の並びで君は何を表現するのか——今回はMackerel CREサポートチームのdo-su-0805さんがこのメタデータにOSのパッケージ情報を格納し、さらにカスタムダッシュボードにテーブルとして表示するところまで作り上げた例を示してくれました。皆さんもぜひメタデータの面白い使い方、考えてみませんか？(id:kmuto)
12月12日 
id:ne-sachirou
グラフの谷間を見て「これなんだっけ？」と過去のSlackやドキュメントを漁る時間は、よくあるトイルそのものです。「何が起きたか（Metrics）」だけでは読み取れない「なぜ起きたか（Events）」を可視化するために、グラフアノテーションで文脈を直接重ね合わせられるのもMackerelの強みですね。(id:yohfee)
12月13日 id:kmuto
Mackerel CREとして4年目を迎えたkmutoさんによる、2025年の良かった機能リリースの紹介記事です。こうして見ると今年もいろんな機能がリリースされたんだな〜としみじみ感じると同時に、kmutoさんが実装に関わった機能の多さに驚かされます。(
id:masarasi)
12月14日 
id:sogaoh
sogaohさんからご寄稿いただきました。進行中のプロジェクトには担当CREとしてMackerel APMの導入支援をさせていただいていますが、Lambdaまわりはいろいろややこしいものがありますね。APMの採用とその効果による開発陣への布教、外形監視やダッシュボードによるチームへの布教という2-sideの導入は理想的です。ビッグプロジェクトの成功、お祈りしています。(id:kmuto)
12月15日 
id:kazeburo
jsonl形式のログからメトリクスを出力できるmackerelio/mackerel-plugin-jsonを作ったお話をkazeburoさんからご寄稿いただきました。特定の用途に限らない、汎用的なプラグインのため様々な場面で活用できるプラグインです！ mackerelio/mackerel-plugin-json との使い分けや、パフォーマンスについても触れていただいているため、jsonl形式のログに見覚えがある方はぜひご一読ください！（id:do-su-0805）
12月16日 
id:cohalz
グラフに変化があった時に「あれ？これって何が原因だっけ？」という状況になりがちな方は必見です。Mackerelのグラフアノテーション機能の活用法にとどまらず、監視ルール名やサービス・ロール名を工夫して、アラートを管理しやすくするノウハウなども紹介されています。(id:masarasi)
12月17日 id:yohfee
11日目に私がご紹介したメタデータ機能とMCPサーバを利用して、ホストの1日を擬人化する（？）記事でした。この記事を見た瞬間感動してしまいました。コンテナが転生し続ける中、過去のコンテナたちの日記を読んでも似たようなことしか書かれておらず、なぜならフロントからConsistent hashで似たようなアクセスしか振り分けられず、そして外の世界を知っていく...みたいなストーリーをつい妄想してしまいました。まじめに考えると、コンテナ同士の日記から負荷傾向を検討させて、増強や縮退の判断とかができそうですよね。（id:do-su-0805）
12月18日 
id:rokoucha
Varnishを題材とした「コンテナ化での監視しづらさ」を、Exporterの同居とOpenTelemetryの活用で解決する実践的な内容です。あえて「1コンテナ・複数プロセス」を選択する割り切りは、インフラの複雑化を避けて運用の負荷を下げる現場感があっていいですね！(id:yohfee)
12月19日 id:masarasi
Mackerelのアラートは基本的に「現在異常がある」ことを伝えるため、自動で復旧してしまう設計が多数ですが、ログ監視のように「1件1件の以上については確認が必要である」ようなパターンに対するアプローチを紹介いただきました。
ラッパーとして作成して既存のオプションがそのまま使えるのも魅力的ですね。（id:do-su-0805）
12月20日 id:KGA
Mackerelのドキュメントは情報量は多いのですが、自分の知りたい情報がどのページに書いてあるのかがわかりづらいことがありますよね（苦笑）。チャットボットなら探さなくても聞けば答えてくれるのでとっても便利です。今はまだ生まれたてで、動かすためには少しお世話が必要な赤ん坊ですが、今後のサバオの成長に期待！（id:masarasi）
12月21日 id:kmuto
タイトルから興味を惹かれました！ルンバが充電されていないという日々の課題を、学びにつなげているのはさすがです。Mackerelはサーバー監視にとどまらない自由な使い方ができるんだぞ、ということが実感できますね。一家に1orgがあたりまえになる未来はそう遠くないかも?（id:masarasi）
12月22日 
id:inommm
しばらくKubernetesに触っていない間にIngress NGINXは廃止されていたんですね。OpenTelemetry Collectorも立てず、アプリケーションコードにも手を入れずに、K8sだけでリクエストのトレースが取れるのは便利に使える場面がありそうです。(id:yohfee)
12月23日 
id:kurikenta
エンジニア向け SaaS であり、OpenTelemetry というまだ歴史がそこまで長くない技術を採用している製品を売る立場のセールスメンバーとして、とても心強く頼もしいエントリでした。AI をうまく使い理解を深めている点も現代的です。（id:KGA）
12月24日 
id:lufiabb
OTel プロジェクトで定められている環境変数によって設定を注入できるという利点が CLI アプリケーションでも活きている（設定ファイルや引数を追加する必要がない）という点が面白いなと思いました。また、記事でも述べられているようにとっかかりとしてもいい題材ですね！（id:KGA）
まとめ
今年もたくさんのご参加、ありがとうございました！来年もMackerelブログでたくさんの情報を発信していきます！
来年もMackerelをどうぞよろしくお願いします。
もう「なんか遅い」で悩まない！開発者のためのAPM入門
アプリケーションを開発・運用していると、特定の処理が遅い、リクエストごとに応答時間がばらつくなど、「なんか遅い」と感じる場面があります。本資料では、こうした「なんか遅い」と感じる状況に対して、どこから調べればよいのか、何を手がかりにすればよいのかという観点から、APM（アプリケーションパフォーマンスモニタリング）が調査の進め方をどう変えるのかを解説します。
