How do you think about external config files for plugins


I’m thinking about building a plugin that sends queries against elasticsearch and use a numerical output for comparing against thresholds. You can look at it as an “elastalert-very-light”. I know, there’s the elasticsearch Icinga Web 2 module that allows to send queries but translating elasticsearch queries into Icinga Web 2 filter syntax is not always easy or even possible.

I was thinking about the possibility to just place the query in an extra file that’s read by the plugin because using big JSON-blobs in arguments for plugins might be a big pain in the bottom.

I built a very, very, very simple prototype with bash, curl and jq but I’m thinking of translating it into a better fitting language like Ruby or Python.

Would you be ok with external command files or is that a thing you didn’t want to use? Especially since you can’t deploy them with Director and shouldn’t send them via Icinga 2 API.

Some older plugins like check_logfiles use something like and the monitoring plugin development guidelines say nothing about it but just because we did in the past doesn’t mean it’s a good thing to carry on.



the monitoring plugins provide this via extra opts, but that’s not implemented anywhere in the ITL. I was made aware of this lately, it defines a specific ini format for arguments you don’t want to pass on the shell (like passwords).

The reason I don’t use them is simple - syncing and deploying the configuration requires extra attention, e.g. with Puppet or Ansible. Users without that will want Icinga to deploy that, and that’s not our main focus replacing a config management solution.


I was just going to open a an issue for that… :wink:

So, any other idea one could deal with rather complex configuration in JSON format?

Use an Icinga Dictionary and serialize it with Json.encode() :smiley: :crazy_face:

template Service "es-service-template" {
  vars.es_config = {
     "filter" = "a in b",
     "grok" = [ "bla", "bumsti", "keksi" ]

object CheckCommand "es-special" {
  arguments = {
    "--extra-config" = {
      value = {{ var es_config = macro("$es_config$"); return Json.encode(es_config) }}

1 Like

Hm… sounds nice, but I think, most queries would be too complex for this to hold. I’ll play around a bit maybe I’m wrong. That would be quite handy.

I still like the idea of having a replicated directory for extra configuration which I could refer to using a simple macro.

I don’t know much about ES filters etc. so my example is not real-world. In terms of syncing extra config, I’m open for suggestions - but not for 2.11 and not for syncing binary plugin scripts.