What is MySQL local? Where is it configured?

Help
,
1

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
2

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
3

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
4

Does this mean rewriting them into DSN strings?

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

1 Like
5

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
6

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
7

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
8

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
9

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
10

Hey everyone,

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

2 Likes
11

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. :/