EF 2.0 Oracle Query Extension - Few Questions as I am Developing

[sivart_89]

The below is noted from https://www.dynatrace.com/support/help/shortlink/extension-yaml#dimensions. Has anyone been able to set the query name as a dimension for 2.0 extensions? The extension I am working on will be the replacement for the 1.0 custom db queries extension. We have several queries running on a db and the results returning to dynatrace. I would like to treat each query separately therefore have the query as the dimension. The doc noted below does not mention anything of the sqlOracle datasource.

You can define a dimension at the metric, group, and subgroup level. The details on how you extract dimension values vary depending on the data source type. See:

• SNMP
• WMI
• Prometheus

Something else, is there a way to specify that the extension use whatever the column name is, as the value rather than actually having to input the column name? Let's say the example below from my yaml only returns 1 column whose name is 'VALUE'. Do I really need to know the column name to put into the yaml? I would prefer for the extension to simply use whatever the query column name is rather than having to do something like value: col:VALUE

query:
SELECT
something from table
metrics:
- key: custom.database.queries.value
value: col:VALUE

Another question. Are the endpoints within each monitoring configuration specific to 1 database? Let's say I have queries hitting 5 different databases, do I need to have 5 monitoring configurations? If so how would that look in the yaml? I don't see a way of configuring in the UI which queries go to which endpoint. I'm trying to understand what this looks like if you have several queries that are all hitting different databases, how you would use 1 single extension for that.

[Mike_L]

Regarding the first and second question:
You can use const: instead of col: in the dimension value to set it to something unique which you can reference later. See documentation here: https://www.dynatrace.com/support/help/extend-dynatrace/extensions20/data-sources/sql/sql-reference#...

As for the last question:
The endpoints are indeed specific to one database. You can have more than one endpoint in one monitoring configuration though as long as they use the same yaml. If you need to execute different queries towards the different databases you'd have to create more than one extension yaml.

[sivart_89]

Thanks Mike for the information here.

In our situation we have maybe 10+ different databases we are hitting with queries, and that is just for right now. Based off your response we would need to have 10+ similar but yet different extensions. This is really unfortunate because the 1.0 extension does allow for the flexibility of using the 1 extension to run queries against multiple databases.

With 2.0 there is some improved functionality but in this sense it is a step backwards since we now have to manage several extensions.

[dglugla]

Hey @sivart_89 , think of the extension YAML in terms of "Monitoring as a code". You can describe what is being tracked, control version changes and access rights, and you have more flexibility in terms of keeping the entire configuration in one place (metrics, dashboard, alerting, ...).

We are aware that in some cases the previous solution was easier to adopt, and we'll do our best to make it simpler to create the new extensions. Though, we do not plan to allow for query specification directly via UI for security reasons.

[sivart_89]

@Mike_L I'm starting to develop the 2.0 extension for oracle db queries. As I am working through this I thought of trying out some things with feature sets, trying to see if we can reduce the amount of extensions we have to create to replace the existing 1.0 extension.

It seems we can have say 1 set of queries hitting 1 db while another set (different queries) is hitting another db, by using feature sets. The thought before was that we would need to create 2 extensions here but because the monitoring configuration is independent of each other and allows for using their own feature set, I've been able to assign one set of queries to a feature set, setup the configuration to use it while setting another configuration to use a different feature set. Do you see any issues with this approach? I understand that there is a limit of 10 configurations per extension so we would still have to create maybe a couple of extensions but using feature sets this way allows us to not have to create near as many.

[Mike_L · Accepted solution]

There are mainly usability challenges with that approach. Ergo, if someone who doesn't understand the bundling of databases starts setting up configurations and accidentally selects the incorrect feature sets the endpoints will start running into errors. It's a lot cleaner to do one extension per set of queries for a database.

The limit is 100 monitoring configurations by the way, where did you grab that screenshot? Then I'll ask for it to be updated.

Also, two days ago we released the first version of the updated documentation on the SQL data source. You can find it here: https://docs.dynatrace.com/docs/extend-dynatrace/extensions20/data-sources/sql/sql-reference

[sivart_89]

Link below for the screenshot. Good that it is higher than I had originally thought :). Thank you Mike for the reply here.

https://docs.dynatrace.com/docs/shortlink/extensions-concepts#monitoring-configuration