2023-08-02

ITエンジニア男育休時のちょいTipsとか買ってよかったやつとか

こちらを最近読んで

takumif.hatenablog.com

一年前の記事ですがめちゃよくまっていてすばらしいですね。

当時子が産まれるちょい前くらいのタイミングで男性育児系の記事いくつか読んだのだけどこれ読んでなかったなと思ったら時期が微妙にずれていたのでした。育児中、だいたい手が空かないのでぴよログのalexa連携はめちゃ良いですね、皆使うと良いと思う。実装してくれたぴよログの人ありがとう。

ということで、最近育児記事みたいなのも増えてきましたが自分も覚えてるうちに少しは書いておこうという気持ちで、サンプル1/1程度のなにかをざっと書いてみましたなやつです。

どんな状態だったか

最初の子
育休期間は4ヶ月弱
夏生まれ
生まれてから一ヶ月ちょいまで妻の母が泊まりでサポートに来てくれていた

我が家の場合

基本的な役割分担
- 自分と妻が交代で子のお世話
- 妻の母が家事サポート
- 実際は家事以外も色々サポートしてもらえたのでだいぶ助かった
件の記事と同じく基本二交代制で、夜勤（と呼んでいた深夜担当）を交互にやっていた
- リビングにベビーベッドおいて、担当するほうが横にふとんを敷いて寝るスタイル
- 最初から交代でいくつもりだったが、出産後の母親はダメージがでかいので床から起き上がるのが困難であり当初一ヶ月はまるまる自分が担当していた
- 夜勤時は3回ミルクタイムが挟まるが、ここは割とがんばって最適化すると自分も寝やすくなるので
  - 予想時間のちょい前に起きて
  - 調乳を済ませ（この間に起きて泣きだしてもいったんスルー）
  - おむつを替え（濡れてるかどうかは気にせずに投機的実行として毎回やる、赤ちゃんめちゃおしっこするのでどうせ高確率で替える必要がある）
  - ミルクを飲ませて寝かしつける
- というフローに最終的に落ち着いていた
- ミルクが一番落ち着くので、これを最後に持っていくようすると寝付きがスムーズになる
育休開始と終了のタイミング
- 予定日の1週間程度前から有給使って開始
- 復職タイミングはだいたい4ヶ月後
- これはめちゃくちゃ子供のタイプに依存すると思われるので自分の場合はー、だけども実際問題タイミングとしてはちょうど良かった
- この時期は睡眠が落ち着いていて（3ヶ月くらいから急に朝まで寝るようになった）、離乳食がまだ始まっておらず、一時的にちょっと楽になったタイミングだったので割となんとかなった

やってよかったこと

サンプルはもらえるだけもらう
- 子が生まれたらベビー用品店でサンプル特典的なものがもらえるので近場でもらいましょう、我が家は西松屋とベビーザらスがあったので両方もらった
- 新生児期は一ヶ月しかないので、どのメーカーが合うのかとか試しているうちにあっという間に過ぎてしまうので、子の体型にあったものを選ぶのにサンプルでちょっとずつ試してみるのがよいですね
- 我が家は哺乳瓶の消毒はコンビの除菌じょ〜ずを使っていたので、たまに実家に買える時などはミルトンを使っていたけどこれくらいであればサンプルでも十分足りてしまう
産後の育児相談
- 産院で初回は無料で相談に乗ってもらえるやつに行った
- 両親学級みたいなもの（だいたいオンラインだった）はあるものの父親はなかなか実際に対面でアドバイスを貰える機会がないのでこれはとても良かった
- 個人的には沐浴やらその他のお世話より何より縦抱きが腕に負担がかかってしんどかったのでこのあたりであったり、ワンオペ風呂のやり方などかなり参考になった
簡易ベビーモニター
- 家ではベビーモニターを使えばいいが、出先では即席のベビーモニターとしてPCとスマホでMeetなどでビデオ通話を繋いでおくというのをやってみたら割とよかった
- 実家などでお昼寝をさせている間など別室から様子がわかるのでおすすめ

買ってよかったもの

