mirror of https://github.com/Icinga/icinga2.git
704 lines
24 KiB
Markdown
704 lines
24 KiB
Markdown
# <a id="monitoring-remote-systems"></a> Monitoring Remote Systems
|
|
|
|
## <a id="agent-less-checks"></a> Agent-less Checks
|
|
|
|
If the remote service is available using a network protocol and port,
|
|
and a [check plugin](#setting-up-check-plugins) is available, you don't
|
|
necessarily need a local client installed. Rather choose a plugin and
|
|
configure all parameters and thresholds. The [Icinga 2 Template Library](#itl)
|
|
already ships various examples.
|
|
|
|
## <a id="agent-based-checks"></a> Agent-based Checks
|
|
|
|
If the remote services are not directly accessible through the network, a
|
|
local agent installation exposing the results to check queries can
|
|
become handy.
|
|
|
|
### <a id="agent-based-checks-snmp"></a> SNMP
|
|
|
|
The SNMP daemon runs on the remote system and answers SNMP queries by plugin
|
|
binaries. The [Monitoring Plugins package](#setting-up-check-plugins) ships
|
|
the `check_snmp` plugin binary, but there are plenty of [existing plugins](#integrate-additional-plugins)
|
|
for specific use cases already around, for example monitoring Cisco routers.
|
|
|
|
The following example uses the [SNMP ITL](#itl-snmp) `CheckCommand` and just
|
|
overrides the `oid` custom attribute. A service is created for all hosts which
|
|
have the `community` custom attribute.
|
|
|
|
apply Service "uptime" {
|
|
import "generic-service"
|
|
|
|
check_command = "snmp"
|
|
vars.oid = "1.3.6.1.2.1.1.3.0"
|
|
|
|
assign where host.vars.community
|
|
}
|
|
|
|
### <a id="agent-based-checks-ssh"></a> SSH
|
|
|
|
Calling a plugin using the SSH protocol to execute a plugin on the remote server fetching
|
|
its return code and output. `check_by_ssh` is available in the [Monitoring Plugins package](#setting-up-check-plugins).
|
|
|
|
object CheckCommand "check_by_ssh_swap" {
|
|
import "plugin-check-command"
|
|
|
|
command = [ PluginDir + "/check_by_ssh",
|
|
"-l", "remoteuser",
|
|
"-H", "$address$",
|
|
"-C", "\"/usr/local/icinga/libexec/check_swap -w $warn$ -c $crit$\""
|
|
]
|
|
}
|
|
|
|
object Service "swap" {
|
|
import "generic-service"
|
|
|
|
host_name = "remote-ssh-host"
|
|
|
|
check_command = "check_by_ssh_swap"
|
|
vars = {
|
|
"warn" = "50%"
|
|
"crit" = "75%"
|
|
}
|
|
}
|
|
|
|
### <a id="agent-based-checks-nrpe"></a> NRPE
|
|
|
|
[NRPE](http://docs.icinga.org/latest/en/nrpe.html) runs as daemon on the remote client including
|
|
the required plugins and command definitions.
|
|
Icinga 2 calls the `check_nrpe` plugin binary in order to query the configured command on the
|
|
remote client.
|
|
|
|
The NRPE daemon uses its own configuration format in nrpe.cfg while `check_nrpe`
|
|
can be embedded into the Icinga 2 `CheckCommand` configuration syntax.
|
|
|
|
Example:
|
|
|
|
object CheckCommand "check_nrpe" {
|
|
import "plugin-check-command"
|
|
|
|
command = [
|
|
PluginDir + "/check_nrpe",
|
|
"-H", "$address$",
|
|
"-c", "$remote_nrpe_command$",
|
|
]
|
|
}
|
|
|
|
object Service "users" {
|
|
import "generic-service"
|
|
|
|
host_name = "remote-nrpe-host"
|
|
|
|
check_command = "check_nrpe"
|
|
vars.remote_nrpe_command = "check_users"
|
|
}
|
|
|
|
nrpe.cfg:
|
|
|
|
command[check_users]=/usr/local/icinga/libexec/check_users -w 5 -c 10
|
|
|
|
### <a id="agent-based-checks-nsclient"></a> NSClient++
|
|
|
|
[NSClient++](http://nsclient.org) works on both Windows and Linux platforms and is well
|
|
known for its magnificent Windows support. There are alternatives like the WMI interface,
|
|
but using `NSClient++` will allow you to run local scripts similar to check plugins fetching
|
|
the required output and performance counters.
|
|
|
|
The NSClient++ agent uses its own configuration format while `check_nt`
|
|
can be embedded into the Icinga 2 `CheckCommand` configuration syntax.
|
|
|
|
Example:
|
|
|
|
object CheckCommand "check_nscp" {
|
|
import "plugin-check-command"
|
|
|
|
command = [
|
|
PluginDir + "/check_nt",
|
|
"-H", "$address$",
|
|
"-p", "$port$",
|
|
"-v", "$remote_nscp_command$",
|
|
"-l", "$partition$",
|
|
"-w", "$warn$",
|
|
"-c", "$crit$",
|
|
"-s", "$pass$"
|
|
]
|
|
|
|
vars = {
|
|
"port" = "12489"
|
|
"pass" = "supersecret"
|
|
}
|
|
}
|
|
|
|
object Service "users" {
|
|
import "generic-service"
|
|
|
|
host_name = "remote-windows-host"
|
|
|
|
check_command = "check_nscp"
|
|
|
|
vars += {
|
|
remote_nscp_command = "USEDDISKSPACE"
|
|
partition = "c"
|
|
warn = "70"
|
|
crit = "80"
|
|
}
|
|
}
|
|
|
|
For details on the `NSClient++` configuration please refer to the [official documentation](http://www.nsclient.org/nscp/wiki/doc/configuration/0.4.x).
|
|
|
|
> **Note**
|
|
>
|
|
> The format of the `NSClient++` configuration file has changed from 0.3.x to 0.4!
|
|
|
|
### <a id="agent-based-checks-icinga2-agent"></a> Icinga 2 Agent
|
|
|
|
A dedicated Icinga 2 agent supporting all platforms and using the native
|
|
Icinga 2 communication protocol supported with SSL certificates, IPv4/IPv6
|
|
support, etc. is on the [development roadmap](https://dev.icinga.org/projects/i2?jump=issues).
|
|
Meanwhile remote checkers in a [Cluster](#cluster) setup could act as
|
|
immediate replacement, but without any local configuration - or pushing
|
|
their standalone configuration back to the master node including their check
|
|
result messages.
|
|
|
|
### <a id="agent-based-checks-snmp-traps"></a> Passive Check Results and SNMP Traps
|
|
|
|
SNMP Traps can be received and filtered by using [SNMPTT](http://snmptt.sourceforge.net/) and specific trap handlers
|
|
passing the check results to Icinga 2.
|
|
|
|
> **Note**
|
|
>
|
|
> The host and service object configuration must be available on the Icinga 2
|
|
> server in order to process passive check results.
|
|
|
|
### <a id="agent-based-checks-nsca-ng"></a> NSCA-NG
|
|
|
|
[NSCA-ng](http://www.nsca-ng.org) provides a client-server pair that allows the
|
|
remote sender to push check results into the Icinga 2 `ExternalCommandListener`
|
|
feature.
|
|
|
|
The [Icinga 2 Vagrant Demo VM](#vagrant) ships a demo integration and further samples.
|
|
|
|
|
|
|
|
## <a id="distributed-monitoring"></a> Distributed Monitoring
|
|
|
|
An Icinga 2 cluster consists of two or more nodes and can reside on multiple
|
|
architectures. The base concept of Icinga 2 is the possibility to add additional
|
|
features using components. In case of a cluster setup you have to add the
|
|
cluster feature to all nodes. Before you start configuring the diffent nodes
|
|
it's necessary to setup the underlying communication layer based on SSL.
|
|
|
|
### <a id="certificate-authority-certificates"></a> Certificate Authority and Certificates
|
|
|
|
Icinga 2 comes with two scripts helping you to create CA and node certificates
|
|
for you Icinga 2 Cluster.
|
|
|
|
The first step is the creation of CA using the following command:
|
|
|
|
icinga2-build-ca
|
|
|
|
Please make sure to export a variable containing an empty folder for the created
|
|
CA files:
|
|
|
|
export ICINGA_CA="/root/icinga-ca"
|
|
|
|
In the next step you have to create a certificate and a key file for every node
|
|
using the following command:
|
|
|
|
icinga2-build-key icinga2a
|
|
|
|
Please create a certificate and a key file for every node in the Icinga 2
|
|
Cluster and save the CA key in case you want to set up certificates for
|
|
additional nodes at a later date.
|
|
|
|
### <a id="enable-cluster-configuration"></a> Enable the Cluster Configuration
|
|
|
|
Until the cluster-component is moved into an independent feature you have to
|
|
enable the required libraries in the icinga2.conf configuration file:
|
|
|
|
library "cluster"
|
|
|
|
### <a id="configure-nodename"></a> Configure the Icinga Node Name
|
|
|
|
Instead of using the default FQDN as node name you can optionally set
|
|
that value using the [NodeName](#global-constants) constant.
|
|
This setting must be unique on each cluster node, and must also match
|
|
the name of the local [Endpoint](#objecttype-endpoint) object and the
|
|
SSL certificate common name.
|
|
|
|
const NodeName = "icinga2a"
|
|
|
|
Read further about additional [naming conventions](#cluster-naming-convention).
|
|
|
|
Not specifying the node name will default to FQDN. Make sure that all
|
|
configured endpoint names and set common names are in sync.
|
|
|
|
### <a id="configure-clusterlistener-object"></a> Configure the ClusterListener Object
|
|
|
|
The ClusterListener needs to be configured on every node in the cluster with the
|
|
following settings:
|
|
|
|
Configuration Setting |Value
|
|
-------------------------|------------------------------------
|
|
ca_path | path to ca.crt file
|
|
cert_path | path to server certificate
|
|
key_path | path to server key
|
|
bind_port | port for incoming and outgoing conns
|
|
peers | array of all reachable nodes
|
|
------------------------- ------------------------------------
|
|
|
|
A sample config part can look like this:
|
|
|
|
/**
|
|
* Load cluster library and configure ClusterListener using certificate files
|
|
*/
|
|
library "cluster"
|
|
|
|
object ClusterListener "cluster" {
|
|
ca_path = "/etc/icinga2/ca/ca.crt"
|
|
cert_path = "/etc/icinga2/ca/icinga2a.crt"
|
|
key_path = "/etc/icinga2/ca/icinga2a.key"
|
|
|
|
bind_port = 8888
|
|
|
|
peers = [ "icinga2b" ]
|
|
}
|
|
|
|
The certificate files must be readable by the user Icinga 2 is running as. Also,
|
|
the private key file should not be world-readable.
|
|
|
|
Peers configures the direction used to connect multiple nodes together. If have
|
|
a three node cluster consisting of
|
|
|
|
* node-1
|
|
* node-2
|
|
* node-3
|
|
|
|
and `node-3` is only reachable from `node-2`, you have to consider this in your
|
|
peer configuration.
|
|
|
|
### <a id="configure-cluster-endpoints"></a> Configure Cluster Endpoints
|
|
|
|
In addition to the configured port and hostname every endpoint can have specific
|
|
abilities to send configuration files to other nodes and limit the hosts allowed
|
|
to send configuration files.
|
|
|
|
Configuration Setting |Value
|
|
-------------------------|------------------------------------
|
|
host | hostname
|
|
port | port
|
|
accept_config | all nodes allowed to send configuration
|
|
config_files | all files sent to that node - MUST BE AN ABSOLUTE PATH
|
|
config_files_recursive | all files in a directory recursively sent to that node
|
|
------------------------- ------------------------------------
|
|
|
|
A sample config part can look like this:
|
|
|
|
/**
|
|
* Configure config master endpoint
|
|
*/
|
|
|
|
object Endpoint "icinga2a" {
|
|
host = "icinga2a.localdomain"
|
|
port = 8888
|
|
config_files_recursive = ["/etc/icinga2/conf.d"]
|
|
}
|
|
|
|
If you update the configuration files on the configured file sender, it will
|
|
force a restart on all receiving nodes after validating the new config.
|
|
|
|
A sample config part for a config receiver endpoint can look like this:
|
|
|
|
/**
|
|
* Configure config receiver endpoint
|
|
*/
|
|
|
|
object Endpoint "icinga2b" {
|
|
host = "icinga2b.localdomain"
|
|
port = 8888
|
|
accept_config = [ "icinga2a" ]
|
|
}
|
|
|
|
By default these configuration files are saved in /var/lib/icinga2/cluster/config.
|
|
|
|
In order to load configuration files which were received from a remote Icinga 2
|
|
instance you will have to add the following include directive to your
|
|
`icinga2.conf` configuration file:
|
|
|
|
include_recursive LocalStateDir + "/lib/icinga2/cluster/config"
|
|
|
|
### <a id="cluster-naming-convention"></a> Cluster Naming Convention
|
|
|
|
The SSL certificate common name (CN) will be used by the [ClusterListener](pbjecttype-clusterlistener)
|
|
object to determine the local authority. This name must match the local [Endpoint](#objecttype-endpoint)
|
|
object name.
|
|
|
|
Example:
|
|
|
|
# icinga2-build-key icinga2a
|
|
...
|
|
Common Name (e.g. server FQDN or YOUR name) [icinga2a]:
|
|
|
|
# vim cluster.conf
|
|
|
|
object Endpoint "icinga2a" {
|
|
host = "icinga2a.localdomain"
|
|
port = 8888
|
|
}
|
|
|
|
The [Endpoint](#objecttype-endpoint) name is further referenced as `peers` attribute on the
|
|
[ClusterListener](pbjecttype-clusterlistener) object.
|
|
|
|
object Endpoint "icinga2b" {
|
|
host = "icinga2b.localdomain"
|
|
port = 8888
|
|
}
|
|
|
|
object ClusterListener "cluster" {
|
|
ca_path = "/etc/icinga2/ca/ca.crt"
|
|
cert_path = "/etc/icinga2/ca/icinga2a.crt"
|
|
key_path = "/etc/icinga2/ca/icinga2a.key"
|
|
|
|
bind_port = 8888
|
|
|
|
peers = [ "icinga2b" ]
|
|
}
|
|
|
|
Specifying the local node name using the [NodeName](#global-constants) variable requires
|
|
the same name as used for the endpoint name and common name above. If not set, the FQDN is used.
|
|
|
|
const NodeName = "icinga2a"
|
|
|
|
|
|
### <a id="initial-cluster-sync"></a> Initial Cluster Sync
|
|
|
|
In order to make sure that all of your cluster nodes have the same state you will
|
|
have to pick one of the nodes as your initial "master" and copy its state file
|
|
to all the other nodes.
|
|
|
|
You can find the state file in `/var/lib/icinga2/icinga2.state`. Before copying
|
|
the state file you should make sure that all your cluster nodes are properly shut
|
|
down.
|
|
|
|
|
|
### <a id="assign-services-to-cluster-nodes"></a> Assign Services to Cluster Nodes
|
|
|
|
By default all services are distributed among the cluster nodes with the `Checker`
|
|
feature enabled.
|
|
If you require specific services to be only executed by one or more checker nodes
|
|
within the cluster, you must define `authorities` as additional service object
|
|
attribute. Required Endpoints must be defined as array.
|
|
|
|
apply Service "dmz-oracledb" {
|
|
import "generic-service"
|
|
|
|
authorities = [ "icinga2a" ]
|
|
|
|
assign where "oracle" in host.groups
|
|
}
|
|
|
|
The most common use case is building a master-slave cluster. The master node
|
|
does not have the `checker` feature enabled, and the slave nodes are checking
|
|
services based on their location, inheriting from a global service template
|
|
defining the authorities.
|
|
|
|
### <a id="cluster-health-check"></a> Cluster Health Check
|
|
|
|
The Icinga 2 [ITL](#itl) ships an internal check command checking all configured
|
|
`EndPoints` in the cluster setup. The check result will become critical if
|
|
one or more configured nodes are not connected.
|
|
|
|
Example:
|
|
|
|
apply Service "cluster" {
|
|
import "generic-service"
|
|
|
|
check_interval = 1m
|
|
check_command = "cluster"
|
|
authorities = [ "icinga2a" ]
|
|
|
|
assign where host.name = "icinga2a"
|
|
}
|
|
|
|
Each cluster node should execute its own local cluster health check to
|
|
get an idea about network related connection problems from different
|
|
point of views. Use the `authorities` attribute to assign the service
|
|
check to the configured node.
|
|
|
|
### <a id="host-multiple-cluster-nodes"></a> Host With Multiple Cluster Nodes
|
|
|
|
Special scenarios might require multiple cluster nodes running on a single host.
|
|
By default Icinga 2 and its features will drop their runtime data below the prefix
|
|
`LocalStateDir`. By default packages will set that path to `/var`.
|
|
You can either set that variable as constant configuration
|
|
definition in [icinga2.conf](#icinga2-conf) or pass it as runtime variable to
|
|
the Icinga 2 daemon.
|
|
|
|
# icinga2 -c /etc/icinga2/node1/icinga2.conf -DLocalStateDir=/opt/node1/var
|
|
|
|
|
|
### <a id="cluster-scenarios"></a> Cluster Scenarios
|
|
|
|
#### <a id="cluster-scenarios-features"></a> Features in Cluster
|
|
|
|
Each cluster instance may use available features. If you have multiple locations
|
|
or departments, they may write to their local database, or populate graphite.
|
|
Even further all commands are distributed (unless prohibited using [Domains](#domains)).
|
|
|
|
DB IDO on the left, graphite on the right side - works.
|
|
Icinga Web 2 on the left, checker and notifications on the right side - works too.
|
|
Everything on the left and on the right side - make sure to deal with duplicated notifications
|
|
and automated check distribution.
|
|
|
|
#### <a id="cluster-scenarios-location-based"></a> Location Based Cluster
|
|
|
|
That scenario fits if your instances are spread over the globe and they all report
|
|
to a central instance. Their network connection only works towards the central master
|
|
(or the master is able to connect, depending on firewall policies) which means
|
|
remote instances won't see each/connect to each other.
|
|
|
|
All events are synced to the central node, but the remote nodes can still run
|
|
local features such as a web interface, reporting, graphing, etc.
|
|
|
|
Imagine the following example with a central node in Nuremberg, and two remote DMZ
|
|
based instances in Berlin and Vienna. The configuration tree on the central instance
|
|
could look like this:
|
|
|
|
conf.d/
|
|
templates/
|
|
germany/
|
|
nuremberg/
|
|
hosts.conf
|
|
berlin/
|
|
hosts.conf
|
|
austria/
|
|
vienna/
|
|
hosts.conf
|
|
|
|
The configuration deployment should look like:
|
|
|
|
* The node `nuremberg` sends `conf.d/germany/berlin` to the `berlin` node.
|
|
* The node `nuremberg` sends `conf.d/austria/vienna` to the `vienna` node.
|
|
|
|
`conf.d/templates` is shared on all nodes.
|
|
|
|
The endpoint configuration on the `nuremberg` node would look like:
|
|
|
|
object Endpoint "nuremberg" {
|
|
host = "nuremberg.icinga.org"
|
|
port = 8888
|
|
}
|
|
|
|
object Endpoint "berlin" {
|
|
host = "berlin.icinga.org"
|
|
port = 8888
|
|
config_files_recursive = [ "/etc/icinga2/conf.d/templates",
|
|
"/etc/icinga2/conf.d/germany/berlin" ]
|
|
}
|
|
|
|
object Endpoint "vienna" {
|
|
host = "vienna.icinga.org"
|
|
port = 8888
|
|
config_files_recursive = [ "/etc/icinga2/conf.d/templates",
|
|
"/etc/icinga2/conf.d/austria/vienna" ]
|
|
}
|
|
|
|
Each remote node will only peer with the central `nuremberg` node. Therefore
|
|
only two endpoints are required for cluster connection. Furthermore the remote
|
|
node must include the received configuration by the cluster functionality.
|
|
|
|
Example for the configuration on the `berlin` node:
|
|
|
|
object Endpoint "nuremberg" {
|
|
host = "nuremberg.icinga.org"
|
|
port = 8888
|
|
}
|
|
|
|
object Endpoint "berlin" {
|
|
host = "berlin.icinga.org"
|
|
port = 8888
|
|
accept_config = [ "nuremberg" ]
|
|
}
|
|
|
|
include_recursive LocalStateDir + "/lib/icinga2/cluster/config"
|
|
|
|
Depenending on the network connectivity the connections can be either
|
|
established by the remote node or the central node.
|
|
|
|
Example for `berlin` node connecting to central `nuremberg` node:
|
|
|
|
library "cluster"
|
|
|
|
object ClusterListener "berlin-cluster" {
|
|
ca_path = "/etc/icinga2/ca/ca.crt"
|
|
cert_path = "/etc/icinga2/ca/berlin.crt"
|
|
key_path = "/etc/icinga2/ca/berlin.key"
|
|
bind_port = 8888
|
|
peers = [ "nuremberg" ]
|
|
}
|
|
|
|
Example for central `nuremberg` node connecting to remote nodes:
|
|
|
|
library "cluster"
|
|
|
|
object ClusterListener "nuremberg-cluster" {
|
|
ca_path = "/etc/icinga2/ca/ca.crt"
|
|
cert_path = "/etc/icinga2/ca/nuremberg.crt"
|
|
key_path = "/etc/icinga2/ca/nuremberg.key"
|
|
bind_port = 8888
|
|
peers = [ "berlin", "vienna" ]
|
|
}
|
|
|
|
The central node should not do any checks by itself. There's two possibilities to achieve
|
|
that:
|
|
|
|
* Disable the `checker` feature
|
|
* Pin the service object configuration to the remote endpoints using the [authorities](#assign-services-to-cluster-nodes)
|
|
attribute.
|
|
|
|
|
|
#### <a id="cluster-scenarios-load-distribution"></a> Load Distribution
|
|
|
|
If you are planning to off-load the checks to a defined set of remote workers
|
|
you can achieve that by:
|
|
|
|
* Deploying the configuration on all nodes.
|
|
* Let Icinga 2 distribute the load amongst all available nodes.
|
|
|
|
That way all remote check instances will receive the same configuration
|
|
but only execute their part. The central instance can also execute checks,
|
|
but you may also disable the `Checker` feature.
|
|
|
|
conf.d/
|
|
templates/
|
|
many/
|
|
|
|
If you are planning to have some checks executed by a specific set of checker nodes
|
|
just pin them using the [authorities](#assign-services-to-cluster-nodes) attribute.
|
|
|
|
Example on the `central` node:
|
|
|
|
object Endpoint "central" {
|
|
host = "central.icinga.org"
|
|
port = 8888
|
|
}
|
|
|
|
object Endpoint "checker1" {
|
|
host = "checker1.icinga.org"
|
|
port = 8888
|
|
config_files_recursive = [ "/etc/icinga2/conf.d" ]
|
|
}
|
|
|
|
object Endpoint "checker2" {
|
|
host = "checker2.icinga.org"
|
|
port = 8888
|
|
config_files_recursive = [ "/etc/icinga2/conf.d" ]
|
|
}
|
|
|
|
object ClusterListener "central-cluster" {
|
|
ca_path = "/etc/icinga2/ca/ca.crt"
|
|
cert_path = "/etc/icinga2/ca/central.crt"
|
|
key_path = "/etc/icinga2/ca/central.key"
|
|
bind_port = 8888
|
|
peers = [ "checker1", "checker2" ]
|
|
}
|
|
|
|
Example on `checker1` node:
|
|
|
|
object Endpoint "central" {
|
|
host = "central.icinga.org"
|
|
port = 8888
|
|
}
|
|
|
|
object Endpoint "checker1" {
|
|
host = "checker1.icinga.org"
|
|
port = 8888
|
|
accept_config = [ "central" ]
|
|
}
|
|
|
|
object Endpoint "checker2" {
|
|
host = "checker2.icinga.org"
|
|
port = 8888
|
|
accept_config = [ "central" ]
|
|
}
|
|
|
|
object ClusterListener "checker1-cluster" {
|
|
ca_path = "/etc/icinga2/ca/ca.crt"
|
|
cert_path = "/etc/icinga2/ca/checker1.crt"
|
|
key_path = "/etc/icinga2/ca/checker1.key"
|
|
bind_port = 8888
|
|
}
|
|
|
|
|
|
#### <a id="cluster-scenarios-high-availability"></a> High Availability
|
|
|
|
Two nodes in a high availability setup require an [initial cluster sync](#initial-cluster-sync).
|
|
Furthermore the active master node should deploy the configuration to the
|
|
second node, if that does not already happen by your provisioning tool. It primarly
|
|
depends which features are enabled/used. It is still required that some failover
|
|
mechanism detects for example which instance will be the notification "master".
|
|
|
|
|
|
#### <a id="cluster-scenarios-multiple-hierachies"></a> Multiple Hierachies
|
|
|
|
Your central instance collects all check results for reporting and graphing and also
|
|
does some sort of additional notifications.
|
|
The customers got their own instances in their local DMZs. They are limited to read/write
|
|
only their services, but replicate all events back to the central instance.
|
|
Within each DMZ there are additional check instances also serving interfaces for local
|
|
departments. The customers instances will collect all results, but also send them back to
|
|
your central instance.
|
|
Additionally the customers instance on the second level in the middle prohibits you from
|
|
sending commands to the down below department nodes. You're only allowed to receive the
|
|
results, and a subset of each customers configuration too.
|
|
|
|
Your central instance will generate global reports, aggregate alert notifications and check
|
|
additional dependencies (for example, the customers internet uplink and bandwidth usage).
|
|
|
|
The customers instance will only check a subset of local services and delegate the rest
|
|
to each department. Even though it acts as configuration master with a central dashboard
|
|
for all departments managing their configuration tree which is then deployed to all
|
|
department instances. Furthermore the central NOC is able to see what's going on.
|
|
|
|
The instances in the departments will serve a local interface, and allow the administrators
|
|
to reschedule checks or acknowledge problems for their services.
|
|
|
|
|
|
|
|
### <a id="domains"></a> Domains
|
|
|
|
A [Service](#objecttype-service) object can be restricted using the `domains` attribute
|
|
array specifying endpoint privileges.
|
|
A Domain object specifices the ACLs applied for each [Endpoint](#objecttype-endpoint).
|
|
|
|
The following example assigns the domain `dmz-db` to the service `dmz-oracledb`. Endpoint
|
|
`icinga-node-dmz-1` does not allow any object modification (no commands, check results) and only
|
|
relays local messages to the remote node(s). The endpoint `icinga-node-dmz-2` processes all
|
|
messages read and write (accept check results, commands and also relay messages to remote
|
|
nodes).
|
|
|
|
That way the service `dmz-oracledb` on endpoint `icinga-node-dmz-1` will not be modified
|
|
by any cluster event message, and could be checked by the local authority too presenting
|
|
a different state history. `icinga-node-dmz-2` still receives all cluster message updates
|
|
from the `icinga-node-dmz-1` endpoint.
|
|
|
|
object Host "dmz-host1" {
|
|
import "generic-host"
|
|
}
|
|
|
|
object Service "dmz-oracledb" {
|
|
import "generic-service"
|
|
|
|
host_name = "dmz-host1"
|
|
|
|
domains = [ "dmz-db" ]
|
|
authorities = [ "icinga-node-dmz-1", "icinga-node-dmz-2"]
|
|
}
|
|
|
|
object Domain "dmz-db" {
|
|
acl = {
|
|
"icinga-node-dmz-1" = DomainPrivReadOnly
|
|
"icinga-node-dmz-2" = DomainPrivReadWrite
|
|
}
|
|
}
|
|
|