
English: 
- Hi, I'm John Watson.
I'm a Lead Software
Engineer here at New Relic,
and one of the maintainers
of the Java implementation
of OpenTelemetry.
The goal of the OpenTelemetry project
is to provide a single set
of APIs libraries and
agents to capture metrics
and distributed traces
from your applications.
This applies across many
languages and platforms.
The project also includes an
optional collector service.
OpenTelemetry has a dedicated
repository for specifications.
It's a lot to take in.
And you may have a lot of questions
on what it all means in practical terms.
Today, I'm gonna try to
provide some context for that
and explain the high level architecture
of an OpenTelemetry implementation.
So, at the high level,
OpenTelemetry is comprised
of three main pieces.
First, we have a set of APIs,
and that's used to instrument
libraries, frameworks and applications.
Second, there's an SDK
that implements those APIs.
And finally, there's an optional collector
that can ingest, aggregate,
and export telemetry data
wherever you need it.

Japanese: 
— こんにちは、私はジョン・ワトソンといいます。
New Relicのリードソフトウェアエンジニアで、
OpenTelemetryにおけるJava実装の
管理者の１人です。
OpenTelemetryプロジェクトのゴールは
アプリケーションからのMetricsと
分散トレースを収集するためのAPIライブラリと
エージェントを1セットで提供することです。
これは多くの言語とプラットフォームに適用されます。
このプロジェクトには、オプションとしてコレクターサービスも含まれています。
OpenTelemetryには、仕様に最適化されたリポジトリがあり、
そこから学べることが色々とあります。
そしておそらく、登場する様々な用語について
沢山の質問が出てくるかと思います。
今回、私からはそれらの意味と
またOpenTelemetry実装における
ハイレベルのアーキテクチャについて説明します。
さて、OpenTelemetryは
大まかに3つの主要な部分で構成されています。
まず、New Relicには一連のAPIがあり、
それはライブラリ、フレームワーク、アプリケーションを
計装するために使用されます。
次に、それらのAPIを実装するSDKがあります。
そして最後に、オプションとしてのCollectorがあり、
必要な場所でテレメトリーデータの取り込み、集積、および
エクスポートができます。

Japanese: 
OpenTelemetryアーキテクチャは、
設定の必要がない完成されたテレメトリーソリューションで
あることが想定されていますが、
必要に応じて、カスタム可能な
拡張要素も多く存在します。
APIについてお話ししましょう。
先述の通り、APIの目的は、
ライブラリやアプリケーションコードのための
計装を可能にすることです。
APIには、4つの主要な区分があります：
Tracing
Meters、
Shared ContextとSemantic Conventionsです。
それらについて１つずつお話ししましょう。
ではまず、当社にはTracer APIがあります。
Tracer APIは、
Spanの作成、注釈、完了をサポートします。
全てのTracerに名前とバージョンが割り当てられ、
それによってどの計装が
Spanを作成したか追跡できます。
Meter APIは様々なMetric 計装への
アクセスを提供します。
これら計装の例は
counters、value recorders、そしてobserversです。
Metric APIとMeter APIは
最大範囲の計装を提供しますが
全てのMetric計装の使用例をカバーする必要があります。

English: 
It's important to note that
although the OpenTelemetry
architecture is intended to be
a complete telemetry
solution out of the box,
there are many extension points
that allow for customization as needed.
Let's start by talking about the API.
So the purpose of the API as I mentioned,
is to enable creating instrumentation
for libraries and the application code.
The API has four main sections:
tracing,
meters,
a shared context and some
semantic conventions.
Let's talk about them one by one.
So first we have the tracer API.
Tracer API, as you might expect,
supports creating, annotating
and completing spans.
Every tracer is assigned
a name and a version
that will enable tracking
what instrumentation created the spans.
The meter API provides access
to a wide variety of metric instruments.
Examples of these instruments
are counters, value
recorders and observers.
The metric API and the meter API
provide a full range
of instruments however
that should cover all metric
instrumentation use cases.

