mirror of https://github.com/Icinga/icinga2.git
Remove unused files.
This commit is contained in:
Gunnar Beutner
parent
81a5ac44ac
commit
0c67414701
|
|
@ -1,131 +0,0 @@
|
|||
Purpose
|
||||
=======
|
||||
|
||||
Documentation on the compatibility and changes introduced with Icinga 2.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Unlike Icinga 1.x, all used components (not only those for
|
||||
compatibility) run asynchronous and use queues, if required. That way
|
||||
Icinga 2 does not get blocked by any event, action or execution.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> If you are upgrading from Icinga 1.x (or Nagios 3.x+) please note that
|
||||
> Icinga 2 introduces a new configuration format.
|
||||
|
||||
Details on the configuration can be found in chapter
|
||||
[Configuration](:icinga2-config.html)
|
||||
|
||||
Icinga 2 ships a config conversion script which will help you migrating
|
||||
the existing configuration into the new format. Please look into the
|
||||
*tools/configconvert* directory and follow the *README* instructions.
|
||||
|
||||
> **Tip**
|
||||
>
|
||||
> If you kept planning to clean up your existing configuration, it may
|
||||
> be a good shot to start fresh with a new configuration strategy based
|
||||
> on the Icinga 2 configuration logic.
|
||||
|
||||
Check Plugins
|
||||
=============
|
||||
|
||||
All native check plugins can be used with Icinga 2. The configuration of
|
||||
check commands is changed due to the new configuration format.
|
||||
|
||||
Classic status and log files
|
||||
============================
|
||||
|
||||
Icinga 2 will write status.dat and objects.cache in a given interval
|
||||
like known from Icinga 1.x - including the logs and their archives in
|
||||
the old format and naming syntax. That way you can point any existing
|
||||
Classic UI installation to the new locations (or any other addon/plugin
|
||||
using them).
|
||||
|
||||
External Commands
|
||||
=================
|
||||
|
||||
Like known from Icinga 1.x, Icinga 2 also provides an external command
|
||||
pipe allowing your scripts and guis to send commands to the core
|
||||
triggering various actions.
|
||||
|
||||
Some commands are not supported though as their triggered functionality
|
||||
is not available in Icinga 2 anymore.
|
||||
|
||||
For a detailed list, please check:
|
||||
[https://wiki.icinga.org/display/icinga2/External+Commands](https://wiki.icinga.org/display/icinga2/External+Commands)
|
||||
|
||||
Performance Data
|
||||
================
|
||||
|
||||
The Icinga 1.x Plugin API defines the performance data format. Icinga 2
|
||||
parses the check output accordingly and writes performance data files
|
||||
based on template macros. File rotation interval can be defined as well.
|
||||
|
||||
Unlike Icinga 1.x you can define multiple performance data writers for
|
||||
all your graphing addons such as PNP, inGraph or graphite.
|
||||
|
||||
IDO DB
|
||||
======
|
||||
|
||||
Icinga 1.x uses an addon called *IDOUtils* to store core configuration,
|
||||
status and historical information in a database schema. Icinga Web and
|
||||
Reporting are using that database as their chosen backend.
|
||||
|
||||
Icinga 2 is compatible to the IDO db schema but the the underlaying
|
||||
design of inserting, updating and deleting data is different -
|
||||
asynchronous queueing, database transactions and optimized queries for
|
||||
performance.
|
||||
|
||||
Furthermore there is no seperated daemon to receive the data through a
|
||||
socket. Instead the IDO component queues the data and writes directly
|
||||
into the database using the native database driver library (e.g.
|
||||
libmysqlclient). Unlike Icinga 1.x libdbi as db abstraction layer is not
|
||||
used anymore.
|
||||
|
||||
Livestatus
|
||||
==========
|
||||
|
||||
Icinga 2 supports the livestatus api while using Icinga 1.x an addon
|
||||
named *mk\_livestatus* was required.
|
||||
|
||||
Next to the GET functionality for retrieving configuration, status and
|
||||
historical data, Icinga 2 livestatus also supports the COMMANDS
|
||||
functionality.
|
||||
|
||||
> **Tip**
|
||||
>
|
||||
> Icinga 2 supports tcp sockets natively while the Icinga 1.x addon only
|
||||
> provides unix socket support.
|
||||
|
||||
Checkresult Reaper
|
||||
==================
|
||||
|
||||
Unlike Icinga 1.x Icinga 2 is a multithreaded application and processes
|
||||
check results in memory. The old checkresult reaper reading files from
|
||||
disk again is obviously not required anymore for native checks.
|
||||
|
||||
Some popular addons have been injecting their checkresults into the
|
||||
Icinga 1.x checkresult spool directory bypassing the external command
|
||||
pipe and PROCESS\_SERVICE\_CHECK\_RESULT mainly for performance reasons.
|
||||
|
||||
In order to support that functionality as well, Icinga 2 got its
|
||||
optional checkresult reaper.
|
||||
|
||||
Changes
|
||||
=======
|
||||
|
||||
This is a collection of known changes in behaviour, configuration and
|
||||
outputs.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> May be incomplete, and requires updates in the future.
|
||||
|
||||
TODO
|
||||
|
||||
/\* vim: set syntax=asciidoc filetype=asciidoc: \*/
|
||||
|
|
@ -1,419 +0,0 @@
|
|||
Configuration Syntax
|
||||
====================
|
||||
|
||||
Object Definition
|
||||
-----------------
|
||||
|
||||
Icinga 2 features an object-based configuration format. In order to
|
||||
define objects the *object* keyword is used:
|
||||
|
||||
object Host "host1.example.org" {
|
||||
display_name = "host1",
|
||||
|
||||
check_interval = 30,
|
||||
retry_interval = 15,
|
||||
|
||||
macros = {
|
||||
address = "192.168.0.1"
|
||||
}
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The Icinga 2 configuration format is agnostic to whitespaces and
|
||||
> new-lines.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Colons (:) are not permitted in object names.
|
||||
|
||||
Each object is uniquely identified by its type (*Host*) and name
|
||||
(*host1.example.org*). Objects can contain a comma-separated list of
|
||||
property declarations. The following data types are available for
|
||||
property values:
|
||||
|
||||
### Numeric Literals
|
||||
|
||||
A floating-point number.
|
||||
|
||||
Example:
|
||||
|
||||
-27.3
|
||||
|
||||
### Duration Literal
|
||||
|
||||
Similar to floating-point numbers except for that fact that they support
|
||||
suffixes to help with specifying time durations.
|
||||
|
||||
Example:
|
||||
|
||||
2.5m
|
||||
|
||||
Supported suffixes include ms (milliseconds), s (seconds), m (minutes)
|
||||
and h (hours).
|
||||
|
||||
### String Literals
|
||||
|
||||
A string.
|
||||
|
||||
Example:
|
||||
|
||||
"Hello World!"
|
||||
|
||||
Certain characters need to be escaped. The following escape sequences
|
||||
are supported:
|
||||
|
||||
------------------------------------ ------------------------------------
|
||||
Character Escape sequence
|
||||
" \\"
|
||||
\<TAB\> \\t
|
||||
\<CARRIAGE-RETURN\> \\r
|
||||
\<LINE-FEED\> \\n
|
||||
\<BEL\> \\b
|
||||
\<FORM-FEED\> \\f
|
||||
------------------------------------ ------------------------------------
|
||||
|
||||
In addition to these pre-defined escape sequences you can specify
|
||||
arbitrary ASCII characters using the backslash character (\\) followed
|
||||
by an ASCII character in octal encoding.
|
||||
|
||||
### Multiline String Literals
|
||||
|
||||
Strings spanning multiple lines can be specified by enclosing them in
|
||||
{{{ and }}}.
|
||||
|
||||
Example.
|
||||
|
||||
{{{This
|
||||
is
|
||||
a multi-line
|
||||
string.}}}
|
||||
|
||||
### Boolean Literals
|
||||
|
||||
The keywords *true* and *false* are equivalent to 1 and 0 respectively.
|
||||
|
||||
### Null Value
|
||||
|
||||
The *null* keyword can be used to specify an empty value.
|
||||
|
||||
### Dictionary
|
||||
|
||||
An unordered list of key-value pairs. Keys must be unique and are
|
||||
compared in a case-insensitive manner.
|
||||
|
||||
Individual key-value pairs must be separated from each other with a
|
||||
comma. The comma after the last key-value pair is optional.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
address = "192.168.0.1",
|
||||
port = 443
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Identifiers may not contain certain characters (e.g. space) or start
|
||||
> with certain characters (e.g. digits). If you want to use a dictionary
|
||||
> key that is not a valid identifier you can put the key in double
|
||||
> quotes.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Setting a dictionary key to null causes the key to be removed from the
|
||||
> dictionary.
|
||||
|
||||
### Array
|
||||
|
||||
An ordered list of values.
|
||||
|
||||
Individual array elements must be separated from each other with a
|
||||
comma. The comma after the last element is optional.
|
||||
|
||||
Example:
|
||||
|
||||
[
|
||||
"hello",
|
||||
"world",
|
||||
42,
|
||||
[ "a", "nested", "array" ]
|
||||
]
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> An array may simultaneously contain values of different types, e.g.
|
||||
> strings and numbers.
|
||||
|
||||
Operators
|
||||
---------
|
||||
|
||||
In addition to the *=* operator shown above a number of other operators
|
||||
to manipulate configuration objects are supported. Here’s a list of all
|
||||
available operators:
|
||||
|
||||
### Operator *=*
|
||||
|
||||
Sets a dictionary element to the specified value.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = 5,
|
||||
a = 7
|
||||
}
|
||||
|
||||
In this example a has the value 7 after both instructions are executed.
|
||||
|
||||
### Operator *+=*
|
||||
|
||||
Modifies a dictionary or array by adding new elements to it.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = [ "hello" ],
|
||||
a += [ "world" ]
|
||||
}
|
||||
|
||||
In this example a contains both *"hello"* and *"world"*. This currently
|
||||
only works for dictionaries and arrays. Support for numbers might be
|
||||
added later on.
|
||||
|
||||
### Operator *-=*
|
||||
|
||||
Removes elements from a dictionary.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = { "hello", "world" },
|
||||
a -= { "world" }
|
||||
}
|
||||
|
||||
In this example a contains *"hello"*. Trying to remove an item that does
|
||||
not exist is not an error. Not implemented yet.
|
||||
|
||||
### Operator *\*=*
|
||||
|
||||
Multiplies an existing dictionary element with the specified number. If
|
||||
the dictionary element does not already exist 0 is used as its value.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = 60,
|
||||
a *= 5
|
||||
}
|
||||
|
||||
In this example a is 300. This only works for numbers. Not implemented
|
||||
yet.
|
||||
|
||||
### Operator */=*
|
||||
|
||||
Divides an existing dictionary element by the specified number. If the
|
||||
dictionary element does not already exist 0 is used as its value.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = 300,
|
||||
a /= 5
|
||||
}
|
||||
|
||||
In this example a is 60. This only works for numbers. Not implemented
|
||||
yet.
|
||||
|
||||
Attribute Shortcuts
|
||||
-------------------
|
||||
|
||||
### Indexer Shortcut
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
hello["key"] = "world"
|
||||
}
|
||||
|
||||
This is equivalent to writing:
|
||||
|
||||
{
|
||||
hello += {
|
||||
key = "world"
|
||||
}
|
||||
}
|
||||
|
||||
Specifiers
|
||||
----------
|
||||
|
||||
Objects can have specifiers that have special meaning. The following
|
||||
specifiers can be used (prefacing the *object* keyword):
|
||||
|
||||
### Specifier *abstract*
|
||||
|
||||
This specifier identifies the object as a template which can be used by
|
||||
other object definitions. The object will not be instantiated on its
|
||||
own.
|
||||
|
||||
Instead of using the *abstract* specifier you can use the *template*
|
||||
keyword which is a shorthand for writing *abstract object*:
|
||||
|
||||
template Service "http" {
|
||||
...
|
||||
}
|
||||
|
||||
### Specifier *local*
|
||||
|
||||
This specifier disables replication for this object. The object will not
|
||||
be sent to remote Icinga instances.
|
||||
|
||||
Inheritance
|
||||
-----------
|
||||
|
||||
Objects can inherit attributes from one or more other objects.
|
||||
|
||||
Example:
|
||||
|
||||
template Host "default-host" {
|
||||
check_interval = 30,
|
||||
|
||||
macros = {
|
||||
color = "red"
|
||||
}
|
||||
}
|
||||
|
||||
template Host "test-host" inherits "default-host" {
|
||||
macros += {
|
||||
color = "blue"
|
||||
}
|
||||
}
|
||||
|
||||
object Host "localhost" inherits "test-host" {
|
||||
macros += {
|
||||
address = "127.0.0.1",
|
||||
address6 = "::1"
|
||||
}
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The *"default-host"* and *"test-host"* objects are marked as templates
|
||||
> using the *abstract* keyword. Parent objects do not necessarily have
|
||||
> to be *abstract* though in general they are.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The += operator is used to insert additional properties into the
|
||||
> macros dictionary. The final dictionary contains all 3 macros and the
|
||||
> property *color* has the value *"blue"*.
|
||||
|
||||
Parent objects are resolved in the order they’re specified using the
|
||||
*inherits* keyword.
|
||||
|
||||
Comments
|
||||
--------
|
||||
|
||||
The Icinga 2 configuration format supports C/C++-style comments.
|
||||
|
||||
Example:
|
||||
|
||||
/*
|
||||
This is a comment.
|
||||
*/
|
||||
object Host "localhost" {
|
||||
check_interval = 30, // this is also a comment.
|
||||
retry_interval = 15
|
||||
}
|
||||
|
||||
Includes
|
||||
--------
|
||||
|
||||
Other configuration files can be included using the *include* directive.
|
||||
Paths must be relative to the configuration file that contains the
|
||||
*include* directive.
|
||||
|
||||
Example:
|
||||
|
||||
include "some/other/file.conf"
|
||||
include "conf.d/*.conf"
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Wildcard includes are not recursive.
|
||||
|
||||
Icinga also supports include search paths similar to how they work in a
|
||||
C/C++ compiler:
|
||||
|
||||
include <itl/itl.conf>
|
||||
|
||||
Note the use of angle brackets instead of double quotes. This causes the
|
||||
config compiler to search the include search paths for the specified
|
||||
file. By default \$PREFIX/icinga2 is included in the list of search
|
||||
paths.
|
||||
|
||||
Wildcards are not permitted when using angle brackets.
|
||||
|
||||
Library directive
|
||||
-----------------
|
||||
|
||||
The *library* directive can be used to manually load additional
|
||||
libraries. Upon loading these libraries may provide additional types or
|
||||
methods.
|
||||
|
||||
Example:
|
||||
|
||||
library "snmphelper"
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The *icinga* library is automatically loaded at startup.
|
||||
|
||||
Type Definition
|
||||
---------------
|
||||
|
||||
By default Icinga has no way of semantically verifying its configuration
|
||||
objects. This is where type definitions come in. Using type definitions
|
||||
you can specify which attributes are allowed in an object definition.
|
||||
|
||||
Example:
|
||||
|
||||
type Pizza {
|
||||
%require "radius",
|
||||
%attribute number "radius",
|
||||
|
||||
%attribute dictionary "ingredients" {
|
||||
%validator "ValidateIngredients",
|
||||
|
||||
%attribute string "*",
|
||||
|
||||
%attribute dictionary "*" {
|
||||
%attribute number "quantity",
|
||||
%attribute string "name"
|
||||
}
|
||||
},
|
||||
|
||||
%attribute any "custom::*"
|
||||
}
|
||||
|
||||
The Pizza definition provides the following validation rules:
|
||||
|
||||
- Pizza objects must contain an attribute *radius* which has to be a
|
||||
number.
|
||||
|
||||
- Pizza objects may contain an attribute *ingredients* which has to be
|
||||
a dictionary.
|
||||
|
||||
- Elements in the ingredients dictionary can be either a string or a
|
||||
dictionary.
|
||||
|
||||
- If they’re a dictionary they may contain attributes *quantity* (of
|
||||
type number) and *name* (of type string).
|
||||
|
||||
- The script function *ValidateIngredients* is run to perform further
|
||||
validation of the ingredients dictionary.
|
||||
|
||||
- Pizza objects may contain attribute matching the pattern
|
||||
*custom::\** of any type.
|
||||
|
||||
Valid types for type rules include: \* any \* number \* string \* scalar
|
||||
(an alias for string) \* dictionary
|
||||
|
|
@ -1,994 +0,0 @@
|
|||
Configuration Format
|
||||
====================
|
||||
|
||||
Object Definition
|
||||
-----------------
|
||||
|
||||
Icinga 2 features an object-based configuration format. In order to
|
||||
define objects the "object" keyword is used:
|
||||
|
||||
object Host "host1.example.org" {
|
||||
alias = "host1",
|
||||
|
||||
check_interval = 30,
|
||||
retry_interval = 15,
|
||||
|
||||
macros = {
|
||||
address = "192.168.0.1"
|
||||
}
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The Icinga 2 configuration format is agnostic to whitespaces and
|
||||
> new-lines.
|
||||
|
||||
Each object is uniquely identified by its type ("Host") and name
|
||||
("host1.example.org"). Objects can contain a comma-separated list of
|
||||
property declarations. The following data types are available for
|
||||
property values:
|
||||
|
||||
### Numeric Literals
|
||||
|
||||
A floating-point number.
|
||||
|
||||
Example:
|
||||
|
||||
-27.3
|
||||
|
||||
### Duration Literal
|
||||
|
||||
Similar to floating-point numbers except for that fact that they support
|
||||
suffixes to help with specifying time durations.
|
||||
|
||||
Example:
|
||||
|
||||
2.5m
|
||||
|
||||
Supported suffixes include ms (milliseconds), s (seconds), m (minutes)
|
||||
and h (hours).
|
||||
|
||||
### String Literals
|
||||
|
||||
A string. No escape characters are supported at present though this will
|
||||
likely change.
|
||||
|
||||
Example:
|
||||
|
||||
"Hello World!"
|
||||
|
||||
### Expression List
|
||||
|
||||
A list of expressions that when executed has a dictionary as a result.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
address = "192.168.0.1",
|
||||
port = 443
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Identifiers may not contain certain characters (e.g. space) or start
|
||||
> with certain characters (e.g. digits). If you want to use a dictionary
|
||||
> key that is not a valid identifier you can put the key in double
|
||||
> quotes.
|
||||
|
||||
Operators
|
||||
---------
|
||||
|
||||
In addition to the "=" operator shown above a number of other operators
|
||||
to manipulate configuration objects are supported. Here’s a list of all
|
||||
available operators:
|
||||
|
||||
### Operator "="
|
||||
|
||||
Sets a dictionary element to the specified value.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = 5,
|
||||
a = 7
|
||||
}
|
||||
|
||||
In this example a has the value 7 after both instructions are executed.
|
||||
|
||||
### Operator "+="
|
||||
|
||||
Modifies a dictionary by adding new elements to it.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = { "hello" },
|
||||
a += { "world" }
|
||||
}
|
||||
|
||||
In this example a contains both "hello" and "world". This currently only
|
||||
works for expression lists. Support for numbers might be added later on.
|
||||
|
||||
### Operator "-="
|
||||
|
||||
Removes elements from a dictionary.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = { "hello", "world" },
|
||||
a -= { "world" }
|
||||
}
|
||||
|
||||
In this example a contains "hello". Trying to remove an item that does
|
||||
not exist is not an error. Not implemented yet.
|
||||
|
||||
### Operator "\*="
|
||||
|
||||
Multiplies an existing dictionary element with the specified number. If
|
||||
the dictionary element does not already exist 0 is used as its value.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = 60,
|
||||
a *= 5
|
||||
}
|
||||
|
||||
In this example a is 300. This only works for numbers. Not implemented
|
||||
yet.
|
||||
|
||||
### Operator "/="
|
||||
|
||||
Divides an existing dictionary element by the specified number. If the
|
||||
dictionary element does not already exist 0 is used as its value.
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
a = 300,
|
||||
a /= 5
|
||||
}
|
||||
|
||||
In this example a is 60. This only works for numbers. Not implemented
|
||||
yet.
|
||||
|
||||
Attribute Shortcuts
|
||||
-------------------
|
||||
|
||||
### Value Shortcut
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
"hello", "world"
|
||||
}
|
||||
|
||||
This is equivalent to writing:
|
||||
|
||||
{
|
||||
_00000001 = "hello", _00000002 = "world"
|
||||
}
|
||||
|
||||
The item’s keys are monotonically increasing and the config compiler
|
||||
takes care of ensuring that all keys are unique (even when adding items
|
||||
to an existing attribute using +=).
|
||||
|
||||
### Indexer Shortcut
|
||||
|
||||
Example:
|
||||
|
||||
{
|
||||
hello["key"] = "world"
|
||||
}
|
||||
|
||||
This is equivalent to writing:
|
||||
|
||||
{
|
||||
hello += {
|
||||
key = "world"
|
||||
}
|
||||
}
|
||||
|
||||
Specifiers
|
||||
----------
|
||||
|
||||
Objects can have specifiers that have special meaning. The following
|
||||
specifiers can be used (before the "object" keyword):
|
||||
|
||||
### Specifier "abstract"
|
||||
|
||||
This specifier identifies the object as a template which can be used by
|
||||
other object definitions. The object will not be instantiated on its
|
||||
own.
|
||||
|
||||
Instead of using the "abstract" specifier you can use the "template"
|
||||
keyword which is a shorthand for writing "abstract object":
|
||||
|
||||
template Service "http" {
|
||||
...
|
||||
}
|
||||
|
||||
### Specifier "local"
|
||||
|
||||
This specifier disables replication for this object. The object will not
|
||||
be sent to remote Icinga instances.
|
||||
|
||||
Inheritance
|
||||
-----------
|
||||
|
||||
Objects can inherit attributes from one or more other objects.
|
||||
|
||||
Example:
|
||||
|
||||
abstract object Host "default-host" {
|
||||
check_interval = 30,
|
||||
|
||||
macros = {
|
||||
color = "red"
|
||||
}
|
||||
}
|
||||
|
||||
abstract object Host "test-host" inherits "default-host" {
|
||||
macros += {
|
||||
color = "blue"
|
||||
}
|
||||
}
|
||||
|
||||
object Host "localhost" inherits "test-host" {
|
||||
macros += {
|
||||
address = "127.0.0.1",
|
||||
address6 = "::1"
|
||||
}
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The "default-host" and "test-host" objects are marked as templates
|
||||
> using the "abstract" keyword. Parent objects do not necessarily have
|
||||
> to be "abstract" though in general they are.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The += operator is used to insert additional properties into the
|
||||
> macros dictionary. The final dictionary contains all 3 macros and the
|
||||
> property "color" has the value "blue".
|
||||
|
||||
Parent objects are resolved in the order they’re specified using the
|
||||
"inherits" keyword. Parent objects must already be defined by the time
|
||||
they’re used in an object definition.
|
||||
|
||||
Comments
|
||||
--------
|
||||
|
||||
The Icinga 2 configuration format supports C/C++-style comments.
|
||||
|
||||
Example:
|
||||
|
||||
/*
|
||||
This is a comment.
|
||||
*/
|
||||
object Host "localhost" {
|
||||
check_interval = 30, // this is also a comment.
|
||||
retry_interval = 15
|
||||
}
|
||||
|
||||
Includes
|
||||
--------
|
||||
|
||||
Other configuration files can be included using the "\#include"
|
||||
directive. Paths must be relative to the configuration file that
|
||||
contains the "\#include" keyword:
|
||||
|
||||
Example:
|
||||
|
||||
#include "some/other/file.conf"
|
||||
#include "conf.d/*.conf"
|
||||
|
||||
Icinga also supports include search paths similar to how they work in a
|
||||
C/C++ compiler:
|
||||
|
||||
#include <itl/itl.conf>
|
||||
|
||||
Note the use of angle brackets instead of double quotes. This causes the
|
||||
config compiler to search the include search paths for the specified
|
||||
file. By default \$PREFIX/icinga2 is included in the list of search
|
||||
paths.
|
||||
|
||||
Wildcards are not permitted when using angle brackets.
|
||||
|
||||
Library directive
|
||||
-----------------
|
||||
|
||||
The "\#library" directive can be used to manually load additional
|
||||
libraries. Upon loading these libraries may provide additional classes
|
||||
or methods.
|
||||
|
||||
Example:
|
||||
|
||||
#library "snmphelper"
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The "icinga" library is automatically loaded by Icinga.
|
||||
|
||||
Type Definition
|
||||
---------------
|
||||
|
||||
By default Icinga has no way of semantically verifying its configuration
|
||||
objects. This is where type definitions come in. Using type definitions
|
||||
you can specify which attributes are allowed in an object definition.
|
||||
|
||||
Example:
|
||||
|
||||
type Pizza {
|
||||
%require "radius",
|
||||
%attribute number "radius",
|
||||
|
||||
%attribute dictionary "ingredients" {
|
||||
%validator "ValidateIngredients",
|
||||
|
||||
%attribute string "*",
|
||||
|
||||
%attribute dictionary "*" {
|
||||
%attribute number "quantity",
|
||||
%attribute string "name"
|
||||
}
|
||||
},
|
||||
|
||||
%attribute any "custom::*"
|
||||
}
|
||||
|
||||
The Pizza definition provides the following validation rules:
|
||||
|
||||
- Pizza objects must contain an attribute "radius" which has to be a
|
||||
number.
|
||||
|
||||
- Pizza objects may contain an attribute "ingredients" which has to be
|
||||
a dictionary.
|
||||
|
||||
- Elements in the ingredients dictionary can be either a string or a
|
||||
dictionary.
|
||||
|
||||
- If they’re a dictionary they may contain attributes "quantity" (of
|
||||
type number) and "name" (of type string).
|
||||
|
||||
- The script function "ValidateIngredients" is run to perform further
|
||||
validation of the ingredients dictionary.
|
||||
|
||||
- Pizza objects may contain attribute matching the pattern
|
||||
"custom::\*" of any type.
|
||||
|
||||
Valid types for type rules include: \* any \* number \* string \* scalar
|
||||
(an alias for string) \* dictionary
|
||||
|
||||
Configuration Objects
|
||||
=====================
|
||||
|
||||
Type: IcingaApplication
|
||||
-----------------------
|
||||
|
||||
The "IcingaApplication" type is used to specify global configuration
|
||||
parameters for Icinga. There must be exactly one application object in
|
||||
each Icinga 2 configuration. The object must have the "local" specifier.
|
||||
|
||||
Example:
|
||||
|
||||
local object IcingaApplication "icinga" {
|
||||
cert_path = "my-cert.pem",
|
||||
ca_path = "ca.crt",
|
||||
|
||||
node = "192.168.0.1",
|
||||
service = 7777,
|
||||
|
||||
pid_path = "/var/run/icinga2.pid",
|
||||
state_path = "/var/lib/icinga2/icinga2.state",
|
||||
|
||||
macros = {
|
||||
plugindir = "/usr/local/icinga/libexec"
|
||||
}
|
||||
}
|
||||
|
||||
### Attribute: cert\_path
|
||||
|
||||
This is used to specify the SSL client certificate Icinga 2 will use
|
||||
when connecting to other Icinga 2 instances. This property is optional
|
||||
when you’re setting up a non-networked Icinga 2 instance.
|
||||
|
||||
### Attribute: ca\_path
|
||||
|
||||
This is the public CA certificate that is used to verify connections
|
||||
from other Icinga 2 instances. This property is optional when you’re
|
||||
setting up a non-networked Icinga 2 instance.
|
||||
|
||||
### Attribute: node
|
||||
|
||||
The externally visible IP address that is used by other Icinga 2
|
||||
instances to connect to this instance. This property is optional when
|
||||
you’re setting up a non-networked Icinga 2 instance.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Icinga does not bind to this IP address.
|
||||
|
||||
### Attribute: service
|
||||
|
||||
The port this Icinga 2 instance should listen on. This property is
|
||||
optional when you’re setting up a non-networked Icinga 2 instance.
|
||||
|
||||
### Attribute: pid\_path
|
||||
|
||||
Optional. The path to the PID file. Defaults to "icinga.pid" in the
|
||||
current working directory.
|
||||
|
||||
### Attribute: state\_path
|
||||
|
||||
Optional. The path of the state file. This is the file Icinga 2 uses to
|
||||
persist objects between program runs. Defaults to "icinga2.state" in the
|
||||
current working directory.
|
||||
|
||||
### Attribute: macros
|
||||
|
||||
Optional. Global macros that are used for service checks and
|
||||
notifications.
|
||||
|
||||
Type: Component
|
||||
---------------
|
||||
|
||||
Icinga 2 uses a number of components to implement its feature-set. The
|
||||
"Component" configuration object is used to load these components and
|
||||
specify additional parameters for them. "Component" objects must have
|
||||
the "local" specifier. The typical components to be loaded in the
|
||||
default configuration would be "checker", "delegation" and more.
|
||||
|
||||
Example "compat":
|
||||
|
||||
local object Component "compat" {
|
||||
status_path = "/var/cache/icinga2/status.dat",
|
||||
objects_path = "/var/cache/icinga2/objects.cache",
|
||||
}
|
||||
|
||||
### Attribute: status\_path
|
||||
|
||||
Specifies where Icinga 2 Compat component will put the status.dat file,
|
||||
which can be read by Icinga 1.x Classic UI and other addons. If not set,
|
||||
it defaults to the localstatedir location.
|
||||
|
||||
### Attribute: objects\_path
|
||||
|
||||
Specifies where Icinga 2 Compat component will put the objects.cache
|
||||
file, which can be read by Icinga 1.x Classic UI and other addons. If
|
||||
not set, it defaults to the localstatedir location.
|
||||
|
||||
Type: ConsoleLogger
|
||||
-------------------
|
||||
|
||||
Specifies Icinga 2 logging to the console. Objects of this type must
|
||||
have the "local" specifier.
|
||||
|
||||
Example:
|
||||
|
||||
local object ConsoleLogger "my-debug-console" {
|
||||
severity = "debug"
|
||||
}
|
||||
|
||||
### Attribute: severity
|
||||
|
||||
The minimum severity for this log. Can be "debug", "information",
|
||||
"warning" or "critical". Defaults to "information".
|
||||
|
||||
Type: FileLogger
|
||||
----------------
|
||||
|
||||
Specifies Icinga 2 logging to a file. Objects of this type must have the
|
||||
"local" specifier.
|
||||
|
||||
Example:
|
||||
|
||||
local object FileLogger "my-debug-file" {
|
||||
severity = "debug",
|
||||
path = "/var/log/icinga2/icinga2-debug.log"
|
||||
}
|
||||
|
||||
### Attribute: path
|
||||
|
||||
The log path.
|
||||
|
||||
### Attribute: severity
|
||||
|
||||
The minimum severity for this log. Can be "debug", "information",
|
||||
"warning" or "critical". Defaults to "information".
|
||||
|
||||
Type: SyslogLogger
|
||||
------------------
|
||||
|
||||
Specifies Icinga 2 logging to syslog. Objects of this type must have the
|
||||
"local" specifier.
|
||||
|
||||
Example:
|
||||
|
||||
local object SyslogLogger "my-crit-syslog" {
|
||||
severity = "critical"
|
||||
}
|
||||
|
||||
### Attribute: severity
|
||||
|
||||
The minimum severity for this log. Can be "debug", "information",
|
||||
"warning" or "critical". Defaults to "information".
|
||||
|
||||
Type: Endpoint
|
||||
--------------
|
||||
|
||||
Endpoint objects are used to specify connection information for remote
|
||||
Icinga 2 instances. Objects of this type should not be local:
|
||||
|
||||
object Endpoint "icinga-c2" {
|
||||
node = "192.168.5.46",
|
||||
service = 7777,
|
||||
}
|
||||
|
||||
### Attribute: node
|
||||
|
||||
The hostname/IP address of the remote Icinga 2 instance.
|
||||
|
||||
### Attribute: service
|
||||
|
||||
The service name/port of the remote Icinga 2 instance.
|
||||
|
||||
Type: CheckCommand
|
||||
------------------
|
||||
|
||||
A check command definition. Additional default command macros can be
|
||||
defined here.
|
||||
|
||||
Example:
|
||||
|
||||
object CheckCommand "check_snmp" inherits "plugin-check-command" {
|
||||
command = "$plugindir$/check_snmp -H $address$ -C $community$ -o $oid$",
|
||||
|
||||
macros = {2yy
|
||||
plugindir = "/usr/lib/nagios/plugins",
|
||||
address = "127.0.0.1",
|
||||
community = "public",
|
||||
}
|
||||
}
|
||||
|
||||
Type: NotificationCommand
|
||||
-------------------------
|
||||
|
||||
A notification command definition.
|
||||
|
||||
Example:
|
||||
|
||||
object NotificationCommand "mail-service-notification" inherits "plugin-notification-command" {
|
||||
command = "/usr/bin/printf \"%b\" \"***** Icinga *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info: $SERVICEOUTPUT$\n\nComment: [$NOTIFICATIONAUTHORNAME$] $NOTIFICATIONCOMMENT$\n\n\" | /usr/bin/mail -s \"$NOTIFICATIONTYPE$ - $HOSTNAME$ - $SERVICEDESC$ - $SERVICESTATE$\" $CONTACTEMAIL$",
|
||||
}
|
||||
|
||||
Type: EventCommand
|
||||
|
||||
An event command definition.
|
||||
|
||||
NOTE: Similar to Icinga 1.x event handlers.
|
||||
|
||||
Example:
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
object EventCommand "restart-httpd-event" inherits "plugin-event-command" {
|
||||
command = "/usr/local/icinga/libexec/restart-httpd.sh",
|
||||
}
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
|
||||
Type: Service
|
||||
|
||||
Service objects describe network services and how they should be checked
|
||||
by Icinga 2.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Better create a service template and use that reference on the host
|
||||
> definition as shown below.
|
||||
|
||||
Example:
|
||||
|
||||
object Service "localhost-uptime" {
|
||||
host_name = "localhost",
|
||||
|
||||
alias = "localhost Uptime",
|
||||
|
||||
methods = {
|
||||
check = "PluginCheck"
|
||||
},
|
||||
|
||||
check_command = "check_snmp",
|
||||
|
||||
macros = {
|
||||
plugindir = "/usr/lib/nagios/plugins",
|
||||
address = "127.0.0.1",
|
||||
community = "public",
|
||||
oid = "DISMAN-EVENT-MIB::sysUpTimeInstance"
|
||||
}
|
||||
|
||||
check_interval = 60s,
|
||||
retry_interval = 15s,
|
||||
|
||||
servicegroups = { "all-services", "snmp" },
|
||||
|
||||
checkers = { "*" },
|
||||
}
|
||||
|
||||
### Attribute: host\_name
|
||||
|
||||
The host this service belongs to. There must be a "Host" object with
|
||||
that name.
|
||||
|
||||
### Attribute: alias
|
||||
|
||||
Optional. A short description of the service.
|
||||
|
||||
### Attribute: methods - check
|
||||
|
||||
The check type of the service. For now only external check plugins are
|
||||
supported ("PluginCheck").
|
||||
|
||||
### Attribute: check\_command
|
||||
|
||||
Optional when not using the "external plugin" check type. The check
|
||||
command. May contain macros.
|
||||
|
||||
### Attribute: check\_interval
|
||||
|
||||
Optional. The check interval (in seconds).
|
||||
|
||||
### Attribute: retry\_interval
|
||||
|
||||
Optional. The retry interval (in seconds). This is used when the service
|
||||
is in a soft state.
|
||||
|
||||
### Attribute: servicegroups
|
||||
|
||||
Optional. The service groups this service belongs to.
|
||||
|
||||
### Attribute: checkers
|
||||
|
||||
Optional. A list of remote endpoints that may check this service.
|
||||
Wildcards can be used here.
|
||||
|
||||
Type: ServiceGroup
|
||||
------------------
|
||||
|
||||
A group of services.
|
||||
|
||||
Example:
|
||||
|
||||
object ServiceGroup "snmp" {
|
||||
alias = "SNMP services",
|
||||
|
||||
custom = {
|
||||
notes_url = "http://www.example.org/",
|
||||
action_url = "http://www.example.org/",
|
||||
}
|
||||
}
|
||||
|
||||
### Attribute: alias
|
||||
|
||||
Optional. A short description of the service group.
|
||||
|
||||
### Attribute: notes\_url
|
||||
|
||||
Optional. Notes URL. Used by the CGIs.
|
||||
|
||||
### Attribute: action\_url
|
||||
|
||||
Optional. Action URL. Used by the CGIs.
|
||||
|
||||
Type: Host
|
||||
----------
|
||||
|
||||
A host. Unlike in Icinga 1.x hosts are not checkable objects in Icinga
|
||||
2.
|
||||
|
||||
Example:
|
||||
|
||||
object Host "localhost" {
|
||||
alias = "The best host there is",
|
||||
|
||||
hostgroups = [ "all-hosts" ],
|
||||
|
||||
hostcheck = "ping",
|
||||
dependencies = [ "router-ping" ]
|
||||
|
||||
services["ping"] = { templates = "ping" }
|
||||
services["http"] = {
|
||||
templates = "my-http",
|
||||
macros = {
|
||||
vhost = "test1.example.org",
|
||||
port = 81
|
||||
}
|
||||
}
|
||||
|
||||
check_interval = 60m,
|
||||
retry_interval = 15m,
|
||||
|
||||
servicegroups = [ "all-services" ],
|
||||
|
||||
checkers = { "*" },
|
||||
}
|
||||
|
||||
### Attribute: alias
|
||||
|
||||
Optional. A short description of the host.
|
||||
|
||||
### Attribute: hostgroups
|
||||
|
||||
Optional. A list of host groups this host belongs to.
|
||||
|
||||
### Attribute: hostcheck
|
||||
|
||||
Optional. A service that is used to determine whether the host is up or
|
||||
down.
|
||||
|
||||
### Attribute: hostdependencies
|
||||
|
||||
Optional. A list of hosts that are used to determine whether the host is
|
||||
unreachable.
|
||||
|
||||
### Attribute: servicedependencies
|
||||
|
||||
Optional. A list of services that are used to determine whether the host
|
||||
is unreachable.
|
||||
|
||||
### Attribute: services
|
||||
|
||||
Inline definition of services. Each service name is defined in square
|
||||
brackets and got its own dictionary with attribute properties, such as
|
||||
the template service being used. All other service-related properties
|
||||
are additively copied into the new service object.
|
||||
|
||||
The new service’s name is "hostname-service" - where "service" is the
|
||||
array key in the services array.
|
||||
|
||||
The priority for service properties is (from highest to lowest):
|
||||
|
||||
1. Properties specified in the dictionary of the inline service
|
||||
definition
|
||||
|
||||
2. Host properties
|
||||
|
||||
3. Properties inherited from the new service’s parent object
|
||||
|
||||
### Attribute: check\_interval
|
||||
|
||||
Optional. Copied into inline service definitions. The host itself does
|
||||
not have any checks.
|
||||
|
||||
### Attribute: retry\_interval
|
||||
|
||||
Optional. Copied into inline service definitions. The host itself does
|
||||
not have any checks.
|
||||
|
||||
### Attribute: servicegroups
|
||||
|
||||
Optional. Copied into inline service definitions. The host itself does
|
||||
not have any checks.
|
||||
|
||||
### Attribute: checkers
|
||||
|
||||
Optional. Copied into inline service definitions. The host itself does
|
||||
not have any checks.
|
||||
|
||||
Type: HostGroup
|
||||
---------------
|
||||
|
||||
A group of hosts.
|
||||
|
||||
Example
|
||||
|
||||
object HostGroup "my-hosts" {
|
||||
alias = "My hosts",
|
||||
|
||||
notes_url = "http://www.example.org/",
|
||||
action_url = "http://www.example.org/",
|
||||
}
|
||||
|
||||
### Attribute: alias
|
||||
|
||||
Optional. A short description of the host group.
|
||||
|
||||
### Attribute: notes\_url
|
||||
|
||||
Optional. Notes URL. Used by the CGIs.
|
||||
|
||||
### Attribute: action\_url
|
||||
|
||||
Optional. Action URL. Used by the CGIs.
|
||||
|
||||
Type: PerfdataWriter
|
||||
--------------------
|
||||
|
||||
Write check result performance data to a defined path using macro
|
||||
pattern.
|
||||
|
||||
Example
|
||||
|
||||
local object PerfdataWriter "pnp" {
|
||||
perfdata_path = "/var/spool/icinga2/perfdata/service-perfdata",
|
||||
format_template = "DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$",
|
||||
rotation_interval = 15s,
|
||||
}
|
||||
|
||||
### Attribute: perfdata\_path
|
||||
|
||||
Path to the service perfdata file.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Will be automatically rotated with timestamp suffix.
|
||||
|
||||
### Attribute: format\_template
|
||||
|
||||
Formatting of performance data output for graphing addons or other post
|
||||
processing.
|
||||
|
||||
### Attribute: rotation\_interval
|
||||
|
||||
Rotation interval for the file defined in *perfdata\_path*.
|
||||
|
||||
Type: IdoMySqlConnection
|
||||
------------------------
|
||||
|
||||
IDO DB schema compatible output into mysql database.
|
||||
|
||||
Example
|
||||
|
||||
library "ido_mysql"
|
||||
local object IdoMysqlDbConnection "mysql-ido" {
|
||||
host = "127.0.0.1",
|
||||
port = "3306",
|
||||
user = "icinga",
|
||||
password = "icinga",
|
||||
database = "icinga",
|
||||
table_prefix = "icinga_",
|
||||
instance_name = "icinga2",
|
||||
instance_description = "icinga2 dev instance"
|
||||
}
|
||||
|
||||
### Attribute: host
|
||||
|
||||
MySQL database host address. Default is *localhost*.
|
||||
|
||||
### Attribute: port
|
||||
|
||||
MySQL database port. Default is *3306*.
|
||||
|
||||
### Attribute: user
|
||||
|
||||
MySQL database user with read/write permission to the icinga database.
|
||||
Default is *icinga*.
|
||||
|
||||
### Attribute: password
|
||||
|
||||
MySQL database user’s password. Default is *icinga*.
|
||||
|
||||
### Attribute: database
|
||||
|
||||
MySQL database name. Default is *icinga*.
|
||||
|
||||
### Attribute: table\_prefix
|
||||
|
||||
MySQL database table prefix. Default is *icinga\_*.
|
||||
|
||||
### Attribute: instance\_name
|
||||
|
||||
Unique identifier for the local Icinga 2 instance.
|
||||
|
||||
### Attribute: instance\_description
|
||||
|
||||
Optional. Description for the Icinga 2 instance.
|
||||
|
||||
Type: LiveStatusComponent
|
||||
-------------------------
|
||||
|
||||
Livestatus api interface available as tcp or unix socket.
|
||||
|
||||
Example
|
||||
|
||||
library "livestatus"
|
||||
|
||||
local object LivestatusComponent "livestatus-tcp" {
|
||||
socket_type = "tcp",
|
||||
host = "127.0.0.1",
|
||||
port = "6558"
|
||||
}
|
||||
|
||||
local object LivestatusComponent "livestatus-unix" {
|
||||
socket_type = "unix",
|
||||
socket_path = "/var/run/icinga2/livestatus"
|
||||
}
|
||||
|
||||
### Attribute: socket\_type
|
||||
|
||||
*tcp* or *unix* socket. Default is *unix*.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> *unix* sockets are not supported on Windows.
|
||||
|
||||
### Attribute: host
|
||||
|
||||
Only valid when socket\_type="tcp". Host address to listen on for
|
||||
connections.
|
||||
|
||||
### Attribute: port
|
||||
|
||||
Only valid when socket\_type="tcp". Port to listen on for connections.
|
||||
|
||||
### Attribute: socket\_path
|
||||
|
||||
Only valid when socket\_type="unix". Local unix socket file. Not
|
||||
supported on Windows.
|
||||
|
||||
Configuration Examples
|
||||
======================
|
||||
|
||||
Non-networked minimal example
|
||||
-----------------------------
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Icinga 2 ITL provides itl/standalone.conf which loads all required
|
||||
> components, as well as itl/itl.conf includes many object templates
|
||||
> already for an easy start with Icinga 2.
|
||||
|
||||
local object IcingaApplication "icinga" {
|
||||
|
||||
}
|
||||
|
||||
local object Component "checker" {
|
||||
|
||||
}
|
||||
|
||||
local object Component "delegation" {
|
||||
|
||||
}
|
||||
|
||||
object CheckCommand "ping" {
|
||||
command = "$plugindir$/check_ping -H $address$ -w $wrta$,$wpl$% -c $crta$,$cpl$%",
|
||||
}
|
||||
|
||||
template Service "icinga-service" {
|
||||
methods = {
|
||||
check = "PluginCheck"
|
||||
},
|
||||
|
||||
macros = {
|
||||
plugindir = "/usr/lib/nagios/plugins"
|
||||
}
|
||||
}
|
||||
|
||||
template Service "ping-tmpl" inherits "icinga-service" {
|
||||
check_command = "ping",
|
||||
macros += {
|
||||
wrta = 50,
|
||||
wpl = 5,
|
||||
crta = 100,
|
||||
cpl = 10
|
||||
}
|
||||
}
|
||||
|
||||
object Host "localhost" {
|
||||
services["ping"] = { templates = "ping-tmpl" },
|
||||
|
||||
macros = {
|
||||
address = "127.0.0.1"
|
||||
},
|
||||
|
||||
check_interval = 10m
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You may also want to load the "compat" component if you want Icinga 2
|
||||
> to write status.dat and objects.cache files.
|
||||
|
||||
/\* vim: set syntax=asciidoc filetype=asciidoc: \*/
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
Configuration Introduction
|
||||
==========================
|
||||
|
||||
In Icinga 2 configuration is based on objects. There’s no difference in
|
||||
defining global settings for the core application or for a specific
|
||||
runtime configuration object.
|
||||
|
||||
There are different types for the main application, its components and
|
||||
tools. The runtime configuration objects such as hosts, services, etc
|
||||
are defined using the same syntax.
|
||||
|
||||
Each configuration object must be unique by its name. Otherwise Icinga 2
|
||||
will bail early on verifying the parsed configuration.
|
||||
|
||||
Main Configuration
|
||||
==================
|
||||
|
||||
Starting Icinga 2 requires the main configuration file called
|
||||
"icinga2.conf". That’s the location where everything is defined or
|
||||
included. Icinga 2 will only know the content of that file and included
|
||||
configuration file snippets.
|
||||
|
||||
# /usr/bin/icinga2 -c /etc/icinga2/icinga2.conf
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You can use just the main configuration file and put everything in
|
||||
> there. Though that is not advised because configuration may be
|
||||
> expanded over time. Rather organize runtime configuration objects into
|
||||
> their own files and/or directories and include that in the main
|
||||
> configuration file.
|
||||
|
||||
Configuration Syntax
|
||||
====================
|
||||
|
||||
/\* TODO \*/
|
||||
|
||||
Details on the syntax can be found in the chapter
|
||||
icinga2-config-syntax.html[Configuration Syntax]
|
||||
|
||||
Configuration Types
|
||||
===================
|
||||
|
||||
/\* TODO \*/
|
||||
|
||||
Details on the available types can be found in the chapter
|
||||
icinga2-config-types.html[Configuration Types]
|
||||
|
||||
Configuration Templates
|
||||
=======================
|
||||
|
||||
Icinga 2 ships with the **Icinga Template Library (ITL)**. This is a set
|
||||
of predefined templates and definitions available in your actual
|
||||
configuration.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Do not change the ITL’s files. They will be overridden on upgrade.
|
||||
> Submit a patch upstream or include your very own configuration
|
||||
> snippet.
|
||||
|
||||
Include the basic ITL set in your main configuration like
|
||||
|
||||
include <itl/itl.conf>
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Icinga 2 recognizes the ITL’s installation path and looks for that
|
||||
> specific file then.
|
||||
|
||||
Having Icinga 2 installed in standalone mode make sure to include
|
||||
itl/standalone.conf as well (see sample configuration).
|
||||
|
||||
include <itl/standalone.conf>
|
||||
|
||||
/\* vim: set syntax=asciidoc filetype=asciidoc: \*/
|
||||
|
|
@ -1,72 +0,0 @@
|
|||
Requirements
|
||||
============
|
||||
|
||||
Packages
|
||||
========
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Use packages whenever possible.
|
||||
|
||||
------------------------------------ ------------------------------------
|
||||
Distribution Package URL
|
||||
Debian TBD
|
||||
RHEL/CentOS TBD
|
||||
SLES TBD
|
||||
------------------------------------ ------------------------------------
|
||||
|
||||
In case you’re running a distribution for which Icinga 2 packages are
|
||||
not yet available download the source tarball and jump to Source Builds.
|
||||
|
||||
Windows Installer
|
||||
=================
|
||||
|
||||
TODO
|
||||
|
||||
Source Builds
|
||||
=============
|
||||
|
||||
Download the source tarball and read the *INSTALL* file for details and
|
||||
requirements.
|
||||
|
||||
Linux Builds
|
||||
------------
|
||||
|
||||
Building from source on specific linux distributions is described on the
|
||||
wiki:
|
||||
[https://wiki.icinga.org/display/icinga2/Linux+Builds](https://wiki.icinga.org/display/icinga2/Linux+Builds)
|
||||
|
||||
Windows Builds
|
||||
--------------
|
||||
|
||||
Icinga 2 ships a MS Visual Studio solution file. Requirements and
|
||||
compilation instructions can be found on the wiki:
|
||||
[https://wiki.icinga.org/display/icinga2/Windows+Builds](https://wiki.icinga.org/display/icinga2/Windows+Builds)
|
||||
|
||||
Installation Locations
|
||||
======================
|
||||
|
||||
------------------------------------ ------------------------------------
|
||||
Path Description
|
||||
|
||||
/etc/icinga2 Contains Icinga 2 configuration
|
||||
files.
|
||||
|
||||
/etc/init.d/icinga2 The Icinga 2 init script.
|
||||
|
||||
/usr/share/doc/icinga2 Documentation files that come with
|
||||
Icinga 2.
|
||||
|
||||
/usr/share/icinga2/itl The Icinga Template Library.
|
||||
|
||||
/var/run/icinga2 Command pipe and PID file.
|
||||
|
||||
/var/cache/icinga2 Performance data files and
|
||||
status.dat/objects.cache.
|
||||
|
||||
/var/lib/icinga2 The Icinga 2 state file.
|
||||
------------------------------------ ------------------------------------
|
||||
|
||||
/\* TODO \*/
|
||||
|
||||
/\* vim: set syntax=asciidoc filetype=asciidoc: \*/
|
||||
|
|
@ -1,268 +0,0 @@
|
|||
Icinga 2 is a network monitoring application that tries to improve upon
|
||||
the success of Icinga 1.x while fixing some of its shortcomings. A few
|
||||
frequently encountered issues are:
|
||||
|
||||
- Scalability problems in large monitoring setups
|
||||
|
||||
- Difficult configuration with dozens of "magic" tweaks and several
|
||||
ways of defining services
|
||||
|
||||
- Code quality and the resulting inability to implement changes
|
||||
without breaking add-ons
|
||||
|
||||
- Limited access to the runtime state of Icinga (e.g. for querying a
|
||||
service’s state or for dynamically creating new services)
|
||||
|
||||
Fixing these issues would involve major breaking changes to the Icinga
|
||||
1.x core and configuration syntax. Icinga users would likely experience
|
||||
plenty of problems with the Icinga versions introducing these changes.
|
||||
Many of these changes would likely break add-ons which rely on the NEB
|
||||
API and other core internals.
|
||||
|
||||
From a developer standpoint this may be justifiable in order to get to a
|
||||
better end-product. However, for (business) users spending time on
|
||||
getting familiar with these changes for each new version may become
|
||||
quite frustrating and may easily cause users to lose their confidence in
|
||||
Icinga.
|
||||
|
||||
Nagios™ 4 is currently following this approach and it remains to be seen
|
||||
how this fares with its users.
|
||||
|
||||
Instead the Icinga project will maintain two active development
|
||||
branches. There will be one branch for Icinga 1.x which focuses on
|
||||
improving the existing Icinga 1.x code base - just like it has been done
|
||||
so far.
|
||||
|
||||
Independently from Icinga 1.x development on Icinga 2 will happen in a
|
||||
separate branch and some of the long-term design goals will be outlined
|
||||
in this document. Status updates for Icinga 2 will be posted on the
|
||||
project website (www.icinga.org) as they become available.
|
||||
|
||||
Code Quality
|
||||
============
|
||||
|
||||
Icinga 2 will not be using any code from the Icinga 1.x branch due to
|
||||
the rampant code quality issues with the existing code base. However, an
|
||||
important property of the Icinga development process has always been to
|
||||
rely on proven technologies and Icinga 2 will be no exception.
|
||||
|
||||
A lot of effort has gone into designing a maintainable architecture for
|
||||
Icinga 2 and making sure that algorithmic choices are in alignment with
|
||||
our scalability goals for Icinga 2.
|
||||
|
||||
There are plans to implement unit tests for most Icinga 2 features in
|
||||
order to make sure that changes to the code base do not break things
|
||||
that were known to work before.
|
||||
|
||||
Language Choice
|
||||
===============
|
||||
|
||||
Icinga 1.x is written in C and while in general C has quite a number of
|
||||
advantages (e.g. performance and relatively easy portability to other
|
||||
\*NIX- based platforms) some of its disadvantages show in the context of
|
||||
a project that is as large as Icinga.
|
||||
|
||||
With a complex software project like Icinga an object-oriented design
|
||||
helps tremendously with keeping things modular and making changes to the
|
||||
existing code easier.
|
||||
|
||||
While it is true that you can write object-oriented software in C (the
|
||||
Linux kernel is one of the best examples of how to do that) a truly
|
||||
object-oriented language makes the programmers' life just a little bit
|
||||
easier.
|
||||
|
||||
For Icinga 2 we have chosen C++ as the main language. This decision was
|
||||
influenced by a number of criteria including performance, support on
|
||||
different platforms and general user acceptability.
|
||||
|
||||
In general there is nothing wrong with other languages like Java, C\# or
|
||||
Python; however - even when ignoring technical problems for just a
|
||||
moment - in a community as conservative as the monitoring community
|
||||
these languages seem out of place.
|
||||
|
||||
Knowing that users will likely want to run Icinga 2 on older systems
|
||||
(which are still fully vendor-supported even for years to come) we will
|
||||
make every effort to ensure that Icinga 2 can be built and run on
|
||||
commonly used operating systems and refrain from using new and exotic
|
||||
features like C++11.
|
||||
|
||||
Unlike Icinga 1.x there will be Windows support for Icinga 2. Some of
|
||||
the compatibility features (e.g. the command pipe) which rely on \*NIX
|
||||
features may not be supported on Windows but all new features will be
|
||||
designed in such a way as to support \*NIX as well as Windows.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Icinga 1.x has a configuration format that is fully backwards-compatible
|
||||
to the Nagios™ configuration format. This has the advantage of allowing
|
||||
users to easily upgrade their existing Nagios™ installations as well as
|
||||
downgrading if they choose to do so (even though this is generally not
|
||||
the case).
|
||||
|
||||
The Nagios™ configuration format has evolved organically over time and
|
||||
for the most part it does what it’s supposed to do. However this
|
||||
evolutionary process has brought with it a number of problems that make
|
||||
it difficult for new users to understand the full breadth of available
|
||||
options and ways of setting up their monitoring environment.
|
||||
|
||||
Experience with other configuration formats like the one used by Puppet
|
||||
has shown that it is often better to have a single "right" way of doing
|
||||
things rather than having multiple ways like Nagios™ does (e.g. defining
|
||||
host/service dependencies and parent/child relationships for hosts).
|
||||
|
||||
Icinga 2 tries to fix those issues by introducing a new object-based
|
||||
configuration format that is heavily based on templates and supports
|
||||
user-friendly features like freely definable macros.
|
||||
|
||||
External Interfaces
|
||||
===================
|
||||
|
||||
While Icinga 1.x has easily accessible interfaces to its internal state
|
||||
(e.g. status.dat, objects.cache and the command pipe) there is no
|
||||
standards-based way of getting that information.
|
||||
|
||||
For example, using Icinga’s status information in a custom script
|
||||
generally involves writing a parser for the status.dat format and there
|
||||
are literally dozens of Icinga-specific status.dat parsers out there.
|
||||
|
||||
While Icinga 2 will support these legacy interfaces in order to make
|
||||
migration easier and allowing users to use the existing CGIs and
|
||||
whatever other scripts they may have Icinga 2 will focus on providing a
|
||||
unified interface to Icinga’s state and providing similar functionality
|
||||
to that provided by the command pipe in Icinga 1.x. The exact details
|
||||
for such an interface are yet to be determined but this will likely be
|
||||
an RPC interface based on one of the commonly used web-based remoting
|
||||
technologies.
|
||||
|
||||
Icinga 1.x exports historical data using the IDO database interface
|
||||
(Icinga Data Output). Icinga 2 will support IDO in a
|
||||
backwards-compatible fashion in order to support icinga-web.
|
||||
Additionally there will be a newly-designed backend for historical data
|
||||
which can be queried using the built-in API when available. Effort will
|
||||
be put into making this new data source more efficient for use with SLA
|
||||
reporting.
|
||||
|
||||
Icinga 2 will also feature dynamic reconfiguration using the API which
|
||||
means users can create, delete and update any configuration object (e.g.
|
||||
hosts and services) on-the-fly. Based on the API there are plans to
|
||||
implement a command-line configuration tool similar to what Pacemaker
|
||||
has with "crm". Later on this API may also be used to implement
|
||||
auto-discovery for new services.
|
||||
|
||||
The RPC interface may also be used to receive events in real-time, e.g.
|
||||
when service checks are being executed or when a service’s state
|
||||
changes. Some possible uses of this interface would be to export
|
||||
performance data for services (RRD, graphite, etc.) or general log
|
||||
information (logstash, graylog2, etc.).
|
||||
|
||||
Checks
|
||||
======
|
||||
|
||||
In Icinga 2 services are the only checkable objects. Hosts only have a
|
||||
calculated state and no check are ever run for them.
|
||||
|
||||
In order to maintain compatibility with the hundreds of existing check
|
||||
plugins for Icinga 1.x there will be support for Nagios™-style checks.
|
||||
The check interface however will be modular so that support for other
|
||||
kinds of checks can be implemented later on (e.g. built-in checks for
|
||||
commonly used services like PING, HTTP, etc. in order to avoid spawning
|
||||
a process for each check).
|
||||
|
||||
Based on the availability of remote Icinga 2 instances the core can
|
||||
delegate execution of service checks to them in order to support
|
||||
large-scale distributed setups with a minimal amount of maintenance.
|
||||
Services can be assigned to specific check instances using configuration
|
||||
settings.
|
||||
|
||||
Notifications
|
||||
=============
|
||||
|
||||
Event handlers and notifications will be supported similar to Icinga
|
||||
1.x. Thanks to the dynamic configuration it is possible to easily adjust
|
||||
the notification settings at runtime (e.g. in order to implement on-call
|
||||
rotation).
|
||||
|
||||
Scalability
|
||||
===========
|
||||
|
||||
Icinga 1.x has some serious scalability issues which explains why there
|
||||
are several add-ons which try to improve the core’s check performance.
|
||||
One of these add-ons is mod\_gearman which can be used to distribute
|
||||
checks to multiple workers running on remote systems.
|
||||
|
||||
A problem that remains is the performance of the core when processing
|
||||
check results. Scaling Icinga 1.x beyond 25.000 services proves to be a
|
||||
challenging problem and usually involves setting up a cascade of Icinga
|
||||
1.x instances and dividing the service checks between those instances.
|
||||
This significantly increases the maintenance overhead when updating the
|
||||
configuration for such a setup.
|
||||
|
||||
Icinga 2 natively supports setting up multiple Icinga 2 instances in a
|
||||
cluster to distribute work between those instances. Independent tasks
|
||||
(e.g. performing service checks, sending notifications, updating the
|
||||
history database, etc.) are implemented as components which can be
|
||||
loaded for each instance. Configuration as well as program state is
|
||||
automatically replicated between instances.
|
||||
|
||||
In order to support using Icinga 2 in a partially trusted environment
|
||||
SSL is used for all network communication between individual instances.
|
||||
Objects (like hosts and services) can be grouped into security domains
|
||||
for which permissions can be specified on a per-instance basis (so e.g.
|
||||
you can have a separate API or checker instance for a specific domain).
|
||||
|
||||
Agent-based Checks
|
||||
==================
|
||||
|
||||
Traditionally most service checks have been performed actively, meaning
|
||||
that check plugins are executed on the same server that is also running
|
||||
Icinga. This works great for checking most network-based services, e.g.
|
||||
PING and HTTP. However, there are a number of services which cannot be
|
||||
checked remotely either because they are not network-based or because
|
||||
firewall settings or network policies ("no unencrypted traffic")
|
||||
disallow accessing these services from the network where Icinga is
|
||||
running.
|
||||
|
||||
To solve this problem two add-ons have emerged, namely NRPE and NSCA.
|
||||
NRPE can be thought of as a light-weight remote shell which allows the
|
||||
execution of a restricted set of commands while supporting some
|
||||
Nagios™-specific concepts like command timeouts. However unlike with the
|
||||
design of commonly used protocols like SSH security in NRPE is merely an
|
||||
afterthought.
|
||||
|
||||
In most monitoring setups all NRPE agents share the same secret key
|
||||
which is embedded into the NRPE binary at compile time. This means that
|
||||
users can extract this secret key from their NRPE agent binary and use
|
||||
it to query sensitive monitoring information from other systems running
|
||||
the same NRPE binary. NSCA has similar problems.
|
||||
|
||||
Based on Icinga 2’s code for check execution there will be an agent
|
||||
which can be used on \*NIX as well as on Windows platforms. The agent
|
||||
will be using the same configuration format like Icinga 2 itself and
|
||||
will support SSL and IPv4/IPv6 to communicate with Icinga 2.
|
||||
|
||||
Business Processes
|
||||
==================
|
||||
|
||||
In most cases users don’t care about the availability of individual
|
||||
services but rather the aggregated state of multiple related services.
|
||||
For example one might have a database cluster that is used for a web
|
||||
shop. For an end-user the shop is available as long as at least one of
|
||||
the database servers is working.
|
||||
|
||||
Icinga 1.x does not have any support for business processes out of the
|
||||
box. There are several add-ons which implement business process support
|
||||
for Icinga, however none of those are well-integrated into Icinga.
|
||||
|
||||
Icinga 2 will have native support for business processes which are built
|
||||
right into the core and can be configured in a similar manner to
|
||||
Nagios™-style checks. Users can define their own services based on
|
||||
business rules which can be used as dependencies for other hosts or
|
||||
services.
|
||||
|
||||
Logging
|
||||
=======
|
||||
|
||||
Icinga 2 supports file-based logged as well as syslog (on \*NIX) and
|
||||
event log (on Windows). Additionally Icinga 2 supports remote logging to
|
||||
a central Icinga 2 instance.
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
A detailed introduction can be found in the chapter
|
||||
[Introduction](icinga2-intro.html). /\* TODO insert url \*/
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
For more information see the chapter Installation. /\* TODO insert url
|
||||
\*/
|
||||
|
||||
Quick Example
|
||||
=============
|
||||
|
||||
/\* TODO \*/
|
||||
|
||||
For a general tutorial see the chapter
|
||||
[Tutorial](icinga2-tutorial.html). /\* TODO insert url \*/
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
/\* TODO \*/
|
||||
|
||||
License
|
||||
=======
|
||||
|
||||
Icinga 2 is licensed under the GPLv2 license, a copy of this license can
|
||||
be found in the LICENSE file on the main source tree.
|
||||
|
||||
Community
|
||||
=========
|
||||
|
||||
- [\#icinga](http://webchat.freenode.net/?channels=icinga) on the
|
||||
Freenode IRC Network
|
||||
|
||||
- [Mailinglists](https://lists.sourceforge.net/lists/listinfo/icinga-users)
|
||||
|
||||
- [Monitoring Portal](http://www.monitoring-portal.org)
|
||||
|
||||
More details at
|
||||
[http://www.icinga.org/support/](http://www.icinga.org/support/)
|
||||
|
||||
Support
|
||||
=======
|
||||
|
||||
For more information on the support options refer to
|
||||
[https://www.icinga.org/support](https://www.icinga.org/support)
|
||||
|
||||
Chapters
|
||||
========
|
||||
|
||||
/\* TODO \*/
|
||||
|
||||
/\* vim: set syntax=asciidoc filetype=asciidoc: \*/
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
Purpose
|
||||
=======
|
||||
|
||||
Documentation on the general migration from Icinga 1.x to Icinga 2.
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
Multi-core cpu, ram, fast disks.
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
Icinga 1.x and Icinga 2 may run side by side, but it’s recommended to
|
||||
backup your existing 1.x installation before installing Icinga 2 on the
|
||||
same host.
|
||||
|
||||
Compatibility
|
||||
=============
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The configuration format changed from 1.x to 2.x. Don’t panic though.
|
||||
> A conversion script is shipped in *tools/configconvert* - please check
|
||||
> the *README* file.
|
||||
|
||||
For details check the chapter [Compatibility](icinga2-compat.html).
|
||||
|
||||
Changes
|
||||
=======
|
||||
|
||||
For details check the chapter [Changes](icinga2-compat.html).
|
||||
|
||||
TODO
|
||||
|
||||
/\* vim: set syntax=asciidoc filetype=asciidoc: \*/
|
||||
|
|
@ -1,811 +0,0 @@
|
|||
Preface
|
||||
=======
|
||||
|
||||
This tutorial is a step-by-step introduction to installing Icinga 2 and
|
||||
setting up your first couple of service checks. It assumes some
|
||||
familiarity with Icinga 1.x.
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
In order to get started with Icinga 2 we will have to install it. The
|
||||
preferred way of doing this is to use the official Debian or RPM
|
||||
packages depending on which Linux distribution you are running.
|
||||
|
||||
------------------------------------ ------------------------------------
|
||||
Distribution Package URL
|
||||
|
||||
Debian [http://icingabuild.dus.dg-i.net:808
|
||||
0/job/icinga2/](http://icingabuild.d
|
||||
us.dg-i.net:8080/job/icinga2/)
|
||||
|
||||
RHEL TBD
|
||||
------------------------------------ ------------------------------------
|
||||
|
||||
In case you’re running a distribution for which Icinga 2 packages are
|
||||
not yet available you will have to check out the Icinga 2 Git repository
|
||||
from git://git.icinga.org/icinga2 and read the *INSTALL* file.
|
||||
|
||||
By default Icinga 2 uses the following files and directories:
|
||||
|
||||
------------------------------------ ------------------------------------
|
||||
Path Description
|
||||
|
||||
/etc/icinga2 Contains Icinga 2 configuration
|
||||
files.
|
||||
|
||||
/etc/init.d/icinga2 The Icinga 2 init script.
|
||||
|
||||
/usr/share/doc/icinga2 Documentation files that come with
|
||||
Icinga 2.
|
||||
|
||||
/usr/share/icinga2/itl The Icinga Template Library.
|
||||
|
||||
/var/run/icinga2 Command pipe and PID file.
|
||||
|
||||
/var/cache/icinga2 Performance data files and
|
||||
status.dat/objects.cache.
|
||||
|
||||
/var/lib/icinga2 The Icinga 2 state file.
|
||||
------------------------------------ ------------------------------------
|
||||
|
||||
Our First Service Check
|
||||
=======================
|
||||
|
||||
The Icinga 2 package comes with a number of example configuration files.
|
||||
However, in order to explain some of the basics we’re going write our
|
||||
own configuration file from scratch.
|
||||
|
||||
Start by creating the file /etc/icinga2/icinga2.conf with the following
|
||||
content:
|
||||
|
||||
include <itl/itl.conf>
|
||||
include <itl/standalone.conf>
|
||||
|
||||
object IcingaApplication "my-icinga" {
|
||||
macros["plugindir"] = "/usr/lib/nagios/plugins"
|
||||
}
|
||||
|
||||
The configuration snippet includes the *itl/itl.conf* and
|
||||
*itl/standalone.conf* files which are distributed as part of Icinga 2.
|
||||
We will discuss the Icinga Template Library (ITL) in more detail later
|
||||
on.
|
||||
|
||||
The *itl/standalone.conf* configuration file takes care of configuring
|
||||
Icinga 2 for single-instance (i.e. non-clustered) mode.
|
||||
|
||||
Our configuration file also creates an object of type
|
||||
*IcingaApplication* with the name *my-icinga*. The *IcingaApplication*
|
||||
type can be used to define global macros and some other global settings.
|
||||
|
||||
For now we’re only defining the global macro *plugindir* which we’re
|
||||
going to use later on when referring to the path which contains our
|
||||
check plugins. Depending on where you’ve installed your check plugins
|
||||
you may need to update this path in your configuration file.
|
||||
|
||||
You can verify that your configuration file works by starting Icinga 2:
|
||||
|
||||
$ /usr/bin/icinga2 -c /etc/icinga2/icinga2.conf
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/icinga-app: Icinga application loader (version: 0.0.1, git branch master, commit 0fcbfdb2)
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/base: Adding library search dir: /usr/lib/icinga2
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/base: Loading library 'libicinga.la'
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/config: Adding include search dir: /usr/share/icinga2
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/config: Compiling config file: /etc/icinga2/icinga2.conf
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/config: Linking config items...
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/config: Validating config items...
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/config: Activating config items in compilation unit 'b2d21c28-a2e8-4fcb-ba00-45646bc1afb9'
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/base: Restoring program state from file '/var/lib/icinga2/icinga2.state'
|
||||
[2013/04/23 13:36:20 +0200] <Main Thread> information/base: Restored 0 objects
|
||||
|
||||
In case there are any configuration errors Icinga 2 should print error
|
||||
messages containing details about what went wrong.
|
||||
|
||||
You can stop Icinga 2 with Control-C:
|
||||
|
||||
^C
|
||||
[2013/04/23 13:39:39 +0200] <TP 0x7f2e9070f500 Worker #0> information/base: Shutting down Icinga...
|
||||
[2013/04/23 13:39:39 +0200] <TP 0x7f2e9070f500 Worker #0> information/base: Dumping program state to file '/var/lib/icinga2/icinga2.state'
|
||||
[2013/04/23 13:39:39 +0200] <Main Thread> information/icinga: Icinga has shut down.
|
||||
$
|
||||
|
||||
Icinga 2 automatically saves its current state every couple of minutes
|
||||
and when it’s being shut down.
|
||||
|
||||
So far our Icinga 2 setup doesn’t do much. Lets change that by setting
|
||||
up a service check for localhost. Modify your *icinga2.conf*
|
||||
configuration file by adding the following lines:
|
||||
|
||||
object CheckCommand "my-ping" inherits "plugin-check-command" {
|
||||
command = [
|
||||
"$plugindir$/check_ping",
|
||||
"-H", "$address$",
|
||||
"-w", "10,5%",
|
||||
"-c", "25,10%"
|
||||
]
|
||||
}
|
||||
|
||||
template Service "my-ping" inherits "plugin-service" {
|
||||
check_command = "my-ping"
|
||||
}
|
||||
|
||||
object Host "localhost" {
|
||||
display_name = "Home, sweet home!",
|
||||
|
||||
services["ping"] = {
|
||||
templates = [ "my-ping" ]
|
||||
},
|
||||
|
||||
macros = {
|
||||
address = "127.0.0.1"
|
||||
},
|
||||
|
||||
check_interval = 10s,
|
||||
|
||||
hostcheck = "ping"
|
||||
}
|
||||
|
||||
We’re defining a command object called "my-ping" which inherits from the
|
||||
*plugin-check-command* template. The *plugin-check-command* template is
|
||||
provided as part of the Icinga Template Library and describes how checks
|
||||
are performed. In the case of plugin-based services this means that the
|
||||
command specified by the *command* property is executed.
|
||||
|
||||
The *command* property is an array or command-line arguments for the
|
||||
check plugin. Alternatively you can specify the check command as a
|
||||
string.
|
||||
|
||||
The check command can make use of macros. Unlike in Icinga 1.x we have
|
||||
free-form macros which means that users can choose arbitrary names for
|
||||
their macros.
|
||||
|
||||
By convention the following macros are usually used:
|
||||
|
||||
------------------------------------ ------------------------------------
|
||||
Macro Description
|
||||
plugindir The path of your check plugins.
|
||||
address The IPv4 address of the host.
|
||||
address6 The IPv6 address of the host.
|
||||
------------------------------------ ------------------------------------
|
||||
|
||||
Note that the *my-ping* command object does not define a value for the
|
||||
*address* macro. This is perfectly fine as long as that macro is defined
|
||||
somewhere else (e.g. in the host).
|
||||
|
||||
We’re also defining a service template called *my-ping* which uses the
|
||||
command object we just created.
|
||||
|
||||
Next we’re defining a *Host* object called *localhost*. We’re setting an
|
||||
optional display\_name which is used by the Icinga Classic UI when
|
||||
showing that host in the host overview.
|
||||
|
||||
The services dictionary defines which services belong to a host. Using
|
||||
the [] indexing operator we can manipulate individual items in this
|
||||
dictionary. In this case we’re creating a new service called *ping*.
|
||||
|
||||
The templates array inside the service definition lists all the
|
||||
templates we want to use for this particular service. For now we’re just
|
||||
listing our *my-ping* template.
|
||||
|
||||
Remember how we used the *address* macro in the *command* setting
|
||||
earlier? Now we’re defining a value for this macro which is used for all
|
||||
services and their commands which belong to the *localhost* Host object.
|
||||
|
||||
We’re also setting the check\_interval for all services belonging to
|
||||
this host to 10 seconds.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> When you don’t specify an explicit time unit Icinga 2 automatically
|
||||
> assumes that you meant seconds.
|
||||
|
||||
And finally we’re specifying which of the services we’ve created before
|
||||
is used to define the host’s state. Note that unlike in Icinga 1.x this
|
||||
just "clones" the service’s state and does not cause any additional
|
||||
checks to be performed.
|
||||
|
||||
Setting up the Icinga 1.x Classic UI
|
||||
====================================
|
||||
|
||||
Icinga 2 can write status.dat and objects.cache files in the format that
|
||||
is supported by the Icinga 1.x Classic UI. External commands (a.k.a. the
|
||||
"command pipe") are also supported. If you require the icinga.log for
|
||||
history views and/or reporting in Classic UI, this can be added
|
||||
seperately to the CompatComponent object definition by adding a
|
||||
CompatLog object.
|
||||
|
||||
In order to enable this feature you will need to load the library
|
||||
*compat* by adding the following lines to your configuration file:
|
||||
|
||||
library "compat"
|
||||
|
||||
object CompatComponent "compat" { }
|
||||
object CompatLog "my-log" { }
|
||||
|
||||
After restarting Icinga 2 you should be able to find the status.dat and
|
||||
objects.cache files in /var/cache/icinga2. The log files can be found in
|
||||
/var/log/icinga2/compat. The command pipe can be found in
|
||||
/var/run/icinga2.
|
||||
|
||||
You can install the Icinga 1.x Classic UI in standalone mode using the
|
||||
following commands:
|
||||
|
||||
$ wget http://downloads.sourceforge.net/project/icinga/icinga/1.9.0/icinga-1.9.0.tar.gz
|
||||
$ tar xzf icinga-1.9.0.tar.gz ; cd icinga-1.9.0
|
||||
$ ./configure --enable-classicui-standalone --prefix=/usr/local/icinga2-classicui
|
||||
$ make classicui-standalone
|
||||
$ sudo make install classicui-standalone install-webconf-auth
|
||||
$ sudo service apache2 restart
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> A detailed guide on installing Icinga 1.x Classic UI Standalone can be
|
||||
> found on the Icinga Wiki here:
|
||||
> [https://wiki.icinga.org/display/howtos/Setting+up+Icinga+Classic+UI+Standalone](https://wiki.icinga.org/display/howtos/Setting+up+Icinga+Classic+UI+Standalone)
|
||||
|
||||
After installing the Classic UI you will need to update the following
|
||||
settings in your cgi.cfg configuration file at the bottom (section
|
||||
"STANDALONE (ICINGA 2) OPTIONS"):
|
||||
|
||||
------------------------------------ ------------------------------------
|
||||
Configuration Setting Value
|
||||
object\_cache\_file /var/cache/icinga2/objects.cache
|
||||
status\_file /var/cache/icinga2/status.dat
|
||||
resource\_file -
|
||||
command\_file /var/run/icinga2/icinga2.cmd
|
||||
check\_external\_commands 1
|
||||
interval\_length 60
|
||||
status\_update\_interval 10
|
||||
log\_file /var/log/icinga2/compat/icinga.log
|
||||
log\_rotation\_method h
|
||||
log\_archive\_path /var/log/icinga2/compat/archives
|
||||
date\_format us
|
||||
------------------------------------ ------------------------------------
|
||||
|
||||
Depending on how you installed Icinga 2 some of those paths and options
|
||||
might be different.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You need to grant permissions for the apache user manually after
|
||||
> starting Icinga 2 for now.
|
||||
|
||||
# chmod o+rwx /var/run/icinga2/{icinga2.cmd,livestatus}
|
||||
|
||||
Verify that your Icinga 1.x Classic UI works by browsing to your Classic
|
||||
UI installation URL e.g.
|
||||
[http://localhost/icinga](http://localhost/icinga)
|
||||
|
||||
Some More Templates
|
||||
===================
|
||||
|
||||
Now that we’ve got our basic monitoring setup as well as the Icinga 1.x
|
||||
Classic UI to work we can define a second host. Add the following lines
|
||||
to your configuration file:
|
||||
|
||||
object Host "icinga.org" {
|
||||
display_name = "Icinga Website",
|
||||
|
||||
services["ping"] = {
|
||||
templates = [ "my-ping" ]
|
||||
},
|
||||
|
||||
macros = {
|
||||
address = "www.icinga.org"
|
||||
},
|
||||
|
||||
check_interval = 10s,
|
||||
|
||||
hostcheck = "ping"
|
||||
}
|
||||
|
||||
Restart your Icinga 2 instance and check the Classic UI for your new
|
||||
service’s state. Unless you have a low-latency network connection you
|
||||
will note that the service’s state is *CRITICAL*. This is because in the
|
||||
*my-ping* command object we have hard-coded the timeout as 25
|
||||
milliseconds.
|
||||
|
||||
Ideally we’d be able to specify different timeouts for our new service.
|
||||
Using macros we can easily do this.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> If you’ve used Icinga 1.x before you’re probably familiar with doing
|
||||
> this by passing ARGx macros to your check commands.
|
||||
|
||||
Start by replacing your *my-ping* command object with this:
|
||||
|
||||
object CheckCommand "my-ping" inherits "plugin-check-command" {
|
||||
command = [
|
||||
"$plugindir$/check_ping",
|
||||
"-H", "$address$",
|
||||
"-w", "$wrta$,$wpl$%",
|
||||
"-c", "$crta$,$cpl$%"
|
||||
],
|
||||
|
||||
macros = {
|
||||
wrta = 10,
|
||||
wpl = 5,
|
||||
|
||||
crta = 25,
|
||||
cpl = 10
|
||||
}
|
||||
}
|
||||
|
||||
We have replaced our hard-coded timeout values with macros and we’re
|
||||
providing default values for these same macros right in the template
|
||||
definition. The object inherits the basic check command attributes from
|
||||
the ITL provided template *plugin-check-command*.
|
||||
|
||||
In order to oderride some of these macros for a specific host we need to
|
||||
update our *icinga.org* host definition like this:
|
||||
|
||||
object Host "icinga.org" {
|
||||
display_name = "Icinga Website",
|
||||
|
||||
services["ping"] = {
|
||||
templates = [ "my-ping" ],
|
||||
|
||||
macros += {
|
||||
wrta = 100,
|
||||
crta = 250
|
||||
}
|
||||
},
|
||||
|
||||
macros = {
|
||||
address = "www.icinga.org"
|
||||
},
|
||||
|
||||
check_interval = 10s,
|
||||
|
||||
hostcheck = "ping"
|
||||
}
|
||||
|
||||
The *+=* operator allows us to selectively add new key-value pairs to an
|
||||
existing dictionary. If we were to use the *=* operator instead we would
|
||||
have to provide values for all the macros that are used in the *my-ping*
|
||||
template overriding all values there.
|
||||
|
||||
Icinga Template Library
|
||||
=======================
|
||||
|
||||
The Icinga Template Library is a collection of configuration templates
|
||||
for commonly used services. By default it is installed in
|
||||
*/usr/share/icinga2/itl* and you can include it in your configuration
|
||||
files using the include directive:
|
||||
|
||||
include <itl/itl.conf>
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Ordinarily you’d use double-quotes for the include path. This way only
|
||||
> paths relative to the current configuration file are considered. The
|
||||
> angle brackets tell Icinga 2 to search its list of global include
|
||||
> directories.
|
||||
|
||||
One of the templates in the ITL is the *ping4* service template which is
|
||||
quite similar to our example objects:
|
||||
|
||||
object CheckCommand "ping4" inherits "plugin-check-command" {
|
||||
command = [
|
||||
"$plugindir$/check_ping",
|
||||
"-4",
|
||||
"-H", "$address$",
|
||||
"-w", "$wrta$,$wpl$%",
|
||||
"-c", "$crta$,$cpl$%",
|
||||
"-p", "$packets$",
|
||||
"-t", "$timeout$"
|
||||
],
|
||||
|
||||
macros = {
|
||||
wrta = 100,
|
||||
wpl = 5,
|
||||
|
||||
crta = 200,
|
||||
cpl = 15,
|
||||
|
||||
packets = 5,
|
||||
timeout = 0
|
||||
}
|
||||
}
|
||||
|
||||
template Service "ping4" {
|
||||
check_command = "ping4"
|
||||
}
|
||||
|
||||
Lets simplify our configuration file by removing our custom *my-ping*
|
||||
template and updating our service definitions to use the *ping4*
|
||||
template instead.
|
||||
|
||||
Include Files
|
||||
=============
|
||||
|
||||
So far we’ve been using just one configuration file. However, once
|
||||
you’ve created a few more host objects and service templates this can
|
||||
get rather confusing.
|
||||
|
||||
Icinga 2 lets you include other files from your configuration file. We
|
||||
can use this feature to make our configuration a bit more modular and
|
||||
easier to understand.
|
||||
|
||||
Lets start by moving our two *Host* objects to a separate configuration
|
||||
file: hosts.conf
|
||||
|
||||
We will also need to tell Icinga 2 that it should include our newly
|
||||
created configuration file when parsing the main configuration file.
|
||||
This can be done by adding the include directive to our *icinga2.conf*
|
||||
file:
|
||||
|
||||
include "hosts.conf"
|
||||
|
||||
Depending on the number of hosts you have it might be useful to split
|
||||
your configuration files based on other criteria (e.g. device type,
|
||||
location, etc.).
|
||||
|
||||
You can use wildcards in the include path in order to refer to multiple
|
||||
files. Assuming you’re keeping your host configuration files in a
|
||||
directory called *hosts* you could include them like this:
|
||||
|
||||
include "hosts/*.conf"
|
||||
|
||||
Notifications
|
||||
=============
|
||||
|
||||
Icinga 2 can send you notifications when your services change state. In
|
||||
order to do this we’re going to write a shell script in
|
||||
*/etc/icinga2/mail-notification.sh* that sends e-mail based
|
||||
notifications:
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
if [ -z "$1" ]; then
|
||||
echo "Syntax: $0 <e-mail>"
|
||||
echo
|
||||
echo "Sends a mail notification to the specified e-mail address."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
mail -s "** $NOTIFICATIONTYPE Service Alert: $HOSTALIAS/$SERVICEDESC is $SERVICESTATE **" $1 <<TEXT
|
||||
***** Icinga *****
|
||||
|
||||
Notification Type: $NOTIFICATIONTYPE
|
||||
|
||||
Service: $SERVICEDESC
|
||||
Host: $HOSTALIAS
|
||||
Address: $address
|
||||
State: $SERVICESTATE
|
||||
|
||||
Date/Time: $LONGDATETIME
|
||||
|
||||
Additional Info:
|
||||
|
||||
$SERVICEOUTPUT
|
||||
TEXT
|
||||
|
||||
exit 0
|
||||
|
||||
Our shell script uses a couple of pre-defined macros (e.g. SERVICEDESC,
|
||||
HOSTALIAS, etc.) that are always available.
|
||||
|
||||
Next we’re going to create a *Notification* template which tells Icinga
|
||||
how to invoke the shell script:
|
||||
|
||||
object NotificationCommand "mail-notification" inherits "plugin-notification-command" {
|
||||
command = [
|
||||
"/etc/icinga2/mail-notification.sh",
|
||||
"$email$"
|
||||
],
|
||||
|
||||
export_macros = [
|
||||
"NOTIFICATIONTYPE",
|
||||
"HOSTALIAS",
|
||||
"SERVICEDESC",
|
||||
"SERVICESTATE",
|
||||
"SERVICEDESC",
|
||||
"address",
|
||||
"LONGDATETIME",
|
||||
"SERVICEOUTPUT"
|
||||
]
|
||||
}
|
||||
|
||||
template Notification "mail-notification" {
|
||||
notification_command = "mail-notification"
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Rather than adding these templates to your main configuration file you
|
||||
> might want to create a separate file, e.g. *notifications.conf* and
|
||||
> include it in *icinga2.conf*.
|
||||
|
||||
The *export\_macros* property tells Icinga which macros to export into
|
||||
the environment for the notification script.
|
||||
|
||||
We also need to create a *User* object which Icinga can use to send
|
||||
notifications to specific people:
|
||||
|
||||
object User "tutorial-user" {
|
||||
display_name = "Some User",
|
||||
|
||||
macros = {
|
||||
email = "tutorial@example.org"
|
||||
}
|
||||
}
|
||||
|
||||
Each time a notification is sent for a service the user’s macros are
|
||||
used when resolving the macros we used in the *Notification* template.
|
||||
|
||||
In the next step we’re going to create a *Service* template which
|
||||
specifies who notifications should be sent to:
|
||||
|
||||
template Service "mail-notification-service" {
|
||||
notifications["mail"] = {
|
||||
templates = [ "mail-notification" ],
|
||||
|
||||
users = [ "tutorial-user" ]
|
||||
},
|
||||
|
||||
notification_interval = 1m
|
||||
}
|
||||
|
||||
And finally we can assign this new service template to our services:
|
||||
|
||||
...
|
||||
services["ping"] = {
|
||||
templates = [ "ping4", "mail-notification-service" ]
|
||||
},
|
||||
...
|
||||
|
||||
In addition to defining notifications for individual services it is also
|
||||
possible to assign notification templates to all services of a host. You
|
||||
can find more information about how to do that in the documentation.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Escalations in Icinga 2 are just a notification, only added a defined
|
||||
> begin and end time. Check the documentation for details.
|
||||
|
||||
Time Periods
|
||||
============
|
||||
|
||||
Time periods allow you to specify when certain services should be
|
||||
checked and when notifications should be sent.
|
||||
|
||||
Here is an example time period definition:
|
||||
|
||||
object TimePeriod "work-hours" inherits "legacy-timeperiod" {
|
||||
ranges = {
|
||||
monday = "9:00-17:00",
|
||||
tuesday = "9:00-17:00",
|
||||
wednesday = "9:00-17:00",
|
||||
thursday = "9:00-17:00",
|
||||
friday = "9:00-17:00",
|
||||
}
|
||||
}
|
||||
|
||||
The *legacy-timeperiod* template is defined in the Icinga Template
|
||||
Library and supports Icinga 1.x time periods. A complete definition of
|
||||
the time Icinga 1.x time period syntax can be found at
|
||||
[http://docs.icinga.org/latest/en/objectdefinitions.html\#timeperiod](http://docs.icinga.org/latest/en/objectdefinitions.html#timeperiod).
|
||||
|
||||
Using the *check\_period* attribute you can define when services should
|
||||
be checked:
|
||||
|
||||
...
|
||||
services["ping"] = {
|
||||
templates = [ "ping4", "mail-notification-service" ],
|
||||
check_period = "work-hours"
|
||||
},
|
||||
...
|
||||
|
||||
Also, using the *notification\_period* attribute you can define when
|
||||
notifications should be sent:
|
||||
|
||||
template Service "mail-notification-service" {
|
||||
notifications["mail"] = {
|
||||
templates = [ "mail-notification" ],
|
||||
|
||||
users = [ "tutorial-user" ]
|
||||
},
|
||||
|
||||
notification_interval = 1m,
|
||||
notification_period = "work-hours"
|
||||
}
|
||||
|
||||
The *notification\_period* attribute is also valid in *User* and
|
||||
*Notification* objects.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
If you are familiar with Icinga 1.x host/service dependencies and
|
||||
parent/child relations on hosts, you might want to look at the
|
||||
conversion script in order to convert your existing configuration. There
|
||||
are no separate dependency objects anymore, and no separate parent
|
||||
attribute either.
|
||||
|
||||
Using Icinga 2, we can directly define a dependency in the current host
|
||||
or service object to any other host or service object. If we want other
|
||||
objects to inherit those dependency attributes, we can also define them
|
||||
in a template.
|
||||
|
||||
In the following example we’ve added a cluster host with the service
|
||||
*ping* which we are going to define a dependency for in another host.
|
||||
|
||||
template Service "my-cluster-ping" {
|
||||
check_command = "my-ping",
|
||||
}
|
||||
|
||||
object Host "my-cluster" {
|
||||
...
|
||||
services["ping"] = {
|
||||
templates = [ "my-cluster-ping" ],
|
||||
}
|
||||
...
|
||||
}
|
||||
|
||||
We can now define a service dependency as new service template (or
|
||||
directly on the service definition):
|
||||
|
||||
template Service "my-cluster-dependency" {
|
||||
servicedependencies = [
|
||||
{ host = "my-cluster", service = "ping" },
|
||||
],
|
||||
}
|
||||
|
||||
Now let’s use that template for the *ping* service we’ve defined
|
||||
previously and assign the servicedependencies to that service.
|
||||
|
||||
...
|
||||
services["ping"] = {
|
||||
templates = [ "ping4", "mail-notification-service", "my-cluster-dependency" ],
|
||||
},
|
||||
...
|
||||
|
||||
Performance Data
|
||||
================
|
||||
|
||||
Because there are no host checks in Icinga 2, the PerfdataWriter object
|
||||
will only write service performance data files. Creating the object will
|
||||
allow you to set the perfdata\_path, format\_template and
|
||||
rotation\_interval. The format template is similar to existing Icinga
|
||||
1.x configuration for PNP or inGraph using macro formatted strings.
|
||||
|
||||
Details on the common Icinga 1.x macros can be found at
|
||||
[http://docs.icinga.org/latest/en/macrolist.html](http://docs.icinga.org/latest/en/macrolist.html)
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You can define multiple PerfdataWriter objects with different
|
||||
> configuration settings, i.e. one for PNP, one for inGraph or your
|
||||
> preferred graphite collector.
|
||||
|
||||
Let’s create a new PNP PerfdataWriter object:
|
||||
|
||||
object PerfdataWriter "pnp" {
|
||||
perfdata_path = "/var/lib/icinga2/service-perfdata",
|
||||
format_template = "DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$",
|
||||
rotation_interval = 15s,
|
||||
}
|
||||
|
||||
You may need to reconfigure your NPCD daemon with the correct path for
|
||||
your performance data files. This can be done in the PNP configuration
|
||||
file npcd.cfg:
|
||||
|
||||
perfdata_spool_dir = /var/lib/icinga2/
|
||||
|
||||
Livestatus Component
|
||||
====================
|
||||
|
||||
The Livestatus component will provide access to Icinga 2 using the
|
||||
livestatus api. In addition to the unix socket Icinga 2 also service
|
||||
livestatus directly via tcp socket.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Only config and status tables are available at this time. History
|
||||
> tables such as log, statehist will follow.
|
||||
|
||||
Once Icinga 2 is started, configure your gui (e.g. Thruk) using the
|
||||
livestatus backend.
|
||||
|
||||
TCP Socket
|
||||
|
||||
library "livestatus"
|
||||
object LivestatusComponent "livestatus-tcp" {
|
||||
socket_type = "tcp",
|
||||
host = "10.0.10.18",
|
||||
port = "6558"
|
||||
}
|
||||
|
||||
Unix Socket
|
||||
|
||||
library "livestatus"
|
||||
object LivestatusComponent "livestatus-unix" {
|
||||
socket_type = "unix",
|
||||
socket_path = "/var/run/icinga2/livestatus"
|
||||
}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You need to grant permissions for the apache user manually after
|
||||
> starting Icinga 2 for now.
|
||||
|
||||
# chmod o+rwx /var/run/icinga2/{icinga2.cmd,livestatus}
|
||||
|
||||
IDO Database Component
|
||||
======================
|
||||
|
||||
The IDO component will write to the same database backend as known from
|
||||
Icinga 1.x IDOUtils. Therefore you’ll need to have your database schema
|
||||
and users already installed, like described in
|
||||
[http://docs.icinga.org/latest/en/quickstart-idoutils.html\#createidoutilsdatabase](http://docs.icinga.org/latest/en/quickstart-idoutils.html#createidoutilsdatabase)
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Currently there’s only MySQL support in progress, Postgresql, Oracle
|
||||
> tbd.
|
||||
|
||||
Configure the IDO MySQL component with the defined credentials and start
|
||||
Icinga 2.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Make sure to define a unique instance\_name. That way the Icinga 2 IDO
|
||||
> component will not interfere with your Icinga 1.x setup, if existing.
|
||||
|
||||
library "ido_mysql"
|
||||
object IdoMysqlDbConnection "my-ido-mysql" {
|
||||
host = "127.0.0.1",
|
||||
port = "3306",
|
||||
user = "icinga",
|
||||
password = "icinga",
|
||||
database = "icinga",
|
||||
table_prefix = "icinga_",
|
||||
instance_name = "icinga2",
|
||||
instance_description = "icinga2 instance"
|
||||
}
|
||||
|
||||
Starting Icinga 2 in debug mode in foreground using -x will show all
|
||||
database queries.
|
||||
|
||||
Custom Attributes
|
||||
=================
|
||||
|
||||
In Icinga 1.x there were so-called "custom variables" available prefixed
|
||||
with an underscore, as well as plenty of other attributes such as
|
||||
action\_url, notes\_url, icon\_image, etc. To overcome the limitations
|
||||
of hardcoded custom attributes, Icinga 2 ships with the *custom*
|
||||
attribute as dictionary.
|
||||
|
||||
For example, if you have PNP installed we could add a reference url to
|
||||
Icinga Classic UI by using the classic method of defining an
|
||||
action\_url.
|
||||
|
||||
template Service "my-pnp-svc" {
|
||||
custom = {
|
||||
action_url = "/pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$' class='tips' rel='/pnp4nagios/popup?host=$HOSTNAME$&srv=$SERVICEDESC$",
|
||||
}
|
||||
}
|
||||
|
||||
And add that template again to our service definition:
|
||||
|
||||
...
|
||||
services["ping"] = {
|
||||
templates = [ "ping4", "mail-notification-service", "my-cluster-dependency", "my-pnp-svc" ],
|
||||
},
|
||||
...
|
||||
|
||||
While at it, our configuration tool will add its LDAP DN and a snmp
|
||||
community to the service too, using += for additive attributes:
|
||||
|
||||
...
|
||||
services["ping"] = {
|
||||
templates = [ "ping4", "mail-notification-service", "my-cluster-dependency", "my-pnp-svc" ],
|
||||
custom += {
|
||||
DN = "cn=icinga2-dev-svc,ou=icinga,ou=main,ou=IcingaConfig,ou=LConf,dc=icinga,dc=org",
|
||||
SNMPCOMMUNITY = "public"
|
||||
}
|
||||
},
|
||||
...
|
||||
|
||||
/\* vim: set syntax=asciidoc filetype=asciidoc: \*/
|
||||
2865
docs/icinga2.md
2865
docs/icinga2.md
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue