Feature Request: Configure custom metrics with prometheus.exporter.oracledb component
Request
The exporter that the prometheus.exporter.oracledb component is based on allows you to configure custom metrics: https://github.com/iamseth/oracledb_exporter/tree/master#custom-metrics
We would like to be able to also configure custom metrics with the prometheus.exporter.oracledb component.
Use case
Creating custom metrics based on SQL queries would greatly increase the utility of the component. We currently run custom SQL queries through a Splunk plugin to create custom metrics from our Oracle databases. We would like to produce the custom metrics from the Grafana agent instead so that we can utilize the grafana ecosystem to better setup observability on our Oracle databases.
@StefanKurek @schmikei what do you folks think about this feature request?
@StefanKurek @schmikei what do you folks think about this feature request?
Ah sorry for the delay, was on vacation for a while so now just seeing this.
Seems like a doable thing and somewhat easy to enable from the Grafana Agent side. The way that custom metrics work with the exporter is a TOML file that we decode (example) which I believe enabling would be trivial from within the Grafana Agent.
It does seem like an inherent risk to arbitrarily execute SQL code based off a TOML file, makes me wonder if there is a security vulnerability there or a feature gate system we should employ to make sure that its at least a little bit safer.
Happy to create, review and/or collaborate on a PR when I have a free moment!
Hey @wwalters12 we had a small talk internally about the safety concern and was wondering if potentially using the Oracle Data Source is applicable here?
Generally I've been notified that the sentiment is that
An exporter will fetch operational details about the system under observation (SUO), allowing it to be efficiently operated and provide troubleshooting data.
whereas
A data source promotes the "big tent" philosophy of using the data where it lies to provide insights. Such as querying a DB for application specific data.
If there are more non-application specific metrics you'd like we can try to grab them in a future feature request but we think the pragmatic approach is for you to use a datasource for custom metrics.
So I was wondering if you'd be willing to give that a shot and still think this feature is needed given it might be a no-go given the high security risk associated with the arbitrary execution?
Again this is just one of our perspectives, if other people want to chime in on this feel free to! Just wanted to provide an update on this issue :)
Is this issue actually Open ATM?