A Practical Guide to SQL Extensions with Dynatrace

[@tusharranjans]

Thank you. Its helpful.

[@dannemca]

Finally!!! I was expecting something like this since I heard about the Custom Query DB decommission 😢. Great explanation. I was able to create my very first extension with this.

[@vduseev]

It makes me very happy to read this! Thank you!

[@VinsonTan]

It would be good if dynatrace documentation show example of this sample configuration as currently it does not provide any guidance on how to specify the sql statement etc.

[@grabnerandi]

Thats a great point. There is already some documentation about it in the section called "SQL data source reference" - have you seen this?

[@vduseev]

Thank you! We are working on it as we speak 😉

[@VinsonTan]

@@grabnerandi yes I did but it missing example on defining the SQL statement for metric capturing n log ingestion example. It only has the connectivity configuration guidance but not the actual SQL statement

[@vduseev]

Vinson, did this video help in any way? There is a small example of using a SQL query that will be parsed into a log ingestion

[@VinsonTan]

Yes I did watch the video. It is good example to show how to configurec it. Thanks

[@nacirarmando8003]

Greetings, what are the API Access Token Scopes to choose while configure our environment?

[@supportperformetriks]

Hi. It would be great if you can provide some example where other string units are used and some queries using user defined functions. Thanks in Advance

[@vduseev]

Hi! Stay tuned for this type of content. More examples and details are coming in separate videos soon!

[@jdar1992]

We need documentation for this. Also an ETA for the app would be great because working with queries right now like this is difficult. Everytime we need to add more queries we would need to modify the extension YAML and reupload.

[@grabnerandi]

Hi. As replied above - there is already documentation for the SQL Data Source. If you follow the SQL Data Sources link you find examples in the reference subsection

[@vduseev]

I feel you, sometimes having to recreate the extension every time the query changes can be cumbersome. Especially when it happens very very often. While you can fully migrate to this technology, it’s still not pure-UI solution. No ETA for the app yet, please look forward to announcements! Question for you: How often do you change the queries?

[@WilsonReisJr]

The documentation exists, but it is really too crude about this extension. I had to come and watch this video to understand this new extension, the documentation doesn't even have a good example. And I agree about the difficult regarding the queries change. This new type is good if we have to set up a monitoring template for databases to have it as a standard for many DBs, however as we worked previously on my side with the old Custom Queries Extension to grab custom Business Data directly using different custom queries for each database, with a custom interval for each query, this kind of solution is a pain as we have to create a new version of the extension whenever we have to change the query or add a new one. So as long as the Custom DB Queries extension runs we will probably be continuous using this.@@grabnerandi

[@m.luthfiassyafii6751]

Hi, is it possible to get value from table without timestamp & ingest to log ? i was try still failed

[@vduseev]

Yes, when you ingest a row from the result set as a log line, the timestamp will be generated for you automatically, when the log line is being ingested. We can specify a timestamp column to use when we want to control its value, but otherwise it's not necessary. We invite you to our Community Forums to ask for a more detailed explanation.

[@m.luthfiassyafii6751]

@@vduseev Thanks, already solved, earlier it was missed on DB user permissions.

[@sumaneshtripathy3987]

Which link is for certificate creation

[@ncunnin656]

Sql extension is the only way to monitor sql server databases?

[@vduseev]

Dynatrace can monitor sql server in at least three ways: remote extension that collects data through sql queries and connects to DB remotely, local extension that runs on the same host and collects data through WMI, and OneAgent running on the same server as DB and monitoring the process. Additionally, as shown in this video, you can write your own extensions for custom data collection.

[@ncunnin656]

@vduseev which one is the easiest? I don't want to have to write scripts. It says our local agent is depreciated.

[@vduseev]

​@@ncunnin656 1. Microsoft SQL Server extension - best benefits. Runs on ActiveGate. Works with almost every type of SQL Server. Connects to database using JDBC and runs SQL queries to collect metrics from database. Gets you the most amount of performance data. 2. OneAgent itself - easiest to set up. Just install OneAgent. Runs on the same host with the SQL Server. Gets you information about SQL Server process (CPU, Memory, etc.). 3. Microsoft SQL Server (Local) extension - least benefits. Runs on OneAgent. Gives you minimal performance monitoring data. Uses WMI to collect metrics. Works well for environments, where remote connection to DB is prohibited. 4. Custom extension - most flexibility but needs time investment. You can do almost anything you want, but you need to code it yourself or engage Dynatrace services to implement it for you. This is a really good option for monitoring business data in databases. P.S. The notice of deprecated agent you get is a warning that the previous version of the extension described in item 3 above is being deprecated. You can simply switch your monitoring to the modern version and that's it. P.P.S. This setup and rating changes every year! The info above is up to date as of Apri 17, 2024, but be sure to check for new announcements and communication from Dynatrace. I wouldn't be surprised if in a year or two, all DB monitoring options would be consolidated into a single option.