2025

※年末なので振り返り自分語りエントリです、特に技術的に有益な情報などはありません。

似たような書き出しで前に書いたのがちょうど5年前で、これを振り返りつつ自分のために書いて参ります。

dasalog.hatenablog.jp

これみると我ながら同じことやってるな・・という気持ちと、お前それで5年後にSRE NEXTのチェアやって年末にはBrendanGreggが新橋でホッピー飲んでいる会に参加しているぞ、というとても自己完結した趣がありますね。

試しに以下大項目を揃えていってみる。

SRE NEXT

2020-2025でSRE NEXTは5回開催され、登壇4回、スタッフ2回でうち1回がCo-Chairとなりました。

2025の前半は完全にこのイベントにフォーカスして過ごしてきたので、さすがにやりきったなあ、という思いです。

このあたりは別途ブログを書いてるのでまあまあ蛇足というとこなんですが、Brendanさんのキーノートについて、やはりITの世界の歴史はまだ浅いし自分たちの考えるスーパーエンジニアも普通に活動していて、会って会話をすることができるのだ、というところですね。

コミュニティの力を使うことで達成できるというのも素晴らしいですし、なんとなく遠くの自分とは関係ない出来事みたいに捉えてしまうのは気持ちとしてはめちゃわかるがそれもなんだかもったいないことかもしれないよね、できることもありますよ、というのが提示できたという意味でもよかったんじゃないかなと思っています。

あと少し違う軸として、カンファレンスの規模をみても日本のSREコミュニティは世界的に見ても結構大きいんじゃないかと思っていて、このあたりの接続点がもう少し持てたらいいんじゃないかなあ、などとも思ったりしたところです。

(公開後追記)あとこれお金もそれなりにかかるし気軽に言う事ではないのだけど、SREconにエンジニアを参加させる日本のIT企業もう少しあってもいいんじゃないかなとも思ったりもしています、たとえばre:Inventにはかなり多くの日本の方が参加されてますし、予算がまったくないわけでもないよなあとか。(追記ここまで)

2026はスタッフとしては参加しませんし先のことはわかりませんが、SRE NEXTは5年を通して自身にとっても圧倒的に大事なコミュニテイとなったので、またいずれなんらかの形で関わりたいなあという思いはあります、まあでもいったん小休止です。

SRE NEXTではないけど今年最後にいつか行きたいと思ってたゆるSREにもなんとか参加できてこれもよかったですね、小規模なミートアップの密な感じはとても良い、なんらかジャンル問わず近場のなにかもいいかもなあ。

英語

2020年から色々やったが、なんやかやとレアジョブは継続していて本日時点のレッスン回数が1739回、レッスン時間は869.5時間となっている。どちらかというと維持するためにダラダラやっていて全然ストイックにはやっていないがトータル少しずつマシにはなってそうではある。

英語喋れる/喋れないみたいな二値に倒すときは自分は意図的にtrueで返していて、まあそれはいいのだけど、目指すべき状態に対しては明確に足りない(まあおもにListeningとかPhrasal Verbsみたいな言い回しのストックとか、根本的な語彙の不足とかそのあたり)というのはわかっており、レベル的にいうとCEFRでいえばだいたいB1の上かB2の下の方が現状でB2の上の方、C1はいらんやろ、くらいに思っている、けどそこの差分はまあまああるなーという感じ。

別に自分は字幕なしで映画がみたいわけでもなく、世間話もそんなにできなくてよくて、単に技術的なセッションやPodcastをストレスなく聞けてそれについて話せるとか、まあそういうジャンル特化なので引き続きやっていこうと思います。

しかしまあ会話がメインなので副産物として子育ての語彙とかは増えたなあ。あとフィリピン事情に少し詳しくなったのでいつか行きたい。

使い所としてはことしまあ所属先のおかげもあり、国際カンファレンスにもいくつか参加して(SREcon25 Americas、KubeCon + CloudNativeCon Japan 2025、Open Source Summit Japan)あともちろんSRE NEXT 2025とGrafana関連のイベントなどでまあまあ喋る機会があり、まあ良かったなと思うと同時にもうちょっとどうにかーという気分にもなり、という感じ、まあでも多少下手くそでもオープンな場でQAできるくらいのメンタル的な図太さができたのでそこはよかったでしょう。

