各ディストリビューションのsystemd-resolve状況調査2022

Lightsailで提供されているamiで使いそうなものをざっと確認

ubuntu 20.04(kernel5.4)

systemd-resoveがデフォルトで動いていてsystemd-resolveとresolvectlが両方いる

$ systemctl --version
systemd 245 (245.4-4ubuntu3.1)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

$ systemd-resolve --statistics
DNSSEC supported by current servers: no

Transactions
Current Transactions: 0
  Total Transactions: 28

Cache
  Current Cache Size: 2
          Cache Hits: 3
        Cache Misses: 29

DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0

$ resolvectl statistics
DNSSEC supported by current servers: no

Transactions
Current Transactions: 0
  Total Transactions: 36

Cache
  Current Cache Size: 1
          Cache Hits: 3
        Cache Misses: 37

DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0

Amazon Linux 2 (kernel4.14)

systemd-resolvedはそもそもいない、手動でインストールできるがコマンドもなくdbus経由でもプロパティ取得できないっぽいのであまり気にしなくてよさそう

2022が正式にリリースされたら再確認

$ systemctl --version
systemd 219
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN

$ dbus-send --print-reply --system --dest=org.freedesktop.resolve1  /org/freedesktop/resolve1 --type=method_call  org.freedesktop.DBus.Properties.GetAll string:org.freedesktop.resolve1.Managerl
Error org.freedesktop.DBus.Error.UnknownInterface: Unknown interface 'org.freedesktop.resolve1.Managerl'.
[ec2-user@ip-172-26-10-221 ~]$ dbus-send --print-reply --system --dest=org.freedesktop.resolve1  /org/freedesktop/resolve1 --type=method_call  org.freedesktop.DBus.Properties.GetAll string:org.freedesktop.resolve1.Manager
method return time=1645836357.009983 sender=:1.64 -> destination=:1.75 serial=8 reply_serial=2
   array [
   ]

CentOS 8.2.2004（kernel4.18）

systemd-resoveがデフォルトで動いている、コマンドもどっちもいて統計情報もとれる

$ systemctl --version
systemd 239
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy

$ systemd-resolve --statistics
DNSSEC supported by current servers: yes

Transactions
Current Transactions: 0
  Total Transactions: 2

Cache
  Current Cache Size: 0
          Cache Hits: 0
        Cache Misses: 0

DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0

$ resolvectl statistics
DNSSEC supported by current servers: yes

Transactions
Current Transactions: 0
  Total Transactions: 2

Cache
  Current Cache Size: 0
          Cache Hits: 0
        Cache Misses: 0

DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0

sysload exporterを実装してみた

タイトルままということで。

github.com

goでゼロからexporterを書こう、sysloadの実装を今更ながら把握しておこうというモチベーションのもとsysloadをprometheusのexporterとして実装してみました。

dashboard image

Dashboardも公開しているの動かして見るぜーという方はこちらもどうぞ。 クエリみて頂ければわかりますが、設計上sysloadの値は単純なgaugeなので既存のノード用ダッシュボードに組み込むのも簡単だとおもいます。

grafana.com

sysload is 何

labs.gree.jp

詳細はこちらの記事とgithubレポジトリを参照頂ければとおもいます。

もともとLoad Averageの不具合を起因としてサーバ負荷（システムリソースのsaturation）を0-100で表す指標として開発されたものです。 単純なCPU負荷だけでなく、nicからの割り込みを受けているCPU群とIOを考慮して高い値が採用される設計になっているのでいずれかのリソースが飽和状態であるということがわかりやすく表すことができるようになっています。

exporterの実装について

基本は写経スタイルで、一部パラメータまわりを扱いやすくしたり細かい部分を調整しつつ、メトリクスの構造をexporter的な形式に寄せた感じ（のつもり）になってます。

