Home
As its name, it's a systems monitor dashboard, which means that it will get all those important events (non OK states) from a monitoring system and will put them on a single display to easy acknowledging.
Actually there are three major backends supported:
- Icinga/Nagios: through status.dat file or livestatus plugin (recomended)
- Zabbix: through its own web API
- Check_MK: through livestatus socket (UNIX or TCP)
There are some nice features that would improve the event handling:
- Multiple backends selection.
- Nested dashboards by using SMD backends type (sysMonDash API).
- The ability to filter out which hosts events that you want to be put at the main display.
- You can also filter out which services you don't want to be displayed at the main screen.
- You can set some critical hosts/services that will be always shown (non OK states).
- You can set the threshold level to show events (only on Zabbix backends).
- And finally, you can get which downtimes will be or have been triggered.
- Apache webserver (you can use whatever you want)
- PHP >= 5.2 (prefered 5.5 or above)
- SimpleXML PHP module (php-xml on some distributions)
- cURL PHP module (if you need to use SMD type backends)
Easy, you only need a PHP enabled webserver, download the package from https://github.com/nuxsmin/sysMonDash/archive/master.zip and once it has been unpacked, you can point your browser to the webserver app root and load the config.php file (make sure that the /etc/sysMonDash/ directory exists and it is writable by the webserver user).
mkdir /etc/sysMonDash
chown apache:apache /etc/sysMonDash
Take care that the webserver user can differ from one distribution to other (www-data, httpd, etc)
Now you can set some options like:
- Refresh time (s): how many seconds the main view will wait until refreshing it.
- New event timeout (s): how many seconds the newly created events (non OK states) will be flashing at the main screen. Notice that the OK states will be displayed (not flashing) for a half of that time.
- Maximum events to show: how many events will be shown at the main screen. Think about when a communication issue takes place, you can get a bunch of annoying events at the view.
- **Show events (*) **: which of these columns you want to be shown.
- Shown hosts REGEX at main view: filter out which hosts events that you want to be put at the main display.
- Hidden services REGEX at main view: filter out which services you don't want to be displayed at the main screen.
- Critical items: a comma separated list of critical hosts/services that will be always shown (non OK states).
- Client URL: you can put sysMonDash on a webserver that acts as a client to the monitoring webserver. In this scenario there would be two sysMonDash instances: client (at the webserver) and server (at the monitoring server). This option is set at the server side.
- Remote server URL: the sysMonDash instance acts as a client. This option is set at the client side.
- Monitoring server URL: this option is only to point some links to the backend web monitoring interface.
Easily...
For security reasons, every time you make a configuration change, the app will generate an unique id that will be stored within the config file (hash tag), so once you point the browser to the config.php URL, you will be asked for that id. The config file is located at "/etc/sysMonDash/config.xml"
You can also generate a fixed password, so you can access to sysMonDash configuration by using both methods.
sysMonDash only gets those events that are in a non OK state and you can set some filters to avoid some hosts/services from being shown at the main display, but they will be always shown on the "Show All" display.
When some host/service is filtered out by any rule on the main display, the applied filter will be shown at the "Status Detail" column of each event.
Filtered events will be always shown on the main display when they are triggered and during the "New event timeout", after that, they only will be visible on the "Show All" display.
This is a special backend type which is used when you are going to pair two or more sysMonDash instances with the sysMonDash API. This allows to get multiple remote backends under the same monitoring display by proxying the requests through the sysMonDash API.
In order to get it working, you will need to provide a secure API token for authentication purposes between the API client and server (sysMonDash instances).
This kind of backend outputs the events data in raw mode, it means that the source backend filtering is not taken into account, so you'll get the whole data from the linked sysMonDash instance.
