OpenTelemetry Meetup 2024-02 まとめ #oteljp
オブザーバビリティの観点として、トレースは100%取りたいというのはめちゃくちゃわかりすぎる。Cloud Traceとかはデフォでサンプリングしてて「後で見返して性能問題とかに気づくものでしょ」って感じのスタンスなので、この辺のカルチャーがとても遅れていると思っている。 #oteljp
2024-02-15 20:49:51@sumiren_t 全数トレースはレイテンシーが遅くてもいいものであればいいんですが、そうでない場合はオーバーヘッドの問題があるので、SDKレベルでalways onをopt outとするのは難しい課題です #oteljp
2024-02-15 20:52:16分散トレースで tail sampling やろうとすると一度集約する必要があって難しい。確かにそんな仕組みを自前でメンテしたくない系だ #oteljp
2024-02-15 20:52:25ISUCONのサンプルアプリに計装加えると、N+1とかここでスリープしているとか、色々見えて面白かった覚えがあります #oteljp
2024-02-15 20:53:38N+1 やら、これ直列に待ってるの誰も嬉しくなくね?やら、主に遅いことが分かっているシステム境界が自動計装されるのは素朴に嬉しいことが多いと思う #oteljp
2024-02-15 20:55:18#oteljp 特定のrequest pathは絶対trace取りたいとかは、 トップレベルのリクエストで判別可能なら、head base samplingでもcustom samplerみたいなの作ってあげればとれるけれど、 トップレベルのリクエストで判別不可能なら tail baseでがんばるしかなさそうな。
2024-02-15 20:55:31そもそものフロントエンドにおけるトレースって何かわからない。ユーザーがページを開いたときが起点?イベントを発火したときが起点? #oteljp twitter.com/kory__3/status…
2024-02-15 20:56:57OTel をフロントエンドで動かすの、span が (自動管理の範囲だと) 非同期境界を越えられず、一トランザクションが複数リクエストにまたがるような場合に手動で span / traceId を引き回す必要があるという認識なんですけど、最近は何とかなったりしてるのか気になります #oteljp
2024-02-15 20:49:31メトリクス、トレース、と集約してコンテキストを入れたい時に Collector 使ってると OpenTelemetry の世界でできて便利 #oteljp
2024-02-15 20:59:15N+5000はなかったが、2msのクエリが1万回くらいfor文で叩かれてたときは、いくらスクロールしても画面の下までたどり着かず、そっ閉じした #oteljp
2024-02-15 21:01:00単純にobservability backendにログを送るだけだったら確かにOTelのメリットをあまり享受できなさそう #oteljp
2024-02-15 21:01:22fluentbit 確かに OpenTelemetry Output のページある "An output plugin to submit Logs, Metrics, or Traces to an OpenTelemetry endpoint" docs.fluentbit.io/manual/pipelin… #oteljp
2024-02-15 21:02:28