はてなブックマーク

o11y界隈でOBIが熱いらしい。OBI、OpenTelemetry eBPF Instrumentation。実行しているプロセスや通信に対し、カーネルが提供するeBPF機能で割り込み、OpenTelemetryのシグナルとして送信できるというもの。 opentelemetry.io Goのゼロコード計装でもeBPFを使っていたね。 kmuto.hatenablog.com ということで、こういうケースではOBIが活躍できるかもしれないというサンプルを作って試していく。 お題のPHP 7アプリケーション OBIとOpenTelemetry Collectorの設定 計装結果の確認 データベースクエリの表示 制約と可能性 お題のPHP 7アプリケーション ここでは例として「PHP 7.4でLaravelを動かしている」という状況を考える。データベースとしてはMySQLを想定しつつMaria

OpenTelemetryのトレースゼロコード計装は、たいていフレームワークの利用を前提としており、PHPも例外ではない。しかし、フレームワークを使わないアプリケーションはいまも広く存在する。そのような状況で、アプリケーションコードにできるだけ手を入れずに計装できるか、しばらく試行錯誤していた。 当初は素朴にNGINXでの計装や一部PHPコードの改変、ライブラリ計装から始めたが、最終的にリクエストに対する「ゼロコード計装っぽいもの」を錬成した気がする。 題材とするアプリケーション ゼロコード計装っぽいものの仕組み 試行錯誤（1）：NGINXの計装チャレンジ 試行錯誤（2）：PHPコードに直接計装 試行錯誤（3）：データベースアクセスの自動計装 試行錯誤（4）：auto_prepend_fileとauto_append_fileによる計装の隠蔽 あとがき 題材とするアプリケーション 構成はシ

ネットワーク機器などに利用されるSNMPのそれぞれのオブジェクトはOIDという識別子で整理されており、このOIDはツリー構造になっている。どのOIDがどういうものを表すかは、MIBというデータベースに定義されている。ASN.1という抽象構文で、人間がこれを拾って読むことはあまり想定されていない（少なくともOIDと紐づけて探すのは人間では無理）。 で、これを見るためにMIBブラウザというソフトウェアジャンルがあるのだが、Linux・macOS・Windowsどれもあんまり良いOSSがない。Linuxではtkmibくらい（Tk…）。 対策の1つとしてOIDと説明をCSVで書き出す『miburi』を過去に作っていた。 kmuto.hatenablog.com しかし、やはりツリー構造をたどりたいケースも多いので、Geminiに聞きながらWebアプリケーションとして今回作ってみた。その名も『MIB

OpenTelemetryのトレースシグナル取得をする上で、ユーザーの属性に応じてサンプリングを調整したいことがある。たとえば以下のような具合だ。 userType=freeの場合は1%サンプリング（1%拾い、99%は廃棄） standardなどほかのuserTypeの場合は全サンプリング（全部拾う） テールサンプリングかな？と思うところだが、これは少々問題がある。 tail_sampling: decision_wait: 10s policies: - name: free_sampling type: and and: and_sub_policy: - name: match_free type: ottl_condition ottl_condition: span: - attributes["userType"] == "free" - name: probabilistic

@matsuuさんのポストより。 x.com Docker Hub、2025/03/01から認証なしでのimage pullはIPアドレス毎に1時間あたり10回までに制限。認証してもPersonalはアカウント毎に1時間あたり40回まで。まじかよ。いよいよ厳しくなってきたな。 / “Usage and limits” https://t.co/hJWuR41b9G— matsuu (@matsuu) 2025年2月23日 x.com これ、先ほどサイト確認したら書き変わってて、2025/03/01→2025/04/01になってた。 Personalアカウント上限も40回→100回 でも認証なしの10回まではそのまま。— matsuu (@matsuu) 2025年2月23日 これはつらい。 最近業務でトレーシングハンズオンをした折に、配布のために魔改造Jaeger HotRODデモをDoc

