YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

OpenTelemetryについての現状まとめ （2020年6月版）

observability OpenTelemetry

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。ここ最近は業務でOpenTelmetry関連をほそぼそとやってきたんですが、ようやくOpenTelemetryも安定版リリースのめどが立ってきたので、これまでと現状と今後を簡単にまとめておこうと思って書き始めたら、全然簡単じゃなくて10000文字超えました。（なおこのシリーズは今後も続きそうな気がするのでタイトルに日付を振っておきました）

TL;DR

  • 分散トレースとメトリクスの計装フレームワークとしてOpenTelemetryというものがCNCF Sandboxプロジェクトとして進行中。これはOpenTracingとOpenCensusのマージプロジェクトであり、各々の正式な後継版である。
  • とはいうものの、まだ仕様もstableリリースになっておらず、当然各言語向けのライブラリも安定版は出ていないので、プロダクションに入れたい人は定期的に様子を伺う程度で良いと思う。
  • 早めに試したいという人はそろそろ各製品向けのexporterが出ているので、軽く試してみても良いと思う。

経緯

OpenTelemetryは現状はアプリケーションのオブザーバビリティのためのライブラリ群で、現状はトレースとメトリクスに関するライブラリを提供しています。OpenTelemetry以前のメトリクスとトレース、そしてOpenTelemetryマージ後の3つに分けて経緯を並べていこうと思います。記憶をもとに書いていますが、時系列はほぼ合ってると思います。

メトリクス

  • Google社内でクラスタマネージメント基盤であるBorgの監視のためにBorgmonを開発する
  • Soundcloudのex-GooglerがBorgmonのコンセプトを元にPrometheusを開発する（2012年ころ）
  • 同時期に同様にTSDBを元にしたモニタリングOSSやAPMが開発され、メトリクス取得に関するAPIやSDKが乱立する
  • 2016年にPrometheusがCNCFプロジェクトととして採択される
  • Google社内で使われていたトレースとメトリクスの計装フレームワークであるCensusを元にOpenCensusが公開される（参照）

トレース

  • 2010年にGoogle社内で使われている分散トレーシング基盤であるDapperに関する論文が発表される
  • Dapperを元にzipkinやJaegerといった分散トレースのOSSが開発される
  • 同時に商用APMでも分散トレーシングの対応が進められる
  • 分散トレースの共通API仕様としてOpenTracingがOSSとして進められ、2016年にCNCFプロジェクトとなる
  • GoogleがOpenCensusとしてメトリクスと同様に分散トレースの仕様と実装を公開・開発する
  • OpenCensusの開発と並行して、W3Cにtrace contextの仕様が提案される
  • 2019年3月末にOpenTracingのブログでOpenCeususとのマージが発表される（まだOpenTelemetryという名前は決まっていなかった）
  • 2019年5月にOpenTelemetryというプロジェクト名が発表されたり、CNCFのTOCへの登録がされたりした。（c.f. CNCFからのアナウンス）またKubeCon EU 2019でも発表された。（セッションの録画）

OpenTelemetryマージ後

  • OpenTracingとOpenCensusの共通項であるトレース部分から仕様の策定が始まり、JavaとGoが参照実装として先行的に実装される。
  • 2019年11月頃にTraceの基本的な仕様と参照実装が揃う
  • 元来は出自からわかるように分散トレースとメトリクスのための計装フレームワークであったが、今後の方向性としてCollectorと呼ばれるエージェントを使うことを想定しているので、Collectorにロギングエージェントとしての機能を持たせるべくLog SIGも2020年4月から活動開始。
  • 2020年5月末現在、仕様はv0.5.0に向けて頑張っている。今の議論が進んでいる議題はMetricsに関してはViews API、CollectorはServerlessサービスとの連携という状況。Logに関してはFluent Bitとの連携を行っている。

仕様

全体的な話

OpenTracingやOpenCensusと同様、OpenTelemetryは各言語ごとにライブラリが存在しているため、細かな実装は言語ごとに異なりますが、OpenTelemetryは常に仕様が先行して策定されるため、大まかな概念はどの言語でも共通しています。

f:id:ymotongpoo:20200601163702p:plain

仕様のレポジトリにある画像を引っ張って来ただけですが、分散トレースもメトリクスも同様の構成になっているので、全体感を把握するにはこの図が一番良いと思います。普通に使う場合は各APMベンダーやOSSが用意したexporterを利用するだけなので、特に気にする必要はないかもしれません。