自動翻訳の進化みたいな話もあるけど、特にSREConのディスカッショントラックなんかはそんなことしている余裕はまったくないので結局普通のテンポで普通に話ができるという価値はしばらくなくならないんじゃないかと思います、次の5年後、もう40後半に入ってしまうけどもうちょっとマシな状態がここに書けてるといいですね。

技術方面

2020年からめちゃくちゃ進歩したかというとまあそんなことはないが、コミュニティ運営に入ったこともありしつこくeBPFを続けたり今更ながらlibbpfと仲良くなろうとしていたり、オブザーバビリティとの接続点のところがはやり面白いのでOBIあたりを追ってみたりという感じで引き続きやっている。OTelは周辺技術ばかりみてきたけど、お仕事的にもまじめに取り組みはじめたので遅まきながらやっていきたいところですね。

子供が生まれて明確に可処分時間が減っているが、まあしつこくやるのが性なのでやっていきましょう。

その他

特に大きな病気はしていないがマイナーな不調が出てるので健康の優先度が一番高い、色々試みはしたものの一回崩れると立て直しにだいぶ時間がかかるようになったので、ここは本当になんらか取り組んでいく所存。

(特に関係ないどこかの写真で締め)

Grafana CloudとNASで自宅のインターネット速度を計測する

この記事は Grafana Advent Calendar 2025 の 4 日目になります。

小ネタですが空いていたのでやっていきます。

自宅はマンションで回線はフレッツ光ネクスト、プロバイダも固定で管理費込みといった環境なのですが、ある頃からPPPoEで通信しているv4側が耐え難いほど遅くなり、紆余曲折を経て現在はプロバイダを追加契約し、transix IPv4接続(固定IP)を利用しています。

元の状態からするとだいぶマシになったのですが、環境や構成の変更により結局どの程度速度が変化したのかを継続的に計測したいと思い、設置しているNAS(QNAPのTS-262)を使いGrafana Cloudに定期的にメトリクスとして送ることにしました。

Internet Speed Dashboard

https://egmc.grafana.net/public-dashboards/62f903fe5b2042e98410dac48e2c5854

予測値をいれてみたり一週間前の比較を入れてざっくり傾向をみたりしてます。

設定など

QNAPのNASにはContainer Stationというコンテナマネジメントが行えるソフト1が付属しており、Docker Hubなどの任意のコンテナレジストリからコンテナをpullして実行できます。

これを使って、speedtestを実行するexporter(speedtest_exporterでいくつかバリエーションがありますがいずれも Speedtest by Ookla - The Global Broadband Speed Test を実行して結果をメトリクスで返すもの)をコンテナで起動し、スクレイプ先のportに対して、別で立ち上げたPrometheusのコンテナからスクレイプします。

configはホスト側においてマウントし、Overrideして読むように

そしてGrafana CloudのHotsted Prometheusに対してRemote Writeする設定を入れればOKです。

global:
  scrape_interval:     1m
  evaluation_interval: 30s
scrape_configs:
  - job_name: 'speettest'
    scrape_interval: 35m
    scrape_timeout: 5m
    metrics_path: "/probe"
    params:
      script: [speedtest]
    static_configs:
    - targets: ['{local ip}:9469']
    metric_relabel_configs:
    - source_labels: [__name__]
      regex: "^(promhttp_|go_|process_|prometheus_|http_).+$"
      action: drop
remote_write:
- url: https://prometheus-blocks-prod-us-central1.grafana.net/api/prom/push
  basic_auth:
    username: {user}
    password: {pass}
  queue_config:
    min_backoff: 10s
    max_backoff: 8h

設定的には抜粋するとこんな感じで、speedtestをあまり叩きすぎるのもあれなのでscrape_intervalは適度に手加減しましょう。

この構成の良いところは、メトリクスの送信がRemoteWriteによるpushになるので、外部へのポート開放などが必要ない点です。