prometheusのexporterはcounterで扱うスタイルが基本ですが、sysload自体はgaugeの値ですしその他追加で取得しているメトリクスや1,5,15分平均もそのまま計算した値を採用しています。

移植にあたって変更した点は細かい点ですが

• 外部コマンドなど細かい部分の依存をなくした
• interruptチェックにあたってのデバイス候補のデフォルト値変更（追加）
• その他データ構造を取り回ししやすいようにいくつか修正

あたりになります。

個人的にメンテしてる環境でさくっと使いたいということで簡易なdebパッケージのみ提供してますが、systemdを前提にしているのでubuntuであれば16.04xenial以降の環境であれば動作するとおもいます、バイナリは大体どこでも動くかと。

ライセンスはオリジナル実装がGPL 2.0なのでそのようになっています。

今後のメンテなど

せっかく実装してみたのでぼちぼち動かしつつメンテしていきたいと思います。

• とりあえず実装して個人のサーバで動作確認しましたというレベルなので、とりあえず何らかのテストを実装したい
• interruptチェックまわりはパラメータ依存ではなくもう少し賢くできるといいんじゃないかと思っているのでここらへんはなにか良き方法があればどーにしかしたい
• issueにとりあえず入れてるけどコンテナから動かせるように/procのマウントパスオプションを追加する

などなど

eBPF Summit 2021

今年はDay1のみリアタイ参戦したのでいくつかセッションのメモを。 内容は全部見ればわかるやろ程度ではあるもののまあポインタ程度の情報でもないよりは良いのではということで感想交えて雑に書いてみようという感じのやつです。

動画はすでに上がっていて個別のセッションはYouTube字幕もすでについていてセッションだけをみるならそちらがよい、QA含めてみるためにはDay1,2それぞれ全部入りの動画をみればおっけーという感じ。ただしDay1のeBPF for Windowsは若干音声まわりのトラブルがあったのでセッション個別はそちらを参照する方がおすすめです。

全体的な雰囲気とか所感とか

eBPF Summit自体は初回からオンライン開催、事前収録+リアルタイムQAスタイルでコミュニケーションはslack、trackも一本なのであっちこっち移動したりスポンサー的な何かがあったりはしないのでここに集中すればよいというのがはっきりしていて参加する方としてもやりやすいんでないかと。

セッション時間は20分 or 5分で短い休憩が挟まるという形式なので、「40分英語セッション集中して聞くの正直しんどい」という自分みたいなものにはこれくらいでちょうどよいですね。

↑の通り動画はすぐにあがるし、自動生成字幕ついてくれた方がありがたいみたいなところもあるのだが、とはいえリアタイじゃないと見ないみたいなのもあるしslack内での盛り上がってる感、雑に質問投げられる感という体験はよいものなのでということでまあ1日でも参加してよかったなーというところです。

全体のレベル感としてはIntroductory and overviewがもっとも多く、1日目はAdvancedなものは一つもなかったので、概要を結構繰り返し説明されるので最近関連ツール触り始めましたみたいな感じでもとっかかりがあればよさそうと思う反面ガチ勢な方々にはちょい物足りないのかもというところでそちらはどちらかというとday2で取り扱ったのだろうと思われます（未視聴

BrendanGregg氏のまず使ってほしい、といったQAコメントや特にDay1のツール利用者等ビギナー向けセッションの様子などをみているとeBPFを長期的に有用なテクノロジーとして扱っていくために裾野を広げて需要があるよ、ということを示していきたいという思いがあるのかなーという印象を受けました。

以下いくつかセッションメモ

The State & Future of eBPF

• 最近発表のあったeBPF Foundationの話と過去、現在、未来についての話
• かつてアプリケーションの観測に必要な機能の実装を「カーネル開発者に依頼して1年後にサポートされ5年後に各ディストロに降ってきてようやく使えるころには不要になってる」みたいなのがeBPFで数日で出来るようになった、これからはネットワーキング、セキュリティ、オブザーバビリティそれぞれ低オーバーヘッドでこういったことを実現してく、というoverview的な内容
• QAでドライバ作れる？というのがあり、一般的じゃないけどまあ出来るみたいな回答だった（はず