そうではなくOpenTelemetryを使って計装されたアプリケーションやライブラリからメトリクスやスパンに関するデータを取得して、独自のバックエンドに送信もしくは保存するということをしたい場合にはこれらの違いを意識することになりますが、たいていの場合はAPIとSDKの両方を利用することになります。仕様のドキュメントにも説明がありますが、簡単に紹介すると

  • API: 計装したデータを取得する最低限のインターフェース。各言語向けライブラリ実装者はAPIはなるべく近い設計で実装するよう求められる。
  • SDK: APIの上にデータの取り出し方法や送信方法などの実際にデータを取得して送信する場合に便利なヘルパーが多く用意されている。

自分で使う場合には各言語向けAPIおよびSDK実装を利用することになるので、 opentelemetry-xxx （xxxは言語名）のライブラリを利用することになりますが、SDK実装は主要なAPMバックエンドOSS（Jaeger、Zipkin、Prometheus、標準出力など）のexporterを例として実装することになっているので（SHOULDレベル）それらを参考にしながら作ると良いと思います。

また各言語向けライブラリのレポジトリのディレクトリ構造もできるだけ意味がおなじになるようにガイドラインが提示されているので、そちらを参照しながらライブラリを見ていくとわかりやすいと思います。

トレース

分散トレースのAPIの仕様はここにあるとおりです。（実際にはOpenCensusとOpenTracingの両方がもととしているDapperにある概念と踏襲しているので、どちらかを触ったことがある人は理解しやすいと思います。）

  • Traceは複数のSpanからなる一連の処理のまとまり
  • Spanがある処理の単位。Spanは各Spanの開始・終了のタイムスタンプ、Span内でのイベントとラベルとタイムスタンプ、その他ラベルのキーと値などを保持している
  • TraceとSpanの紐付けをSpanContextで行っている
  • Linkは例えばキューなどを挟んだバッチ処理など、長めの時間軸で別れた処理をつなげる場合に使う
    • Linkを用いると複数のTraceをまとめることができる。（実際にはTrace内のSpanContext同士を紐付ける）
  • Spanの状態はTracerと呼ばれる管理オブジェクトで管理し、Tracer自体の呼び出しはTracerProvierによって行う。（TracerProviderはグローバルでsingletonとして提供される）

メトリクス

メトリクスは基本的にOpenCensusの概念を踏襲しているので、OpenCensusを使ったことがある人は理解しやすいかもしれません。これもやはり仕様を読んでもらえばそのとおりですし、protoファイルを読むのに抵抗がない人はそれを読むのが一番早いのですが、簡単にまとめます。

  • Metric: 取得したいデータとそれに付随するメタデータを取りまとめるオブジェクト。各種メタデータのキーと値、と時系列のデータを保持している。Metricの種類に応じて、記録した時系列データに対する送信インターバル間での処理が変わる。
    • 同期的、加算的、単調的の3つの性質を判断基準として現在Metricの種類が6種類定義されている。
  • Measurement: Metricに記録される時系列データの最小単位。ある時刻におけるデータとそこに紐づくラベルが記録されている。
  • Label: あるアプリケーション内で共通なラベルもMetric事に異なるラベルもすべて同じデータ型である "Label" として扱われている
  • Resource: あるイベントではなく、すべてのMeasurementもしくはMetricに紐づくようなリソースに関係するラベルはResource内でまとめて管理され、再利用される。（例: Kubernetesのpod名、GCEのインスタンス名、など）
  • MetricはMeterを通じて記録され、各MetricはMeterと紐付けられている。MeterはMeterProviderにより提供される。（MeterProviderは通常グローバルでsingletonとして提供される）

各種APMベンダーが自身のバックエンドとの互換性を持てるように意見を出してなるべく最大公約数を踏まえつつ仕様を頑張って絞っているので、Dapperの概念が下地にあって共通認識が持ちやすかった分散トレースよりも議論に時間がかかり、当初予定しているよりもだいぶリリース計画が後ろ倒しになっています。

