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に参加しました

conference

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

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の話をしました

sre conference

登壇編です。

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

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をやりました

conference sre

前回

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の話）

Prometheus conference

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のメトリクスが取れるようになりました

Prometheus monitoring 小ネタ

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

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利用各位は是非お試しください🙌

PHP Sessionless Conference（ピセカ）に参加しつつ「eBPFと周辺技術を利用してPHPアプリケーションコードを変更しない可視化をやってみる」というワークショップをどうにかやってきました

Prometheus bpf php

長タイトルまま、主に参加記録です。

PHP Sessionless Conference（ピセカ）という、セッションが一切なく全編ワークショップという若干狂ったカンファレンス(?)に参加して、かつeBPFのワークショップをやるproposalが通ったのでやってきました。

参加は楽しく、概ね目標は達成できたのではないかと思いますが反省もまたあるのでそんなこんなを書いておきます。

参加モチベ

  • ワークショップやる（参加者、ナビゲータとして）
  • eBPFで何ができるのかをPHPerな方々に知ってもらう

前者は今年自身がやる方のカンファレンスでワークショップ（的なもの）をやるぞ！と言いながらワークショップ経験いうてそんなにない、というのがあったのでワークショップもっと経験しないとな・・ワークショップばっかのやつあるじゃん、というモチベ。

後者については、最近意識の変化があり、やはりこれ使う人、関心をもつ人を増やしていかないとのちのち自分が使いたい時に困るんじゃなかろうか、というある種の危機感を背景に、根底としてはもちろん便利なツールとしての可能性を知ってもらいたい、というモチベでした。

当初ワークショップやることまではあまり考えていなかったのだけど、PHPカンファレンス名古屋2025のproposalが通らなかったのもあり、さりとてもろもろのスケジュールの都合で直近のPHPイベは見送り気味、あまり寝かせたくはない、というのもあり、どうせワークショップを学ぶならもう一周回ってもう自分でやればいいんじゃないか？となりこの内容でproposalを投げました。

自分がやったワークショップ

ワークショップ、登壇じゃないので表現が難しい、主催した、とか、なんか大げさでイベント主催感あるし、まあ、やりました（と書いていたらナビゲーターという表現を見かけた、なるほど、ナビゲーターしました）。

proposal

fortee.jp

本編

github.com

内容としてはebpf_exporterで最近遊んでいたPHP関連のトレースポイント（uprobe、USDT）をGrafanaで可視化するとこまでやるもの。

対象は普段PHPでサーバサイドのコードを書いている方なので、要素的にも馴染みのないであろうものも多く、これは準備が大変だなと思いましたが案の定大変でした。 ワークショップレポジトリの前日あたりのコミットログが結構アレなことになってます。

ただまあこの手のハンズオン的な内容でありがちな「上から順番にコマンド叩いたらなんかできたけどよくわからない」は避けたかったのでセットアップスクリプトは用意しつつ、要素技術の説明は入れ、あとで振り返ってやり直せるくらいのものを目指しました、目指したつもり。

内容が内容なので万人受けするとは思っていないが、せっかく手を動かすので少数でも刺さる人がいて、今後深堀りしたいなーと思ってもらえたら嬉しいところですね。

ワークショップに参加された方/レポを使って遊んでみたい方はぜひ、例えば自分の手元のPHPアプリで試したり、bpftraceであれこれフックを試してみたり、みたいなことを試してもらえるとより面白いんでないかと思います。

よかった点

  • 事前登録みて何人参加されるかなーと思ったけど結局11人参加されたはず、よかった
  • サーバ方面のトラシューに割と慣れている方がちょいちょいいて結果的に救われた＆いい感じに質問を投げてもらいつつ進められた
  • セットアップスクリプトは頑張って仕込んだのでこれ自体の不具合は起きず思ったよりスムーズに進められた（時間切れはなるべく避けたかった
  • これほかでもできるかもな、という感触が得られた

