LinuxにおけるMonitoringツールごとの使用メモリ算出いろいろ2023

サマリ

• Linuxにおいて使用メモリの情報はだいたい/proc/meminfoの情報から計算されるが、計算式にゆらぎがあって異なるツールやSaaSエージェントを使うと結果が異なることがあるので故あって調べた
• ダッシュボードの表示とfree(1)の結果が異なるなど
• 2023現在使用メモリはだいたいMemTotal-MemAvailableということでOK
• free(1)などprocps依存なコマンドもMemTotal-MemAvailableをUsedとして扱うようになる
• 稀に計算式が異なるケースもあるのでおかしいな、と思うことがあれば一応まだ気にしたほうがよいことがあるかもしれない
• ツールをまたぐ時は特に

各種SaaSやツールの状況

procps

• v4.0.1からMemTotal - MemAvailable、それ以前はMemTotal - MemFree - Buffers - Cached - SReclaimable
• 変更の経緯としてはコミットログからリンクされているが最終的にカーネルが推定する使用可能なメモリ以外をUsedとして扱うことになった
• v4.0.1のリリースは2022/10/20でubuntuの現行LTSであるjammyで入ってくるバージョンはまだ3.3.17であり、将来的にバージョンアップが進んで4.0.1が取り込まれるとfree、top、vmstatなどprocpsを利用するツールも計算式が変わると思われる

gitlab.com

gitlab.com

Datadog

• MemTotal - MemAvailableを出している
• datadog-agentの実装をみるとAvailableの計算はshirou/gopsutilに依存していて、カーネル3.14より古い場合はこのアルゴリズムをベースに計算されているっぽい

github.com

github.com

Mackerel

• MemAvailableを使える場合はMemTotal - MemAvailable、使えない場合はMemTotal - MemFree - Buffers - Cached（SReclaimableは含まれない）

github.com

github.com

node_exporter + Grafana Dashboard

• node_exporterは/proc/meminfoをそのまま出力するのでダッシュボードの作り方に依存する
• Node Exporter Fullの現在のバージョン（Revison29）においてはmemory basicの方はnode_memory_SReclaimable_bytesを考慮するようになっていてRAM Usedはtotal-availableになっている
• 細かいバージョンは不明だが過去のバージョンではmemory basicの計算はSReclaimableを考慮しないMemTotal - MemFree - Buffers - Cachedだった

grafana.com

GCP（Ops エージェント）

この VM が使用したメモリの割合（ディスク キャッシュを除く）。Linux VM の場合はカーネルメモリも除外されるため、ユーザー空間のみの使用量になります。

• メモリ使用率が上記の説明でMemory Usageにはusedというメトリクスがあるが、procpsの仕様とは違ってMemTotal-MemAvailableよりは低く、MemTotal - MemFree - Buffers - Cached - SReclaimableよりは高い値が出てるっぽい
• 気が向いて時間があれば調べる

余談1 SReclaimableを入れるか入れないのかについて

• procpsの実装はfreeのマニュアルにもある通りcachedが/proc/meminfoでいうところのCached+SReclaimableなので、Availableを使う計算式以前にMemTotal - MemFree - Buffers - Cachedという計算式がダッシュボードでよく採用されていた経緯が気になる（freeやtopの結果の結果と異なることになるので混乱があったのではと思うが）（単に読み違えたのか他に理由があったのか）
• SReclaimableが含まれる場合、slab cacheは長期的に増えるので、生存期間の長いサーバでUsedが増えているように見えてユーザーが実行しているアプリケーションでリークが疑われるケースなどがあった（世の中的にもあったんじゃなかろうか
• かつてあったこれとかもUsedに含まれて表示されると混乱したんじゃないかとか

余談2 Mackerelのめちゃ細かい話

• Mackerelのグラフで表示される数値とfree -mの結果が微妙にずれるのだけどどうもこれはよくあるMB、MiBの違いっぽい
• グラフ表示画面のリクエストみるとメトリクスはbyte単位で返しているのだけどグラフ描画時に単位ごとに/1000して表示してる模様
• 単位はMB、GB等で表示されてるので間違いではないのだけど個人的にはMiB/GiBにしてくれると良いなあと思っている

SRE NEXT 2022で「プロダクション環境の信頼性を損ねず観測する技術」というお話をしました

登壇＆参加エントリです。

ややエモよりになる予定。