ITエンジニアリングに対する理解が深く、開発チームと（embededレベルで）密接に連携しながら、ユーザーに伝わるヘルプドキュメント・マニュアルを機能リリースと同期して出していく職種ってどうだろう、と妄想していた。 ＜妄想＞ プロダクトをよく理解していて開発チームにガッツリ入り、プランニング時点でドキュメント準備にかかる。デイリー報告やチーム議論に加わり、開発チームの言葉・デザイナーの言葉を咀嚼しながら、プロダクトユーザーへの伝わりやすさを常に考えてドキュメントを組み立てる。スプリントレビュー時点でドキュメントの作業を完成させ、機能リリースと同時にドキュメントも公開される。ドキュメントができていなければ、オーナーと協議して機能リリースを遅らせることもある。 ライティングや文章構成、ユーザーにとってのわかりやすさについて知見があり、ドキュメント関連に専念し、ユーザー視点での機能のわかりやすさ

OpenTelemetryのzero-code計装として公式に言及されているGo、.NET、Java、Python、PHP、JavaScriptについて、同系統の簡単なWebサーバーを立てながら試してきた。 kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com 「簡単なWebサーバー」の作りがいろいろ大雑把だったので、フレームワークで作ったものだといろいろ出るし、基本ライブラリに近いコーディングだとあまり出ない。ORMなデータベースが絡めばサービス間通信っぽさが出るけど、別段不要な場合は自己完結で終わってトレースとしてはいまいち面白さはない（簡単なWebサーバーなのに、裏でデータベースアクセスを

MackerelでのOpenTelemetry対応パブリックベータの提供が開始したので、Mackerel CREの私も習熟すべくいろいろと実験をしています。 mackerel.io ホストやミドルウェアのメトリックを取得しようというときにはOpenTelemetry CollectorのReceiverでメトリックを収集し、ExporterにMackerelのOTLPエンドポイントを示して投稿、というのが王道なのですが、今回はあえて「Mackerelの既存のメトリックプラグインの出力をOpenTelemetryのメトリックとして送ってみる」ということを試してみました。 結論から言えば、（加工は少し必要ですが）ContribにあるCarbon Receiverで実現できます。 Carbon Receiverとは OpenTelemetry Collector ContribのReceiver

3行 現時点ではOpenTofu 1.6.0はユーザー体験としてはほぼTerraform 1.6なので、コマンドがterraform→tofuになった以外はユーザー側で感じる変化はなさそう（設定ファイルやstateファイルなどもTerraformそのまま）。Mackerel Providerも動く。 Provider側としては、すでに登録されているProviderであれば、当面は何もしなくてもGitHubリリースしたものがOpenTofuレジストリに最新反映される模様（GPG署名している場合は公開鍵をレジストリにサブミットする必要あり）。 今の時点では問題ないと言っても、OpenTofu/Terraformの乖離が進んで互換性が失われると、Providerは別リポジトリを用意する必要がありそう or Terraform/OpenTofuどちらかを諦めることになりそう。 3行 背景 ユーザー

これはMackerel Advent Calendar 2023 14日目の記事です。昨日はinommmさんでした。 要約 アラート時刻近辺の重量プロセス一覧をMackerelのアラートメモかグラフアノテーションに投稿する、「sabanote」（さばのて）というプラグインを作ったよ。あと、Mackerel Meetup #15やるよ。 前置き 改めまして、はてな社でMackerel CREを務めて1年になる id:kmuto です。SaaS型監視サービスのMackerel。そのユーザーの抱える課題の解決支援を担うCRE（Customer Reliability Engineer）のカスタマーサクセスユニットの一員として、ユーザーと直にMackerelのご利用についてお話しし、ご意見・ご要望をいただく機会が多いです。 そんな日々の中で、最近よく挙がっていたのが「アラートが発生した際のサーバー

OSSのアンチウイルス/アンチマルウェアサービスとして、ClamAVというものがあり、そこそこ広く使われている(私も昔は物理サーバーに入れていたが、CPUやメモリ負荷がかなり高いサービスで、VPSにしてからはメモリあふれが多発してしまうので普段は使っていない)。 現在はCiscoがスポンサーしているようだ。 つい先日、このClamAVのデータベース更新で入ったパターンで、Mackerelエージェントのmackerel-agentバイナリがマルウェア判定されてしまうという現象が発生した。 私のほうでFalse Positiveとして報告したところ、今日の更新で解除になっていた。ほかにも多数報告があっての解除かもしれないが、今後も同様のケースはありそうなので、ざっくり手順をまとめておく。 パターンデータベース更新はおおよそ1日1回はあるので、まず報告しようとしている時点ですでに直っていないかど

（結論はなく、ダラダラ昔話を書いただけ。） サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア（OSS）を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin

blog.jxck.io で（md2inao→md2indesignの進行は過去にもちょっとかかわりがあってウォッチした） もうすでにそういう製品があったり、知らないだけで全コードがハイライトされた書籍を出してる出版社はあるのかもしれないが、そういう本を少なくとも自分は見てない。 という記載があったのでちょっと書いてみる。 オーム社さん、オライリー・ジャパンさん、インプレスさん、羊土社さん、講談社サイエンティフィク社さんなどの一部の書籍では、コードハイライト付きになっていて、さらにそのうちいくつかは紙版では白黒、電子版ではカラーを使い分けていたりする。 というのも、前職の制作会社時代に私がその仕組みを作ってきたから。 組版はInDesignを使うのもあれば、TeXを使っているのもある。紙白黒/電子カラーのような使い分けは、TeXではOK、InDesignではもしデータを2種類管理しなければ

業務でGitのリポジトリを多数扱っていて、サポートのお手伝いのためにエラーメッセージからコードリーディングを串し刺しで探すことがある。で、このときに 「うぉー見つからねーどれが出してるんだー」「まったくわからん」「pullしてないやん…」 「なるほどーこれはあかんね」「いや確か直したってこの前聞いたよな」「pullしてないやん…」 といった悲しい出来事がまれによくあるケースになりそうなので、カレント直下のGitリポジトリ群をともかく最新にpullするツールを書くことにした。 この手のツールといえば、debian-installer開発の頃に使っていた、Joey Hessの通称mr、myreposが思い浮かぶのだが（パッケージはまだ配布されていてbrewにもある）、Perl依存はあまりしたくないというのと、ちょっとアレは用途に対して大きすぎる（VCS乱立期だったので、ほぼ全部のVCSに対応し

退職から少しのお休みを経て、本日から株式会社はてな https://hatena.co.jp/ のMackerel CRE（Customer Reliability Engineer）としてのキャリアを始めた。 Mackerel https://ja.mackerel.io/ は、はてな社が開発・運用しているサーバ監視SaaSで、オンプレミスや各種クラウドのサーバ群を一貫したインターフェイスで手軽かつ高度に監視できるサービス。 ja.mackerel.io CREチームはこのMackerelのユーザー企業のみなさまへのテクニカルサポートのほか、導入支援やドキュメンテーション、コーディング、そしてユーザー企業の成功のために継続的な活用サポートを提案・提供していくことが主なミッションとなる。 ja.mackerel.io 転職ふりかえりなどはいずれ載せていくつもりだけど、まずは速やかに即戦力と

本日で株式会社トップスタジオ https://www.topstudio.co.jp/ の勤務を終え、これから有給消化に入る。 SIerからの転職で1999年に入社し、3年くらいかなーと思っていたのが5年となり、10年となり、……といつのまにかずいぶんと長く在籍していた。 仕事的には自由度が高く、先端の技術分野の書籍を制作しながら知識を得て血肉にすることができ、私にはとてもフィットする職場だった。同僚にも恵まれて楽しかったので、離れるのは寂しい思いがある。 トップスタジオで何をやってきたの？ 長くいたこともあり、それなりに成果を積んできたとは思う。 入社当初より、編集者として、各社のIT書籍の請負制作をしてきた。Linux、OSS、ネットワーク、セキュリティ、ソフトウェア工学、エンジニアリング、そして最近だと機械学習が多い。翻訳の監修や、執筆なども関連して担当。企画はあまりやっていない。

去年の会社引越しに伴うオンプレ→VPS+SaaSの切り替え決意のときにかなり大々的にサービス類を作り直し、まだまだ現役でいけそうな1Uサーバ類やラックなども全部捨てて、それが当時としては大正解ではあった。しかし、それでもVPSという、IaaS的に全部管理しなければいけないものはやはり管理コストが高い（自分の技術関心方向と合っていたので格安で済んでいるが、企業としては隠れ管理コストになっていてよろしくない）。 ということで、いろいろヘンテコピタゴラ技術でやっていたところは諦めたりSaaSに切り替えたり（DNS bindをついに追放）というのを最近の作業の1つとしているのだが、厄介な問題としてずっと引き継いできた社内用データチェックツールの存在がある。 中身的には、ログインしてLinux CUIで動かすコマンド類（VPSでは証明書+shellinaboxで入って作業。データはNextCloud