この記事は英語の原文を日本語に翻訳したものです。原文: https://opentelemetry.io/docs/specs/semconv/db/database-metrics/
翻訳元: open-telemetry/semantic-conventions v1.44.0(コミット e10a930)
データベースクライアントのメトリクスに関するセマンティック規約
ステータス: Mixed
[!IMPORTANT]
この文書のv1.24.0 以前のバージョンを使っている既存のデータベース計装は、次に従うべきです。
- 既存のメジャーバージョンにおいて、デフォルトで発行するデータベース規約のバージョンを変更してはなりません(SHOULD NOT)。 規約には、属性、メトリクス名、スパン名、計測単位などが含まれますが、これらに限定されません。
- 既存のメジャーバージョンにおいて、カテゴリー別の値をカンマ区切りで列挙するリストとして環境変数
OTEL_SEMCONV_STABILITY_OPT_INを導入すべきです(SHOULD) (例: http、databases、messaging)。値の一覧は次のとおりです。
database- 安定版のデータベース規約を発行し、それまで計装が発行していた実験的なデータベース規約の発行を停止します。database/dup- 実験的な規約と安定版の規約の両方を発行し、安定版セマンティック規約への段階的な移行を可能にします。- これらの値がいずれも指定されていない場合のデフォルトの動作は、その計装がそれまで発行していた実験的なデータベース規約のバージョンをそのまま発行し続けることです。
- 注記: 両方の値が指定されている場合、
database/dupはdatabaseよりも優先されます。- 両方の規約セットを発行し始めてから少なくとも6か月間は、既存のメジャーバージョンを(少なくともセキュリティパッチの適用という形で)維持すべきです(SHOULD)。
- 次のメジャーバージョンでは、この環境変数を削除し、安定版のデータベース規約のみを発行してもかまいません(MAY)。
Database operation
Metric: db.client.operation.duration
ステータス: Stable
このメトリクスは推奨されています。
このメトリクスがデータベース操作のスパンと合わせて報告される場合、メトリクスの値はそのデータベース操作のスパンの継続時間と同じにすべきです(SHOULD)。
このメトリクスは、ExplicitBucketBoundaries advisoryパラメータを [ 0.001, 0.005, 0.01, 0.05, 0.1, 0.5, 1, 5, 10 ] として指定すべきです(SHOULD)。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.operation.duration | Histogram | s | データベースクライアント操作の継続時間。 [1] |
[1]: バッチ操作は単一の操作として記録すべきです(SHOULD)。
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.system.name | Required | string | クライアント計装によって識別された、データベース管理システム(DBMS)製品。 [1] | other_sql; softwareag.adabas; actian.ingres | |
db.collection.name | Conditionally Required [2] | string | データベース内のコレクション(テーブル、コンテナ)の名前。 [3] | public.users; customers | |
db.namespace | Conditionally Required If available. | string | サーバーアドレスとポートの範囲内で完全修飾された、データベースの名前。 [4] | customers; test.users | |
db.operation.name | Conditionally Required [5] | string | 実行されている操作またはコマンドの名前。 [6] | findAndModify; HMSET; SELECT | |
db.response.status_code | Conditionally Required [7] | string | データベースの応答ステータスコード。 [8] | 102; ORA-17002; 08P01; 404 | |
error.type | Conditionally Required If and only if the operation failed. | string | 操作が終了した際のエラーのクラスを記述する。 [9] | timeout; java.net.UnknownHostException; server_certificate_invalid; 500 | |
server.port | Conditionally Required [10] | int | サーバーのポート番号。 [11] | 80; 8080; 443 | |
db.query.summary | Recommended [12] | string | データベースクエリの低カーディナリティな要約。 [13] | SELECT wuser_table; INSERT shipping_details SELECT orders; get user by id | |
db.stored_procedure.name | Recommended [14] | string | データベース内のストアドプロシージャの名前。 [15] | GetCustomer | |
network.peer.address | Recommended If applicable for this database system. | string | 操作が実行されたデータベースノードのピアアドレス。 [16] | 10.1.2.80; /tmp/my.sock | |
network.peer.port | Recommended If and only if network.peer.address is set. | int | ネットワーク接続のピアポート番号。 | 65123 | |
server.address | Recommended | string | データベースホストの名前。 [17] | example.com; 10.1.2.80; /tmp/my.sock | |
db.query.text | Opt-In | string | 実行されているデータベースクエリ。 [18] | SELECT * FROM wuser_table where username = ?; SET mykey ? |
[1] db.system.name: 実際のDBMSは、クライアントによって識別されたものと異なる場合があります。たとえば、PostgreSQLクライアントライブラリを使用してCockroachDBに接続する場合、計装が把握できる最善の情報に基づき、db.system.name は postgresql に設定されます。
[2] db.collection.name: すぐに利用可能であり、かつデータベース呼び出しが単一のコレクションに対して実行される場合。
[3] db.collection.name: 値は、大文字小文字の正規化を試みずに、アプリケーションから提供されたとおりに取得することが推奨されます(RECOMMENDED)。
データベースシステムが非バッチ操作において複数のコレクションを含むクエリテキストをサポートする場合、コレクション名は db.query.text から抽出してはなりません(SHOULD NOT)。
バッチ操作については、個々の操作が同じコレクション名を持つことがわかっている場合、そのコレクション名を使用すべきです(SHOULD)。
[4] db.namespace: データベースシステムが複数の名前空間コンポーネントを持つ場合、それらはコンポーネント間の区切り文字として | を使い、最も一般的なものから最も特定的なものへと連結すべきです(SHOULD)。欠落しているコンポーネント(およびそれに対応する区切り文字)は省略すべきです(SHOULD)。
個々のデータベースシステムに関するセマンティック規約は、そのシステムにおいて db.namespace が何を意味するかを文書化すべきです(SHOULD)。
値は、大文字小文字の正規化を試みずに、アプリケーションから提供されたとおりに取得することが推奨されます(RECOMMENDED)。
[5] db.operation.name: すぐに利用可能であり、かつデータベース呼び出しを記述する単一の操作名が存在する場合。
[6] db.operation.name: 値は、大文字小文字の正規化を試みずに、アプリケーションから提供されたとおりに取得することが推奨されます(RECOMMENDED)。
データベースシステムが非バッチ操作において複数の操作を含むクエリテキストをサポートする場合、操作名は db.query.text から抽出してはなりません(SHOULD NOT)。
操作名にスペースが含まれる可能性がある場合、連続する複数のスペースは単一のスペースに正規化すべきです(SHOULD)。
バッチ操作については、個々の操作が同じ操作名を持つことがわかっている場合、その操作名の前に BATCH を付けて使用すべきです(SHOULD)。そうでない場合、db.operation.name は BATCH、またはより適切であれば他のデータベースシステム固有の用語にすべきです(SHOULD)。
[7] db.response.status_code: 操作が失敗し、ステータスコードが利用可能な場合。
[8] db.response.status_code: データベースによって返されたステータスコード。通常はエラーコードを表しますが、部分的な成功、警告、または様々な種類の成功結果の区別を表すこともあります。
個々のデータベースシステムに関するセマンティック規約は、そのシステムにおいて db.response.status_code が何を意味するかを文書化すべきです(SHOULD)。
[9] error.type: error.type は、データベースまたはクライアントライブラリによって返された db.response.status_code、または発生した例外の正式名称と一致すべきです(SHOULD)。
正式な例外型名を使用する場合、計装は最も関連性の高い型を報告するよう最善を尽くすべきです(SHOULD)。たとえば、元の例外が汎用的な例外にラップされている場合、元の例外を優先すべきです(SHOULD)。
計装は、error.type がどのように設定されるかを文書化すべきです(SHOULD)。
[10] server.port: このDBMSのデフォルトポート以外のポートを使用しており、かつ server.address が設定されている場合。
[11] server.port: クライアント側から観測され、かつ中間者を介して通信している場合、server.port は、利用可能であれば、あらゆる中間者(たとえばプロキシ)の背後にあるサーバーポートを表すべきです(SHOULD)。
[12] db.query.summary: 計装フックを通じて利用可能な場合、または計装がクエリ要約の生成をサポートしている場合。
[13] db.query.summary: クエリ要約は、データベースクエリのクラスを記述するものであり、特に複雑なクエリを含むデータベース呼び出しのテレメトリーを分析する際に、グルーピングキーとして有用です。
要約は、計装フックその他の手段によって計装から利用可能な場合があります。利用可能でない場合、クエリ解析をサポートする計装は、クエリ要約の生成の節に従って要約を生成すべきです(SHOULD)。
バッチ操作については、個々の操作が同じクエリ要約を持つことがわかっている場合、そのクエリ要約の前に BATCH を付けて使用すべきです(SHOULD)。そうでない場合、db.query.summary は BATCH、またはより適切であれば他のデータベースシステム固有の用語にすべきです(SHOULD)。
[14] db.stored_procedure.name: 操作が特定のストアドプロシージャに適用される場合。
[15] db.stored_procedure.name: 値は、大文字小文字の正規化を試みずに、アプリケーションから提供されたとおりに取得することが推奨されます(RECOMMENDED)。
バッチ操作については、個々の操作が同じストアドプロシージャ名を持つことがわかっている場合、そのストアドプロシージャ名を使用すべきです(SHOULD)。
[16] network.peer.address: 個々のデータベースシステムに関するセマンティック規約は、network.peer.* 属性が適用可能かどうかを文書化すべきです(SHOULD)。ネットワークピアのアドレスとポートは、アプリケーションが個々のデータベースノードと直接やり取りする場合に有用です。
データベース操作が複数のネットワーク呼び出し(たとえばリトライ)を伴う場合、最後に接続したノードのアドレスを使用すべきです(SHOULD)。
[17] server.address: クライアント側から観測され、かつ中間者を介して通信している場合、server.address は、利用可能であれば、あらゆる中間者の背後にあるサーバーアドレスを表すべきです(SHOULD)。
[18] db.query.text: サニタイズについてはdb.query.text のサニタイズを参照してください。
バッチ操作については、個々の操作が同じクエリテキストを持つことがわかっている場合、そのクエリテキストを使用すべきです(SHOULD)。そうでない場合、個々のクエリテキストはすべて、セパレーター ; 、またはより適切であれば他のデータベースシステム固有のセパレーターで連結すべきです(SHOULD)。
パラメータ化クエリテキストはサニタイズすべきではありません(SHOULD NOT)。パラメータ化クエリテキストには機密データが含まれる可能性がありますが、パラメータ化クエリを使用することで、ユーザーは機密データがパラメータ値として渡されるという強い意図を示していることになり、デフォルトでクエリテキストの静的な部分を取得することによるオブザーバビリティ上の利点が、そのリスクを上回ります。
db.system.name には、以下の既知の値の一覧があります。これらのいずれかが該当する場合、対応する値を使用しなければなりません(MUST)。それ以外の場合は、独自の値を使用してもかまいません(MAY)。
| Value | Description | Stability |
|---|---|---|
actian.ingres | Actian Ingres | |
aws.dynamodb | Amazon DynamoDB | |
aws.redshift | Amazon Redshift | |
azure.cosmosdb | Azure Cosmos DB | |
cassandra | Apache Cassandra | |
clickhouse | ClickHouse | |
cockroachdb | CockroachDB | |
couchbase | Couchbase | |
couchdb | Apache CouchDB | |
derby | Apache Derby | |
elasticsearch | Elasticsearch | |
firebirdsql | Firebird | |
gcp.spanner | Google Cloud Spanner | |
geode | Apache Geode | |
h2database | H2 Database | |
hbase | Apache HBase | |
hive | Apache Hive | |
hsqldb | HyperSQL Database | |
ibm.db2 | IBM Db2 | |
ibm.informix | IBM Informix | |
ibm.netezza | IBM Netezza | |
influxdb | InfluxDB | |
instantdb | Instant | |
intersystems.cache | InterSystems Caché | |
mariadb | MariaDB | |
memcached | Memcached | |
microsoft.sql_server | Microsoft SQL Server | |
mongodb | MongoDB | |
mysql | MySQL | |
neo4j | Neo4j | |
opensearch | OpenSearch | |
oracle.db | Oracle Database | |
other_sql | その他のSQLデータベース。フォールバックとしてのみ使用する。 | |
postgresql | PostgreSQL | |
redis | Redis | |
sap.hana | SAP HANA | |
sap.maxdb | SAP MaxDB | |
softwareag.adabas | Adabas (Adaptable Database System) | |
sqlite | SQLite | |
teradata | Teradata | |
trino | Trino |
error.type には、以下の既知の値の一覧があります。これらのいずれかが該当する場合、対応する値を使用しなければなりません(MUST)。それ以外の場合は、独自の値を使用してもかまいません(MAY)。
| Value | Description | Stability |
|---|---|---|
_OTHER | 計装が独自の値を定義していない場合に使用するフォールバックのエラー値。 |
Development
ステータス: Development
Database response
以下のメトリクスinstrumentは、データベースクエリの応答を記述します。
Metric: db.client.response.returned_rows
このメトリクスは推奨されています。
このメトリクスは、ExplicitBucketBoundaries advisoryパラメータを [1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 2000, 5000, 10000] として指定すべきです(SHOULD)。
バケット構成の説明:
- 1, 2, 5, 10, 50, 100: これらのバケットは、少数の項目だけが返されるシナリオを捉えるのに有用です。このような小さなクエリは、パフォーマンスと素早い応答が重要なリアルタイムまたはインタラクティブなアプリケーションでよく見られます。
- 200, 500, 1000: これらの値は、各クエリで中程度の量のデータが返される典型的なワークロードを表します。
- 2000, 5000: これらの境界は、クエリが大きなデータセットを返すシナリオを捉えます。このように大きなページサイズは、メモリやCPUの使用量を増加させ、クエリの実行時間を長くする可能性があるため、こうした範囲でのパフォーマンスを追跡することが重要になります。
- 10000: この境界は、稀に発生する非常に大きな応答サイズを捉えるために含まれています。このようなクエリは、メモリ、CPU、ネットワーク帯域幅などのシステムリソースに大きな負荷をかける可能性があり、高いレイテンシーやネットワークの切断といったパフォーマンス上の問題につながることがよくあります。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.response.returned_rows | Histogram | {row} | データベース操作によって実際に返されたレコード数。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.system.name | Required | string | クライアント計装によって識別された、データベース管理システム(DBMS)製品。 [1] | other_sql; softwareag.adabas; actian.ingres | |
db.collection.name | Conditionally Required [2] | string | データベース内のコレクション(テーブル、コンテナ)の名前。 [3] | public.users; customers | |
db.namespace | Conditionally Required If available. | string | サーバーアドレスとポートの範囲内で完全修飾された、データベースの名前。 [4] | customers; test.users | |
db.operation.name | Conditionally Required [5] | string | 実行されている操作またはコマンドの名前。 [6] | findAndModify; HMSET; SELECT | |
db.response.status_code | Conditionally Required [7] | string | データベースの応答ステータスコード。 [8] | 102; ORA-17002; 08P01; 404 | |
error.type | Conditionally Required If and only if the operation failed. | string | 操作が終了した際のエラーのクラスを記述する。 [9] | timeout; java.net.UnknownHostException; server_certificate_invalid; 500 | |
server.port | Conditionally Required [10] | int | サーバーのポート番号。 [11] | 80; 8080; 443 | |
db.query.summary | Recommended [12] | string | データベースクエリの低カーディナリティな要約。 [13] | SELECT wuser_table; INSERT shipping_details SELECT orders; get user by id | |
network.peer.address | Recommended If applicable for this database system. | string | 操作が実行されたデータベースノードのピアアドレス。 [14] | 10.1.2.80; /tmp/my.sock | |
network.peer.port | Recommended If and only if network.peer.address is set. | int | ネットワーク接続のピアポート番号。 | 65123 | |
server.address | Recommended | string | データベースホストの名前。 [15] | example.com; 10.1.2.80; /tmp/my.sock | |
db.query.text | Opt-In | string | 実行されているデータベースクエリ。 [16] | SELECT * FROM wuser_table where username = ?; SET mykey ? |
[1] db.system.name: 実際のDBMSは、クライアントによって識別されたものと異なる場合があります。たとえば、PostgreSQLクライアントライブラリを使用してCockroachDBに接続する場合、計装が把握できる最善の情報に基づき、db.system.name は postgresql に設定されます。
[2] db.collection.name: すぐに利用可能であり、かつデータベース呼び出しが単一のコレクションに対して実行される場合。
[3] db.collection.name: 値は、大文字小文字の正規化を試みずに、アプリケーションから提供されたとおりに取得することが推奨されます(RECOMMENDED)。
データベースシステムが非バッチ操作において複数のコレクションを含むクエリテキストをサポートする場合、コレクション名は db.query.text から抽出してはなりません(SHOULD NOT)。
バッチ操作については、個々の操作が同じコレクション名を持つことがわかっている場合、そのコレクション名を使用すべきです(SHOULD)。
[4] db.namespace: データベースシステムが複数の名前空間コンポーネントを持つ場合、それらはコンポーネント間の区切り文字として | を使い、最も一般的なものから最も特定的なものへと連結すべきです(SHOULD)。欠落しているコンポーネント(およびそれに対応する区切り文字)は省略すべきです(SHOULD)。
個々のデータベースシステムに関するセマンティック規約は、そのシステムにおいて db.namespace が何を意味するかを文書化すべきです(SHOULD)。
値は、大文字小文字の正規化を試みずに、アプリケーションから提供されたとおりに取得することが推奨されます(RECOMMENDED)。
[5] db.operation.name: すぐに利用可能であり、かつデータベース呼び出しを記述する単一の操作名が存在する場合。
[6] db.operation.name: 値は、大文字小文字の正規化を試みずに、アプリケーションから提供されたとおりに取得することが推奨されます(RECOMMENDED)。
データベースシステムが非バッチ操作において複数の操作を含むクエリテキストをサポートする場合、操作名は db.query.text から抽出してはなりません(SHOULD NOT)。
操作名にスペースが含まれる可能性がある場合、連続する複数のスペースは単一のスペースに正規化すべきです(SHOULD)。
バッチ操作については、個々の操作が同じ操作名を持つことがわかっている場合、その操作名の前に BATCH を付けて使用すべきです(SHOULD)。そうでない場合、db.operation.name は BATCH、またはより適切であれば他のデータベースシステム固有の用語にすべきです(SHOULD)。
[7] db.response.status_code: 操作が失敗し、ステータスコードが利用可能な場合。
[8] db.response.status_code: データベースによって返されたステータスコード。通常はエラーコードを表しますが、部分的な成功、警告、または様々な種類の成功結果の区別を表すこともあります。
個々のデータベースシステムに関するセマンティック規約は、そのシステムにおいて db.response.status_code が何を意味するかを文書化すべきです(SHOULD)。
[9] error.type: error.type は、データベースまたはクライアントライブラリによって返された db.response.status_code、または発生した例外の正式名称と一致すべきです(SHOULD)。
正式な例外型名を使用する場合、計装は最も関連性の高い型を報告するよう最善を尽くすべきです(SHOULD)。たとえば、元の例外が汎用的な例外にラップされている場合、元の例外を優先すべきです(SHOULD)。
計装は、error.type がどのように設定されるかを文書化すべきです(SHOULD)。
[10] server.port: このDBMSのデフォルトポート以外のポートを使用しており、かつ server.address が設定されている場合。
[11] server.port: クライアント側から観測され、かつ中間者を介して通信している場合、server.port は、利用可能であれば、あらゆる中間者(たとえばプロキシ)の背後にあるサーバーポートを表すべきです(SHOULD)。
[12] db.query.summary: 計装フックを通じて利用可能な場合、または計装がクエリ要約の生成をサポートしている場合。
[13] db.query.summary: クエリ要約は、データベースクエリのクラスを記述するものであり、特に複雑なクエリを含むデータベース呼び出しのテレメトリーを分析する際に、グルーピングキーとして有用です。
要約は、計装フックその他の手段によって計装から利用可能な場合があります。利用可能でない場合、クエリ解析をサポートする計装は、クエリ要約の生成の節に従って要約を生成すべきです(SHOULD)。
バッチ操作については、個々の操作が同じクエリ要約を持つことがわかっている場合、そのクエリ要約の前に BATCH を付けて使用すべきです(SHOULD)。そうでない場合、db.query.summary は BATCH、またはより適切であれば他のデータベースシステム固有の用語にすべきです(SHOULD)。
[14] network.peer.address: 個々のデータベースシステムに関するセマンティック規約は、network.peer.* 属性が適用可能かどうかを文書化すべきです(SHOULD)。ネットワークピアのアドレスとポートは、アプリケーションが個々のデータベースノードと直接やり取りする場合に有用です。
データベース操作が複数のネットワーク呼び出し(たとえばリトライ)を伴う場合、最後に接続したノードのアドレスを使用すべきです(SHOULD)。
[15] server.address: クライアント側から観測され、かつ中間者を介して通信している場合、server.address は、利用可能であれば、あらゆる中間者の背後にあるサーバーアドレスを表すべきです(SHOULD)。
[16] db.query.text: サニタイズについてはdb.query.text のサニタイズを参照してください。
バッチ操作については、個々の操作が同じクエリテキストを持つことがわかっている場合、そのクエリテキストを使用すべきです(SHOULD)。そうでない場合、個々のクエリテキストはすべて、セパレーター ; 、またはより適切であれば他のデータベースシステム固有のセパレーターで連結すべきです(SHOULD)。
パラメータ化クエリテキストはサニタイズすべきではありません(SHOULD NOT)。パラメータ化クエリテキストには機密データが含まれる可能性がありますが、パラメータ化クエリを使用することで、ユーザーは機密データがパラメータ値として渡されるという強い意図を示していることになり、デフォルトでクエリテキストの静的な部分を取得することによるオブザーバビリティ上の利点が、そのリスクを上回ります。
db.system.name には、以下の既知の値の一覧があります。これらのいずれかが該当する場合、対応する値を使用しなければなりません(MUST)。それ以外の場合は、独自の値を使用してもかまいません(MAY)。
| Value | Description | Stability |
|---|---|---|
actian.ingres | Actian Ingres | |
aws.dynamodb | Amazon DynamoDB | |
aws.redshift | Amazon Redshift | |
azure.cosmosdb | Azure Cosmos DB | |
cassandra | Apache Cassandra | |
clickhouse | ClickHouse | |
cockroachdb | CockroachDB | |
couchbase | Couchbase | |
couchdb | Apache CouchDB | |
derby | Apache Derby | |
elasticsearch | Elasticsearch | |
firebirdsql | Firebird | |
gcp.spanner | Google Cloud Spanner | |
geode | Apache Geode | |
h2database | H2 Database | |
hbase | Apache HBase | |
hive | Apache Hive | |
hsqldb | HyperSQL Database | |
ibm.db2 | IBM Db2 | |
ibm.informix | IBM Informix | |
ibm.netezza | IBM Netezza | |
influxdb | InfluxDB | |
instantdb | Instant | |
intersystems.cache | InterSystems Caché | |
mariadb | MariaDB | |
memcached | Memcached | |
microsoft.sql_server | Microsoft SQL Server | |
mongodb | MongoDB | |
mysql | MySQL | |
neo4j | Neo4j | |
opensearch | OpenSearch | |
oracle.db | Oracle Database | |
other_sql | その他のSQLデータベース。フォールバックとしてのみ使用する。 | |
postgresql | PostgreSQL | |
redis | Redis | |
sap.hana | SAP HANA | |
sap.maxdb | SAP MaxDB | |
softwareag.adabas | Adabas (Adaptable Database System) | |
sqlite | SQLite | |
teradata | Teradata | |
trino | Trino |
error.type には、以下の既知の値の一覧があります。これらのいずれかが該当する場合、対応する値を使用しなければなりません(MUST)。それ以外の場合は、独自の値を使用してもかまいません(MAY)。
| Value | Description | Stability |
|---|---|---|
_OTHER | 計装が独自の値を定義していない場合に使用するフォールバックのエラー値。 |
Connection pools
以下のメトリクスinstrumentは、データベースクライアントのコネクションプールの操作を記述します。
Metric: db.client.connection.count
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.count | UpDownCounter | {connection} | state 属性によって記述された状態にある、現在の接続数。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource | |
db.client.connection.state | Required | string | プール内の接続の状態 | idle |
db.client.connection.state には、以下の既知の値の一覧があります。これらのいずれかが該当する場合、対応する値を使用しなければなりません(MUST)。それ以外の場合は、独自の値を使用してもかまいません(MAY)。
| Value | Description | Stability |
|---|---|---|
idle | idle | |
used | used |
Metric: db.client.connection.idle.max
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.idle.max | UpDownCounter | {connection} | 許可されているアイドル状態の接続の最大数。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource |
Metric: db.client.connection.idle.min
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.idle.min | UpDownCounter | {connection} | 許可されているアイドル状態の接続の最小数。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource |
Metric: db.client.connection.max
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.max | UpDownCounter | {connection} | 許可されている接続の最大数。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource |
Metric: db.client.connection.pending_requests
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.pending_requests | UpDownCounter | {request} | 接続が開くのを待っている、現在の保留中のリクエストの数。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource |
Metric: db.client.connection.timeouts
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.timeouts | Counter | {timeout} | プールから接続を取得しようとして発生した接続タイムアウトの数。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource |
Metric: db.client.connection.create_time
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.create_time | Histogram | s | 新しい接続の作成に要した時間。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource |
Metric: db.client.connection.wait_time
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.wait_time | Histogram | s | プールから開いている接続を取得するのに要した時間。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource |
Metric: db.client.connection.use_time
このメトリクスは推奨されています。
| Name | Instrument Type | Unit (UCUM) | Description | Stability | Entity Associations |
|---|---|---|---|---|---|
db.client.connection.use_time | Histogram | s | 接続を借用してからプールに返却するまでの時間。 |
Attributes:
| Key | Stability | Requirement Level | Value Type | Description | Example Values |
|---|---|---|---|---|---|
db.client.connection.pool.name | Required | string | コネクションプールの名前。計装されたアプリケーション内で一意である。コネクションプールの実装が名前を提供しない場合、計装は名前を一意にするパラメータの組み合わせを使用すべきである。たとえば、属性 server.address、server.port、db.namespace を組み合わせ、server.address:server.port/db.namespace の形式にする。異なるパターンに従ってコネクションプール名を生成する計装は、それを文書化すべきである。 | myDataSource |