反省点（たくさんある）

  • BPFプログラムのビルド部分での引っ掛かり、これはある程度時間がかかると認識していたが結構SSHセッションが切れてしまったりして完走できない人が出てしまった（場合によってはスペックアップで切り抜けてもらったり・・）
    • スペックの部分は難しく、本当はMySQLも入れてトレースしたら楽しいだろうなと思ったけど単純にちょっと大変なのと要求スペックが上がるので個人の持ち出し環境ではちょっとな、と思ってやめました
  • 時間配分はまあまあでいけたが進捗がわからないのでコントロールが難しい、めっちゃ進捗確認した、これはまあハンズオン全般的にそうかな・・
  • PHPのサンプルコードがだいぶひどい、個人で遊んでたコードをそのまま持ってきたのだけど、これはまあ時間切れですね
  • ebpf_exporterだけ手動で立ち上げるようにしたけど、今回に限ってはあまり意味なかったのでターミナル空けるためにこれもsystemd管理にしとけばよかったね、などなど
  • ワークショップの参加を見送った方に「BPF is 何」と結構聞かれた、これはタイトルの難しさですね、（懇親会で武田さんともお話したが）キャッチーにしたかったけど、要素としてはちゃんと入れたい、「APM作れますよ」みたいなのも考えたけど、ちょっとタイトル詐欺感があってうーん、となりました、結果これ、次あったらもうちょい考えたい
  • 最後に10分ユースケースのディスカッション時間をとっていて、これはできたのだけど自分が参加した島でトラシューしたり諸々話してたら時間がきてグループの発表時間がとれなかった、個別に聞いてまわったがこれはちょっと惜しかった・・

参加したワークショップ

PIE (PHP Installer for Extensions) をみんなで試そう by 小山哲志(こいほげ)

こちらは純粋に機能面の興味から。

ワークショップ自体はコマンドいれて動かしてみてextension入ったね、であとは細かいところを眺めつつ、ゆるゆると会話する感じでなんというか気楽な回でよかったですね。

PIE自体動かしてみて話を聞いてみると、あーなるほど、当初思ったんと違いますね（composerみたいにvendoringされるのかと思ったら実行中のPHP環境にグローバルにがっつり入りますねとか、iniまわりが空気読んでそれっぽいパスに入るとか）というのが実感できたのでこれはやはりやってみてなんぼというところ。

「こんなテストコードは嫌ぁ〜ダ！ヤダー！」を祓う会

こちらはディスカッションメインのザ・ワークショップとして参加。 実のところPHPでテストコード書いたことはないのですがまあテスト一般の話なのでいけるであろうということで。

Miroを使ってグループ分けからディスカッションを進行していくスタイルでワークショップのやり方として参考になるなーと思いつつ参加してました。

祓えたか？はわからんですがディスカッション通して違う視点が得られるのでこういうのがやはりいいですね。

カンファレンス全体

雑多に色々

  • オープニング、エンディングもワークショップで固めてこれはちひろさんこだわりだなあ、と思った次第、うまいことやってるなあと思いました
  • 会場はあれどスポンサー的なものはなく、ナビゲータをやる側もお金払って来てるので参加者の当事者意識が高い
  • 良くも悪くもコミュニケーション多量なので、人はまあ選ぶかも、そういう前提で来てるから参加者としては違和感なし

写真

全員に事前に許諾とっておくというストロングスタイルのはずなので人いれてもいいんだけどちょっと日和気味にあげておく、足すかも。

同窓会、ではないが

やはりPHPコミュニティなので顔見知りの同窓会っぽい雰囲気は感じつつ、自分はPHPコミュニティに多少顔出してたのは10年以上前であり、当時も特に熱心にコミュニティ活動してたわけではないので参加者はSRE NEXTスタッフでもあるちひろさん除いてほぼ初対面でした。一方的にフォローして知ってるぞーという人が多少いるくらいで。

という状況ではありながら、PHPは自分的にはホームの言語であるという意識はあるのでなんだか懐かしいぞ、と何をしていたのかというと老人会仕草をしてなんやかやとワイワイやらせていただきました、お話いただいた皆様ありがとうございます。またそのうちどこかの勉強会かカンファレンスにも参加したいが、次はちょっと（自分の方のあれこれが）落ち着いてからになるかな・・。

会場のピクシブさんも多分10年前のPHPめちゃ書いていた頃なんらかの勉強会で来たことがあってちょっとそういう懐かしみもありましたね。

おまけ