Lilac Configurator, also known as Lilac Platform, was created by Taylor Dondich. Lilac Configurator was previously known as “Fruity”. I give many props to him for creating this wonderful tool that allows you to configure Nagios in a separate web interface that saves the configuration to a MySQL server. The beauty of this tool is that you can configure your entire environment without ever touching Nagios. However, i would be remiss to not state the true power of this beast, its ability to allow you to create templates and use inheritance to assign services to Nagios objects.
Yes, the true ability of the Lilac Configurator, beyond the web based configuration of Nagios is the Templates. You can create commands, then create service and host templates. The host templates allow you to literally apply preconfigured settings to any host in an instant while creating the host. This saves hours of configuration for each host. Plus you can update a group of hosts in just a few mouse clicks. Service templates are essentially the same thing, but related only to services. Again, you can apply settings to a service template and apply the template to host services. No need to spend hours configuring servers. Both of these come in handy when you need to configure a bunch of similar servers with similar requirements and/or services.
The next thing you should know is that you can create host groups and service groups. Obviously this is a core part of Nagios, but the beauty of the configurator is that you can assign services based on service templates to host groups. By doing this, the services are now monitored on any host assigned to the host group. Service groups work slightly different, you just assign the service templates to the service group and any hosts being monitored that have the service template assigned either directly or by a host group, are now monitored in the service group. Hopefully this makes sense. Course the best way is to give it a try, so here is a quick walk through of / guide to the Lilac Configurator.
Ok, this part assumes you have successfully installed the Lilac Configurator on your Nagios monitoring server. Current version of Nagios is 3.2.3, but I am using Nagios 3.2.1 and Lilac Configurator 1.0.3 for this guide. I only wrote this guide because the information here: http://www.lilacplatform.com/trac/wiki only covers the install, upgrade, export, import, and auto discovery features of the Lilac Configurator.
So here goes.
First things first, the menu is at the top right. This is your primary navigation. The General section is for the general configuration of Nagios and the Lilac Configurator. This is where you set you nagios Daemon paths for Lilac to use when exporting configurations and restarting/reloading the service, web interface settings for Nagios, Time periods for templates and hosts, Contacts, resources, host groups, service groups, contact groups and Nagios commands.
Most of the stuff on this page, you will set it once and probably never change it, however, the nagios commands, host and service groups are going to be your bread and butter. You will use the templates section to spread the butter evenly and the network section to select which objects have the butter applied.
First major section is the Nagios Command section. This is where you create the commands you are going to use in the service templates, service checks and host checks. For me, i use NsClient++ on all the windows hosts, so i need to use the check_nt built-in Nagios command a lot for different things. Since the check_nt command has many switches, i generally create a command for each switch. For example, when i want to check a service on the windows hosts, i need to run the check_nt command with the service switch, IE:
$USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -v SERVICESTATE -l $ARG1$
The first section is the path “$USER1$/check_nt” the second section “-H $HOSTADDRESS$” specifies a host lookup and the variable which will be the hostname of the machine its supposed to check. The third section is the port specification“-p 12489”, IE Use port(-p) 12489. The forth section tells check_nt to check the service state( -v SERVICESTATE ) of the fifth section which is the service you specify ( -l $ARG1$ ). Obviously $ARG1$ is not the service, it’s the argument specified in the service check template or service check. The $ARG1$ is replaced by say “Spooler”, which would be us checking the spooler service on the host.
So in this case, the Command Name would be “Check_nt_Service” because I am checking a service with check_nt . Obviously this is arbitrary, but i use this naming convention because it makes sense when you read it 2 years later. Anyhow, the Command line would be as noted above:
“$USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -v SERVICESTATE -l $ARG1$”
The command description would whatever you want, i used “Checks to see if a windows service is running”.
Personally, I create a five commands just for check_nt. Mine are Disk space, Process, Service, CPU Load and Counter. There are more check_nt commands, but these are the only ones i am using for now.
The names of both are completely arbitrary. Name them what you want, just make sure that you name them something that makes sense to more than just you. Unless of course you are going for a theme where you name your anti-spam servers Jedi Knights, your mail servers droids, ok ok, you get the picture…
Anyhow, create a host group, name it what you will. Next you will see 6 options at the top. Members are added by going to the host(once added) and making them a member of the group. Extended information is for the Nagios web interface. Dependencies allow you to specify a host or host group this group relies on to function.
Escalations allow you to set an escalation tree for the specific host group, this allows you to send alerts to your exchange admins directly when the exchange host group is experiencing outages. Here you can add contacts or contact groups to notify when an issue is occurring. This is obviously a great tool for when you have different groups of people handling different server groupings.
The final tab, services, is where you can add services to the group. This forces any services assigned to the group to all hosts in the group. You can do this two ways, create a service an assign all the necessary settings or go to the templates page and create a service then come back to the services tab under the host group, create a service and assign the service template. My suggestion would be the latter one, it ensures that the settings are standardized no matter what host has the service check assigned and it allows you to add the service ONCE and then use inheritance the rest of the time.
So let’s say we created a service template already(there are a few stock ones). What you would do is click the services tab and click “create a new service for this hostgroup”. Next you name and describe what you want to call the services, again completely arbitrary and click “add service”.
Next you would click on the inheritance tab, use the drop down to select the pre-created template and click “add template”. This would assign all the settings from the template to the service you want to monitor. Of course if you created a service template to monitor a specific service, you are essentially done since no other settings are necessary( assuming you configured the template with all your hearts desires ).
For sanity’s sake, you can click on the “checks” tab at the top and view all the inherited settings. Keep in mind, you can click the “edit” button at the bottom to modify any or add some settings, nothing is set in stone. This is the case with most settings, you can override at any point.
As with the host group settings, each service has its dependencies, contacts, extended information, and escalations. These do the same things, its just there so you can set settings on a granular level. This scales VERY well. You will notice however, a few more tabs. Flapping, notifications, group membership and check command parameters.
Flapping settings can be set in the template, this is just a granular control function. Notifications, again another granular control. Group Membership is where you can assign the service to a service group so it will show up in the service groups area of Nagios. Normally you would not add a service to a service group under a host group because you already added the service template to a service group. But lets say you created a manual service under one host group because you needed to, then it may be time to add it to a service group, but again, that’s up to you.
The check command parameters is for the check arguments. Remember the $ARG1$ variable in the nagios command section i covered above? This is where you would enter the variable. Now normally this would not be necessary because you entered the variable in the service template, but if you created a custom command that requires a custom variable and you are creating a custom service on this host group, you would then need to the add the variable for that argument here. Hopefully that made sense. Also note that if you had more than one $ARG1$ for the command, say $ARG1$, $ARG2$, $ARG3$, you would also need to add each variable here. This is another good reason to use service templates instead.
Service groups are less useful than host groups, but still as important. If you need to monitor a whole bunch of services in a group, this is where you would make them a group. This is different from the host groups because you many want to only monitor FTP services and say you have different FTP servers running on different hosts, this section would allow you to group those disparate services into a group. We had this issue with MySQL, you can name the windows services whatever you want and our software vendors did just that. So the only way to group them was with a service group.
Service groups have only three tabs, the general one where you set the name and description(usually done when the group is created, but you can edit it here), the extended information section for the Nagios web interface and the members section. The members section only tells you what services and service templates are a member of the group, you cannot add them here, they must be added in the service template or the service settings.
Yay, the fun part, Host templates and service templates are just that, templates. They allow you to set the settings to your heart’s content and then apply those settings to any host or host group that uses the template.
This is split into two categories, hosts and services. There are bunches of settings for each, suffice to say, think of it as a way to set it and forget it for both services and hosts.
Now the host template settings are relatively straight forward. You can inherit from a another template, set specific checks and check settings, flapping settings, logging settings, notifications, contacts, extended info, and dependencies, escalations. The services section is just like the host group section except in this case you can assign an inheritance via the host template. This allows you to apply the same settings to as many hosts as you want without actually making them a host group. An example of this would be if you had a specific set of services you monitor on every Linux host and every Windows host. You set it here and apply the template to each host and viola time is saved!
Do not add the host template to a host group unless you know for sure the services applied to the host template also exist on the host the template will be applied to. This of course assumes you applied services to the host group. If you didn’t, then no worries.
So at this point you should be enlightened to how powerful the templates can be. Set it once and apply it many times. On top of that you can override at any level. The only exception being the services applied to groups, they trickle down but there is no way to exclude them for a specific host if they are applied a the host group level.
Next we have service templates. This is where you set all the specific settings for the service templates and of course add any arguments needed for the command check chosen. Once you set these up, you can just add them to any of the host groups, host templates and hosts using the inheritance tab.
Network is where you add hosts. Hosts can be switches, routers, servers, computers and random network connected devices. This is where you add items you want to monitor.
When adding a child host at the top level, its just a stand alone hosts. When adding a child host under another existing host, it becomes part of a hierarchy. The hierarchy prevents notifications being sent for each host if the main parent host is offline. Such the case when you have a router with a subnet of servers, pcs and printers attached. If Nagios detects the router down as well as all the hosts assigned to that router as child hosts, then it will only complain/notify you of the router issue. This ensures you do not receive a notification for each object unless you specify an override notification.
Anyhow, when adding a child host, type in the DNS hostname or use the IP if there is no hostname in DNS, IP address, friendly name and descriptions. Once added, the inheritance tab is where you would add the host template you have already created. Assuming all the settings are in the template and the template has assigned services or the host group has all the services, you should be done. Obviously you can override any of the settings on any of the tabs, so make sure to take advantage of this when it makes sense. Make sure to make use of the group membership tab so you can add the host to host group. Obviously, this may not be necessary given that you may have already assigned the host template to a group, but make sure to take note.
While the guides on the lilac configurator page are pretty good, i found some issues exporting to Nagios 3.2.1 initially. The main crux of the problem was that i had several host and service groups with no assigned hosts or services. I found this out after basically manually deleting all the Nagios configuration files and tracing error messages. So be for warned, clear out any host groups or service groups with nothing assigned.
Exporting is rather simple. Essentially set the job name and description if you want, select the Nagios exporter and set your options. I only use the backup options, because otherwise i have to set the paths at the bottom. I also had some issues with Nagios as noted above. Feel free to use them though.
Once you have created the job and it works without failing, you are better off to just keep the job. Then once you have modified the lilac settings, you can just click on the job previously created and select “restart”. This will restart the job and export the configuration. Assuming you haven’t set it to check or restart Nagios, its now up to you to do this manually on the Nagios system. Here are the commands i run:
“/etc/nagios/bin/nagios -v /usr/nagios/etc/nagios.cfg” for the sanity check ( your path may vary )
“/etc/rc.d/init.d/nagios reload” to reload Nagios without restart(which clears your uptimes) ( your path may vary).