> Source: https://www.ymotongpoo.com/works/oteps/metrics/otep-0090/


# OTEP-0090: メトリクスAPIからLabelSetオブジェクトを削除する

この提案は、現在の[`LabelSet`](./0049-metric-label-set.md) APIを削除し、LabelSetを受け取っていたすべての現行APIを、ラベル（キーと値のリスト、あるいは言語の機能に応じたキーと値のマップ）を直接受け取るように変更するものです。

## 動機 {#motivation}

[`LabelSet`](./0049-metric-label-set.md) API型は、メトリクスAPIのために事前定義されたラベルの集合に対するハンドルとして機能するために追加されました。

このAPIは現在のメトリクスAPIに対する最適化を表しており、実装が同じラベルの集合に対して何度もラベル制限のエンコードとチェックを行うのを避けられるようにするものです。
メトリクスAPIの利用や実装からは、LabelSetがほとんど利益をもたらさないまま余計な複雑さを追加していることが示されています。

一部のユーザーは、よりクリーンなコードのためにこのパフォーマンス最適化を避けることを好みますし、OpenTelemetryはそうしたユーザーにも対応する必要があります。
つまり、OpenTelemetryにとって、ユーザーがラベルを直接渡せるレコードAPIをサポートすることが重要だということです。

OpenTelemetryは、この最適化が非常に重要だと判断すれば、（後方互換性のある変更として）後からいつでも追加できます。

## トレードオフと緩和策 {#trade-offs-and-mitigations}

パフォーマンスが重要になる場合、ほぼ同等のパフォーマンスを達成する方法は次のとおりです。

- 現在のAPIでは、`LabelSet` が異なる複数のインストルメントにまたがって（各インストルメントに対して1回ずつ）再利用される場合、ユーザーはバッチ記録の仕組みを使うことができ、内部的にはSDKがラベルのエンコードを1回で済ませることができます。
- 現在のAPIでは、`LabelSet` が同じインストルメントへの記録に複数回使われる場合、ユーザーはインストルメントバインディングを使うことができます。
- 現在のAPIでは、`LabelSet` が複数のバッチ記録にまたがって使われ、このパターンが非常に重要になった場合、OpenTelemetryはバッチがバインディングを受け付けられるようにサポートを追加できます。

現在のバッチ記録が、どの計測を記録するかを制御するローカルな条件がある場合のシナリオでも役立つようにするために、`newBatchRecorder` は `BatchRecorder` と呼ばれるインターフェースを返すことを推奨します。
このインターフェースは `measurement` を追加するために使われ、すべてのエントリーが追加された後に `record` を呼び出すことで、すべての `measurements` を記録できます。

## 先行技術と代替技術 {#prior-art-and-alternatives}

既存のメトリクスライブラリのほぼすべてが、値を記録する際にLabelSetのようなものをユーザーが作成することを要求していません。