do_su_0805's blog

dairyquestions は typo です。

Mackerelの公式メトリックプラグインとOpenTelemetry Receiverの取得内容の比較 : NGINX 編

nginx OpenTelemetry Mackerel

Mackerel - Qiita Advent Calendar 2024 - Qiita 3日目の記事です。 2日目は id:missasan の Mackerel CREチーム ディレクターが育休復帰3ヶ月でやったこと - missasan's notebook でした。id:missasan が復帰してから、そのブランクを感じさせない大立ち回りっぷりを見せており、さすがだなぁと同じチームメンバーとして感じていたのですが、そのまとめと背景についての記事となっておりました。ここ最近のMackerelの活動まとめにもなっております。ぜひご一読いただければと思います。

こんにちは、id:do-su-0805 です。仕事では id:do-su-0805 を利用していますが、普段は id:do_su_0805 として生活しています。
はてなでは約5年ほど Platform SRE を担当した後、2023/05 よりMackerel CREチームでテクニカルサポートを担当しております。

2024年3月にOpenTelemetry 対応（パブリックベータ）提供開始 - Mackerel ブログ #mackerelioでのお知らせ以後、2024年11月、Mackerelのメトリックがオブザーバビリティ標準であるOpenTelemetryに正式対応し、あわせて価格体系を全面的に改定します - Mackerel ブログ #mackerelioや、Mackerelはオブザーバビリティプラットフォームとして進化していきます - Mackerel ブログ #mackerelio などでもお知らせしているように、MackerelはOpenTelemetryに対応する機能を公開・拡充し続けています。

opentelemetry.io

詳しくは過去の公開記事等を参照いただけたらと思いますが、今回はOpenTelemetry Metricsに関するお話です。
OpenTelemetry Metricsに対応しました！といっても「いままでmackerel-agentで監視していたものから移行できるのかな？」という不安・懸念へのご案内の一つとして、NGINXの監視を題材とし、Mackerel公式プラグインである mackerel-plugin-nginx と、OpenTelemetry Collector の Receiver である NGINX Receiver での取得方法や取得内容を比較してみました。
mackerel-plugin-nginxを利用したメトリック取得設定の方法や、NGINX Receiver を利用したメトリック取得設定の方法については、以下をご参照ください。

NGINX のメトリック取得に必要な NGINX の設定について

取得に関しては、いずれも取得用の機構(プラグイン,Receiver)実行時に、ngx_http_stub_status_moduleの結果を提供するパスにアクセスする仕組みになっており、差分はありません。

mackerel-plugin-nginx

メトリックプラグイン - mackerel-plugin-nginx - Mackerel ヘルプ

mackerel-plugin-nginxは、実行された際にngx_http_stub_status_moduleの結果をパースしメトリックとして投稿しています。

NGINX Receiver

opentelemetry-collector-contrib/receiver/nginxreceiver/README.md at main · open-telemetry/opentelemetry-collector-contrib

NGINX Receiverは、Receiverとして設定を有効にしたCollectorが起動した場合に、ngx_http_stub_status_moduleの結果をパースしメトリックとして投稿しています。

投稿されるメトリックについて

投稿されるメトリックに関しては、mackerel-plugin-nginxとNGINX Receiverではグルーピングの違いや差分値計算の有無といった違いがあります。*1

mackerel-plugin-nginx

プラグインヘルプ内監視できるメトリックに記載の通り、"Nginx Connections","Nginx requests","Nginx connection status"の3種類にグルーピングされた状態で投稿されます。

mackerel-plugin-nginxにて取得したメトリックの様子

NGINX Receiver

opentelemetry-collector-contrib/receiver/nginxreceiver/documentation.md at main · open-telemetry/opentelemetry-collector-contrib　に記載の通り、"nginx.connections_accepted","nginx.connections_current","nginx.connections_handled"の3種類にグルーピングされた状態で投稿されます。

NGINX Receiverにて取得したメトリックの様子

投稿されるメトリックの比較

グルーピングの違い

現在の接続数を示すメトリックは、mackerel-plugin-nginxでは"Nginx Connection"に含まれる"Active connections"(custom.nginx.connections.connections)として投稿されていますが、NGINX Receiverでは"nginx.connections_current"として投稿される4本のうちstate="active"である1本になっています。

現在の接続数を示すメトリックの表示例(plugin,Receiver全体,Receiverの結果を `state="active"` で絞り込んだもの)
グラフウィジェットにて `state="active"`で絞り込んだ状態にする例

