[SQL receivers] Remove duplicate SQL functionality #13546
Comments
evan-bradley
added
enhancement
|
Pinging code owners: @dmitryax @pmcollins. See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
This issue has been closed as inactive because it has been stale for 120 days with no activity. |
…30709) **Description:** As noted in the related issues, a lot of the logic in the sqlquery receiver can be moved to a central package to be used by other receivers. I realize this appears to be a large change, but it's purely a re-organization PR, there's no functional changes. GitHub is not recognizing moved files, so please refer to new file names and their deleted counterparts. A lot of members are now public in the internal package that were private in the receiver which is likely what's causing GitHub to miss that they're just moved files. This doesn't require a changelog (in my mind) because all things moving were originally private to the receiver. They're now still purely internal, so they won't be published. I believe `internal` is the best destination for now as it allows us to solidify the usage and interface before moving it to `pkg` to be publicly available. There are still a lot of unknowns as far as how it can be used by other receivers, so I fully expect "breaking changes" to this. If we keep it internal we can update all usages with the changing interface, so the changes won't be breaking. **Link to tracking Issue:** #30297, #13546
|
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
This issue has been closed as inactive because it has been stale for 120 days with no activity. |
Is your feature request related to a problem? Please describe.
We are starting to run into having logic duplicated in a few places with SQL receivers. The receivers in question are:
All three of these receivers are used to create database connections, and then use queries to return data in the form of metrics.
Describe the solution you'd like
The sqlqueryreceiver is the generic form of this functionality, and can be used to connect to any supported database technology. The only pre-requisite is to be able to import the proper driver, which will be a requirement no matter what since drivers are required to establish a database connection from the collector.
Since the
sqlqueryreceiver can be used as the standard connector to databases without the explicit need for each database technology to have its own receiver, I believe we should use it as the main receiver for sql query metrics.Describe alternatives you've considered
The alternative is to create new receivers for each database technology. This can help user experience so that users can find what they're looking for faster ("I want to query mysql for metrics, I need the mysql receiver"), but in the end results in lots of duplicated code and logic. Duplicated code and logic means any development changes will take longer, and will be harder to maintain. If we document functionality properly, we shouldn't have to worry as much about things being hard to find.
The text was updated successfully, but these errors were encountered: