Override config files

Can I configure Netdata with item-level overrides to the default config files rather than copying the entire config file and modifying it?

For example, if I want to disable the python mysql plugin then I run./edit-config python.d.conf which copies /usr/lib/netdata/conf.d/python.d.conf to /etc/netdata and opens it in vim. I find the line, change it and save the file.

But from now on I am responsible for this 111 line config file. When in future a new version of Netdata comes with changes in python.d.conf I guess I will have to merge the changes manually.

I would prefer to only keep the differences in my configs. I tried creating a config file /etc/netdata/python.d.conf with one line in it mysql: no but this disabled python.d. So I guess it’s not so simple.

Hey,

So, it is entirely possible to only “define” a subset of the configuration attributes, as the ones that are not defined, will have the default (the one which is commented). One you described, should work, so it would be best if you share the entire configuration file, so we can see what is happening.

What you wrote about comments being defaults is interesting. For example, in the Netdata original conf.d/python.d.conf the line enabled: yes is not a comment. Does this imply that python.d is disabled by default and that I have to keep that line in my python.d.conf file if I want it enabled?

Hi @thefsb

You are correct, since you’ve created a config file you are responsible for its content and the appropriate stock configuration is no longer loaded.

This is true not only for the plugin configuration file but for other configuration files too, that is a global pattern.

When in future a new version of Netdata comes with changes in python.d.conf I guess I will have to merge the changes manually.

No worries. You need no to sync anything. If you can give me a specific example of when/why you need to sync it - I am all ears.


Override config files

But I see some value in changing the logic for {python.d, go.d}.conf files. Instead of loading only one, we could:

  • load stock
  • load user
  • merge user into stock

The downside of it is we no longer have unified configuration handling for all components.

1 Like

@thefsb, currently netdata only can setup module settings via .local files, but can’t turn on/off modules in this manner: 'local' support for on/off plugins?

Question @ilyam8 ,

What do you mean with the following quote?

No worries. You need no to sync anything.

1 Like

I wasn’t aware of this @k0ste , thanks for pointing it out!

@ilyam8 I am sensing the birth of an FAQ here. Can you help me clarify this?

Let’s say my config files were copies taken before this change. No problem with keeping my old configs?

setup module settings via .local files

I wasn’t aware of this @k0ste

I wasn’t aware too :thinking: What are those .local files? :man_shrugging:


@thefsb no problem at all.


Can only repeat

  1. I see a value in merging plugins user/stock configuration files ({python.d, go.d}.conf).
  2. I see no sense in merging modules user/stock configuration files.

If there are arguments for 2 - share. If there is interest in 1 - I am ok with implementing it.

@k0ste 1 is your request if I understand it right.

  • user python.d.conf
apache: no
  • stock python.d.conf
apache: yes
nginx: no
...
  • result (merge user into stock)
apache: no
nginx: no
...

Correct!

version 1.0 stock:

apache: no
nginx: yes

user version 1.0:

apache: yes

result:

apache: yes
nginx: yes

–version upgrade–
version 1.5 stock:

apache: yes
nginx: no
  • user old config from version 1.0:
    result:
apache: yes
nginx: no
1 Like

Ok, that is easy to implement and that is not a breaking change. I think we will add it.

2 Likes

Thanks @k0ste for these suggestions!

1 Like

Idk what happened in the end but I’m pleased y’all are pleased with the outcome. I think k0ste’s post articulates the problem I had in mind but, tbh, idk exactly what I had in mind. I just know that I put my MariaDB configs in /etc/mysql/mariadb.conf.d. A few files, each with a few lines that I wrote. Same with most software I configure, I generally don’t need to copy big config files from your source control into mine.

I’m also concerned about health.d. I have eight health.d files in my source control, a total of 818 lines, each file with one or two lines changed relative to the stock version I copied years ago. I imagine Netdata has improved its health algorithms since I copied these files.

Implemented for python.d.plugin in PR#11217