「OpenTelemetry Meetup 2024-06」に参加してきました

ABEMA と分散トレーシングのあゆみ

マイクロサービスを採用してる
Netflix/vizceralをもとにした独自可視化ツールを使ってた
- 新しいサービスでのメンテが辛くなってきた
- 負荷試験でどこで詰まってるか探しづらい
- istio-proxyで詰まることが多くてマイクロサービスのメトリクスに反映されない
当初
- AWSとGoogleCloud使い分けてる
  - EKSはAWS App Mesh AWS X-Rayを導入
  - GKEはCloud Trace
- 両方へ依存は学習コスト高い
- 金額的なコストも高い
  - サンプリングレートは0.01%
  - 本番だとこれじゃ足りないのでユースケース絞って負荷試験で活用するくらい
- クラウドをまたがったトレースができない
OpenTelemetryを導入へ
- 当初は慣れてる従来のツールを使う人が多かった
- 開発者に影響がないように導入したので知らない人も多かった

flagを変えた時間からエラーが増えたからと行ってそれが原因と言い切れない
flagの管理はいろいろサービスがあるので使うといい
- だいたいsdkが用意されててそれを使う
- ロックインが強いので選定は注意
OpenFeature
- OSSで標準規格を見据えてる
- BEとの中間層に位置する
- 裏側を差し替えられるのでロックインしなくなる
OpenFeatureHooks
- flag評価のライフサイクルへで処理を動かせる
- そこでログ記録したりできる
- otel用のhooksがあるのでそれを使うと自動でシグナル送れる

Lambdaの呼び出しなどもDatadogに送りたい
- Datadogを使ってるのでX-Rayは使いたくない
- OTel以外のライブラリは使いたくない
LambdaでOTel
- OTel collectorをLambdaExtensionで動かす
- extensionを使うと関数を拡張してinitなどのタイミングで処理を呼べる
- opentelemetry-lambda
  - Layerとして配布されている
- AWS Distribution for OpenTelemetry Lambda
  - ADOT Lambda
  - AWSがメンテしてるopentelemetry-lambdaのディストリビューション
  - AWSが選んだコンポーネントからなるcollectorを動かす
OTel Lambdaのカスタムビルド
- Datadogを使いたいのでカスタムビルドする
- Otel collectorのカスタムビルドと考え方は同じ
- opentelemetry-lambdaをforkしてREADMEに従ってやるといい

リポジトリが複雑でどこに何があるかわからない
- モノレポになってる
TraceとMetricsはStable
LogはExperimental
@opentelemetry/xxxのnpmパッケージが大量にありすぎてほしいものを見つけられない
@opentelemetry/api
- spanを作るようなところはここに入ってる
自動計装パッケージ
- ほぼexperomental
- TraceProviderのregistorで渡すだけで使える
- globalのfetchなどを上書きして送る
globalの関数を上書きせずに自動計装したい
- ServiceWorkerでfetchイベントをプロキシする
- そこでspan作ったりする
- TraceExporterがfetchしか動かない環境を想定してない
  - issue作ってる