English: 
Next, we have the context API.
And this enables tracking
and executing span context
and propagating that context
both within and externally to your system.
Pretty uniquely to OpenTelemetry,
the APIs have been designed
so that context is actually available
to both tracers and metric instruments.
And this actually will enable
some interesting features
that are relatively unique,
like capturing exemplar spans
while metrics are being collected.
So the final piece of the API
is a set of semantic conventions.
These semantic conventions
contain guidelines and
rules for naming mostly.
Naming the spans, attributes, labels,
and metric instruments themselves.
And the goal of the conventions
is to ensure consistency
across various language implementations,
and also for external instrumentation
that might be built with those APIs.

Japanese: 
次に、当社にはContext APIがあります。
これはSpan contextの追跡と実行を可能にし、
そのContextをあなたのシステムの
内外に伝搬させることができます。
OpenTelemetryにとっては非常に珍しいことですが、
このAPIは、そのContextが
TracerおよびMetric計装の両方で
利用可能となるように設計されました。
実際にこれは興味深い機能を可能にします。
それはMetricsが収集されている間に
見本となるSpanを収集するような
とてもユニークなものです。
さて、APIの最後のピースは
Semantic Conventionsです。
Semantic Conventionsの
大半はネーミングに関する指針とルールが含まれています。
Span、属性、ラベル、および
Metric計装そのもののネーミングです。
Semantic Conventionsが目標としているのは、様々な言語での実装の全体的な一貫性を
確保することと、
それらのAPIと合わせて構築される場合がある
外部の計装のためでもあります。

Japanese: 
先述したように、これらAPIの目的は
計装を書き出せるようにすることです。
しかし、その計装から
テレメトリーを実際に生成するためには、
SDKが必要です。
そしてSDKは、それらAPIの実装です。
そしてつまり、
SDKは大まかに3つの分けることができます：
Tracer SDK、Meter SDKおよびShared Contextです。
ではまず、Tracer SDKで実装されている
Tracer Pipelineについて説明しましょう。
Tracer SDKは、Spanプロセッサおよび
サンプリング戦略で設定可能です。
Spanプロセッサの役割は
Spanが発生した際にそのライフサイクルを観察し
それらのSpanをexporterに送ることです。
お察しの通り、それからSpan Exporterは
そのOpenTelemetry Spanの表示をあなたのバックエンド用の
適切なフォーマットに変換し、
それからバックエンドへ送ります。
それでは、Meter Pipelineについて少しお話ししましょう。
Meterの役割は

English: 
So, as I mentioned, the
purpose of these things APIs
is to enable writing instrumentation.
But in order to actually generate
telemetry from that instrumentation,
you're gonna need to have an SDK.
And that SDK is an
implementation of those APIs.
So, as you might expect,
the SDK can be roughly
broken into three parts:
the tracer SDK, the meter
SDK and the shared context.
So first let's talk
about the tracer pipeline
implemented with a tracer SDK.
The tracer SDK is configurable
with span processors and
the sampling strategy.
The span processor's responsibility
is to watch the lifecycle
of spans as they occur
and then deliver those
spans to an exporter.
Span exporter then as you might expect,
converts that OpenTelemetry
span representation
to an appropriate format for your backend
and then sends it to that backend.
Now let's talk a little bit
about the meter pipeline.
So the role of a meter

English: 
is to maintain a set of metric instruments
that you use for your instrumentation.
And I mentioned a few of those earlier,
counters and observers.
So each measurement made
with a metric instrument
is then aggregated if needed,
and then delivered to an exporter.
And then that exporter analogous to spans
will then convert that data
to structures that are native
to the telemetry backend.
And it's interesting to note
there are two styles of export
that are supported in OpenTelemetry.
One is push-based export,
where the exporter sends
data to the backend
on a timed interval,
and there's pull-based export
where the backend requests
from the OpenTelemetry system itself.
New Relic is an example
of a push-based export,
and Prometheus is a pull-based backend.
Finally let's talk a little bit about
this shared context idea.
The context implementation
lies between the tracer and the meter
and enables all non-observer
metric recordings
to take place in the context
of an executing span.