最近ネットワーク機器を諸々入れ替えたのですが、SNMP Exporterでメトリクスを取得したりOtelでLokiにログを送信するみたいなこともできるようになってきたので、自宅のネットワーク監視も同様にやっていきたいですね。


  1. 使ったことはないのですがSynologyのNASなどにも同様の機能がありそうです

Observability Conference Tokyo 2025に参加しました

クイック参加記事(※技術的な話は特にない)です。

o11ycon.jp

個人的な背景として今年は前半カンファレンスの運営をやっていたために(あとまあ家庭的な話もあり)かなりそれに合わせて参加イベントを絞っていたので、このカンファレンスについては純粋に参加して楽しみたいという気持ちで朝から参加させていただきました。

結果的にセッション聴講を適度にしつつ、登壇者のQAやその他の会話で現地の体験をしつつなかなか満足度高く過ごせたなーという感想です。

セッション

Affordable Observability: Strategy to Implementation

Liz Fong-Jonesさんによるキーノート。

Observabilityの価値的な大枠の話から具体的なサンプリングの手法、組織への展開までの話がよくまとまっていて良いセッションでした。

QAの時間も充実していて、自身の質問(障害時にサンプル対象が増えた場合の対応的な話)も拾ってもらい大変よかった。

オブザーバビリティが育む開発者のシステム理解と好奇心

maruさんの、個人的今回のベストセッション。

開発、運用でのメンタルモデルの違いの話から、継続的な負荷試験の仕組み整備から組織へのデプロイ、アラートの話まで、全体として身も蓋もないが自分とこであまりうまくやれてなかったり半ば諦めたりした内容が詰め込まれていて、やらんとねえ・・という気持ちになったのが大きいですね。継続的なパフォーマンス計測というのをやりたい気持ちが再燃しました。

アラートのコード管理まわりは一応自社でもやってるので(よくできているかはさておき)、どこかで機会があれば書こうかなとは思います。

その他雑多に

サイン会とか

著者から翻訳者まで一気にサインしてもらえるというよく考えたら豪華な会でしたね。

個人的にLizさんは物理で見るのは3回目で2019年のSREcon19Amricas(Chairをしていた)、今年のSREcon25Americas(Observabilityのディスカッショントラックをホストしていた)、そして今回だったわけですが、短い時間ながらはじめて会話できてしかもそれが日本というのもなんだかすごいですね。

運営

今年自身も運営をやっていたのもあり、「3ヶ月で?スポンサー集めてCfPやって配信もNOCも翻訳もあり?キャラクターやグッズまで作って?」とよくわからないがすごくてすごい、全体としてスムーズに運営されていてすごいというかちょっと怖いなあという感想です、大変お疲れ様でした、ありがとうございました!

オブザーバビリティやっていかんとねえ・・、といいつつeBPFのOTel自動計装とかそういった方面をつい眺めがちでおります、ここは興味関心の接続点なのでちまちまやっていきたいですね(いやOTelもまずひととおりやるべきなのだが)。

SRE NEXT 2025でeBPFの話をしました

登壇編です。

スタッフ、チェアやった編はこちら。

dasalog.hatenablog.jp

SREのためのeBPF活用ステップアップガイドというタイトルでお話しました。

speakerdeck.com

写真ありがたい。

2023チェアのぐりもお (@gr1m0h)さんに「チェアと登壇同時にやるとやばい」と聞いてましたがかつてなく準備がギリギリになって焦りましたがなんとかなりました。 娘がとあるモールの施設で妻と遊んでいる間にサイゼに籠もって作業するなどのフェーズを挟むことによりなんとか間に合いました。

今回初の30分枠で(自分たちでそう設計したからね・・)いつもより10分多いやったーと思っていたら前日ようやく出来たリハで3分オーバーしていて、しかし削るところはもうないしスピーカーノートを追加してなんとか喋りを間に合わせようとしましたが結局少しオーバーしてしまいましたというのが反省点です。途中息切れしてきて一息つくべきところを水飲んでる時間もないなーと思って無理やり進めたので最終的にめっちゃ息切れしたのも反省点です。アーカイブをみるのが怖い、聞き苦しくなかったかやや心配しております。