当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としてのZoom Event体験はかなり良かった、ブースの仕様はやや残念ではあったが個人的にはそれでも楽しめた）、まあ同じことを書いてもということで発表まわりや個別の参加体験の方を書いていきます。

登壇について

プロダクション環境の信頼性を損ねず観測する技術というタイトルで登壇させて頂きました。 6/9時点でまだスライドのみですが、ぼちぼちアーカイブの方も上がってくるかなと思います。

www.youtube.com

前回2020の登壇から2年、SRE NEXTが開催されたら何はともあれproposalは出したいと考えていたので募集の段階でネタを考えました。

ネタは2本考え、1つは長期運用した監視システムの移行についての事例を話すというものでしたがこちらはボツにして監視まわりのトラブルからのLesson Learned的な話一本に絞り、無事採択されました。

前回登壇の反省点として20分セッションに対して必要な背景説明が多くかなり駆け足になってしまったというのもあり、事例紹介もいいけどテーマ絞って背景はコンパクトにできれば聞く側も何を持ち帰ればよいのか？という部分に集中できてよいだろうという判断だったのですが、そうはいっても3事例入れて結果的に駆け足気味になってしまったという反省があります。次はもうちょっとうまくやりたい（再）。

狙いとしては、世の中エージェント入れてGet Startedしたらすぐにオブザーバリティが達成できますよみたいな紹介が多くあり、まあそれはそれで間違ってはいないのですが実際トラブルもあるし結局地道にエンジニアリング的な解決が必要になりますし、できれば実際に障害になる前にこういうことを考えたいよね・・ということで一部の人には刺さるかなーと思ってこういった内容にしました。

他方当日までこれ需要あるのかという不安もありましたが¹、これも一つのSRE DIVERSITYということで（多分）採択していただき、技術的な理由によるサービストラブル事例みたいなお話がそれほどなかったというのもありありがたいことにはまった方もいたのではないかという感触でした。よかった。

次回以降、ちょっと現時点で不確定なことはありつつ、できればまた開催して頂ければproposal出したいし、たとえ通らなくても継続的に参加していきたいですね。

セッション、参加体験まわり

自分は特段コミュニティにがっつりというタイプでもないのですがぼんやりとtwitterでやってるなーと思っている方々と久々にお話する機会などありこういうのもトピック広いイベントの良さよなあと思うなどしていました。

全体の体験については冒頭に書いたんですがコミュニケーションツールがtwitterに寄せられてたのは個人的には良かったですね。

セッションについては諸事情によりメモにアクセスできなくなってしまっているのでいくつか思い起こしながら少し書くと、やはり（内容は雰囲気なりに）yuuk1さんのAIOpsのお話は面白く、これは特にご本人に伺ったわけではないので想像ですが課題感の設定やアプローチに実際のサービス運用経験が反映されてるんだろうなーと思いながら聞いてました。自分は監視システム運用する方なので、「これやるために大量のメトリクス扱わないといけないのでそっちはそっちでコストが・・」とか考えがちですが、こういった仕組みが人間の意思決定補助してくれる世界は期待したくなるところ。

LINEのmaruloopさんのお話、fujiwaraさんのお話はそれぞれポストモーテムの運用に関する話で、このあたりは自分とこでも課題があり、最近だとシステム運用アンチパターンの9章「せっかくのインシデントを無駄にする」を眺めつつ、まあいきなりかっちりやるのは難しいにせよ、共有文化ややり方については大いに参考にしたいですねという気分になりました。

SRE DIVERSITY

これは誰に向けてなのかというところですがまあ個人的にこれでいいのではというメモとして、SREに関するトピックは非常に広く²、各社それぞれ組織的な取り組みをしていて素晴らしいと思うのですが、他方やはり結局解決しなければならない課題は組織のフェーズ、規模等々によって異なりますし、それぞれ必要だと思うプラクティスを取り込んで行けば良いし合わないものは無理に頑張る必要ないと思います。このあたりは技術選定に対する考え方みたいなのとあまり変わらないかなと。

自分に関していえば2020当時は自身の課題意識としてアラートなんとかしたい、という思いが強くそこにSRE本で提示されている考え方、プラクティスがはまったので自組織に合わせて適用していったという感じで特段それに関して「SRE導入しましょう」みたいな話はしなかったですし、そういったほうがうまくいくのであればすればよいのではくらいに考えてます。

