cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Custom Database Queries going to EF 2.0?

sivart_89
Mentor

Does anyone know if this 1.0 extension will be migrated to 2.0? Link to extension below. We've noticed that issues related to a table not existing, does not create a problem in Dynatrace but is logged on the AG side. We were going to setup some log monitoring and alerts to notify us of when the query is bad but if this extension will be migrated to EF 2.0 then maybe that can be included in it? I've seen that the existing 1.0 extensions will not be updated.

Custom Database Queries | Dynatrace Hub

 

11 REPLIES 11

Mike_L
Dynatrace Guru
Dynatrace Guru

There is no plan to migrate this extension to extension framework 2.0. Instead the plan is that customers use the declarative database datasource to write yaml files for doing the monitoring.

Mike

Thank you Mike for the information here.

Hello @Mike_L  could you please attach a link to doc about this? I would like to read about it. Thks.

The true delight is in the finding out rather than in the knowing.

Sure, here you go. There are actually even more databases supported than listed there, such as DB2 and PostgreSQL: https://www.dynatrace.com/support/help/extend-dynatrace/extensions20/data-sources/sql

Mike

@DanielS Basically, it is about writing your own extension. The docs are here:
https://www.dynatrace.com/support/help/extend-dynatrace/extensions20/extensions-concepts

I highly recommend using the Visual Studio Code plugin - Dynatrace VSCode Extension add-on for creating and building extensions:
https://marketplace.visualstudio.com/items?itemName=DynatracePlatformExtensions.dynatrace-extensions

There is a very good tutorial for the plugin at https://github.com/dynatrace-extensions/dynatrace-extensions-vscode which will guide you through the process of writing your own extensions and how to use the plugin.

If you are interested in custom SQL queries in particular, I recommend downloading some of the existing extensions such as Postgres or Oracle (a more complex one) and having a look at the yaml file how data is obtained.

Certified Dynatrace Master | Alanata a.s., Slovakia, Dynatrace Master Partner

Thanks @Mike_L @Julius_Loman I guess that I need to start with extensions. Thanks again.

The true delight is in the finding out rather than in the knowing.

Hello Julius, How/from where can i download this yaml file?? 

If you go to the hub, you can grab any extension from the "release notes" tab. For example: https://www.dynatrace.com/hub/detail/postgresdb-remote-monitoring/?query=postgresql&filter=all#relea...

Mike

ct_27
DynaMight Pro
DynaMight Pro

Thank you for the information but is this really Dynatrace's general direction?  That we have to have developers on staff to keep building these extensions?  We bought Dynatrace to simplify our monitoring solutions through a configuration UI, which it had and it was doing.  We wanted to leave the world of developing or writing code to monitor entities.

 

For a long time we were asking for a solution like what Custom Database Queries provides. It started off slow but over the 1 year it improved to be something valuable.  My DBAs finally had a UI where they could configure a query for monitoring, gather metrics, and build alerts all on their own; they were thrilled as was I because they could self-serve and got direct benefit out of Dynatrace. They're actually just about to load over 50 checks into it as part of PoC 2.0 because PoC 1.0 was a success with this extension. Sure it still had room for improvement. Now it sounds like a little over a year later it's heading to end-of-life with Extension 1.0.

 

The new Dynatrace approach requires clients to have a developer resource on staff to use the tool vs using out-of-box Dynatrace modules that require just some UI configuration.   This is not a model smaller clients can sustain.  We have very small staff to support monitoring.

HigherEd

I fully understand your concerns. The move reminds me of another monitoring tool I used to work with a decade ago where it was a huge effort (4h minimum) to get value from a script/database/jmx and each change required a similar effort.

With the Extensions 2.0 it's not that complicated and when you actually set up the environment and get familiar with the concepts and limitations, you can do that very easily. Unfortunately, the learning curve is still somehow steep, but the VScode extensions lowered that pretty significantly to bare minimum.

It's really not developing in the sense of writing your code, but more or less writing a YAML file exactly as Mike mentions. You really don't need a developer to write it.

I think there should be a quick tutorial on how to write a simple DB extension to do a query to DB from scratch and how to deploy and maintain it.

Certified Dynatrace Master | Alanata a.s., Slovakia, Dynatrace Master Partner

We get your point @ct_27 and we are aware of the limitations that the new Extension Framework brings.

But at the same time it brings a lot of additional value, either not possible before, or not that convenient to use. We improved activation of the extensions, making it possible to chose an AG group, host groups or management zones. We introduced a custom entity model to shape the topology just as you need. The custom queries are no longer as restricted and can gather multiple metrics at once, where you can specify their processing rules. Finally the security aspects got improved as well, which was mandatory to meet enterprise standards of our customers. For that, we needed to separate the personas and their use cases: extension developer and admin. That's also why we do not plan to allow for queries customization during the extension's activation process.

Unfortunately that complicated the basic use cases, like the simple business data extraction. With the VSCode add-on we're making our best to simplify the extension creation process, and we're open for suggestions to make it even more convenient. That allows us to offer a unified approach to extending Dynatrace capabilities in terms of data collection and processing.

Please review your custom DB queries and you'll probably find some areas to improve, where the new Extension Framework capabilities can be leveraged. E.g.optimizing queries' performance by combining some of them into one. Or think of a data structure that you collect - maybe you'll find a candidate to use custom topology. Or the ability to track the changes in extension's configuration... I believe there are plenty of examples where the new framework comes in handy; just give it a chance. And whenever you find an area to improve - please let us know and we'll work together to make it possible.

Empower Enterprise Apps and Services monitoring in Dynatrace

Featured Posts