OpenCensus Meetup vol.1に参加してきました。本記事ではイベントで話されたことをまとめます。

イベントでは OpenCensusの概要紹介や、OpenCensusを使ってみて便利だったところと辛かったところ、辛さを解消するために行ったことについて話されていました。

OpenCensusの概要の把握や、深掘りするかどうかの判断の参考になれば幸いです。

目次

Session 1: OpenCensus Intro and Status Update @ymotongpoo

オープニング兼 OpenCensus の概要紹介のセッションでした。OpenCensus Servicesは期待

  • OpenCensusはアプリケーションのメトリクスと分散トレースを取得するためのライブラリ
  • 様々な環境をサポートしている
    • 言語: Go, Java, Node, PHP, Rubyなど
    • バックエンド: Prometheus, Stackdriver, Datadog, X-Rayなど
  • メトリクスを収集して、保存や可視化を行うバックエンドに投げるまでが責務
  • 責務の範囲を図解したのが下図。CollectorとExporterを担当する
  • 現在進行中のプロジェクトとして、OpenCensus Agent/Collectorが開発されている
    • Agent: Exporterを担当する。Export先のBackendを切り替えたい場合に、アプリケーションの変更無しに切り替えられるようになって嬉しい
    • Collector: Collector / Agent からメトリクスを多段で収集できる
  • Observability についてわいわいやるDiscordつくったので来てね

(発表資料から抜粋)

発表資料: OpenCensus Intro and Status Update

Session 2: OpenCensusを実際に使ってみて、便利なところと、困ってるところ @sinmetal

自作のマルチプレイヤーゲームのパフォーマンスモニタリング、Spannerのパフォーマンステストをして得られた知見についてのセッションでした。

レアケースが取りにくい問題は実運用で起こりそうなので、条件がわかるようにログを埋め込むのが大事だと感じました。

マルチプレイヤーゲームのパフォーマンスモニタリング

  • 100msecごとにAIの行動を決定するサービスにリクエストを投げ、Firestoreに書き込む
  • AIの思考時間とFirestoreの処理時間を計測した
  • GoでTraceを取得した。計測したい箇所で startSpan して即 defer span.End() すればOK
  • AIの処理時間が気になっていたが、traceを取ってみると大して時間がかかっていないことがわかる!
  • GCPのクライアントライブラリを使う場合は、通信部分にライブラリ側に入ってるので自動的にトレースが取れるようになる
  • 特にSpannerのライブラリはリッチで、通信以外の計測もしてくれている

(発表資料から抜粋)

Spannerのパフォーマンスモニタリング

  • Spannerがたまに遅いときがある気がするという話があったので調査した
  • 問題になるレアケースがサンプリングされない。つらい
  • AlwaysSampleにもしてみたが、バッファがいっぱいになって取りこぼす
  • 捕まえたいケースが出たらalways sampleしようと思ったが、サンプリングするかどうかは親のspanで決まってるので無理
  • どうにか条件掴んで再現し、トレースを取りましょう

発表資料: OpenCensusを実際に使ってみて、便利なところと、困ってるところ

Session 3: Distributed Tracing with OpenCensus at Wantedly @munisystem

WantedlyでOpencensusを導入した理由、どう使っているかと残っている課題についてのセッションでした。 技術選定の過程で考えたことまで解説されているので、ぜひ発表資料も見てみて下さい。

  • Wantedlyでは2016年の Wantedly Peopleからマイクロサービスを採用している
    • 当時は主にRailsだったが、Railsでは実現しにくい機能があった(並列化、機械学習)
    • 開発とリリースの高速化
  • リクエスト先でどんな処理が行われるかを知りたいので分散トレーシングを導入
  • 分散トレーシングのバックエンドはDatadog APM と Stackdriver Trace
    • もともと Datadogを利用していたためメインはDatadog APM
    • 将来的にはバックエンドを統一する
  • 各マイクロサービスに必要なロジックを提供するためのライブラリを用意している
    • Timeout, Retry, Authentication, Loggingなど
  • 下記メタデータをTraceに乗せている
    • Kubernetes metadata (node, pod, podIDなど)
    • Request ID
    • User ID
    • Datadog APM 用のデータ
  • サンプリングの設定
    • 開発環境はすべてのリクエストを、Productionでは1%のリクエストのトレースを取っている
  • 現状感じている課題
    • バックエンド固有の仕様に対応するのが大変
    • 例: Datadog APMでは spen.typeの値でサービスのカテゴライズが変わる。これをどこで実装するか?
    • Opencensus Serviceが回答になるかも

発表資料: Distributed Tracing with OpenCensus at Wantedly

Session 4: OpenCensus Javaで始めるOpenCensus @grimrose