Japanese: 
あなたが計装で利用する
一連の計装を維持することです。
それらの一部は、先述したように
CountersとObserversです。
Metric計装で行われた各測定は
必要な場合に集積され、
それからExporterに伝搬されます。
それからSpanに類似するExporterが、
そのデータをテレメトリーバックエンドに対して
ネイティブなストラクチャに変換します。
また、OpenTelemetryは２種類のスタイルのエキスポートを
サポートしていることも興味深い点です。
１つはプッシュベースのエクスポートで、
Exporterが、適切なインターバルをおいて
データをバックエンドへ送ります。
またプルベースのエクスポートもあり、
バックエンドがOpenTelemetryシステムそのものから
リクエストします。
New Relicはプッシュベースのエクスポートの例で、
Prometheusはプルベースのバックエンドです。
最後に、Open Telemetry Collectorについて
少しお話しさせていただきます。
Contextの実装は
TracerとMeterの間で行われ、
全てのObserverがいないMetricの記録を
Spanを実行するContext内で行うことができます。

Japanese: 
これは非常に興味深い機能で、
それは最終的にSDKがMetricの値に対して
見本となるSpanを収集することを可能にします。
Contextは、Propagatorsを利用することでカスタム可能で、
Propagaterは、SpanのContextを
システムの内外に伝搬することを可能にします。
それは当然ながら真の分散トレーシングを可能にします。
最後に、OpenTelemetry Collectorについて
少しお話ししましょう。
Collectorは、様々なソースからの
MetricsとSpanを取り込める
独立型のサービスです。
それにはZipkin、Jaeger、OpenCensus、
そしてもちろんOpenTelemetryプロトコルそのものが含まれます。
Collectorは、それらSpanのテールベースの
サンプリングをするように設定できます。
それはまた、SpanやMetricsを多数のベンダーと
オープンソーステレメトリーシステムへの
エクスポートを可能にします。
もちろん、New Relicも含みます。
結論として、
OpenTelemetryアーキテクチャは
非常に柔軟かつ拡張的に設計されています。
あなたの全てのOpenTelemetryや全てのテレメトリーのニーズ
を満たすはずですが、
それは実装を非常に複雑にします。

English: 
As mentioned, this is a
really interesting feature,
that will enable, eventually enable SDKs
to capture exemplar
spans for metric values.
The context can be customized
with the use of propagators,
which enable propagating the span context
into and out of the system.
And that of course enables
true distributed tracing.
Finally, it's worth
talking a little bit about
the OpenTelemetry Collector.
The Collector is a standalone service
that can ingest metrics and spans
from a wide variety of sources,
including Zipkin Jaeger, OpenCensus,
and of course, the
OpenTelemetry protocol itself.
The collector can be configured
to do tail based sampling of those spans.
It also enables exporting
spans and metrics
to a large number of vendor
and open source telemetry systems.
Of course, that includes New Relic.
So in conclusion,
the OpenTelemetry architecture
is designed to be very
flexible and extensible.
It really should meet
all your OpenTelemetry,
all your telemetry needs,
but that does make the
implementation pretty complex.

Japanese: 
最も覚えておいて頂きたいのは、
２つのメインセクションに分割可能で、
それは計装の作成者に対して
設計およびターゲティングされたAPIと、
運用者とアプリケーション開発者のために
設計されたSDKです。
ご清聴ありがとうございました
OpenTelemetryやその他の
New Relicが関係するオープンソースプロジェクトについて
学ぶことにご興味があれば、
当社のオープンソースポータル
opensource.newrelic.comをご覧ください。
お時間ありがとうございました。

English: 
Most important takeaways,
it can be divided into two main sections,
the API, which is designed and targeted
to instrumentation authors,
and SDK, which is designed
for operators and application developers.
Thanks for listening today
and if you're interested in learning
more about OpenTelemetry or
the other open source projects
that New Relic is involved with,
please go to our open source portal
at opensource.newrelic.com.
Thanks for your time.