Getting Started with BPF observability

• いきなりツール開発するのではなくsysadmin的に考えていこうという内容で昨年のセッションから現在の状況を踏まえてマイナーチェンジした感じ
• よく使われるレイヤーごとのツール群のマッピング画像がパワーアップしてた、気がする
• LISA21の方がInternalのお話をしていたのでこちらはやはりnewな人向けな内容だと思いますがとにかくBrendan Gregg見たいぜという人にも

eBPF in Microservices Observability

• マイクロサービスをeBPFで観測してこうという話
• 前半はOverview的な説明
• 旧来のツールではそれぞれのツールを使いこなす必要があり必要な詳細度の情報が得られないことがある
• 特定のサービス、RPCを特定するためコンテキストを付与した情報を得るためにeBPFを使う
• 具体的なソリューションとしてはCilium/Hubble、Pixie、Flowmillなど
• Futureの部分でFargateでeBPF使えるようにしたいという話が出てQAで早々に突っ込まれて盛り上がっていた
• 個人的にもこのあたりのレイヤの機能提供の話がAWSから出てくると思ってなかったので今度の動きがやや気になるところ

Extending systemd security features with eBPF

• セキュリティまわりは大体スルーしてしまったけどsystemdでも使われているという話
• systemdでファイルシステムのタイプに応じてアクセス可否を制御したり特定のネットワークデバイスへの制御を行う実装をeBPFでしているというお話とデモ

Getting started deploying and running BCC in your Kubernetes Cluster

• Kubernetes ClusterでBCCツールを動かすステップの解説、大体以下のような流れだったと思う、まあそうりますよねいう印象
• initコンテナで カーネルヘッダをもってくる
• BCCツール用コンテナを用意する
• DaemonSetで、privilegedで動かす or capabilityをセットして動かす（カーネルバージョンが低くてcapabilityは試せてないって言ってたかも、コード的にはprivilegedとcap_sys_adminつけてそう
• 必要な諸々のボリュームをマウントする
• コードは↓なのでこれで試せる
• （しかしやはりちょっと大変だなという印象・・

GitHub - mclenhard/ebpf-summit

ということで

• 前回のサミットからもう1年経っており主にk8s環境まわりの可観測性みたいなところはまだホットなトピックなんだよなーというのがありつつ
• 個人的にはKernel5.8以降の環境がぼちぼち使えてきそうな気配を感じるので、手軽に動かせる単体のexporter実装みたいなのが扱いやすそうな気がしてきたのでちょっとやってみたいですね

WFH2021

WorkFromHomeなスタイルが本格化して1年近くなり、数々のプラクティスやイケてる超絶スタイリッシュなデスクに憧れをいだきつつも全然そこまでではない、しかし開始時よりは良いQoLを目指し幾分整った感のある弊WFH環境を書いてみるやつ。

開始時からの変化としては、クラムシェル運用にしてデスク上を広くした、可能な限りワイヤレス化した、音を幾分よくした、以上、みたいな感じで終わるわけですが、まあまあ記録として。

before

before

after

after

いやあんまり変わってない。がまあ本体をクラムシェル運用にしてデスクの下に追いやったのでそのあたりはすっきりしてよくなった感。

デスク上が広くなったので、今まで棚上に配置するしかなかった49鍵のDTM用キーボードを配置できるようになったのはよき。

keyboard

クラムシェル運用

under my desk

デスク下にセリアで調達した網を固定し、フックを3点上下に設置してmacbook pro/airを差し替えできるように配置。 
当初Bauhutteのケーブルオーガナイザーとか、あのあたりを使えばいいかなーと考えていたものの、100均チャレンジで失敗してもまあよかろうということでやってみて、まあまあうまくいったんでないかと思う。
最終的に使ったものはこの網、アイアンバー、フック類、などトータルで1000円いかないくらい。 細かい部分の固定は安定の結束バンド（これもセリアのやつ）で。

