サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
kmuto.hatenablog.com
MackerelでのOpenTelemetry対応パブリックベータの提供が開始したので、Mackerel CREの私も習熟すべくいろいろと実験をしています。 mackerel.io ホストやミドルウェアのメトリックを取得しようというときにはOpenTelemetry CollectorのReceiverでメトリックを収集し、ExporterにMackerelのOTLPエンドポイントを示して投稿、というのが王道なのですが、今回はあえて「Mackerelの既存のメトリックプラグインの出力をOpenTelemetryのメトリックとして送ってみる」ということを試してみました。 結論から言えば、(加工は少し必要ですが)ContribにあるCarbon Receiverで実現できます。 Carbon Receiverとは OpenTelemetry Collector ContribのReceiver
OpenTelemetryブームなので、実際今Collectorでどこまですぐに(何かを自作せずに)監視したいもの、特にミドルウェアまわりが見られるのか、というのを把握しておこうと思う。 opentelemetry-collector-contribリポジトリのまずはreceiverを一覧してざっとREADMEを見て回るところから始めた。 github.com 箇条書きのalpha、betaといったものは安定度(stability)で、development→alpha→beta→stableというステージになっているとのこと。実際のところcontribにあるものでstableなものはなく、developmentやalphaがゴロゴロしている状況。 renovate系更新が多いので、改良具合は見通しが悪い。新規フォルダが作られるのとREADMEを追跡するのがいいのかな。 activedir
コンピューティングは日々あっという間に進化していくイメージがあるけど、いくら進化が速いとは言っても、人間が作り、かつほかの人間たちの理解と評価があって普及していくという現状においては、そうそうシンギュラリティというほどのことは起きず、あくまで知識の連続性に立っているのだろうと思う。 で、社会人としてもうだいぶ長くいると、過去にためた知識・スキルがひょんなことで役立つときがままある。 クラウドと言ったところでデータセンターやオフィスのネットワーク機器の監視にSNMPは安心実績の機能であり続けているし、サーバー管理にクールなGUI(あるいはSF的なVR)は多数のリソース管理には不向きでテキストベースのIaCとシェルスクリプト芸に戻ってきた。 Unicodeで解決と言われていた文字コードは、あいかわらずCP932は健在だし、BOM有無の挙動、Emojiでの文字数とバイト数の乖離と面白現象の宝庫。
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のご利用についてお話しし、ご意見・ご要望をいただく機会が多いです。 そんな日々の中で、最近よく挙がっていたのが「アラートが発生した際のサーバー
その10からの続き。 kmuto.hatenablog.com オンライン開催ですでにご購入いただいている皆様、ありがとうございます! 明日はついに池袋サンシャインシティでの技術書典15オフライン開催日。お天気予報は曇り、少し雨かも、そして寒そうということで、寒さ対策&会場が混雑していると暑い、の両面対応でご来場ください。 参加予定の方は入場券を技術書典サイトで入手されたかな。すでに午前中の入場は売り切れている模様。スマホに技術書典の公式アプリを入れて、かんたん後払いできるようにしておこう。 同人誌の印刷製本の仕上がりは、出たとこ勝負になるのがなかなかドキドキする。 前職での入稿のときは、版元も見るし、色校、場合によってはその前の試し刷りもあったりするので、基本事項とあとは印刷所入稿仕様を見ていれば問題なかった。カバーデータはデザイナーが進めるのでこちらは細かいところまで気にしなくていいし
その7からの続き。 kmuto.hatenablog.com 編集について。同人誌でアンソロジーということもあり、全体にわたる表記やトーンの調整はせず、記事内での表記統一と、簡単な“てにをは”レベルの修正にとどめた。 序盤に脱稿いただいたものについては、ある程度しっかりと中身を読み、表現的にわかりにくいところなどについてリライト案を考えてGitHub PR内のファイルにコメントあるいはSuggestとして判断を委ねている。 ただ表記統一で逐一Suggestをするのは著者もこちらも手間 & GitHubのCommit Suggestionでのスクロール挙動が面倒なことになるので、「これらの表記統一をしますよ」と宣言して同意を得たらまずはその統一・コミットを行い、それから上記のとおりコメントやSuggestを実施した。 stefafafanさんの記事へのSuggestの例 終盤の脱稿物について
その9からの続き。 kmuto.hatenablog.com 3日坊主を乗り越えてついにその10。明日がいよいよ技術書典15のオンライン開催、明後日が池袋サンシャインシティでオフライン開催ですよ。ワオ。 techbookfest.org 改めて新刊『Hatena Tech Book Vol.2』の記事を並べてみよう。 Perlの未定義動作110連発(id:papix) ラムダ計算で遊んでみよう(id:todays_mitsui) VSはよいものだ(id:koudenpa) すごいIAMアイデンティティセンター無料で使おう(id:rokoucha) Pythonでフォントを加工する(id:cockscomb) 注目されない自分と付き合う技術(id:motemen) 人事を支える技術(id:onishi) スクラムによる開発の理想と現実(id:stefafafan) 小説同人サークルを支える技
その4からの続き。 kmuto.hatenablog.com 表紙などのデザイン面について。デザイナーは id:mazco さん。 9/28にデザイン打ち合わせ・10/3にコンセプト確定。多様性、ごった煮、はてなっぽさは出しつつ今までのはてなとはちょっと違うコンセプト、楽しい感じ……とブレインストーミング的に並べていき、「はてラボっぽさを出す方向で決定。「完成度が50%未満のものもあります。」の精神、良き。 サークルカットが『技術季報』用に早くに必要だった覚えがあったので、まずはこれを出さないと!と進行していただいたものの、今の季報ではもう名前でしか掲載していないらしい……申しわけない。サークルカットはWebサイト上で使われるもので、正方形データをアップロードすると丸型に切り抜かれることがわかったので、2案のデザイン案をいただいて、いつものはてなとは少し違って賑やかなタグステッカー風のほう
OSSのアンチウイルス/アンチマルウェアサービスとして、ClamAVというものがあり、そこそこ広く使われている(私も昔は物理サーバーに入れていたが、CPUやメモリ負荷がかなり高いサービスで、VPSにしてからはメモリあふれが多発してしまうので普段は使っていない)。 現在はCiscoがスポンサーしているようだ。 つい先日、このClamAVのデータベース更新で入ったパターンで、Mackerelエージェントのmackerel-agentバイナリがマルウェア判定されてしまうという現象が発生した。 私のほうでFalse Positiveとして報告したところ、今日の更新で解除になっていた。ほかにも多数報告があっての解除かもしれないが、今後も同様のケースはありそうなので、ざっくり手順をまとめておく。 パターンデータベース更新はおおよそ1日1回はあるので、まず報告しようとしている時点ですでに直っていないかど
その2からの続き。危ない、3日坊主になるところだった。 kmuto.hatenablog.com 今日はどんなスケジュールを引いたかについて書いてみよう。 社内チャットに技術書典15プロジェクトチャンネルを自分が建立したのは6月15日だったらしい。技術書典14が終わって(6月4日)出展機運があったので、じゃぁやろうず的に立てた。 このときにはまだ技術書典15がいつ開催されるかは不明だったけれども、過去の開催ペース、国の新型コロナへのスタンス、主催のmhidakaさんの感想戦の雰囲気からまだ続けるだろうと見込んで、半年くらい先には開かれるのではないかと予測していた。 8月19日に技術書典15のサークル申し込み開始。はい、id:onk さん早かった(チャンネルに先に書かれた)。 スポンサーでブース供与があるならそれに乗るのが気楽なので、スポンサー募集が出るのを待つかーということでしばし待つ。こ
その1からの続き。 kmuto.hatenablog.com テーマについては「あなたの『推し』の技術を教えてください!」に決め、社内チャットで執筆よろしくをお願いして、id:mazco さんと表紙の雰囲気を相談し、id:toya さんにはキャッチコピーを丸投げ(すいません)。 自分は制作全般は任せろーということで、紙面レイアウトの用意とビルド環境を固めていく。制作システムは(当然ながら?)Re:VIEW。手慣れたTeXで作るとして、review-jsbook/review-jlreqについてはカスタマイズのしやすさの観点でreview-jlreqのほうにした。 サイズはB5。A5かB5かどっちかという選択で、ある程度の分量になりそうという推測と、コードの折り返しを減らしたいという観点からチョイス。紙面デザインについては id:mazco さんの時間確保が厳しめ & 自分にはデザインセンス
「はてなに入社したらやりたい100のこと」の1つに、「はてなのエンジニアの皆さんを巻き込んで技術書典に出展する」がある。 はてな自体そもそも2019年の技術書典6に出展したことがあって、そのときの『Hatena Tech Book』の販売は大いに活況だったらしい。5月の技術書典14についても社内チャットで話題になっていて、いつかまた出てみるのもいいかもねーという雰囲気は醸成されていた。 developer.hatenastaff.com 入社してしばらく経ち、ようやくいろいろと仕事も見えるようになってきたので(本当に?)、技術書典15に出展するのは良いタイミングではないか。社内で出展に興味があるか募ってみたところ、技術書典6の経験メンバーや新規の方々が手を挙げてくれた。 技術書典15プロジェクトを始動。まずは技術書典15のスポンサー参加の働きかけから始めた。こちらは技術グループと広報との間
最近Mackerelの通知チャンネルをいろいろ見ることがあったのだけど、SlackやTeamsといった対応済みのもの以外への通知はWebhookを使う、というのが基本スタンスとなっている。 MackerelのWebhook通知として提供されるのは、サンプル(Mackerelの「テスト」で送出されるもの)、アラート通知、アラートグループ通知、ホストステータス変更、ホスト登録、ホスト退役、監視ルールの操作(追加・変更・削除)。 困ったことに、ドキュメントのWebhookにアラートを通知するでは「通知されるJSONは以下のような内容を含んでいます。」というかなり曖昧なものしかなく、アラート通知のことしか書かれていない。 この機会にWebhookまわりをひととおり洗い直すか〜と思い、以下をやってみた。 各通知のJSONスキーマを作る それぞれのWebhookに応じてメソッドを呼び出し、ターゲットに
あと3ヶ月するとはてな社に入って1年になるという状況だけど、今期が始まり今月からエンジニアグループのシニアエンジニアの役割を仰せつかった。もともとMackerel CREチームではテックリードとして前期の下半期は活動していたのだけど、もう1軸ポジションが加わることになる。 シニアエンジニアの役割の1つに、横軸のエンジニアグループ内でのメンター役がある。採用情報にある「キャリアプランの相談や、悩み・問題点の早期発見を目的」のほか、技術的相談とか、所属チームでどうあるべきか、その他普通に雑談も含めて、チームマネージャーとは異なるエンジニアからの視点で定期的にメンティーと話すことで、メンティーの成長を支援していく制度である、という認識(まだメンターとしてやるべきことの細かい部分の指示を受けていないのだけど、入社以来メンティーとしては受けてきた)。 hatena.co.jp 現代的な技術力や思考の
(結論はなく、ダラダラ昔話を書いただけ。) サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア(OSS)を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin
昨日6月10日付けでDebian 12、コードネーム「bookworm」がリリースされていた。 www.debian.org 「bookworm」は『トイ・ストーリー3』の図書室の主だった「本の虫」。なお、次のDebian 13のコードネームは、こちらも『トイ・ストーリー3』からトリケラトプスの「trixie」とのこと。 今回は機能的にはそんなに目新しいというほどのものはなく、バージョンとしてはGNOME 43、Linuxカーネル6.1、MariaDB 10.11、PostgreSQL 15、OpenJDK 17、Perl 5.36、PHP 8.2といったあたりか。 nodenvやrbenvはなるべく使いたくないのだけれども、結局1年くらいするとどうにもならなくなりがちなので、そのあたりはもはやそういうエコロジーなものだと思って諦めるしかなさそう。 今回のリリースでは、non-freeから
blog.jxck.io で(md2inao→md2indesignの進行は過去にもちょっとかかわりがあってウォッチした) もうすでにそういう製品があったり、知らないだけで全コードがハイライトされた書籍を出してる出版社はあるのかもしれないが、そういう本を少なくとも自分は見てない。 という記載があったのでちょっと書いてみる。 オーム社さん、オライリー・ジャパンさん、インプレスさん、羊土社さん、講談社サイエンティフィク社さんなどの一部の書籍では、コードハイライト付きになっていて、さらにそのうちいくつかは紙版では白黒、電子版ではカラーを使い分けていたりする。 というのも、前職の制作会社時代に私がその仕組みを作ってきたから。 組版はInDesignを使うのもあれば、TeXを使っているのもある。紙白黒/電子カラーのような使い分けは、TeXではOK、InDesignではもしデータを2種類管理しなければ
techbookfest.org の感想文を書こうと読み進めていたのだが、読んでいるうちにいいかげんおうちサーバのkmuto.jpもなんとかしないとな、と重い腰を上げることにした。重要な連絡メールもたまに受けているのに、spam多すぎてSMTPへの呪詛が強まっていた今日この頃だったので、ちょうどいいきっかけである。 実際のところ、先人の www.hs3.org と https://www.tyksnet.com/blog/archives/2593 だけでほぼ解決してしまうので、感謝してこれを読みましょう。で終わってしまうんだけど、ネットの情報は永遠に残るわけではないので、備忘録も兼ねてやり方はほぼコピー、内容は抜粋という雑なものではあるが記録しておく。 OSはDebian 11 bullseye, 現状のstableバージョン。DNSはAWSのRoute 53に置いている。MTAはPos
ようやく読み終わり。また雑なメモで。 gihyo.jp 「サバンナ便り」 テストピラミッドの話。コストと忠実性が高く、実行速度と決定性が低いテストはケース数を減らすべき、という考え方。end-to-endのようなユーザー視点に近いテストは決定性が低く、信頼不能テストにつながる。下段のテストを信頼性高くしておく。上段はLargeテスト、中段にMiddleテスト、最下段にSmallテストを配置する。下段中段上段は70:20:10を目安にし、規模拡大につれて80:15:5を目指す。 「TypeScript最新活用」 うひょさんらの執筆記事。 satisfies構文。式が制約を満たすかどうかをチェックできる。従来の const priceTable: Record<string, number> = { apple: 150, orange: 200 } だとキー情報は使われず priceTabl
以前に記事にしたとおり、先月からk8sの翻訳を始めている(大作だった3つ目をレビューに出し終えたところ)。 kmuto.hatenablog.com Debianでの作業のときにはWebページの更新状況を調べるページがもともとあった+自分でも補完的に作っていたのだけれども、k8s websiteではその手のが見当たらなかったので、似たようなものを作ってみた。毎日日本時間16:02に更新。 kmuto.jp コードについては以下(プロジェクト名typoしたな……)。 github.com Rubyのgitライブラリは実際にはgitコマンドを呼び出しているだけだった。オーバーヘッドぶんだけ遅い。特に、コミットの日付を調べるコストが高くて、git ls-files同等で見た後に1つずつ丁寧にgit log -1同等で日付を取り出すというプロセスとなるため、実行が終わるまでにVPSの環境では15分
1行で カジュアルな気持ちでk8sの翻訳に関わり始めたよ。 背景 YAPC KYOTO 2023はYouTubeで視聴していて、Linux Conferenceの主催側立場だったりした頃を思い出したり、Debian ConferenceやRuby会議も楽しかったなーなどと感慨にふけっていた(今年のRuby会議はちょっと行きたいなと思ったんだけど、業務とつなげるのが現状では難しそうなのもあって見送り)。 yapcjapan.org 発表はどれも印象深かったのだけれども、最後のLTで@nasa9084さんの「Kubernetesの翻訳協力者募集!」を聞いて「Kubernetes使える人は英語で特段問題なさそうだなぁ」と感想を呟いたところ、@nasa9084さんに拾っていただいて反応をもらった。 speakerdeck.com そもそも翻訳をできる人は日本語のドキュメントを必要としてないので、コ
他者のGit管理下のプロジェクトに対して、ローカルでのビルドでpackage.jsonが変わってしまうとか、.rbenvでのバージョンが微妙なのでそこはいじったとかな場面で、うっかりコミット候補に入ってしまわないよう注意深さを必要とするのが、地味に手間だった(怠惰)。 .gitignoreのローカル向けの.git/info/excludeは未コミットのものを最初から除外しておくものなので、すでに追跡されているもの向けではない。 サブコマンドで何かあったような気が……と探したところ、skip-worktreeサブコマンドを使うのが良いようだ(記事ありがとうございます)。 qiita.com 最初。 $ git status On branch main Your branch is up to date with 'origin/main'. Changes not staged for c
この週末は、社内デモとしてぱぱっと作ったWebサービスを手習いとしてモダンに書き直してみていて、良書で学んだことが役に立ってるなーと感じている。 デモのプロトタイプは時間の都合でこれまでに十分知っているツール(Ruby+Ajax)で作っていたのだが、これをNode.js + TypeScript + Vueで書き直した。前職ではWebサービスはPHPかRailsかERubyあたりで留まっていて、TypeScriptもAdobe ES3の世界のなかでは活躍のシーンがなかったので、まじめに独自なアプリケーションを一本書くのはほぼ初めてとなる。 これが、予想よりもずっとあっけなく完成できた。背景としてはサービスがシンプルだったからというのももちろんあるのだが、情報がまとまった形となっている書籍を読み学んでおいたことで、あまり迷いが生じなかったということがあると思う。 雑誌記事やWeb記事はスポッ
年始にmackerel-agentのコードをひととおり読んでいたのだけど、キューの実装部分がコードだけでは読み取れなかったので、シミュレーションを書いて挙動実験をしていた。 (なお、公開してからFILOじゃなくてLIFOだよなということに気付いた) mackerel-agentは、IaaSやオンプレサーバーにインストールしてもらい、Mackerelにそのホストのメトリックを定期的に送る小さな常駐エージェント。仮にネットワーク障害などでメトリックを送れないときがあっても、収集したメトリックを失わないようにキューを自身で保有し、復旧時に再送を試みる仕組みになっている(そうでないと、障害原因の検証に役立ったかもしれない詳細情報が失われてしまうので)。 mackerel-agent自体はGo言語で記述されており、ほとんどの箇所はGoビギナーでも理解しやすい。 ただ、キューの部分はGoの並行処理にな
業務でGitのリポジトリを多数扱っていて、サポートのお手伝いのためにエラーメッセージからコードリーディングを串し刺しで探すことがある。で、このときに 「うぉー見つからねーどれが出してるんだー」「まったくわからん」「pullしてないやん…」 「なるほどーこれはあかんね」「いや確か直したってこの前聞いたよな」「pullしてないやん…」 といった悲しい出来事がまれによくあるケースになりそうなので、カレント直下のGitリポジトリ群をともかく最新にpullするツールを書くことにした。 この手のツールといえば、debian-installer開発の頃に使っていた、Joey Hessの通称mr、myreposが思い浮かぶのだが(パッケージはまだ配布されていてbrewにもある)、Perl依存はあまりしたくないというのと、ちょっとアレは用途に対して大きすぎる(VCS乱立期だったので、ほぼ全部のVCSに対応し
「Mackerelエージェントのプラグインの仕組みを知り、プラグインを書いてみる」練習として。プラグインテンプレートとしてGo言語のは用意されているのだけど、さっちゃんのアドベントカレンダー記事にもあるとおり、メトリック自体は「メトリックに付ける一意な名前」「値」「Unix時刻」をタブ区切りで出力するだけでよい。 c4se.hatenablog.com ではRubyでさくっと書いてみるかーということで、題材としてはかねてからやろうかなと思っていた、Fail2banのBAN IP数を測ってみる。できたのはこちら。 github.com kmuto.jpに訪れるいろいろな攻撃をFail2banで叩き落としているが、そのJAILルールごとに現在BANしているIP数をグラフ化している。 Fail2ban BAN IPのグラフ化 BANしているのを眺めてどんなメリットがあるんだという意見もあるが、「
Mackerel Advent Calendar 2022 23日目の記事です。昨日は@genkiroidさんでした。 この日記をご覧になっていた方々には既知ですが、書籍制作プロダクション会社での書籍制作者&社内情シスという職種から、はてな社のMackerel CREポジションとして、先月の11月16日に転身しました。 kmuto.hatenablog.com 先達の皆さんがMackerelの活用方法や素晴しい思い入れを大いに示している中で場違いな気持ちが否めないのですが、「You書いちゃいなよ」と後押しされましたので、Mackerelの新人CREとして1ヶ月働いてのふりかえりをしてみます。 CREとは Customer Reliability Engineer、顧客信頼性エンジニアと訳されています。提供しているサービスにおいて、顧客の抱える問題・課題を我が事として捉え、支援や提案で顧客の
つくりおきAdvent Calender 2022、15日目。昨日はsawa-kazさんでした。 はてな社に先月に転職し、最初は情報量をさばくのに目が回り、1ヶ月後の今になってようやく一息ついているという状況です。一食入魂の精神であまりつくりおきはしないのですが、たまに作るつくりおきが「フムス」。 フムス(ホンモス、フンムスなどとも呼ばれる。ḥummuṣ)は、中東を中心にトルコ、ヨーロッパなどでもよく食べられているひよこ豆のペーストです。起源を巡ってはイスラエルやレバノンで争ってたりして掘り下げるといろいろ地雷になる模様。 材料 ひよこ豆。ガルバンゾ、カブリチャナとも呼びます。普通のスーパーや輸入食材店だとお高めですが、現地出身の方々がやっているお店だと乾物で安く入手できます。Amazonでもわりと安いですね。 レモン。生でもポッカレモンでもいいですが、最近では冷凍レモンがベストだなという
次のページ
このページを最初にブックマークしてみませんか?
『kmuto’s blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く