Nagadmin is a web-configurator for configuring a Nagios installation. It also serves as a frontend - a place where you can see the status of your services.
It's not meant to support all Nagios features. It may force a certain workflow upon you, which may or may not be to your taste. The reason it does this is to optimize for the common monitoring use-case and make things simpler for it.
If your requirements are complicated, you may need to look into some other solutions or fork-and-improve this one.
There are lots of web-configurator systems that aim to make Nagios installations easy to configure from the web. Editing Nagios configuration files may be inconvenient (requires terminal access), and more importantly does not show a good overview of what's really configured.
None of the existing Nagios configurator systems seemed to achieve the goals of:
- providing a simple user-interface that's easier than "SSH into the Nagios host & edit raw config files"
- providing a beautiful and pleasant user-interface that also works on mobile devices
- providing both a configuration and frontend tool in one
- providing advanced access control, so that many users can see and potentially do different things
- optimizing for the common use-case, by hiding certain complex Nagios features
- giving you a good overview of the current configuration and status
- Docker
- Docker Compose (v1 or v2)
cd /srv/http
git clone <repository url> nagadmin
cd nagadmin
Start by copying the sample configuration parameters file:
cp config/parameters.json.dist config/parameters.json
cp .env.dist .env
Now modify config/parameters.json and .env to your liking.
make runNot all services will run well yet. Nagios will encounter some errors, because it can't find some of its configuration yet. We resolve this below during the Installation step.
Run the following command to initialize the database (initial data-set import and databse indexes creation):
make init-databaseRun the following command to set up Resource Variables and install the initial Nagios configuration:
make installNagios should now properly start and run.
Create a new administrator user account for you:
./bin/container-console devture-user:add USERNAME_HERE EMAIL_ADDRESS_HEREYou'll be asked for a password, etc.
Use a web browser to access Nagadmin at this URL: http://nagadmin.127.0.0.1.nip.io:20180
You should be able to log in with the user that you created in the previous step.
You can also access Nagios at this URL: http://nagadmin.127.0.0.1.nip.io:20188
You need to authenticate using the username/password you've specified in .env (NAGIOSADMIN_USER and NAGIOSADMIN_PASS).
Run the check command to see if things are running correctly:
./bin/container-console check:statusSee resources/webserver. You may also wish to adjust the %trusted_proxies% parameter in config/parameters.json.
No - read the introduction above.
Yes. Nagadmin is both a web configuration tool for Nagios and a frontend. It can be used as a simple alternative to the default Nagios CGI interface.
No. You'd need to start from scratch.
The source code will always be available. Developing additional features and complicating it much further is not the aim of this project. Community members are free to make improvements to the existing codebase.
Nagadmin is written in PHP and uses the Silex microframework.
We require an x86-84 (amd64) Linux server with Docker and Docker Compose regardless of the distribution.
All services run in containers.
No. Nagios only runs in a container as part of this setup.
Nagadmin only works with Nagios. Some of these systems are similar, so you may be able to migrate your existing setup to Nagios (powered by Nagadmin).
Not right now, or at least it won't work so well. Nagadmin hasn't been optimized for your use-case (yet) - read the introduction above. It targets smaller installations, which don't have quite that many services.
Limitations listed below are either caused by features not being implemented (yet) or by conscious design decisions to omit them (and potentially replace them) with something else.
Because of this, all hosts are (internally) forced to have an OK state. We do this to allow service checks to run for them.
They seem to be yet another thing that the administrator is asked to enter, complicating the workflow and not adding too much value.
This keeps things simple, by removing the complex inheritance model.
That's an advanced feature.
Nagadmin supports automatic service dependencies though (see the NagiosBundle.auto_service_dependency.master_service_regexes parameter in config/parameters.json).
A service that has a name "ping" or "host-alive" (case-insensitive) is automatically made a parent service of all other services on the same host. This allows you to easily define an "important" service, which all other services depend on. It makes up for the missing "Host checks and notifications" feature mentioned above.
When such an important/parent service is down, individual notifications for all of its children will be suppressed.
That's considered an advanced feature, outside the scope of what Nagadmin aims to provide (at least at this point in time).
That's considered an advanced feature, outside the scope of what Nagadmin aims to provide (at least at this point in time).
If you've been using Nagios by configuring it manually, you'd need to replicate all your existing configuration again via Nagadmin's UI.
Nagadin targets a simpler use-case and smaller installations (at this time at least). The code and user interface are done in a way that doesn't currently scale to thousands of services. If you have to monitor thousands of services, it may also appear a bit limiting and simple to you anyway.