wrapper around sql monitor

[xp-1000]

Hello, I seen https://github.com/signalfx/signalfx-agent/pull/1389 from @keitwb (thanks) which is very interesting and powerful.

I like very much the "agnostic" approach but having to configure multiple monitors (and expressions) to gather every useful metrics is painful where mysql, postgresql .... integrations should be able to retrieve everything we need (at least for basic alerting and dashboarding purpose).

For example here, we will need to use both sql and collectd/mysql to have everything we need (i.e. slave status + other metrics).

So it leads to the following question: may be the end of the path is to:

• keep this powerful sql agnostic approach to fetch all kinds of metrics from sql queries on every DBMS.
• create a wrapper monitor for each DBMS like Mysql which will define every relevant expression rules for mysql using sql monitor and optionnaly some "specific" metrics retrieving from other way (if applicable).

From this way, we enjoy the sql monitor (but implicitely) but the agent configuration remains as easy as before : only have to configure once DBMS dedicated monitor and not (at least) 2 with multiple expression rules to maintain / update outside the agent version.

[keitwb]

Yes, this is a good approach. The postgresql monitor is basically what you are describing. It uses the sql monitor code under the covers but provides a bunch of "out of the box" queries specific to postgres. We could do the same for mysql. You are welcome to contribute such a thing if you have the time, or we might do it at some point.

[xp-1000]

hello @keitwb thanks for your fast answer as usual.

I am open to contribute of course, I just would like to know if you think it makes sens or not.

I will try to improve existing collectd/mysql to use sql and POC with a simple missing metric like slave status.

[keitwb]

Yes, it absolutely makes sense. I would make a new monitor mysql though and not mess with collectd/mysql since it would have nothing to do with collectd.

[xp-1000]

Yes, it absolutely makes sense. I would make a new monitor mysql though and not mess with collectd/mysql since it would have nothing to do with collectd.

I understand your point and I confess I agree in long term point of view but I need a straightforward and immediate solution for now. Adding slave status from sql query in existing collectd/mysql will allow Signalfx and us to keep retro compatibility, preset dashboards, existing detectors ... and unstuck us. Then we could duplicate this in a new fresh monitor to fully replace collectd by sql expressions. At this moment, we could recreate preset dashboards and allow some "host/container" metrics (avoiding full custom metrics reporting) and so we could eventually drop the collectd check.

This is not perfect but I don't have the time to fill the gab between existing collectd mysql resources with a fresh new one immedialtely. But you agree to improve collectd monitor for now in best effort, so it unstuck us and I will be able to work on a fresh new monitor version step by step when I have some time.

[xp-1000]

or I can try to create a new fresh mysql monitor which will wrap sql one AND collectd/mysql (temporary).

[keitwb]

If you are trying to get the extra metrics for slave status as well as keep the existing collectd/mysql metrics for compatibility, just make a mysql monitor that wraps the sql monitor and only does only the slave status metrics for now. We would make that monitor a beta, or even alpha status of course, but there is no reason it must have a full set of metrics starting out if it provides some marginal value over the collectd/mysql monitor. It would functionally be the same as what you are saying about adding the slave metrics to collectd/mysql, but would avoid the confusing quality of having a collectd/* monitor that isn't fully collectd based (which we have no precident for, and I don't really want to introduce one since we are trying to phase out collectd).

[xp-1000]

hello @keitwb again a totally understand your point of view but I still would prefer to be able to configure only one monitor with basic conf and retrieve everything we need. with your suggestion I still need to configure 2 different monitors (duplicate authentification conf for example) even if it remains a bit easier to configure the new mysql monitor in addidtion to collectd/mysql than configure sql one. may be it is acceptable, I will propose to my colleague and see what they think.

[xp-1000]

@keitwb I spoke to my colleagues and configuring 2 different monitors waiting for the new mysql monitor will cover every useful metrics from collectd/mysql seem acceptable for them.

So I will give a try and start a new monitor as you suggested.

[keitwb]

Ok, great. Depending on what you are using to generate the config, you might be able to use YAML anchors/references to deduplicate specific values a bit.

[atoulme]

Closing this issue as inactive. Please reopen if this issue is still occurring.