Netdata Community

What is MySQL local? Where is it configured?

I have 3 mysqld instances on a server, one in the main namespace and the other two in LXC containers.

I set up /etc/netdata/python.d/mysql.conf to connect to these and that works fine.

But my Netdata display shows four MySQL sets of graphs, as shown. Three are as expected but there’s another called MySQL local that I didn’t configure. MySQL local appears to show the same graphs as MySQL main.

image

Is Netdata querying status variables from this mysqld twice and consuming Netdata storage with redundant data?

If so, how do I get rid of the MySQL local?

2 Likes

If your manually configured python.d/mysql.conf doesn’t have the job named ‘local’, you should check Go version config located at go.d/mysql.conf. Btw, Go version consumes less resources - you could also fully switch to it from Python version.
I would also advice tweaking your go.d.conf and python.d.conf files to explicitly disable unwanted plugins.

5 Likes

Thanks, @Habetdin!

You are right, it looks like @thefsb has 3 python.d.plugin MySQL jobs and 1 go.d.plugin.

You can:

  • move ebf1, ebf2, main jobs to the go.d/mysql.conf (preferable)
  • disable go.d.plugin mysql module in the go.d.conf
4 Likes

Does this mean rewriting them into DSN strings?

(btw, did Go really adopt PHP’s wacky DSN format?)

1 Like

Why? If a plugin doesn’t operate because the thing it monitors doesn’t exist on the system then what’s the problem?

1 Like

If you have manually configured some of plugins that exist in both of Go and Python versions, you probably won’t like situation where both versions of that plugin work together and lead to result that become the reason this topic exists.
In that case disabling manually configured plugin’s twin one is good approach, I believe.

2 Likes

both versions of that plugin work together and lead to result that become the reason this topic exists

Actually, there is some protection from this case - you can’t have running both python.d mysql and go.d mylsq job with the same name (true for any other collector). If you try to do it, the python one will fail.

1 Like

That is the story about Local jobs.

As you know (almost) any python.d/go.d collector is able to collect data from different sources - local or remote.

We have bunch of preconfigured jobs for every collector - all of them have local name. Why many and not one? Because there are multiple ways to collects the metrics from an app - could be via unix socket, or tcp socket, or http endpoint, etc. We want to try different ways and hope that one of them succeed. We try them in the order they are defined in the configuration file, as first as we have the succeed one we stop trying others.

This this the restriction - onle one running job with the same name per collector (apache, nginx, mysql, etc.) per plugin (python.d, go.d).

1 Like

Ok, I see what you mean and that makes sense.

I did not, afaik, manually configure the Go plugin. I guess the Go MySQL plugin arrived in an update with a default configuration and I didn’t pay attention.

I deleted my python.d/mysql.conf and added a go.d/mysql.conf to replace it with a DSN for each mydqld instances.

jobs:
  - name: main
    dsn: netdata@unix(/var/run/mysqld/mysqld.sock)/
  - name: epf1
    dsn: netdata@tcp(epf1:3306)/
  - name: epf2
    dsn: netdata@tcp(epf2:3306)/

I think the presence of this defeats the default go.d/mysql.conf

1 Like

Hey everyone,

To better grasp how the collector system is designed, you can check out this FAQ:

2 Likes

I’ve suspected for a while that Netdata is more complicated than I am able to understand. Confronted with this FAQ I suspect I might have been right about this suspicion. :/