今年もMackerel CREの仕事に絡めて技術素振りしていた、という話
Mackerel Advent Calendar 2024 19日目の記事です。昨日は同僚の id:masarasi さんの「プログラミングほぼ未経験の私がプラグインにオプションを追加した話」でした。初挑戦、いいですね。
私はMackerel CRE（Customer Reliability Engineer）のカスタマーサクセスユニットに所属しています。お客さまと直接に会話しながら、Mackerel導入前の技術的不安を取り除いたり、導入支援をしたり、新しい機能をご紹介したり、その他お困りごとに対応をしたりというのが主たる活動です。さらには開発チームへのフィードバック役として、お客さまの声を届け、一緒にどうプロダクトを改善できるかを議論し、実装を後押ししています。私の場合は実際にPR書いたり提案のためのツールを作ったりすることも多めです。
特に今年はオブザーバビリティプラットフォームを打ち出してMackerelの新たな面を見せていくぞという動きに合わせて、メトリック課金モデルの導入、OpenTelemetry正式対応に合わせた新機能群、大規模ユーザー向けのSAML機能の公開など、CREも試行錯誤しながら新しいことを進めていく多忙な1年でした。
そんなポジションにおいて、お客さまに安心いただける説明を行い、開発チームと同じ言葉で議論を進めるためには、日々の技術素振りが欠かせません。
素振りなので表には出していないこともたくさんあるのですが、いくつかはブログに出していましたので、2024年のMackerelに関係の深い過去記事を振り返ってみます。
OpenTelemetryのシグナルを収集・フィルタリング・送出するOpenTelemetry Collectorは重要な役割です。特にmackerel-agentのプラグインとの比較が今後問われるだろうなと予想し、receiverをひととおり見ていました。
既存のmackerel-agentプラグインに相当するreceiverがない場合でも、mackerel-agentプラグインからOpenTelemetryのメトリック投稿に変換することはできるのではないか、という発想で実験していました。
ログ監視のcheck-logプラグインのアラートは、ログにずっと出続けているものでなければ（もう出なくなっているため）すぐに自動クローズされることになります。これが嫌なときにはprevent_alert_auto_close = trueを使う……といってもこれはこれで蓄積することになるので微妙ですね。
ほかのオブザーバビリティサービスでは一定期間後にアラートをクローズするという機能がある、というのを目にして、シェルスクリプトで時限クローズするものを書いてみました。
SNMPメトリックプラグインのmackerel-plugin-snmpを設定する際、OIDを探すのが大変めなのと、Windows向けの良いOSSがないという状況があります。これに対して、お客さまへのご提案に使えないかなと思って作りました。
作っているうちにSNMPの理解も深まったので、良い挑戦でしたね。
RubyでOpenTelemetryのメトリックを送る方法について、お客さまから問い合わせをいただいたのを機に、深掘り調査してみたものです。
SDKでの計装は他の言語も含めて初めてだったので、ドキュメントをひきながら試していました。
ちなみにもうmetricsのPRはマージされていて、実験版扱いではあるけれども使えるようになっているようです。
思索中心ですが、シナリオ監視について考えていました。
世の中のVRT・E2Eテストなどをいろいろ調べたりしていましたが、結論は出ていません。
通常の外形監視よりはだいぶ激しいことができるため、悪用されてしまうと困りますが、そのあたりは他社さんはどうしているんでしょうね。もし画面描画は重要ではなくリクエストとレスポンスの連続で見るのでよければ、id:arthur-1 さんの「mackerunn: runnで実行したシナリオ監視の結果をMackerelに投稿するツール」もよさそうです。
kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com
怒涛の3部作。
背景としては、お客さまにEC2オートスケールとMackerelの自動退役・ロールグラフの対応をご説明する機会をいただいたことによります。
それまでの手持ちのデモは単純なスケジュールベースのスケールで、負荷に応じたオートスケールではないため、口頭の説明とそぐわないな……ということをずっと感じていました。
今後営業メンバーなどが使うことも想定すると、リクエスト数調整の制御についてはシェルの引数などでやるよりもMackerelのWebコンソール上でやったほうがよかろう、と考えてやや大がかりな仕掛けとなっています。
しかしEC2だとやっぱりスケールの追従が遅いので、コンテナで調整したくなるのがよくわかりました。
Mackerelに加わった分散トレースサービスVaxila。Mackerelによるオブザーバビリティの重要なキーとなるものですが、理解を深めるためやお客さま向けに小さなデモがほしいなと思い、チャレンジしました（otel-demoはでっかすぎる）。
この当時はVaxilaまだ荒削りだなぁと思っていたけれども、最近は毎日改善が進んでおり、日本語UIも提供されるようになっています。気付いたことを開発チームにフィードバックしていてだいぶ大変な量になっていますが、お客さまにとって使いやすいサービスにしていきたいなと思っています。
また、HotRodデモのほうは、分散トレーシングの効用がわかりやすいものを目指して独自の魔改造を今も続けています。これについてはいずれ記事にするかもしれません。
お客さま質問由来で、簡単にできそうだという思いで作ってみました。
計測精度自体はしょせんpingレベルではあるのですが、Goの並行実行をこの機会に使ってみたり、グラフの定義や重ね合わせの使い方を学んだりと技術的には得たものが大きい経験でした。Goでのプラグイン実装にだいぶ慣れてきています。
ということで、今年もいろいろ素振りをしてきました。来年もMackerelが機能開発を進めていくのに合わせて、素振りを続けていきます。
Mackerel Advent Calendar 2024の明日は id:lufiabb さんです。