JavaでOpenCensusを使う際の知見や、他のライブラリとの違いについてのセッションでした。

  • OpenCensusのJava実装: opencensus-java
    • Export先
    • Trace .. Stackdriver, Jaeger, Zipkin, Datadogなど
    • Stats .. Stackdriver, Prometheusなど
    • Android compatible(androidでも使える) らしい
  • 特定のバックエンドに対応したExporterが多い
  • Spring で使う場合下記が有名
    • Tracing .. Spring Cloud Sleuth. export先はzipkin
    • Stats .. micromether. export先が豊富
  • 実装する際のtips
    • まずpropergationのformatを選びましょう
    • Servlet向けのライブラリは用意されてます。それ以外のフレームワークを使う場合は自分たちで頑張る
    • Traceの実装では try with resources文を使います。ネストが深くなりすぎないよう気をつける
    • Statsの実装で、CustomMetricsを作る場合は単位と境界(時間的な話かな)に気をつける
    • on/offや接続先を切り替えられるようにする

発表資料: OpenCensus Javaで始めるOpenCensus

LT1: Ruby実装について / Ruby implementation @kawasy

OpenCensusのRuby実装の人気がなさすぎて悲しいので(しかし自分たちには必要)、コントリビュートしていく宣言をするLTでした

発表資料: Ruby実装について

LT2: TracingとLoggingの連携 / Tracing and logging correlation @ladicle

トレースにログを埋め込むLTでした。TracingとLogging、連携させていきたい。

  • Observabilityの三本柱
    • Metrics
    • Tracing
    • Logging
  • 上記3つを計測していると、デバッグ時にはトレースから、その時のログを見たくなる場合が多い
  • トレースにログを追加する
  • デモ。Go + OpenCensus + Jaegerでトレースとログを取得した
    • https://github.com/Ladicle/opencensus-and-jaeger
    • 少し闇の実装があって、OpenCensusではログをトレースに付与するためのフィールドがないため、アノテーションにログをおいた
    • 遅いリクエストのトレースから、その時の状況が分かって嬉しい

発表資料: TracingとLoggingの連携

LT3: OpenCensus Stats で PaaS のメトリクスを補完する / Interpolate PaaS metrics with OpenCensus Stats @apstdnb

Platformでは取得できないアプリケーションのメトリクスをOpenCensus Statsで取得するLTでした

  • AppEngine と Stackdriverは連携しており、何もしなくてもいくらかのメトリクスは取れる
  • しかしアプリケーション固有のメトリクスは出ない
  • そこでOpenCensus Stats
  • Goではnet/http向けにochttpパッケージが提供されている
  • ochttpで各ルートのhttp.Handleラップ、viewの設定、exporterの設定をすればOK
    • 詳細な実装は発表資料、ドキュメントを参照

発表資料: OpenCensus Stats で PaaS のメトリクスを補完する

LT4: JavaのCustom Exporterを書いてみた / Writing custom exporter for Java @r_rudi

OpenCensus で Java の X-Ray 向け Exporter がなかったので作ってみたLTでした。

  • 会社のプロジェクトでは Java11 (+一部go) + AWS で開発している
  • 分散アプリケーションの分析とデバッグには X-Rayを使用
  • しかしJava向けのX-Ray exporterがない
  • 作ってみた opencensus-exporter-trace-xray
  • X-RayとOpenCensusの仕様の差
    • name .. XRay:アプリケーションごと / OC: spanごと
    • attribute .. XRay: 1回のsegmentごと / OC: timelineの個々のイベントごと
    • child span .. XRay: subsegmentを埋め込む / OC: parentから構築
  • 徐々に充実させていく

発表資料: JavaのCustom Exporterを書いてみた

LT5: ウェブフロントエンドからサーバーまでの一気通貫のトレーシングに挑戦してみる / Try consistent tracing from web frontend to backend servers

ユーザの操作を含めたトレーシングに挑戦するというLTでした。 トレースとユーザの操作履歴が同時に見られる環境、めちゃ便利そう

  • 不具合があったときに、ユーザがどういう操作をして不具合が起きたかを知りたい
  • OpenCensusは良さそうだが、フロントむけのものは見当たらない
    • LT当日に所望のライブラリがあることが発覚
    • opencensus-web
  • 作ってみた
    • APIとは別でフロントのログを取るためのエンドポイントを作る
    • websocketを利用し、1つのrootSpanごとの1セッションの接続でハンドリングする
    • Redux-Thunkのアクションを1つのroot spanにする
    • https://github.com/shibukawa/opencensus-sample

発表資料: ウェブフロントエンドからサーバーまでの一気通貫のトレーシングに挑戦してみる

最後に

今までOpenCensus はTraceを少ししか触ったことなかったのですが、今回のミートアップで全体像の把握と利用イメージをついて良かったです。

OpenCensus使っていこうと思います。ミートアップ2回目も楽しみにしてます!

参考リンク

Opencensus: https://opencensus.io/