オブザーバビリティを 支える要素技術を学ぼう フロントエンド・オブザーバビリティ Meetup @sadnessOjisan

自己紹介 ● ID: sadnessOjisan

今日の経緯 ゆかこさん「フロントエンドとo11y周りの知見ある人いない？」 わるいひと「sadnessOjisan」 - - - ゆかこさん「かくかくしかじか、よろしくおねがいします」 sadnessOjisan「おk」 sadnessOjisan「（フロントエンドの o11y って何？）」

o11y 何もわからないよ〜 otel Meter agent RUM APM

フロントエンドの o11y ってなに？ ● ブラウザの世界ではプロファイルは出せるけど、それって盗み見れないし可観 測性はないよな ● クライアントサイドJSに仕込む APM の話？ ● CDNやNode.jsまで拡張してフロントエンドと呼んで良い？ ● PaaS戦国時代で最近はフロントエンドエンジニア自らがインフラの面倒も見る し、インフラメトリクスの話もあり？ インフラメトリクス + APM + Node.js 計装の話をします

なぜフロントエンドの o11y を勉強しているのか ● 昔からソフトウェア改善に関する仕事をスポットでこなしています。 ● しかし、正直言ってきちんと仕事を完遂できたことはあまりないです。 ● （相談に回ってくるものは、最初からハードモードなので... ● 根本的な改善ができないので、何かしらの妥協を提案するしかない ● o11y 周りの整備はちょうど良い

妥協提案での o11y がコスパ良い ● ソフトウェア改善活動の前にテストを用意したい ● テストを書きたいが、そもそもテスタブルな設計ではないので書けない ● テスタブルな設計に書き換えたいけど、テストがない... ● 代わりに o11y を担保して、「ソフトウェアの中で何が起きているかを盗み見 て仕様を読み取る」「動作確認にトレースを比較する」といったことができる ● o11y 向上はソースコードを改変せずに始められる

tracing がお気に入り ● OpenTelemetry も好きだが、そもそも trace 技術そのものが好き ● 実は分散トレーシングには興味がなく、嬉しかった思い出もない ● 1アプリケーションだけでも挙動をトレースに出せることが旨い。 OpenTelemetry はそのためのSDKが揃っているというのが旨い。

インフラのモニタリングの始め方 システム 集計サーバー いま負荷これくらい 計測

計測エージェント ● インスタンスに直接仕込む ○ OS にダウンロードする ○ 製品がバイナリを配布しているので、それを読み込んでインスタンスを起動するとセットアップ できる ○ 自動で立ち上がるように最初のセットアップで行う。大抵はワンライナーが提供されている。 ● コンテナに仕込む ○ 最近はコンテナでアプリを展開するのが普及しているので ○ コンテナにエージェントをダウンロードし、エージェントごとアプリを起動する ○ Dockerfileいじるだけで完結させられる

エージェントが何をしているのか ● 知らない。バイナリ配布されていてコードが読めないから... ● OSS のエージェントもある ○ https://github.com/zabbix/zabbix/tree/master/src/zabbix_agent ● https://www.zabbix.com/documentation/2.2/jp/manual/concepts/agent に よると計測はネイティブのシステムコールを利用する

システムコール ● カーネルに処理を依頼するための プリミティブな命令 ● OS が持っているさまざまな数値 を出すコールがある。 ○ ディスクの読み書き状況 ○ CPU負荷 ○ ネットワーク負荷 ● 普段使っているコマンドの前に strace と付けると見れる パフォーマンスチューニング本と言われ ているが、実態はLinux鈍器。 perf に関するシステムコールの教科書 という側面もある 分厚さが伝わる画像

ブラウザのモニタリング ● 名前が知られているのは Lighthouse ● けどこれは自分のブラウザで実行するもの ● 人の環境でこれを実行することができる。 ● →Real User Monitoring ● ※ パフォーマンスの測定だけなら外型監視 でも済ませられる。Synthetics Monitoring

Real User Monitoring ● ユーザーの行動を録画して、ダッシュボードで再生できる ● ユーザーがどういう回遊をすればコンバージョンするかを調べる ● ユーザーの実機でどのようなパフォーマンスか調べる ユーザーのブラウザ上で動くエージェントが必要

UXモニタリング ● ヒートマップ ○ 古くからいろんなマーケティング企業が提供して いる ○ ブラウザのマウスカーソル位置をスクロール量を 記録するだけで実装できる ● 画面の録画 ○ 自作した話をフロントエンドカンファレンス北海 道で聞いた ○ rrweb というライブラリもあるらしい https://speakerdeck.com/yukukotani/recording-we b-app-user-screen-powered-by-web-tech

ブラウザでのパフォーマンス測定 ● https://www.npmjs.com/pack age/web-vitals のラッパーを作 れば標準的なメトリクスは提供 できる。 ● ブラウザ自体にも https://developer.mozilla.org /en-US/docs/Web/API/Perfor mance_API があり、 web-vitals はこれを利用してい る

Application (Error|Perf) Monitoring ● アプリケーションに計測ライブラリを入れるやつ ● インフラモニタリングと違って、ソースコード自体に手を入れる必要がある ● 場合によっては計測のために関数を呼ぶ必要もある

Sentry ● 言わずと知れたやつ。エラーのアラートに使わ れがち。 ● 昔 SDK を読んだことがある ● captureExceptionに渡したエラーが報告される ● OnUncaughtException にて補足されていないエ ラーが報告される ● Sentryでの見え方、アラートの出方はどう Error を作るか次第 https://blog.ojisan.io/sentry-sdk-kan zen-rikai/

Error.prototype.name, Error.prototype.cause ● Error の name プロパティによって整理される。カス タマイズエラーを定義するなどしてカスタマイズ推 奨。 ● Node v16 から cause によってエラーのトレースを引 き継げるようになり、例外の握り潰しを防げるように なった。 ● カスタムエラーの作り方は https://www.wantedly.com/companies/wantedly /post_articles/492456 というブログに従うと良い と思う。 ● cause の積み方は自分もブログに書いたことがある。 https://blog.ojisan.io/my-new-error/

OpenTelemetry ● OpenTelemetry, also known as OTel, is a vendor-neutral open source Observability. ● コミュニティ主導で SDK も作られている ● trace も metrics も取れる 自分の言葉で説明できないので今日は触れ ません。

tracing ● The path of a request through your application. Traces give us the big picture of what happens when a request is made to an application. ● span という単位で処理の記録を見れる。 ● span は自分自身の id と親の id を持てる ので、span 間の関係が分かる -> どの span の中で作られた span かが分かること で処理の依存関係や実行時間を可視化でき る。 ● attribute として関数のIN/OUTも紐付け られる https://opentelemetry.io/docs/concepts/signals/traces/#spans 処理した関数の引数 なども記録できる。

OpenTelemetryの始め方 ● 一番簡単なのはライブラリ入 れて、 起動スクリプトを書 いて、アプリケーションの実 行時に起動スクリプトを呼び 出すこと ● これだけで tracing できま す！ ● ほんとうに？ https://opentelemetry.io/docs/languages/js/getting-start ed/nodejs/

送り先は環境変数でセットできる ● 送り先を設定していなくない？ ● 環境変数でセット。 OTEL_EXPORTER_OTLP_ENDPOINT など ● 送り先の port, OTLPかgRPCによって変 わったりもする ● 仕様として決まっている（知っていて当 然扱い）になっていて、otel サポート の SaaS にこの情報が書かれておらず、 初学者が導入したときにどこに送れば良 いかわからなくて困ることがある（１ 敗） https://opentelemetry.io/docs/specs/otel/configuratio n/sdk-environment-variables/

自動計装ライブラリが計装ライブラリを呼び出す ● @opentelemetry/auto-instrumentatio ns-node: 自動計装ライブラリ ● @opentelemetry/api: 計装ライブラリ ● 本来計装では span の開始と終了を関数の 中に仕込んでいく ● 自動でやってくれるって本当に？ https://opentelemetry.io/docs/languages/js/in strumentation/#create-nested-spans

どうして自動計装が可能なのか A. 計装対象を絞っているからです. 右にあ るライブラリの関数はフックされる https://blog.ojisan.io/otel-node-sdk/

モンキーパッチでフックする ● shimmer を使ったモンキーパッチ ○ モンキーパッチ（Monkey patch）は、システムソフトウェアを補完するために、プログラムをその時その場の実行範囲内で拡張または 修正するというテクニックである。モンキーパッチの影響はその時その場のプロセス（プログラムの実行インスタンス）だけに限定さ れて、プログラム本体には及ばない。 モンキーパッチは動的プログラミング分野の用語であり、その定義はRubyやPythonなどの各言語 コミュニティに依存している[1][2]。サードパーティ製のランタイムシステム、ソフトウェアフレームワーク、仮想マシン上で発生し がちな、好ましくない動作の違いや各種バグに対してパッチ当てすることを目的にしての、プロセス上に展開されたクラスコードやモ ジュールコードの動的な修正作業、という点は共通している。 ● express の場合、route, use という関数が使われると計装の処理が挟み込まれ るようにモンキーパッチしている

自動計装で十分ですか ● A. 自分は不十分だと思っている ● o11y の嬉しさの一つに追加実装なしでデバッグできることというのがあると思 うが、少ない trace でデバッグしようとしても困難だと思う。結局 log を出力 するためのコードを挟むことになるとは思う。なのでマニュアル計装した方が 良いという立場 ● けど大変だよね

手動計装の何が大変か ● 高階関数を作る ● span を作る ● トレースしたい値があれば attribute にセットする ● span を閉じる 実装が計測のためのコードで汚れる！！！ なんか変じゃない？？？？？？？？？ https://opentelemetry.io/docs/languages/js/in strumentation/#create-nested-spans

その点 Rust は良いよなぁ ● 計測に関するコードを全部マクロに押 しやれる ● 入門記事を書いた https://blog.ojisan.io/rust-tracing/ マクロの引数で値のマスキ ングもできる

とはいえ始めるなら自動計装 ● Opentelemetry を始める障壁は小さい ○ （ otel backend を作るのは大変ってのは今日は触れていないが。。。お金を払って IaaS で解決 するしか...) ● 自動計装ライブラリ入れてセットアップスクリプトを書くだけで、ソースコー ドを汚さずに trace を取れるようになる ● 段階的にマニュアル計装を入れていくと良い とりあえず始めるなら otel + tracing です。 誰も触れないような古いシステムのデバッグの第一歩にちょうど良い！

JS + otel 周辺に対する最近の本音 ● （otel 流行ってるけど、ちゃんと導入して役に立った思い出ある？） ● （自動計装だと全然情報取れなくて何もわからなかった） ● （マニュアル計装はソースコードが汚れるからあまりしたくない） ● （実際、皆さんどうですか？本当に満足していますか？）

宣伝: WDC 9/7 に喋ります！SameSite Cookie 付けたシ ステム、ローカルホストでどう開発するの問題？ https://fortee.jp/web-dev-conf-2024