ハブ類はtype-cのハブから有線LANやらワイレレスマウスのレシーバーやらを接続して固定しており、本体を差し替えればそのまま使えるように。

キーボードはbluetoothで複数端末をswitchできるということでこいつを（フルキーボードじゃなくてよかったしthinkpadのやつなども悩んだが結局素直にmac配列使いたい、ということでこれに）

Satechi サテチ Bluetooth ワイヤレススマートキーボード (白/Mac US配列) Wireless Keyboard White ST-BWSKMS

マウスに関してはマイクロソフト製品を全面的に信用しているので、適当な2.4GHzワイヤレス接続タイプのマウスを使っている、bluetoothと違って天板を挟むと反応が非常に悪くなるので、仕方なくデスク上までレシーバーが出てくるように配置している。

その他の機材としてはモニタ＆モニターアームを導入して、アームはとても良かったのだけど、IKEAの安デスクにモニターアーム二個取り付けたら重さで盛大に傾いてしまったしタイプ動作によってまあまあ揺れるので、デスクもしっかりしたものをチョイスすべきだなあという反省。次にQoLを高めるのはこれかな・・。

その他機材

マイク

BETA57

マイクはたまたま家に二本転がっていたSHUREのBETA57とこれも使ってなかったマイクスタンドとポップガードを引っ張り出して使っている。
USBのコンデンサマイクなども良いけど、実際ノイズも結構乗ったりすると思うので、単一指向性のダイナミックマイクをスタンドで使うというのも音質面ではそれなりに悪くないんじゃないかと思う（ミーティングと英会話にしか使っていないが）。

オーディオインターフェース

WFH開始時、マイクとスタンドはあってもオーディオインターフェースがFireWire接続のものしかなく、2021年においてこいつをつなぐ術を模索するよりは昨今の安いUSB-A接続のものを合理的であろうということで割と序盤でポチったやつ。 当初Behringerの激安製品UM2 U-PHORIA を導入しそれなりに満足していたが、最近M-AUDIOから新たなる激安の刺客が来たので乗り換えてしまった。 どちらもそれなりに良かった。 UM-2の方が若干音声入出力が始まるタイミングのノイズが大きく、それだけがやや気になったが、概ね音質面ですごい差があるってほどではなく。

UM-2は5000円程度で購入しメルカリで3000円で売って利益2000円くらいだったので、結構コスパよく使えたという気分。ありがとうメルカリ。

ベリンガー 2入力2出力 USBオーディオインターフェース ブラック 1-Channel UM2 U-PHORIA

M-Audio レコーディング、ストリーミング、Podcast用USBオーディオインターフェース 1/4デュアルXLR入力端子、LINE/インストゥルメント入力端子搭載、音楽制作ソフトウェア付属 M-Track Duo

ということで

このへんはQoLの高まりとしてよかったのは安オーディオインターフェースと各種ワイヤレスソリューションというベタな感じ締めつつ。

100均チャレンジは、最悪しくじってもいいというレベルのものであれば試していくのはよきですね。

Process ExporterとTreemap for Grafanaでプロセスごとのメモリ使用量をざっくり可視化する

タイトルまま。 いい加減Grafana力を高めようと最近Grafonnetに入門し、Process Exporterをソースとした有益なダッシュボードを作りたいなーとあれこれ試していた過程でTreemapプラグインを発見し、Datadogで以前みかけたメモリマップみたいなビュー作ったら良さそうだなーということで作ってみた。

環境

Process Exporterは2環境で動かしていてOSはそれぞれUbuntu xenial、bionic

• Grafana  7.2.0
• Treemap plugin 0.5.0
• process-exporter 0.7.5

grafana.com

github.com

Process Exporterの設定