現在の接続数の内訳を示すメトリックは、mackerel-plugin-nginxでは"Nginx connection status"に含まれる"Reading"(custom.nginx.queue.reading),"Writing"(custom.nginx.queue.writing),"Waiting"(custom.nginx.queue.waiting)としてグルーピングされ投稿されており、NGINX Reveiverでも"nginx.connections_current"として投稿される4本のうちstate="reading",state="writing","state="waiting" の3本になっています。

現在の接続数の内訳を示すメトリックの表示例(plugin,Receiver全体,Receiverの結果を`state != "active"` で絞り込んだもの)

受け付けたクライアント数や処理した接続数などを示すメトリックは、mackerel-plugin-nginxでは"Nginx requests"に含まれる"Accepted connections"(custom.nginx.requests.accepts),"Handled connections"(custom.nginx.requests.handled),"Handled requests"(custom.nginx.requests.requests)としてグルーピングされ投稿されていますが、NGINX Receiverでは"nginx.connections_accepted","nginx.connections_handled","nginx.requests"として投稿される1本のメトリックとして分かれて投稿されています。

受け付けたクライアント数や処理した数などを示すメトリックの表示例(plugin,ReceiverでのAccepted,ReceiverでのHandled,ReceiverでのRequests)

確認できるメトリックの差分

上記「グルーピングの違い」に示した図を見ていただくと分かるように、受け付けたクライアント数や処理した接続数などを示すRequest,Accepts,Handledを表現するメトリックのみ、mackerel-plugin-nginxとNGINX Receiverでは値が異なっています。 mackerel-plugin-nginxでは差分値(前回の取得値との差分)となっており、NGINX Receiverでは累積値(ngx_http_stub_status_moduleが返す値をそのまま利用)となっています。

ただし、当方の検証環境では NGINX Receiver を利用した ngx_http_stub_status_module の結果取得をするためのリクエストにて"accepts"ならびに"handled"が増加せず、"requests"のみが増加する様子を確認しており*2、 実際に利用する際にはご自身の環境での出力の様子を併せてご確認いただき、必要な差分計算等をCollectorや利用時のPromQLにて実施いただくとよいと思います。

監視設定例

NGINX への現在の接続数が100を超えた場合にアラートを上げる例を紹介します。

mackerel-plugin-nginxを利用している場合は、以下のように custom.nginx.connections.connections メトリックに対してホストメトリック監視を作成いただくことで監視が可能です。

ホストメトリック監視にて cutom.nginx.connections.connections を対象に 100 以上の際にアラートを上げる設定例

NGINX Receiverを利用している場合は、以下のように nginx.connections_current{state="active"} を対象にクエリによる監視を作成いただくことで監視が可能です。必要に応じてさらにラベルによる絞り込みなどを設定してください。

クエリによる監視を利用して nginx.connection_current{state="active"} を対象に監視を設定する例

まとめ

Mackerelの公式メトリックプラグインであるmackerel-plugin-nginxと、OpenTelemetry Receiverである NGINX Receiver での取得内容について見ていきました。 一部、NGINX Receiverを利用する際は差分計算が必要な点は調整が必要となるかもしれませんが、取得内容としては同様の内容であるため、既存の監視から ためしにシフトしやすいものなのではないかと思います。

CREは仲間を探しています

CREは仲間になってくれる人を探しています。気になった人はぜひお声がけください。

hatena.co.jp

明日の Mackerel Advent Calendar 2024 は id:RyuGoo の記事です。12/02時点で書き終えているとのことでしたので、お楽しみに。

*1: 簡単のため、Mackerelにおいて同じグラフ定義にまとめられるメトリックと、Opentelemetry Metricsにおいて同一メトリック名にて投稿されラベルにてフィルタリング可能な状態のことをグルーピングと称しています。

*2: 仕組みが分からなかった...

個人AWSアカウントでNATGWの料金がしんどかったので、NATインスタンスに置き換えた

あまり活用できていないんだけど、ちょっとした物置としてAWSアカウントを1つ運用している。 初期導入などのためにNATGWを配置していたんだけど、ご存じの通り結構な料金が発生する。

2024年7月の利用実績

NATGW自体は素晴らしいサービスだと思っているが、やはり個人ユーズにはきつい費用である。

詳しい損益分岐点をちゃんと計算したわけではないが、全然通信しないようなNATGWならインスタンスに置き換えたほうが安いに決まっているだろうと、実際に置き換えた。

NATインスタンスの作り方はいろいろとあるが、今回は fck-nat を採用した。 上記公式サイトを参照してスムーズに構築できた。

NATインスタンス切り替え後の費用推移（日別）

見てわかるように、大幅に費用削減できた。

NATインスタンスの通信状況

見てわかるように全然通信していない。しばらくはこれでよいだろう。

Zendesk explore の「ベータ版ビルダー」を利用したダッシュボードにおける高さを素早く伸ばす Tips

