Project Proposal: Database server-side semantic conventions

[niuxiaojuan-github]

Description

Create experimental semantic conventions for database server metrics. The DB Metric page only contains database client metric instruments, currently there are no database server metric instruments, there is a need to fill the gap.

Currently, there are following DB receivers in the collector contrib repo.

• Microsoft SQL Server Receiver
• MySQL Receiver
• PostgreSQL Receiver
• Oracle DB Receiver
• CouchDB Receiver
• MongoDB Atlas Receiver
• MongoDB Receiver
• Elasticsearch Receiver
• InfluxDB Receiver
• Aerospike Receiver
• Redis Receiver
• Riak Receiver
• SAP HANA Receiver
• SQL Query Receiver, this one uses customized query to get metrics, it's not specific to a certain type of database.

Deliverables

• Deliver experimental database resource attributes
• Deliver experimental database server metric instruments

Staffing / Help Wanted

The goal is to follow @tedsuo's proposed Semantic Convention Process.

Question: This process is for stabilizing convention, is there a process for starting experimental convention project?

• Stage 1: Working Group Preparation
• Stage 2: Specification
• Stage 3: Implementation

Required staffing for Stage 1 and 2

• @niuxiaojuan-github project lead
• @estolfo domain expert
• @dakrone domain expert
• Need: Technical committee sponsors
• Need: The domain experts from different types of databases.
• Need: Engineers willing to write prototypes in at least two languages (if relevant to project). Languages should be fairly different from each other (for example: Python).
• Need: Maintainers or approvers from those languages committed to reviewing the prototypes.

Question: Are prototypes required for an experimental project, or is it only required for stabilizing?

Required staffing for Stage 3

Question: Do we need Stage 3 for experimental convention project? My expectation is to release the experimental database server resource attributes and metric instruments without implementation, is that an acceptable goal?

Meeting Times

Once a project is started, the working group should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar.

Timeline

Stage 1: Discuss the type of databases that we would mainly focus on and recruit domain experts. We may need 2 weeks for this stage considering the heterogeneous nature of database technology.

Stage 2: estimate 2 months

• Discuss what are the common database attributes, submit semconv PR.
• Discuss what are the common database metric instruments, submit semconv PR.

Labels

The tracking issue should be properly labeled to indicate what parts of the specification it is focused on.

Linked Issues and PRs

All PRs, Issues, and OTEPs related to the project should link back to the tracking issue, so that they can be easily found.

Proposed database semantic convention for discussion:

• Database metrics - adding conventions for database server metrics semantic-conventions#299

Relevant issues:

• Add database resource specification opentelemetry-specification#2916
• db.name should be broken down into individual layers semantic-conventions#714

Project Board

Once approved by TC, a project should be managed using a GitHub project board. This project board should be pre-populated with issues that cover all known deliverables, organized by timeline milestones.

A Technical Committee (TC) member associated with the project can create the board, along with a new project-specific GitHub label to automatically associate issues and PRs with the project. The project lead and all other relevant project members should have edit access to the board.

Once created, please link to the project board here.

[niuxiaojuan-github]

Got the answer in Sep 18 meeting

Question: This process is for stabilizing convention, is there a process for starting experimental convention project?
A: It should be sth. similar, we can follow the same process.

Question: Are prototypes required for an experimental project, or is it only required for stabilizing?
A: Existing receivers are considered prototypes.

Question: Do we need Stage 3 for experimental convention project? My expectation is to release the experimental database server resource attributes and metric instruments without implementation, is that an acceptable goal?
A: Stage 3 would be updating existing receivers to use experimental conventions.