Process Exporterの設定はちょっと癖のある感じだが、どの単位でグルーピングしたいか？を定義して上から順に試行してマッチしたところにまとめられる、みたいな動作だと思っている。
のでこれはまとめたいみたいなものを上の方に条件として書いていき、最後にどこにもマッチしなかったら実行ユーザー単位でまとめるみたいな設定を書いている。

process_names:
  - comm:
    - php-fpm7.2
    - mysqld
    - memcached
    - apache2
  - name: "exporters"
    cmdline:
    - '/usr/local/bin/.+[_-]exporter'
  - name: "{{.Username}} processes"
    cmdline:
    - '.+'

exporter系はまとめたいなーとかそういう扱いをしているが、とりあえず実行ユーザー単位でまとめておけばカーディナリティも爆発せず割と推測できるレベルにまとまるのであまりがんばらなくてもいいんじゃないかと思う（ubuntuのデフォ環境だったらwww-dataだったらapacheの子プロセスだよねーとか）。

process exporterでまとまった結果はプロセス数もメトリクスとして持っているので、たとえば「長期的にapacheの1プロセスあたりが使うメモリが増えてきている」みたいな傾向をみたりするのにも使えるのでうまく使えばベンリなんでないかと。

グラフの定義

ダッシュボードが二個混在していて分かりづらいですがこんな感じで。 Treemapはtextとnumericの値をもったtable的な構造を期待しているので、Rangeとしての結果ではなくInstantオプションを指定して最新の値のみを使うように。

github.com

↑はgrezzlyでapplyすることを前提にしているのでいちおう出力結果のjsonはこんな感じ。

2021/2/14 追記

ある程度汎用的に定義しなおしてgrafana.comの方にあげてみました

grafana.com

2020

特に技術的な話でもないやつ、あまりに書く意味あるのみたいなことを書くのもどうかという気持ちになるくらいおっさんになったものの、まあなんかたまにはええやろというのと、そもそもかつてインターネッツはそういうところだったよね、という気分になったのでやる気があるうちに書いておくメモ。

SRE NEXT

sre-next.dev

人生初登壇、というわけではないのだけど「初proposal出して通ってお話したやつ」ということで結構個人的に頑張ったなあというやつ。
イベント自体も非常によかったしこれ本当に翌月以降の状況をみるにできていてよかったですねーーと思わざるを得ない。
懇親会も含め非常に体験がよかったので、次回というものがあるのか、どういう形になるのか、というか運営の皆様マジお疲れ様ですと思いつつ機会があるのならばぜひ参加したいイベント。

ちょうど人はなぜ登壇するのかみたいな話があがっていたりいなかったりするようですが、これに関しては結構思うところがあり「SREは盛り上がってるしSRE本で紹介されているプラクティスは素晴らしいが他方これは基本的にGoogleの話であり、規模もサービスの性質も異なる我々は実際どのようにこのプラクティスを自組織に適用していったり、あるいはしなかったりしているのかがみんな知りたいんじゃないの？というか自分はめっちゃ知りたいんだが・・」ということでGoogleが提示する理想と現実の我々、みたいなところをお話し、自分としては各組織感の差分を知っていきたいみたいなモチベーションで内容を考えてproposalを出すに至ったというところでした（ので内容もなるべくこういうプラクティスではあるけどうちはこうやったよみたいなところを意識してスライドを作った、つもり）。

個人的に反省点はめっちゃあり、人はおっさんになってもこんなに緊張するんかというくらい緊張したし、当初時間の少ない枠を選択し、時間に対しこれくらいの内容を提示できれば良いという方向で考えていたもののいざスライドを作っていくと連鎖的に説明が必要になる内容が増え、結果的にだいぶ駆け足になってしまい聞き苦しかったのではないかーーすいませんというところが非常にはい。

次登壇の機会があればこのあたりもっとペース配分考えてうまく作っていきたい。

英語