やりたいことは目の前の課題をどうにかしたいであって、SRE的な考え方がはまればそれでいいですし、これは合わないとかtoo muchですねみたいなものはスルーする、SRE implements DevOpsだけど実装はある程度合わせたほうがワークするし、なのでSRE DIVERSITYということになるんだろうなあと（いや別にそういうわけではないというツッコミが入るかもしれませんが自分なりに）勝手に解釈しつつ、粛々と課題解決やっていきましょうという気持ちを述べておきます。

最後に運営各位楽しいイベントをありがとうございました。ささやかなブログポストであれですがこちらでも感謝を述べつつ締めたいと思います。

---

1. 完全に余談ですがテーマ的には2020の方がproposal出して通るだろうという自信があり、他方今回は人をやや選ぶからどうかなあと思ってました↩

2. 実際USENIXのSREConもかなり広範なトピックが取り扱われますし、LISAが21で終わりになってSREConに統合されそのあたりの大規模インフラ寄りな話も今後増えてくるのかなと思ってます↩

オンコールアラートアンチパターン

オンコールアラートを設定しようと考えた際に考慮すべき点を自分なりにアンチパターンとしてまとめたなにかです。

ホワイトボックスモニタリングにより得られたメトリクス、ログなどからアラーティングを行う、または併用する環境を想定しています、ブラックボックスモニタリングによるアラート、SLOベースのアラートのみでうまく運用されているサービスにはあてはまらないと考えてます。

参考書籍は色々あり、最後に記載していますが提示されてるプラクティス通りではないものもあります 。自組織、システムにあった設計をしましょう。

システムの監視がまったくありませんみたいな状況であればまずはサービスのURLに対する外形監視からはじめましょう。

言葉の定義

• オンコールアラート：ここではSRE本でいうところのページ、担当エンジニアに電話をかけるなど即座に対応を求めることを目的としたアラート
• runbook：ここでは発生したアラートに対してより詳細な文脈を与え、問題特定のためのステップ、想定される対応方法などを記載したドキュメント

アンチパターン

サービスに対する外形監視が設定されていない

• その他のオンコールアラートを設定する前にまずサービスに対する外形監視を入れましょう
• 監視先はサービスが機能していることを確認できる（機能するために必要なデータベースなどにもアクセスする）エンドポイントを用意し、ロードバランサーで使うヘルスチェックエンドポイントとは分け、dbアクセスなどを伴いある程度のコードパスを通るよう設計しましょう
• よほどの理由がなければ自前運用よりはSaaSを使いましょう、クラウドベンダーの提供するものでも良いです
• 可能であれば複数のロケーションから監視できると良いですが、最低限複数回のチェックがサポートされていれば良いでしょう（一発NGを避ける、後述
• 外形監視によるアラートの通知経路はその他のアラートとは分け、監視システムそのもののダウンによるリスクを分離し相互に補完できるよう設計しましょう
• サービスに対する外形監視が設定できていれば、後述のそれ以外のアラート設定で問題があった場合でもカバーできますし、サービスに問題があった時に見落としてしまう->アラートを厳しく設定しなければならないという欲求を抑えることができます

アラートを受け取って直ちに何かアクションを行う必要がない

• アラートを設定したい理由が「検知をしたい」であればまずは流量に気をつけつつチャットへの通知など情報を伝えるだけでよくオンコールアラートである必要はありません
  • 検知してから判断したい、でオンコールアラートを設定してしまうと大半は実際にアクションを行うことなく終わるのでアラート疲れを招きます
• 近いうちにアクションしなければならないが、直ちに行う必要がない（例えばストレージの不足が近い将来に起こる場合など）ケースは運用者が利用しているチケットシステムへ連携、それが難しい場合はチャットにアクションを行うための専用のチャンネルを用してそこに通知するなどすると良いでしょう
  • チャット通知を利用する場合、必ずアクションのいる通知とそうでないものを分けるのがおすすめです
  • 単に気になる情報を流しているチャンネルと同一のチャンネルを利用すると要アクションな通知が埋もれてしまいます、可能であれば担当者が見落とさないよう明示的な通知にしておくのがよいでしょう

アラートに対応するrunbookが存在しない