あと資料あげようとした段階でこれタイトル間違ってないか?ということに気づきました、これもアーカイブが怖い、活用が正しいです。

最終コミットの差分

発表について

内容自体は自分のやってきたeBPF関連のあれこれ全部のせという感じのものを難易度順に並べてステップアップガイドとして仕立てた感じになっています。

実際に使えた、使える事例にすることが優先事項で、事例自体はちょっと古めのものが入っているんですがなるべくコンテキストを追加して意味がわかるようにしようとしています(したつもりです)。

SRE NEXTにもeBPFの発表とか欲しいよね、と長らく思っていたのですが結局自分でやることになりました。

なんというかeBPFに関して自分よりももっと技術的に高度な話ができる人はたくさんいるので、SRE NEXTの場で話してもらうのもそういう人たちがいいんじゃないかと思ってたんですけど、昨年末からeBPF Japan Meetupの運営入りをしたり、流れでたまたまちょっとしたPRやバグレポを上げたりしてみた結果心境の変化があり、もっと認知や普及に取り組んだほうがいいんじゃないか、高度な事例じゃなくても現実にSREの役立つのだよ、ということを伝えていこうということで、この内容でProposalを投げました。

それこそBrendanGreggが話すのに自分がeBPFの話をする意味とは、というところなんですが考えてみればそれはSRE本があるのに無限にSREをしている我々と似たようなもので、現実世界での事例があれば解像度が上がりますし、Fast by Fridayの末端の一つの例くらいになればいいでしょう、という感じです。これスライドに書けばよかったですね・・。

当日

人の入りは割と心配してたんですが、おかげさまで(いや本当に)たくさんの方に聴講いただけました。

いくつか個人的にありがてえ、と思ったポストを貼っておきます。

あ、やっぱ利用って書いてますね・・。

死ぬほど詳しいガチ資料でおすすめです。

やっていきに繋がったらありがたい。

あとこれがめちゃ嬉しい、概要はこれみたらわかります。

Ask the Speaker

よく考えたら人生初のAsk the Speakerだったんですが、セッションに来てくれていたBrendanさんとそれに気づいて英訳を流してくれていた @inductorさんと(これもありがた) @logica0419 さんと4人でふつうに喋ってました。Askは一回もされてない。自分もまだ聞きたいことがあったのでAskしてました。よかったです。そういうのもあります。

ということで

eBPFの話でした。

そもそも自分がeBPFの存在を知ってツールを触り始めたのはBPF Perfomance Toolsを読んだからであり、半分は個人の趣味としてちまちまと続けてきた結果を少しまとめられたのはよかったのではないかと思います。

世は大コンテナ時代なんですが、ツールまわりもうちょっと整備したいですし、なにかがしかまた有用な事例が出せたらいいなあと思っております。

Photo by SRE NEXT Staff

SRE NEXT 2025でCo-Chairをやりました

前回

dasalog.hatenablog.jp

書くことがたくさんある気がしていてどこから何を書いていいのかわからない。

普段あまりこういう事は書かないのですが、思った以上に良いカンファレンスになったな・・と思ってます。反省点は山程ありますし、やらかしもたくさんあるんですが、それでもこの良さは両立するな、という気分です。自分は何もうまくやっていないのに「なんか気づいたら想定以上の状態になっててみんなすごい・・」という感じです。すごいですね。

みんなという抽象度高すぎてなんだかふわっとしてしまうわけですが、スタッフ(コアスタッフ、当日スタッフ、NOCの皆様)だけでもないしスピーカーの皆様だけでもないしスポンサーの皆様だけでもないしイベントブースの方も来場者の方々も・・・となるともうみんなとしか言えないというのが学びポイントです。

BrendanGreggさんが来ました

BrendanGreggを呼んだ!というとなんだか自分がやったみたいな感じであれなんですが、もちろんそんなことはなく、こちらも協力頂いた皆様のおかげで実現しました、本当にありがとうございます。人生の目標が一つ達成されました。

基調講演で話して頂くだけではなく、自分含め参加者との交流を取っていただいてホスピタリティが素晴らしくありがたさに感動しました。