2018年のre:invent、2019年のSREcon19 Americasと続けて海外カンファレンスに参戦する機会があり、どちらもそれなりに良い体験であったもの、セッションをもうちょい自然に聞き取れるようになりたいなーということで人生において割と最高潮に高まっていたところ、リモートワーク環境も整ったというのもあり5月からレアジョブでオンライン英会話を開始した。 一回あたりのレッスン費用を考えると大変お安いのだが生来の貧乏性と半ば意地もありオフィシャルな休校日を除き開始から毎日継続している。基本カレンダー抑えて、超絶難しい教材を選択しない限りは会話、たのしい、くらいなのでそんなに頑張っているという感じではないがとはいえ予定があったりお酒飲みたかったりしたりする日もあるので調整しつつ継続している感じで。 出社がなくなり単に家族以外と話をする機会をもつ、という意味においてもまあ良いんじゃないかと思っている、微妙な英語力でもアニメの話したり、興味のある話をするのはまあまあたのしい。

9月頃TOEICのオンライン公開模試があって試しに家でやってみたところ800前後のまあまあよさげなスコアが取れたので、これはまあ少なくとも下がることはないだろうということで、会場の抽選にもあたったので実に16年ぶりくらいにTOEICを受けスコアを更新した。680->800ちょいくらい。

海外カンファレンスがオンライン開催になって参加しやすくのでeBPF Summit 2020、SREcon20 Americasはリアタイ参戦してみたが、レベル的には幾分ましにはなったもののやはりスピードがはやく抽象的な話に寄ってるものは厳しく、結局語彙の不足と英語発音が単純に聞き分けできてないってことで聞き分けとスピードの方は発音がーという一周まわってまあ地道にやるしかないですよねえ、ということで。
レッスンでも語彙が増えないわけではないのだけど、まあ会話だけしてても急に伸びたりはしないよねーという当たり前の話なので覚悟を決めて発音の訓練をやらんとなあ・・という結論になって終わった2020、でした、ね。ということで引き続き地味にやっていき。

技術方面

eBPF関連がたのしくBPF Performance Toolsを会社のみなさまの力を借りつつ読みすすめたりしつつ、特に現在語られる文脈とはやや違うものの、Brendan Gregg氏のいうプロダクション向けの継続的なSuperpowerなObservabilityツールとして有益な意思決定につなげる運用に持ち込みたいなーと目論んでいきたいとい2021ということで、周辺技術とか低レイヤーな方面を引き続きもうちょいなんとかしていきたいところ。

eBPF+USDTでphpをトレースしてみる、php-fpmとmod-phpでもやる

前回から気づけばだいぶ経過してましたが

dasalog.hatenablog.jp

実際phpスクリプトが動いてる環境はmod-phpであったりphp-fpmであったりするので、そのあたりは結局動かせておらず

このあたりも試してみたのでいちおう記録として。 個人的な環境のアレによりphp-fpmの方はubuntu bionic、mod-phpの方はfocalで動かしたがまあ特にやることは変わらないはず。

結局動かすためにはプロセスに対しUSE_ZEND_DTRACE=1環境変数をセットすることが必要で、「どこから仕込むことができるか？」ということだけですね、ということで基本はsystemdの設定を上書きする方法でトレースは実行できました。

環境は上述の通りubuntu前提ですがsystemdレイヤーでやっているので、他の環境でも同様にできはするかなと（ubuntu以外で--enable-dtraceされてるバイナリが提供されてるのかどうかは定かではないですが・・

php-fpm

systemdの設定を上書きするunitファイルを仕込んでみます。

sudo cp /lib/systemd/system/php7.2-fpm.service /etc/systemd/system/php7.2-fpm.service

して /etc/systemd/system/php7.2-fpm.service に Environment="USE_ZEND_DTRACE=1" を追加して設定反映、再起動すればOK