温度指定可能な電気ケトル
- とりあえず一回100℃で煮沸しておいておき使うときに80℃にして使う
- 温度をキープする機能もあったりするが1hとかなのでほぼ使わなかった（次の調乳のタイミングまでにはどうせ冷めてしまう）、十分はやく沸くし狙った温度になるのでそれだけでOK
電動鼻吸い
- 自分＆妻は口で吸うタイプの鼻吸いが使いこなせなかったので、割と早い段階で導入した
- 3ヶ月くらいまでは鼻が詰まってしまうとミルク飲み時に苦しくなくってぐずるというコンボになってしまうことがありそういう時にかなり重宝した
- 安くはないものの成長していっても使うのでヨシ
イブルマット
- 義弟氏のおすすめで出産祝いで一畳ちょいくらいのを一枚もらい、その後同じサイズのを買い足した
- 乾きやすい、毛玉的なものが出ない、などでかなり重宝
爪切り
- 我が家は爪切りが怖かったので基本爪やすりで済ませていた、赤ちゃん爪柔らかいので割とこれだけでダイジョブだった
- ある一定のライン（1歳が近づいたあたり）を超えたら大人と同じ爪切りに移行
アリエクで買ったやすいスマート温度湿度計
- 夏の間だったのでとりあえず新生児期くらいは環境的な要因でなにか不快になる要素はなるべく減らしとこうと思い、これで26-28℃、湿度40-60%でアラーム設定してせっせと温度調整したり除湿機の水を捨てる仕草をやっていた

これではなかったけど同じようなやつを使ってた

ケトル、温度がみえてかっこいいけどお湯を入れすぎるとやや蓋が開きづらい、もうちょいシンプルなやつのほうが使いやすいかも

鼻吸い、後発品ということでお高かったけど構造的にチューブの部分に鼻水が入ってこず先端を洗って除菌じょ〜ずで消毒すれば良いので運用は結構楽だった、見た目もシンプルでよい

使わなかった / 使えなかったもの

手動鼻吸い
- ↑の通り使いこなせなかった
赤ちゃん用綿棒
- 小さいのでいまいち使いづらく、大人用綿棒でよかった
- ワセリンと組み合わせて耳掃除するのに重宝
おむつ替えシート
- 黄色い専用シート的なものをベビーザらスで買ってみたが我が子は動きがダイナミックだったせいか破けるしあまりよくなかった
- ペットシーツがサイズ的にも耐久性的にもちょうどよくておすすめ
コンビ以外の肌着
- 短肌着とかあまり着なかった、だいたいずっとコンビで、洗濯さえ回ってれば意外と少ない枚数でいけてしまった

2023-01-22

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

monitoring

サマリ

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

Datadog

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

github.com

Mackerel

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

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にしてくれると良いなあと思っている

2022-06-09

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

sre

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

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

当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としての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ということになるんだろうなあと（いや別にそういうわけではないというツッコミが入るかもしれませんが自分なりに）勝手に解釈しつつ、粛々と課題解決やっていきましょうという気持ちを述べておきます。

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

完全に余談ですがテーマ的には2020の方がproposal出して通るだろうという自信があり、他方今回は人をやや選ぶからどうかなあと思ってました↩
実際USENIXのSREConもかなり広範なトピックが取り扱われますし、LISAが21で終わりになってSREConに統合されそのあたりの大規模インフラ寄りな話も今後増えてくるのかなと思ってます↩

2022-05-23

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

sre monitoring

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

ホワイトボックスモニタリングにより得られたメトリクス、ログなどからアラーティングを行う、または併用する環境を想定しています、ブラックボックスモニタリングによるアラート、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など）という条件を基本として設定しましょう
- 一回のチェックに失敗したら即発報といった設定はクラウドサービス上のインスタンスで一時的にネットワークが不安定になったというだけで深夜にエンジニアを起こすことになり、そういったことは実際のところ結構な頻度で発生します
- 発見が遅くなるのではという不安はもっともですが、深夜にアラートを受けて対応を開始するまでにはそもそも時間がかかりますし、実際のところ即時に発報されたアラートに対して対応者が最初に取るであろうアクションは「継続してるかどうかメトリクスを確認する」になりがちです
結局のところ機械的な対応は機械がやる方がぶれがなく、人間に負荷をかけることもありません

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

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

参考

2022-02-26

各ディストリビューションの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

2021-09-22

sysload exporterを実装してみた

monitoring

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

github.com

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

f:id:egmc:20210918175302p:plain — 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のマウントパスオプションを追加する

などなど

2021-08-22

eBPF Summit 2021

bpf monitoring

今年は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実装みたいなのが扱いやすそうな気がしてきたのでちょっとやってみたいですね