現在上記の定義に加え、Views API (OTEP #89)というものの導入が議論されています。これはOpenCensusにおけるViewに相当するもので、これが入るとアプリケーションでの計装が楽になると同時に、exporterの実装内でMetricの種類に応じた集計（Aggregation）もやりやすくなる予定です。

コレクター

OpenCensus時代にはServiceと呼ばれていたもので、OpenTelemetryにおいても当初はServiceと呼ばれていたものが、Collectorという名前に改称されました。

OpenTelemetryの特徴はOpenCensusと同様に、テレメトリーデータの取得と送信を切り分けていて、exporterの差し替えを行うだけでバックエンドの切り替えができる（＝アプリケーション内の計装を変えずに済む）という点が利点でした。さらにそれを推し進めてOpenTelemetry用のエージェントを用意して、バックエンドの切り替えをエージェント側でのみ行うようにすれば、アプリケーションコードを一切変更せずに、エージェントの設定切り替えだけでバックエンドの切り替えができるようになります。

またそれだけでなく、コレクターはGoで実装されているのですが、コレクターからバックエンドへの送信を行うexporterはGoでのみ実装すれば良くなるので（各言語のSDK実装はコレクターへの送信を行うexporterは実装している）、コレクターがメインの構成が進むとAPMベンダーの対応も楽になるという利点があります。

f:id:ymotongpoo:20200601163747p:plain

この図はopentelemetry-collector内の設計に掲載されているものですが、見てわかるようにOpenCensusのときのものをそのまま採用しています。

もちろん、アプリケーションから直接テレメトリーを送信する構成と違って、新しい層が導入されるので複雑さは増しますが、アプリケーションからバックエンド固有のコードを排除したという意味では、開発プロセスを考えたときにメリットがありそうです。

さらに、分散トレースとメトリクスの送信を行うエージェントがせっかく走っているので、ログフォワーディングもそれに行わせたい、というのがいまLog SIGで行っていることです。

ガバナンス

プロジェクト全体

CNCFプロジェクトであるためオープンガバナンスが求めらます。おおよそCNCF sandboxプロジェクトとして求められる役職と手続きを設定して行っていますので、詳細はこちらを参照してください。

まず大元にGovernance Committee Charterがあり、Technical Committee Charterの健全性の担保やCode of Conductの設定、マーケティング活動、などなどを行っています。Governance Committeeのメンバーは2019年は初期メンバー5人がOpenTracingとOpenCensusのコミュニティーから設定され、以降は選挙により1年毎に2年の任期で選出されます。（3人、2人と年ごとに交代していく）選挙への参加はコミュニティーでの貢献（Pull Request数、Issue数など）が20以上のアクテイブな人と、既存のメンテナーが可能です。立候補者が出揃った後、選挙参加者による投票によって得票数順にGovernance Committeeメンバーが決定されます。

Technical Committee Charterはリリースに関する決定やレポジトリの管理、コーディング規約など、技術的な意思決定を行います。また各SIGとのすり合わせもTCの担当です。TCメンバーもGCと同様の基準の参加者による選挙から選出されます。またTCにはChairもいて、その決定も追加の選挙で行われます。

また言語関係ない仕様の提案に関しては、 OTEP (OpenTelemetry Enhancement Proposal) という形で提案が行われ、cross language spec SIGのapproverが許可したものに関しては仕様に反映されていく形になります。

各SIG・レポジトリ

各SIGのメンバーはmember、approver、maintainerの3種類に別れ、それぞれ細かな基準があります。

各SIGは技術領域によって分かれていて、現在は次のSIGが存在しています。

各SIGのレポジトリは opentelemetry-xxx という命名規則で open-telemetry org配下に置かれています。

各SIGのミーティングは常にオープンで、いつ開催されるかは各種カレンダーフォーマットで公開されていて、議事録はGoogle Docsで公開されていて誰でも参加・閲覧可能です。また各SIGのGitterも誰でも参加可能です。

詳細は community レポジトリの README.md に諸々リンクしてあります。

github.com

またOpenTelemetry本体の機能としては入らないけれども、みんなが使えると嬉しいもの（特定の言語でメジャーなフレームワークに対して組み込めるプラグインなど）は opentelemetry-xxx-contrib というレポジトリにまとめていく方向で動いています。

参加企業・OSS

OpenTelemetryはアプリケーションの後ろで使われるAPMに大きく影響を与えることになるため、その参加企業・OSSプロジェクトがどれくらい積極的に参加しているかも気になると思います。いままで自分はGo SIGしか確認していませんでしたが、各SIGの議事録も含めて確認できた参加企業やOSSプロジェクトは次の通りでした。（レポジトリのPull Requestだけでなく、仕様策定や実装策定に関わっている人をピックアップするためにそうしました）

大まかな数でしか見ていないですが、前に書いてある会社ほど参加回数が多くなるように並べています。

  • APM vendor/Cloud Platformer
    • Google、Microsoft、New Relic、Dynatrace、LightStep、Splunk / Omnition、Honeycomb.io、Datadog、AWS、Sumo Logic、Zillow Group、VMWare / Wavefront、Elastic、Logz.io、Sentry、Orijitech、Arm Treasure Data
  • OSS
    • Prometheus、Jaeger、Grafana
  • Infrastructure
    • Salesforce/Heroku、Postmates、Fastly、Kinvolk、Bison Trails、Verizon Media、Cisco、Mailchimp、Out There Labs
  • User

参照