$ cat /etc/systemd/system/php7.2-fpm.service
[Unit]
Description=The PHP 7.2 FastCGI Process Manager customized
Documentation=man:php-fpm7.2(8)
After=network.target

[Service]
Type=notify
PIDFile=/run/php/php7.2-fpm.pid
ExecStart=/usr/sbin/php-fpm7.2 --nodaemonize --fpm-config /etc/php/7.2/fpm/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID
Environment="USE_ZEND_DTRACE=1"

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl restart php7.2-fpm.service

おもむろにbpftraceでトレースすると対象プロセスでUSDTがトレースできることができる。

$ sudo BPFTRACE_STRLEN=200  bpftrace -e 'usdt:/usr/sbin/php-fpm7.2:execute__entry { printf("%s, %d\n", str(arg0), arg1); }' -p `pgrep -u www-data php-fpm|head -n1`
Attaching 2 probes...
/var/www/html/info.php, 2
, 0
/var/www/html/info.php, 2
, 0
...

probeが二個あることになってるのはなんでやろ・・。とりあえず動きはしたのでヨシ。

mod-php

php-fpmと同様にsystemdの設定に書くか、apacheのenvvarsで設定する、どちらでもとりあえず動かせはする。

$ cat /etc/systemd/system/apache2.service
[Unit]
Description=The Apache HTTP Server Customized
After=network.target remote-fs.target nss-lookup.target
Documentation=https://httpd.apache.org/docs/2.4/

[Service]
Type=forking
Environment="APACHE_STARTED_BY_SYSTEMD=true" "USE_ZEND_DTRACE=1"
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl stop
ExecReload=/usr/sbin/apachectl graceful
PrivateTmp=true
Restart=on-abort

[Install]
WantedBy=multi-user.target

or

/etc/apache2/envvars に export USE_ZEND_DTRACE=1 を追記しておく。

おもむろに子プロセスにアタッチしてみれば動く、こちらの環境はlibphp7.4が使われてるのでこんなかんじで。

$ sudo BPFTRACE_STRLEN=200  bpftrace -e 'usdt:/usr/lib/apache2/modules/libphp7.4.so:execute__entry { printf("%s, %d\n", str(arg0), arg1); }' -p `pgrep -u www-data apache2|head -n1`
Attaching 1 probe...


/var/www/html/test.php, 2
/var/www/html/test.php, 2
/var/www/html/test.php, 2
...

その他

bpftraceで --usdt-file-activation 使えるとプロセス特定してアタッチみたいなところが幾分楽できそうな気がする。

--usdt-file-activationは/proc/[0-9]*/maps覗いてアタッチすべきプロセスを見つけたらアタッチするという流れっぽくてpid指定しないで動くのは楽ちんだけど当たり前ながらpid変わったら追っかけられないのでちょっと楽くらいの位置づけかなあ https://t.co/PNV9lIWDsF

— EG (@EGMC) 2020年12月26日

まとめ

ということで若干あやしいところもありつつトレース自体は動かせた。

いずれにせよ USE_ZEND_DTRACE=1 したプロセスしかトレースはできないし、php-fpmにせよmod-phpにせよ子プロセスは入れ替わっていくので、アドホックなトレーシングはともかく「追っかけ続ける」仕組みをつくるのはしんどそうだなーとか、例えばexecute__entryを逐一標準出力に出していくみたいなのはもちろんプロダクションでおもむろにやるにはオーバーヘッドが許容できないであろうということは容易に想像でき、じゃあBPF_MAPを使うのか、どの粒度で情報を保持するのか、そもそもそここまでしてUSDT使うのか、みたいなところでやはりなかなか使い所はむずかしいなーという印象です。動かせるのは楽しいんですけどね。

全体に雰囲気で動かしているのでもっとうまくやる方法があればすごく知りたいところ・・。

参考

ubuntuのsystemd設定上書きについてはこちらの記事を参照させていただきました

第598回 systemdユニットの設定を変える：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社