小ネタです。

Zendesk explore でダッシュボードを作成する時、従来版とベータ版の2種類を 2023/07/21 現在は選択できます。

「新規ダッシュボード」をクリックした後に表示されるポップアップ。2種類の選択肢が表示されており、「従来版ビルダーを使用」と「ベータ版ビルダーを使用」のボタンが表示されている。
ダッシュボード作成時に表示される選択肢

このうち、ベータ版を利用する際にダッシュボードの高さを伸ばすためのテクニックの紹介です。 なお、従来版であれば、「タグオプション」に高さのオプションが、「ダッシュボード」に幅のオプションがあるため、数値で変更することができます。 ( thx to id:tukaelu )

やり方

まずはベータ版ビルダーを使って、表示されている高さと一致するようなウィジェットを2つ配置します。

Zendesk explorer のベータ版ビルダーを使って作成したダッシュボードに、元々表示されていた高さと一致するような文字列ウィジェットを横並びに2つ配置されている様子
ウィジェットを2つ配置した様子

次に、配置したウィジェットのうち片方を掴み、もう片方の上に持っていきます。

横並びに2つ配置されていたウィジェットのうち片方を、もう片方のウィジェットの上に移動させた様子
ウィジェットを縦に並べた様子

最後に、上に配置したウィジェットの右下を掴み、サイズ変更ができるようになったら、スクロールをかけ、止まったらちょっと掴んだままマウスを下にづらし、またスクロールをかけ...を繰り返します。

伸ばしている様子

M1 Mac と Type-C モニター(USB-A ハブ付き) の相性

MBP2021 (M1/13inch) と HP U28 4K における話。

 

U28 4K の USB ハブに HHKB Pro2 Type-S と Scarlett Solo Gen.3 (オーディオインターフェース) を挿して、 USB Type-C ケーブルで MBP と繋いでる。

 

なんとなくわかってきた相性として、「起動時にType-C 挿しっぱなし」だとほぼほぼ USBインターフェースが認識しない（ディスプレイとしては認識する）。そのタイミング〜ログイン画面では USB ハブ側のケーブルも、Type-C ケーブルも抜き差ししたところでなかなか認識されない。たまに認識されるがなぜかはわからない。

 

が、一度ログインしてデスクトップまで行ってから Type-C ケーブルを抜き差しすると（記憶が確かなら）100％認識する。

 

不思議。一瞬オーディオインターフェースの起電力的なあれか？とか思ったけど、別に HHKB だけ挿してもさほど症状は変わらなかった。

「頭が冴える！　毎日が充実する！　スゴい早起き」を読んだ

読了記事

注意

感想記事を書くにあたって、「ブログや scrapbox といった公共発信においてどこまで内容などに触れて良いか」を軽く調査しました。
結果として、「引用や翻案権に注意する」「表紙の写真は貼らない」などのポイントが見えてきたのでそれを実践しつつ記載して見ます。
何か問題などありましたら do_su_0805 (@do_su_0805) | Twitter までよろしくお願いいたします。
慣れてきたりもう少しまとまってきたらそちらもブログに書けたらと思います。

読んだ本

https://www.amazon.co.jp/dp/B07KWLFXX1/

ISBN-10 ‏ : 4799107771 ISBN-13 ‏ : 978-4799107775

感想

はじめに、僕は結構この手の本を読むのを諦めることが多い。
理由としては、ライフスタイルなどに関する本において、大体筆者の行動のきっかけに共感ができなかったり、差し込みにイラッとすることが多いからである。 *1

今回もそうかなぁ... とビクビクしながら読んでみたところ、そこまでのものはなく「そういうことがしたかったんだね」くらいに思える程度での紹介などで読みやすかったというのが助かった。*2.

タイトルの通り、「早起きをして活動を行うとどういうメリットがあるか」という話ではあるんだが、筆者の体験や経験、理論に基づいて「別の誰か」に実践したもらった時のストーリーや結果があるのがパターン評価できてよかった。
結構「とにかく早起きはすごいんだ！」みたいな論調になる本を見かけるけど、この本だと「この人はこういう目標がある中こういうことに困っていた。そこで早起きをして活動時間を確保したところ、こういうメリットを享受できて、結果目標を達成できた(ないしはできそうである)」という流れでの紹介が何パターンもあり、自分の場合どういう実践が取れるかという参考になるのがとてもよかった。

また、心理学的なメソッドやパターンを紹介しつつ、それに当てはめた説明がなされることも納得感がありよかった。根性論みたいな話題でもないので心穏やかな気持ちで読み進めることができた。