• 新規のオンコールアラートを追加する前に必ず対応するrunbookを用意しましょう
• テンプレートが存在しない場合はgitlabのテンプレなど既存のテンプレートを参考に作成しましょう、自組織に合わせて必須項目は少なく設計するのが良いです
  • 必須項目が多く、完璧さを求められると記載のためのハードルがあがりrunbook自体の運用が滞る危険性があります
  • 最小の項目で追加し改善のサイクルを早く回せるようにする方が良いでしょう
• runbookで完全な復旧手順を目指す必要はありません、エンジニアがオンコールアラートを受けて対応するということは対応にスキルをもったエンジニアの能力が必要であるということで、誰でも実行可能なコマンドの指示で対応できるのであればそれは自動化可能なものです
• 長期的に機能し、詳細すぎず、対応するエンジニアにとって復旧のための調査に必要となる情報が記載されているrunbookを用意しましょう
  • 短期的な問題に対するアドホックな対応を記載する場合、そのことをrunbook自体にも明示しておくと良いでしょう
  • 問題解決時にアラート自体をなくせる、将来的に内容が役立たなくなる可能性があることがわかります
  • 過去に担当したチームメンバーが設定したアラートは消していいのか判断が難しくなるため、そういった文脈を付与するためにも有用です
• 用意したrunbookは必ずアラートとセットで通知できるようにしましょう、アラートのmetadataなどを利用してメッセージに含めるのも良いですし、特定の命名規則に応じて自動でドキュメントにマッピングできるとなお良いです

自動対応可能なアラートである

• runbookの内容が決まりきった復旧手順（特定のプロセスの再起動を行う、インスタンスなどを単純に入れ替えるなど）となる場合それは自動化可能かもしれません
• 自動化というと敷居が高い感じがしますが、例えばAWSであればssm-documentなどを経由してインスタンスで特定のコマンド群を実行するといったことはそれほど難しくありません
  • 例えばAWSであればまずrunbookに記載する-> 一連のコマンド群をssm documentで用意して手動実行可能にする->自動実行にする　といった段階的なフローで導入していくことができます
• いきなりの自動化は難しくても、まずrunbookに手順を示し、必要に応じて将来的に自動化を行うのも良いでしょう

しきい値を設定するのに十分な情報がない

• しきい値を設定するのに十分なデータが集まっていない状態でオンコールアラートを設定すべきではありません
• いきなりオンコールアラートを設定するのではなくまずはwarningレベルでアラートを設定し、最低でも一ヶ月以上（サービスによっては大きなイベントが一巡するくらいの期間）運用しfalse positiveなアラートが発生していないか確認しましょう
• false positiveが含まれる場合はしきい値を調整し確実にまずいと判断できるものだけを捉えられるよう調整しましょう

一回のNG判定で発報される

• しきい値を超えた/ログが出力されたらいきなりアラートが発報される設定になっている
  • 複数回連続して発生したら、一定時間続いたら（prometheusのalertruleにおけるfor: N、CloudWatch AlarmのDatapoints to Alarmなど）という条件を基本として設定しましょう
  • 一回のチェックに失敗したら即発報といった設定はクラウドサービス上のインスタンスで一時的にネットワークが不安定になったというだけで深夜にエンジニアを起こすことになり、そういったことは実際のところ結構な頻度で発生します
  • 発見が遅くなるのではという不安はもっともですが、深夜にアラートを受けて対応を開始するまでにはそもそも時間がかかりますし、実際のところ即時に発報されたアラートに対して対応者が最初に取るであろうアクションは「継続してるかどうかメトリクスを確認する」になりがちです
• 結局のところ機械的な対応は機械がやる方がぶれがなく、人間に負荷をかけることもありません

追加（のみ）されていくアラートルール

• アラートルールは定期的に見直され、不要なアラートは削除され、しきい値は調整される必要があります
• アラートはなにか問題があった際、とりわけ既存ルールで見落とされたタイミングで追加されていきますが、意図的に機会を作らない限りなかなか減らされることはありません
• アラートルールもメンテナンスコストがかかりますし、多すぎるアラートルールはやはりアラート疲れを招きます
• 定期的なフローにアラートの見直しを含めましょう

参考

• Google - Site Reliability Engineering
• Delete All Your Alerts – Robust Perception | Prometheus Monitoring Experts
• O'Reilly Japan - システム運用アンチパターン
• Effective Alerting in Practice

各ディストリビューションの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均チャレンジは、最悪しくじってもいいというレベルのものであれば試していくのはよきですね。