Icinga 2 is an open source monitoring system that checks the availability of network resources, notifies users of outages, and generates performance reports. It is scalable and can monitor large, complex environments across multiple locations. There are many ways to contribute including submitting patches, testing, reporting bugs, and updating documentation. Icinga 2 stores status data in an IDO database that is used by Icinga Web 2. Reporting tools then process usable data from the IDO to generate availability reports and ensure service level agreements are met. ICINGA Reporting consists of open source projects that are being expanded to provide more data sources.

2. ICINGA
2
O P E N S O U R C E M O N I TO R I N G S Y S T E M

3. WHAT IS ICINGA?
• Icinga 2 is an open source monitoring system which checks the availability of your
network resources, notifies users of outages and generates performance data for
reporting.
• Scalable and extensible, Icinga 2 can monitor large, complex environments across
multiple locations.
• Icinga 2 and the Icinga 2 documentation are licensed under the terms of the GNU
General Public License Version 2.

4. HOW TO CONTRIBUTE TO ICINGA 2
• There are many ways to contribute to Icinga
a) By sending patches
b) Testing
c) Reporting Bugs
d) Reviewing or updating documentation

5. INSTALLATION
• Basically ICINGA 2 is for UNIX Operating System and not for windows. But its web
version is supported for windows
• We can monitor any system through ICINGA Web 2 on windows.
• Different commands are used to install ICINGA 2 on different operating system.
• If we want to install it on UBUNTU, we use the following command
apt-get install icinga2
• If we want to install it on CENTOS, we use the following command
yum install icinga2
* Meanwhile there are different commands to install ICINGA 2 for different operating systems

6. DATABASE
• Databases that is used for ICINGA 2 are MYSQL/MariaDB & PostgreSQL
• There are different methods to set up database on different operating systems.

7. MONITORING BASICS OF ICINGA 2
• Given below are the monitoring basics of ICINGA 2
a) Attributes & Values
b) Hosts & Services
c) Templates
d) Custom Attributes and Values
e) Runtime Macros
f) Apply Rules
g) Groups
h) Notifications
i) Commands(Check Commands)
j) Dependencies

8. ATTRIBUTES & VALUES
• In ICINGA 2 configuration we have different value types which we called data types in sense
of programming.
• The value types are :
a) Number // This type contain any numeric value
b) Duration // This type contain the duration e.g 1m // one minute
c) String // Any thing written in quotation marks e.g “Hello”
d) Boolean // Its value can be true or false depending on the situation
e) Array // { “value1” , “value2” }
f) Dictionary // in which we specify the value of element inside array
{ “key1” = “value1”, “key2” = “value2”}
*It is important to use the correct value type for object attributes as otherwise the configuration validation will fail

9. HOSTS & SERVICES
• Hosts and Services can be virtually anything that can be checked in some way
• Host can be in one of the following states
a) Up // The Host is available
b) Down // The Host is unavailable
• Services can exist in one of following states
a) Ok // The Service is working properly
b) Warning // The Service is experiencing some problem but still in working condition
c) Critical // The Service is in critical state
d) Unknown // This check could not determine the state of service
• When a problem is detected in Host or Service, ICINGA 2 re-checks object using following
settings
a) max_check_attempts //Host/Service has not recently changed and this state is known as HARD
b) retry_interval // Host/Service has recently changed and is being rechecked and this state is known as
SOFT

10. TEMPLATES
• Templates may be used to apply a set of
identical attributes to more than one
object
Example
We make a generic service which
includes
some attributes like
duration, max_attempts,
check_attempts, retry_interval etc.
Instead of defining it in
every service we just import the
template service so that our service will
inherit the properties of template
service

11. CUSTOM ATTRIBUTES
• Like built in attribute values and types we
can also define our own attributes inside
the vars attribute
• Vars can be defined in two ways
• The custom attribute value types are
a) String
b) Numbers
c) Boolean
d) Arrays and Dictionaries
e) Functions

12. • Macros can be used to access other objects and attributes at runtime
Example
These runtime macros are used in command definitions to figure out which IP
address a
check should be run against
• The evaluation order for the runtime macros executes as the following
a) User Object (for notifications)
b) Service Object
c) Host Object
d) Command Object
e) Global Custom Attributes in Variables Constant
RUNTIME MACROS

13. APPLY RULES
• By using apply rules we can use only one service
object and that can be applied to multiple hosts by
just including check command to perform check on
it.
• For example
If you want basic monitoring for all your hosts, add
a ping4 service apply rule for all hosts which have
the address attribute specified. Just one rule for
1000 hosts instead of 1000 service objects. Apply
rules will automatically generate them for you.

14. GROUPS
A group is a collection of similar objects. Groups
are used as visualization aid in web interfaces
By considering an example that we can create a
host group and then we check every host and we
can add the desired host to the created group

15. NOTIFICATIONS
• Notifications for service and host problems are an integral
part of your monitoring setup.
• When a host or service is in a downtime, a problem has
been acknowledged or the dependency logic determined
that the host/service is unreachable, no notifications are
sent. You can configure additional type and state filters
refining the notifications being sent
• There are many ways of sending notifications, e.g. by
email, XMPP, IRC, Twitter, etc.
• On its own Icinga 2 does not know how to send
notifications. Instead it relies on external mechanisms such
as shell scripts to notify users

16. COMMANDS
• Icinga 2 uses three different command object types
to specify how checks should be performed,
notifications should be sent, and events should be
handled.
• CheckCommand objects define the command line
how a check is called.
• CheckCommand objects are referenced
by Host and Service objects using
the check_command attribute.

17. DEPENDENCIES
Icinga 2 uses host and service Dependency objects for
determining their network reachability.
A service can depend on a host, and vice versa.
A service has an implicit dependency (parent) to its host.
A host to host dependency acts implicitly as host parent
relation.
When dependencies are calculated, not only the immediate
parent is considered, but all parents are inherited.

18. ICINGA 2
REPORTING

19. REPORTING
Basically, it is a framework and a
foundation created to handle the
data collected by ICINGA 2 and
other data providers. The
reporting does not collect or
calculate any of the data.
01
The framework processes usable
data from data providers such as
ICINGA IDO. We need to know
that what is ICINGA IDO.
02

20. ICINGA 2 IDO
The IDO (ICINGA Data Output) feature is for the
ICINGA 2 which take care of exporting all the
configurations and status information in to a
database. The IDO database is used by the
ICINGA Web 2 as a data backend.
The ICINGA’S IDO or ICINGA Web 2 modules
make the usable data output available in
different formats. The first version can display
the data directly within the ICINGA Web
Interface or export it to PDF, JSON or CSV
format. Through the scheduled reports we can
receive the prepared data periodically via email.

21. IDO REPORTS
• The IDO is the database where ICINGA 2 stores all the status data it collects.
It is also the first data provider for ICINGA Reporting.
• Firstly, we calculate the availability of the hosts and services over a certain
amount of time and return a percentage value.
• This allows us to evaluate and compare the accessibility of our applications
and network devices.
• We can also use the data to check that if the Service Level Agreement is
met and to share it with the team and managers.

22. OPEN SOURCE
PROJECTS
• ICINGA reporting consists of multiple
project. The team is still working, and
they are trying to extend the existing
modules to provide data for ICINGA
Reporting.

23. ANY
QUESTIONS
?