サイン会は電子書籍OKにしたのですが大半の人は物理本を持っていて、初版から原著までバリエーションがあり、こんなに様々な詳解システムパフォーマンスが一堂に会することは二度とないんじゃないかと思います、全部で何キロあったんでしょうね。自分は初版とBPF Performance Toolsをそれぞれ持って二版を紙で追加購入しました。

講演の内容、(単なるファン的な話はさておき) SRE NEXTという場に呼ぶことの狙いについては一応少し思惑があり、現状のコンテナ隆盛の時代において複雑なパフォーマンスの問題の調査を素早く行うためにはこれ(ツール、メソドロジ)が必要である、という視点は良いディスカッションのもとになるんじゃないかと思うなどしていました。

ディスカッションイベント「Talk NEXT!」

インタラクティブなコンテンツやりたい、ワークショップとか、みたいな話をしていましたがこの形になりました。

一応形式的にはSREconのディスカッショントラックを参考にして、Breakout Group Discussionの形式を4テーマ同時にやろう、ということ説明スライドなどもせっせと作ったんですが(そして実際その通りに進行はしていただいたんですが)気づけば人はたくさん参加しているし、ルール説明もそこそこに練度の高い参加者自身がいい感じに進行していてなんだこれはすごいな、と感動しました。

netmark.jp

馬場さんがはやくもオブザーバビリティのところを書いてくださっております。

今回やや控えめな開催にしているのは意図していてカナリーリリース的な思惑もあったんですが、やってみた結果もっと踏み込んでも全然いけたな、と思いました。

スピーカーディナーイベント

公募セッション(30分)のスピーカー、ゲストスピーカーの方々を招いてコアスタッフとクローズドなディナーイベントを初開催しました。

実施タイミング的に正直負荷もあるものの、スピーカーの目線でもスタッフの目線でも持続性の観点で良いんじゃないかと思い今回初開催してみました。自分としては大変よかったと思っているのですが、参加された方の感想をきいてみたいなーと思います。

スタッフ

プログラムとディスカッションイベントのことを主にやりつつ、英語圏サポートを少しいい感じにする対応などをやったりしてました。

招待講演の方は川崎さんはじめチームメンバーのみなさんのおかげで、なんと打診させて頂いたみなさますべてに快諾頂き(調整ありがとうございます本当に)ました。

おかげさまで多様で豪華なセッションにになり最高でした。

zenn.dev

CfPは例によってめちゃ大変だったんですが、応募された方も大変だったと思います(ありがとうございます)。今回クロージングでも少しお話した通り大枠のフレームワークは踏襲しつついくつか変更を加えました。

地味にメール送信まわりを改善したり、受付のSlack通知を改善したりと多少コード書いて成果があがったのはよかったですね。

Co-Chair

人はチェアになったからといって急に練度があがるわけじゃないのだけど、ある程度ロールが人をつくるみたいなところもありますね・・、ということでなんとかやってた1年でした。

チェアとしての責務は意思決定が多めになるので、「SRE NEXT自体の持続性の観点ではどうか」を一つの基準としてアレコレ考えて判断する、わからんことは積極的におまかせしよう、方針はなるべく言語化しよう、のスタンスでやってきました。

おかげさまで(本当におかげさまで)2歳児(途中で3歳になったけど)がいてもチェアは一応できる、ということで実績解除したと思います(いやこれ皆それぞれ家庭の事情はありますし特段大変アピールするのもあれなんですが個人としてはそれなりにやはりいろいろありはするのでー、という)。

開催一週間前に胃腸炎が発覚した時は一瞬死を覚悟したけどなんとかなりました。よかったですね。

Co-Chairの部分は個人的にめちゃ重要でこれはちょっと一人は無理でした、前チェア陣からのフレームワークの受け継ぎと渡部さんとの分担でどうにかなりましたね。

人ってこんなに感謝の気持ちが出るだってくらい感謝の気持ちしかないです

ryuichi1208.hateblo.jp

いやそうなりますよね、と言いつついったん締め、登壇の話はまた別で書きます。

