How to write DSL checks, is there an IDE or similar tool?

Dear Icinga community,

I am trying to get myself familiar with the Icinga DSL, and write some checks where multiple already existing objects and checks are being used to cluster them together into a single check and also use some inner logic. Later these custom checks will be fed into business processes, but first I want to get some custom checks set up and experiment with what I can do with the DSL.
For this, I would need a way to be able to interact with the DSL while developing my checks, and I thought that using the Icinga console one can do this.
I have searched around, but I could not find a more elegant IDE or tool for this, and I am wondering what I am doing wrong.
Namely, when I try to do simple things like get the exit status of some checks by copy-pasting into the console the following three lines, it all works fine, and the return values are all 0.000000 as expected:

get_service("fqdnhostname", "ping4").last_check_result.exit_status
get_service("fqdnhostname", "ntp_time").last_check_result.exit_status
get_service("fqdnhostname", "ssh").last_check_result.exit_status

However, when I try to copy-paste into the console some code which contains a bit of logic, like for example:

var listofchecks = [ "ping4", "ntp_time", "ssh" ]
for (var mycheck in listofchecks ) {
  if (get_service("fqdnhostname", mycheck).last_check_result.exit_status > 0) {
      return 2 //something is broken
    } else {
      return 0 //all checks are OK

this will fail with the first error being:

      return 2 //something is broken
Invalid flow control statement.

The above will fail even if I remove the “// comment” from the end of the lines.
In theory the above code should work, but just for testing purpose I have tried to copy-paste into the Icinga console the code from and this also fails to run in the Icinga console.

Could you please help me out what is the right way and environment/IDE/tool to interact with existing objects and develop custom DSL checks? Most likely I had overlooked something in the documentation how to do this in pactice.
While on this topic, is there a simple way to just print out variables in the DSL without explicitly having to “return” them?

I would like to thank you in advance for your help.

Best regards

There is some syntax highlighting for Emacs GitHub - knowhy/icinga2-mode: Emacs major mode for editing icinga2 configuration files and other editors but no LSP.

For debugging I use the log command Library Reference - Icinga 2.

Maybe this blog post helps as well: Icinga DSL: A couple of (unconventional) examples


thanks for the reply.
It does not really give me more details how to develop DSL code for Icinga, but still thanks for the effort for sharing the info.
Even the log function is not much helpful when I want to work with objects from the monitoring system in production, since the logs will not be printed on the screen in that case, but they go into the /var/log/icinga2/icinga2.log tainting the log file. On the other hand, if I don’t explicitly connect to the local Icinga console on the server in production, the Icinga console will have no access to the objects used in the current monitoring environment, so all I can use it for is eventually to get a pass/fail for the syntax with the --file option, like running icinga2 console --file test1.conf

Probably my expectations were too high, and I thought that one can run for/while loops and extended code in the Icinga console directly, allowing for more interactive DSL monitoring code development, like one would develop a Python code.
But as far as I can tell, in the Icinga console for/while loops and if statements and such do not work, one can only execute limited “one-liner” commands.
Thus, I guess there is no way around it, but setting up a dummy host connected to the current DSL check being developed, constantly editing the new DSL check file, restarting icinga2 service for change to take effect and checking the state in the WebUI.

Is there a better option what I am not aware of?

Best regards,

I do it the trial and error way in the director in the check command arguments only but the console would be a lot nicer and is should work according to the documentation.

$ icinga2 console
Icinga 2 (version: v2.11.0)
<1> => function test(name) {
<1> ..   log("Hello " + name)
<1> .. }
<2> => test("World")
information/config: Hello World
<3> =>

source: Cli Commands - Icinga 2

In my view, using the console would be a lot faster and more elegant way than using the usual trial-and-error method. This is why I am looking for better alternatives.

However, at least in my Icinga console (I got version: r2.13.6-1) the for loop and if statements seem not to work in the console.
If possible, could you eventually try to run my code what I pasted in the first post (of course, for fqdnhostname use an actual hostname and with actual check names which run on that host), and see whether it runs fine in your version of icinga console?
To get access to the variables and objects running in the current monitoring environment, one has to connect to the actual console instance on the monitoring server like:
ICINGA2_API_PASSWORD=<YourAPI_Passwd> icinga2 console --connect 'https://root@localhost:5665/'
A simple instance started by icinga2 console will not have access to the objects, just will return “null” when evaluating any of the objects.

Best regards

Hello, have you tried making the code more simple to interpret? For instance, use a break statement in the loop, and a single return statement at the end? The error message leads me to think you might not break out of the loop with a return statement.


my main point is about looking for an environment which allows for DSL check development without lots of trial-and-error, where one can simply interact with objects without having to constantly deploy a check after minor modifications, schedule the check and go to the webGUI to see what changed.
As I wrote in my first post, even if I copy-paste some code from the Icinga2 webpage, that fails to run in the icinga-console.
Thus, to me it seems that I will have to bite the bullet, and just do the tedious trial-error until composite checks are working as expected. Would have been so much nicer though to be able to do this interactively in the icinga-console, and just paste the working code into a check file.

Best regards,

As it’s supposed to work like this according to the documentation, I advice you to open a issue about this if you can’t find one already existing.

This turned out to be indeed an issue with my code, where the “//” in one line for a comment in the code was misplaced, and instead of // there was a single /.

Since as far as I understood there is no more easy-to-use IDE, using the icinga2 console is the best option for developing your own custom DLS scripts.

If it helps some future people bumping into this thread, the takeaway messages are:

  • if the script copy-pasted into the icinga2 console is failing to run, most likely the issue is with your script, so look for typos, missed parentheses etc.
    -one should keep in mind the “scope” of the functions and variables when working in the console. Things which work when pasted into the icinga2 console might work fine within the local scope, but they can fail when used as configuration files.

Best regards

1 Like