少し引いた視点で読んでみると、「早起きをするという『活動』を継続するためのメソッド」をさまざまに説明してくれている本でもあるので、任意の活動に置き換えた時のアプローチパターンという読み方もできるな、と終盤気づいてこれは新鮮な気持ちになった。
( ただし、具体的なメソッドを省いて要約するとつまりは PDCA なんだな、ということもなんとなくわかり、PDCA!PDCA! と叫ぶだけではなくて、それが自然と遂行されるような具体的なメソッドまで落とし込んで説明・理解することが大事なんだな、ということにも気づいて面白かった )

終わりに

  • 結局具体的なメソッドをメモるには private scrapbox しかないのかもう... ってなった
  • Kindle でマンガ以外読むのが大の苦手なのでその訓練も兼ねて読んだんだけど、意外と読めたことに驚きつつ、この本が「位置」表記なのでページがわからなくて困った。こういうもんなのだろうか。

*1: 僕は早とちりかつ若干価値観が変なので、要は手段をくれ！って気持ちになったり、そんな崇高な気持ちはないんじゃ... とへこたれてしまうことが多い

*2:僕の耐性がついただけかはわからない

今日遭遇した ShellCheck

久々に shellscript 書いていたら二つほど koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts に注意されたのでメモ

SC2003 expr is antiquated. Consider rewriting this using $((..)), ${} or [[ ]].

SC2003 · koalaman/shellcheck Wiki

shellscript の中で expr を使ったところ食らった。シェルコマンドに組み込まれている奴らを使いなさいな、とのこと。
自然と expr ${i} + 1 書きがちだし気をつけようと思った

SC2012 Use find instead of ls to better handle non-alphanumeric filenames.

SC2012 · koalaman/shellcheck Wiki

とあるフォルダ配下に、実行後のログファイルを連番でおいていこうとした時に、ついこう書いてしまった。

count=$(ls ${dir} | wc -l)
if [ "${count}" == "" ]; then 
  ${count}=0
fi
filenum=$(expr ${count} + 1)

これも (*.gz) とか知らなかったし、さっきの SC2003 にもあった #var とかも全然使ってないのでふむふむといいながらやっていた。
今回の場合は、count=$(find ${dir} -maxdepth 1 -type f -name "*.csv.gz" | wc -l) にした。一応いいところ取りのつもりではある。

余談

  • alphanumeric : 英数字 はえ〜ってなった。

おまけ : VSCode で ShellCheck

timonwong/vscode-shellcheck: An extension to use shellcheck linter in vscode があるので是非使いましょう。便利

何に使っているかわからない github repository の webhook の正体を探る ( AWS CodeBuild / AWS CodePipeline 編)

aws

題目の通りですが、なんか気づいたらリポジトリに webhook が設定されていたけど、「これなんの webhook だ？」ってなることありませんか？私はあります。

今回は、AWS CodeBuild / AWS CodePipeline 向けの Webhook が「どのプロジェクト」であったり「どのパイプライン」に紐づくものなのかという話です。

AWS CodePipeline 編

CodePipeline が生成する webhook については、aws codepipeline list-webhooks というずばりなコマンドが aws-cli にありますので活用しましょう。 ドキュメントはこちら list-webhooks — AWS CLI 2.1.33 Command Reference

後述の CodeBuild とは違い、CodePipeline 側の設定から github 側の hook 設定画面に飛べるわけではないですが、おそらくご期待の調査は可能かなと思います。

注意点としては、SecretToken など普通に出てくるので実行環境などには注意しましょう。

CodePipeline については、コンソールから調べる方法はわかりませんでした。何かあったら教えてください。

AWS CodeBuild 編

CodeBuild が生成する Webhook については、上手い感じに探せる方法はとりあえずは見つからなく、コンソールからプロジェクトの「ビルドの詳細」画面でちまちまみていくのが良さそうです。画像のような画面の「プライマリソースのウェブフックイベント」にある「ウェブフック」にあるリンクから github repository 側の hook 設定画面にいけますので、それで対応を取ってください。

(逆にいうと、当該リポジトリに対する webhook がなかったらアカウントが違うかそれとも放置されたかって感じです。最低限プロジェクトなかったら webhook 自体がエラーになって github 側からわかると思うのでその辺りはよしなに...)

f:id:do_su_0805:20210331211547p:plain
CodeBuild の設定画面

2021/03/31現在、aws-cli/2.1.32 の時点で aws-cli には webhook 関係が create/update/delete しかなく、webhook 中心の調査ができなさそうです。また、コンソールから開いても同様です。頑張ってください。*1

ドキュメントはこちらです。 codebuild — AWS CLI 2.1.33 Command Reference

*1: 私はがんばりました