KubeConが良かった話(主にPrometheusの話)

6/16-17に日本初開催となるKubeCon + CloudNativeCon Japan 2025に参加してきた話です。 前年のKubeDay Japanも参加しましたが、さすがにKubeConとなると規模も大きくより国際カンファレンス感が高まったな、という印象ですね。

個人的にしょうもない反省点もありますがよかった点を振り返っていきたいと思います。

PrometheusコミュニティとしてのGrafana

2025年だけで2月のObservabilityCON on the Road Tokyo 2025、3月のSREcon25 Americasなどブース訪れたりセッション聞いたり中の人と話したり、という機会が割とあったのですが、KubeCon + CloudNativeConにおいてはCNCF GraduatedプロジェクトとしてのPrometheusをメンテナンスするGrafanaの開発者たちの話が多く聞けたのが個人的に良かったなーと思ってます(PromConぽいな、という感じで)。

セッションとしては

youtu.be

youtu.be

youtu.be

でGrafana Labs関連のセッションはすべて網羅したんじゃないかと思います。

元々Prometheus3.0まわりの動向はまあまあ追ってはいたのですごく目新しい話があったわけではないですが、開発者と直接話して情報を得られたりニーズを伝えられたりするのはやはりいいですね。

具体的な収穫としてはこのあたり

個人的には新しいガバナンス体制は割と期待しており、特にprometheurs-community orgのメンテナが少なくてリリースにめちゃ時間がかかるみたいな現状が改善されるとよいなと思っています(ちょうど前回のエントリで書いた件のように)。

dasalog.hatenablog.jp

また、Native Histgramは仕様がかなり込み入っているように見えるので言語間の移植はどうなのかなーと思っていたけどとりあえずテキストフォーマットはPython実装があるようだし、Grafana Cloud側のでのサポートも進みそうなの期待している(スクレイプ、クエリとも少し複雑にはなりそうだけども)。

その他諸々雑多に

さすがにでかいイベントで1500人も集まったということなのでインターネットでお世話になっていたり一方的にフォローしている人に会えたりしてそのあたりも大変よかったですね。

とはいえなんというか大半は日本人と話してた感じはあり、2日目は特に寝不足も相まって気力が死んでいて海外からの一般参加者との会話がほぼできなかったなあ、というのが反省点。

来年も日程が公開されたので、また参加したいなーとは思っております、年末はLPCなどもあるので日本の国際カンファレンスに参加できそうな機会が増えて個人的に嬉しいところ。

ということで期待しつつ、適当に写真を貼ってしめておく、関係者のみなさま大変おつかれさまでした!

systemd_exporter v0.7.0がリリースされてsystemd-resolvedのメトリクスが取れるようになりました

タイトルまま、これは記念エントリです。

github.com

これ。

systemd_exporterにsystemd-resolvedのメトリクスを取得するPRを投げ、マージされてから1年と2ヶ月経過してやっとこ新バージョンがリリースされました。

github.com

これです。

こんなのが取れます

systemd resolved dashboard

使う人向け情報

systemd_exporter --systemd.collector.enable-resolved

でsystemd_resolvedのメトリクスを取得するようになります。

READMEへの変更はマージされてないのでアレですが --help で確認できます

