mirror of
https://github.com/Icinga/icingaweb2.git
synced 2026-06-10 09:01:04 -04:00
The `monitoring` module was removed in v2.13.0 and its references
remained in the docs. Remove these references and replace them with
`icingadb` where appropriate.
(cherry picked from commit 821f6a4775)
This commit is contained in:
Sukhwinder Dhillon
Johannes Meyer
parent
1d6fa0aabd
commit
34ebac074d
6 changed files with 19 additions and 157 deletions
|
|
@ -12,8 +12,8 @@
|
|||
## About
|
||||
|
||||
**Icinga Web 2** is the next generation open source monitoring web interface, framework
|
||||
and command-line interface developed by the [Icinga Project](https://icinga.com/), supporting Icinga 2,
|
||||
Icinga Core and any other monitoring backend compatible with the IDO database.
|
||||
and command-line interface developed by the [Icinga GmbH](https://icinga.com/), supporting Icinga 2,
|
||||
Icinga DB Web and many more modules.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -51,13 +51,9 @@ configuration like the [Director](https://github.com/Icinga/icingaweb2-module-di
|
|||
|
||||
See [here](08-Modules.md#modules) for information on how to install and configure modules.
|
||||
|
||||
### The monitoring module <a id="about-monitoring"></a>
|
||||
### Icinga DB Web
|
||||
|
||||
> **Note for Icinga DB Users**
|
||||
>
|
||||
> This module is only for the IDO backend. Use [Icinga DB Web](https://github.com/Icinga/icingadb-web) instead.
|
||||
|
||||
This is the core module for most Icinga Web 2 users.
|
||||
[Icinga DB Web](https://icinga.com/docs/icinga-db-web/latest/) is the core module for most Icinga Web 2 users.
|
||||
|
||||
It provides an intuitive user interface for monitoring with Icinga 2.
|
||||
There are lots of list and detail views (e.g. for hosts and services)
|
||||
|
|
@ -66,8 +62,6 @@ you can sort and filter depending on what you want to see.
|
|||
You can also control the monitoring process itself by sending external commands to Icinga.
|
||||
Most such actions (like rescheduling a check) can be done with just a single click in the UI.
|
||||
|
||||
More details about this module can be found in [this chapter](../modules/monitoring/doc/01-About.md#monitoring-module-about).
|
||||
|
||||
### Documentation <a id="about-documentation"></a>
|
||||
|
||||
With the documentation module you can read the documentation of the framework (and any module) directly in the user interface.
|
||||
|
|
|
|||
|
|
@ -58,14 +58,14 @@ The following shows a role definition from the configuration file mentioned abov
|
|||
[winadmin]
|
||||
users = "jdoe, janedoe"
|
||||
groups = "admin"
|
||||
permissions = "config/*, module/monitoring, monitoring/commands/schedule-check"
|
||||
permissions = "config/*, module/icingadb, icingadb/command/schedule-check"
|
||||
refusals = "config/authentication"
|
||||
monitoring/filter/objects = "host_name=*win*"
|
||||
icingadb/filter/objects = "host.name=*win*"
|
||||
```
|
||||
|
||||
This describes a role with the name `winadmin`. The users `jdoe` and `janedoe` are members of it. Just like the
|
||||
members of group `admin` are. Full configuration access is granted, except of the authentication configuration,
|
||||
which is forbidden. It also grants access to the *monitoring* module which includes the ability to re-schedule
|
||||
which is forbidden. It also grants access to the *icingadb* module which includes the ability to re-schedule
|
||||
checks, but only on objects related to hosts whose name contain `win`.
|
||||
|
||||
#### Syntax
|
||||
|
|
@ -81,7 +81,7 @@ groups | Comma-separated list of **group names** whose users
|
|||
permissions | Comma-separated list of **permissions** granted by this role.
|
||||
refusals | Comma-separated list of **permissions** refused by this role.
|
||||
unrestricted | If set to `1`, owners of this role are not restricted in any way (Default: `0`)
|
||||
monitoring/filter/objects | **Filter expression** that restricts the access to monitoring objects.
|
||||
icingadb/filter/objects | **Filter expression** that restricts the access to icingadb objects.
|
||||
|
||||
### Administrative Roles
|
||||
|
||||
|
|
@ -128,12 +128,7 @@ user/\* | allow all account related functionalities
|
|||
user/application/stacktraces | allow to adjust in the preferences whether to show stacktraces
|
||||
user/password-change | allow password changes in the account preferences
|
||||
user/share/navigation | allow to share navigation items
|
||||
module/`<moduleName>` | allow access to module `<moduleName>` (e.g. `module/monitoring`)
|
||||
|
||||
### Monitoring Module Permissions
|
||||
|
||||
The built-in monitoring module defines an additional set of permissions, that
|
||||
is described in detail in the monitoring module documentation.
|
||||
module/`<moduleName>` | allow access to module `<moduleName>` (e.g. `module/icingadb`)
|
||||
|
||||
## Restrictions
|
||||
|
||||
|
|
@ -141,8 +136,8 @@ Restrictions can be used to define what a user can see by specifying an expressi
|
|||
data. By default, when no restrictions are defined, a user will be able to see the entire data that is available.
|
||||
|
||||
The syntax of the expression used to define a particular restriction varies. This can be a comma-separated list of
|
||||
terms, or [a full-blown filter](06-Security.md#filter-expressions). For more details on particular restrictions,
|
||||
check the table below or the module's documentation providing the restriction.
|
||||
terms, or a full-blown filter. For more details on particular restrictions, check the table below or the module's
|
||||
documentation providing the restriction.
|
||||
|
||||
### General Restrictions
|
||||
|
||||
|
|
@ -157,86 +152,4 @@ It is possible to reference the local username (without the domain part) of the
|
|||
this, put the macro `$user.local_name$` in the restriction where you want it to appear.
|
||||
|
||||
This can come in handy if you have e.g. an attribute on hosts or services defining which user is responsible for it:
|
||||
`_host_deputy=$user.local_name$|_service_deputy=$user.local_name$`
|
||||
|
||||
### Filter Expressions
|
||||
|
||||
Filters operate on columns. A complete list of all available filter columns on hosts and services can be found in
|
||||
the monitoring module documentation.
|
||||
|
||||
Any filter expression that is allowed in the filtered view, is also an allowed filter expression.
|
||||
This means, that it is possible to define negations, wildcards, and even nested
|
||||
filter expressions containing AND and OR-Clauses.
|
||||
|
||||
The filter expression will be **implicitly** added as an **AND-Clause** to each query on
|
||||
the filtered data. The following shows the filter expression `host_name=*win*` being applied on `monitoring/filter/objects`.
|
||||
|
||||
|
||||
Regular filter query:
|
||||
|
||||
AND-- service_problem = 1
|
||||
|
|
||||
+--- service_handled = 0
|
||||
|
||||
|
||||
With our restriction applied, any user affected by this restrictions will see the
|
||||
results of this query instead:
|
||||
|
||||
|
||||
AND-- host_name = *win*
|
||||
|
|
||||
+--AND-- service_problem = 1
|
||||
|
|
||||
+--- service_handled = 0
|
||||
|
||||
#### Stacking Filters
|
||||
|
||||
When multiple roles assign restrictions to the same user, either directly or indirectly
|
||||
through a group, all filters will be combined using an **OR-Clause**, resulting in the final
|
||||
expression:
|
||||
|
||||
|
||||
AND-- OR-- $FILTER1
|
||||
| |
|
||||
| +-- $FILTER2
|
||||
| |
|
||||
| +-- $FILTER3
|
||||
|
|
||||
+--AND-- service_problem = 1
|
||||
|
|
||||
+--- service_handled = 0
|
||||
|
||||
|
||||
As a result, a user is be able to see hosts that are matched by **ANY** of
|
||||
the filter expressions. The following examples will show the usefulness of this behavior:
|
||||
|
||||
#### Example 1: Negation
|
||||
|
||||
```
|
||||
[winadmin]
|
||||
groups = "windows-admins"
|
||||
monitoring/filter/objects = "host_name=*win*"
|
||||
```
|
||||
|
||||
Will display only hosts and services whose host name contains **win**.
|
||||
|
||||
```
|
||||
[webadmin]
|
||||
groups = "web-admins"
|
||||
monitoring/filter/objects = "host_name!=*win*"
|
||||
```
|
||||
|
||||
Will only match hosts and services whose host name does **not** contain **win**
|
||||
|
||||
Notice that because of the behavior of two stacking filters, a user that is member of **windows-admins** and **web-admins**, will now be able to see both, Windows and non-Windows hosts and services.
|
||||
|
||||
#### Example 2: Hostgroups
|
||||
|
||||
```
|
||||
[unix-server]
|
||||
groups = "unix-admins"
|
||||
monitoring/filter/objects = "(hostgroup_name=bsd-servers|hostgroup_name=linux-servers)"
|
||||
```
|
||||
|
||||
This role allows all members of the group unix-admins to see hosts and services
|
||||
that are part of the host-group linux-servers or the host-group bsd-servers.
|
||||
`host.vars.deputy=$user.local_name$|service.vars.deputy=$user.local_name$`
|
||||
|
|
|
|||
|
|
@ -27,18 +27,14 @@ format | json/csv/sql | Selected views can be exported as JSON or CS
|
|||
Examples for `showFullscreen`:
|
||||
|
||||
http://localhost/icingaweb2/dashboard?showFullscreen
|
||||
http://localhost/icingaweb2/monitoring/list/services?service_problem=1&sort=service_severity&showFullscreen
|
||||
|
||||
Examples for `showCompact`:
|
||||
|
||||
http://localhost/icingaweb2/dashboard?showCompact&showFullscreen
|
||||
http://localhost/icingaweb2/monitoring/list/services?service_problem=1&sort=service_severity&showCompact
|
||||
|
||||
Examples for `format`:
|
||||
|
||||
http://localhost/icingaweb2/monitoring/list/services?format=json
|
||||
http://localhost/icingaweb2/monitoring/list/services?service_problem=1&sort=service_severity&dir=desc&format=csv
|
||||
|
||||
http://localhost/icingaweb2/health?format=json
|
||||
|
||||
## VirtualHost Configuration <a id="virtualhost-configuration"></a>
|
||||
|
||||
|
|
@ -203,7 +199,7 @@ about
|
|||
|
||||
* manual creation of the Icinga Web 2 database `icingaweb2` including a default user (optional as authentication and session backend)
|
||||
* additional configuration for the application
|
||||
* additional configuration for the monitoring module (e.g. the IDO database and external command pipe from Icinga 2)
|
||||
* additional configuration for the desired modules (e.g. the database resource and external command pipe from Icinga 2)
|
||||
|
||||
This comes in handy if you are planning to deploy Icinga Web 2 automatically using
|
||||
Puppet, Ansible, Chef, etc.
|
||||
|
|
@ -308,41 +304,6 @@ users = "icingaadmin"
|
|||
permissions = "*"
|
||||
```
|
||||
|
||||
### Icinga Web 2 Manual Configuration Monitoring Module <a id="web-setup-manual-from-source-config-monitoring-module"></a>
|
||||
|
||||
|
||||
**config.ini** defining additional security settings.
|
||||
|
||||
```
|
||||
vim /etc/icingaweb2/modules/monitoring/config.ini
|
||||
|
||||
[security]
|
||||
protected_customvars = "*pw*,*pass*,community"
|
||||
```
|
||||
|
||||
**backends.ini** referencing the Icinga 2 DB IDO resource.
|
||||
|
||||
```
|
||||
vim /etc/icingaweb2/modules/monitoring/backends.ini
|
||||
|
||||
[icinga2]
|
||||
type = "ido"
|
||||
resource = "icinga2"
|
||||
```
|
||||
|
||||
**commandtransports.ini** defining the Icinga 2 API command transport.
|
||||
|
||||
```
|
||||
vim /etc/icingaweb2/modules/monitoring/commandtransports.ini
|
||||
|
||||
[icinga2]
|
||||
transport = "api"
|
||||
host = "localhost"
|
||||
port = "5665"
|
||||
username = "api"
|
||||
password = "api"
|
||||
```
|
||||
|
||||
### Icinga Web 2 Manual Setup Login <a id="web-setup-manual-from-source-login"></a>
|
||||
|
||||
Finally visit Icinga Web 2 in your browser to login as `icingaadmin` user: `/icingaweb2`.
|
||||
|
|
@ -384,14 +345,12 @@ The structure of the configurations looks like the following:
|
|||
/etc/icingaweb2/
|
||||
/etc/icingaweb2/authentication.ini
|
||||
/etc/icingaweb2/modules
|
||||
/etc/icingaweb2/modules/monitoring
|
||||
/etc/icingaweb2/modules/monitoring/config.ini
|
||||
/etc/icingaweb2/modules/monitoring/instances.ini
|
||||
/etc/icingaweb2/modules/monitoring/backends.ini
|
||||
/etc/icingaweb2/modules/<module-name>
|
||||
/etc/icingaweb2/modules/<module-name>/<configfile>
|
||||
/etc/icingaweb2/roles.ini
|
||||
/etc/icingaweb2/config.ini
|
||||
/etc/icingaweb2/enabledModules
|
||||
/etc/icingaweb2/enabledModules/monitoring
|
||||
/etc/icingaweb2/enabledModules/<module-name>
|
||||
/etc/icingaweb2/enabledModules/doc
|
||||
/etc/icingaweb2/resources.ini
|
||||
```
|
||||
|
|
|
|||
|
|
@ -25,7 +25,6 @@
|
|||
<exclude-pattern>library/Icinga/File/Pdf.php</exclude-pattern>
|
||||
<exclude-pattern>library/Icinga/Util/LessParser.php</exclude-pattern>
|
||||
<exclude-pattern>modules/doc/library/Doc/Renderer/DocSectionRenderer.php</exclude-pattern>
|
||||
<exclude-pattern>modules/monitoring/library/Monitoring/Plugin.php</exclude-pattern>
|
||||
</rule>
|
||||
<rule ref="PSR1.Classes.ClassDeclaration.MultipleClasses">
|
||||
<exclude-pattern>*/test/php/*</exclude-pattern>
|
||||
|
|
@ -45,8 +44,5 @@
|
|||
<exclude-pattern>*/application/views/helpers/*</exclude-pattern>
|
||||
<exclude-pattern>*/library/Icinga/Web/Paginator/ScrollingStyle/SlidingWithBorder.php</exclude-pattern>
|
||||
</rule>
|
||||
<rule ref="Generic.Files.LineLength.TooLong">
|
||||
<exclude-pattern>*/modules/monitoring/library/Monitoring/Backend/Ido/Query/*</exclude-pattern>
|
||||
<exclude-pattern>*/modules/monitoring/library/Monitoring/Backend/Livestatus/Query/*</exclude-pattern>
|
||||
</rule>
|
||||
<rule ref="Generic.Files.LineLength.TooLong"/>
|
||||
</ruleset>
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
This module is provided with the Icinga Web 2 package and does
|
||||
not need any extra installation step.
|
||||
|
||||
## Enable the Module <a id="monitoring-module-enable"></a>
|
||||
## Enable the Module <a id="doc-module-enable"></a>
|
||||
|
||||
Navigate to `Configuration` -> `Modules` -> `doc` and enable
|
||||
the module.
|
||||
|
|
|
|||
Loading…
Reference in a new issue