$ curl -s http://localhost:9558/metrics | grep resolve
# HELP systemd_resolved_cache_hits_total Resolved Total Cache Hits
# TYPE systemd_resolved_cache_hits_total counter
systemd_resolved_cache_hits_total 236418
# HELP systemd_resolved_cache_misses_total Resolved Total Cache Misses
# TYPE systemd_resolved_cache_misses_total counter
systemd_resolved_cache_misses_total 247689
# HELP systemd_resolved_current_cache_size Resolved Current Cache Size
# TYPE systemd_resolved_current_cache_size gauge
systemd_resolved_current_cache_size 48
# HELP systemd_resolved_current_transactions Resolved Current Transactions
# TYPE systemd_resolved_current_transactions gauge
systemd_resolved_current_transactions 0
# HELP systemd_resolved_dnssec_bogus_total Resolved Total number of DNSSEC Verdicts Boguss
# TYPE systemd_resolved_dnssec_bogus_total counter
systemd_resolved_dnssec_bogus_total 0
# HELP systemd_resolved_dnssec_indeterminate_total Resolved Total number of DNSSEC Verdicts Indeterminat
# TYPE systemd_resolved_dnssec_indeterminate_total counter
systemd_resolved_dnssec_indeterminate_total 0
# HELP systemd_resolved_dnssec_insecure_total Resolved Total number of DNSSEC Verdicts Insecure
# TYPE systemd_resolved_dnssec_insecure_total counter
systemd_resolved_dnssec_insecure_total 0
# HELP systemd_resolved_dnssec_secure_total Resolved Total number of DNSSEC Verdicts Secure
# TYPE systemd_resolved_dnssec_secure_total counter
systemd_resolved_dnssec_secure_total 0
# HELP systemd_resolved_transactions_total Resolved Total Transactions
# TYPE systemd_resolved_transactions_total counter
systemd_resolved_transactions_total 476851

特権は特に必要ないので

[Unit]
Description=Systemd Exporter

[Service]
Type=simple
User=nobody
ExecStart=/usr/local/bin/systemd_exporter --systemd.collector.enable-resolved --systemd.collector.unit-include=(apache2|.*exporter.*|prometheus|grafana)\.service

[Install]
WantedBy=multi-user.target

自分はこんな感じのsystemd unitファイルを書いてます。

systemd_exporterはunitごとのメトリクスを取るためカーディナリティが高いので、systemd.collector.unit-includeでunitを絞ったり、prometheusのrelabel_configでよしなにdropするなどすると良いと思います(有償のマネージドサービスを利用する場合は特に)

収集されたメトリクスの可視化はGrafanaダッシュボードで行えます。

grafana.com

に基本的なものを用意してあります(とりあえずtimeseries graphに置き換えたので最近のGrafanaでも使えるはず)。

systemd-resolvedについて

systemd-resolved - ArchWiki

ローカル DNSタブリスナによるネットワーク名前解決をローカルアプリケーションに提供する systemd サービスです

少なくとも最近のubuntuではデフォルトで動作するようになっており、名前解決結果をキャッシュします。

k8s環境では残念ながらおそらくそれほど使われていない(node localなキャッシュは別で提供されますしね・・)ですが、VMで利用している方は意識せずとも使われてる環境が多いかと思います。

統計情報がD-Busインターフェース(とそれを利用するcli)により提供されています。

統計情報はカウンターなのでそのままでは扱いづらいですが、定期的に収集、rateを計算することでキャッシュヒット率など意味のある指標を得ることができます。

systemd_exporterの systemd.collector.enable-resolved optionはD-Bus経由で統計情報を取得します。

systemd_exporterとマージされるまでの流れ

なんというか特にすごい機能というわけではないものの、当初の実装からマージされてリリースされるまでだいぶかかったなーという思いの記録。

  • systemd_exporterはもともとPovilas Versockas氏により開発、メンテされていた
  • systemd-resolvedのメトリクス収集についてはOct 22, 2020からissueが立てられていた
  • Mar 5, 2022に個人で作成していたsystemd_resolved_exporterをベースにPR出そうか?と自分がコメントしたもののプロジェクトの状況が思わしくなさそうなので放置
  • そうこうしているうちに、レポジトリがprometheus-communityに移行する案が提案され、Jul 19, 2022に移行完了
  • コミュニティベースになったのなら今後も期待できるかなと思い、コメントをきっかけにsystemd-resolved対応のPRを出したのがDec 22, 2023、マージされたのがJan 12, 2024
  • 何回かメンテナ氏を突っついてみるもののしばらく音沙汰なし
  • 今日(2025-03-14)唐突に新バージョンがリリースされる

prometheus-community orgに移されたあとは割と期待したのですが、そうはいってもメンテナが少なくなかなかリリースサイクルがかかっている感じがします。

もうちょっと気軽にこのあたり関われればと思いつつ、なかなか悩ましいところ。

さておきこれで人にもすすめやすくなったなーと思うので、VM環境でPrometheus利用各位は是非お試しください🙌