summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2019-07-30 22:10:36 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2019-07-30 22:10:48 +0000
commit2b1ad90af6138c229b9e28ef87804ab0b8c0e33c (patch)
tree0daef04b21b3ec3c12b6880ae7c19b94705a15e1
parentReleasing progress-linux version 2.10.5-1~progress5+u1. (diff)
downloadicinga2-2b1ad90af6138c229b9e28ef87804ab0b8c0e33c.tar.xz
icinga2-2b1ad90af6138c229b9e28ef87804ab0b8c0e33c.zip
Merging upstream version 2.11.0~rc1.
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
-rw-r--r--.github/ISSUE_TEMPLATE.md14
-rw-r--r--.github/ISSUE_TEMPLATE/bug_report.md40
-rw-r--r--.github/ISSUE_TEMPLATE/feature_request.md20
-rw-r--r--.gitignore19
-rw-r--r--.mailmap12
-rw-r--r--.travis.yml73
-rw-r--r--AUTHORS32
-rw-r--r--CHANGELOG.md70
-rw-r--r--CMakeLists.txt137
-rw-r--r--CONTRIBUTING.md17
-rw-r--r--README.md4
-rw-r--r--RELEASE.md71
-rw-r--r--VERSION2
-rw-r--r--agent/CMakeLists.txt18
-rw-r--r--agent/windows-setup-agent/App.config7
-rw-r--r--agent/windows-setup-agent/Icinga2SetupAgent.csproj55
-rw-r--r--agent/windows-setup-agent/Properties/AssemblyInfo.cs4
-rw-r--r--agent/windows-setup-agent/Properties/Resources.Designer.cs4
-rw-r--r--agent/windows-setup-agent/Properties/Settings.Designer.cs4
-rw-r--r--agent/windows-setup-agent/SetupWizard.Designer.cs6
-rw-r--r--agent/windows-setup-agent/SetupWizard.cs2
-rw-r--r--appveyor.yml32
-rwxr-xr-xchangelog.py233
-rw-r--r--choco/CMakeLists.txt19
-rwxr-xr-xchoco/chocolateyInstall.ps1.cmake4
-rwxr-xr-xchoco/icinga2.nuspec.cmake6
-rw-r--r--cmake/FindJSON.cmake9
-rw-r--r--cmake/FindUTF8CPP.cmake7
-rw-r--r--cmake/FindYAJL.cmake28
-rw-r--r--cmake/InstallConfig.cmake18
-rw-r--r--cmake/SetFullDir.cmake17
-rw-r--r--contrib/GPLHeader20
-rwxr-xr-xcontrib/discover-api.py17
-rwxr-xr-xcontrib/discover.py17
-rw-r--r--doc/01-about.md53
-rw-r--r--doc/02-installation.md (renamed from doc/02-getting-started.md)31
-rw-r--r--doc/03-monitoring-basics.md674
-rw-r--r--doc/04-configuration.md (renamed from doc/04-configuring-icinga-2.md)104
-rw-r--r--doc/05-service-monitoring.md772
-rw-r--r--doc/06-distributed-monitoring.md1340
-rw-r--r--doc/07-agent-based-monitoring.md8
-rw-r--r--doc/08-advanced-topics.md56
-rw-r--r--doc/09-object-types.md187
-rw-r--r--doc/10-icinga-template-library.md895
-rw-r--r--doc/11-cli-commands.md138
-rw-r--r--doc/12-icinga2-api.md337
-rw-r--r--doc/13-addons.md2
-rw-r--r--doc/14-features.md131
-rw-r--r--doc/15-troubleshooting.md293
-rw-r--r--doc/16-upgrading-icinga-2.md290
-rw-r--r--doc/17-language-reference.md43
-rw-r--r--doc/18-library-reference.md82
-rw-r--r--doc/19-technical-concepts.md543
-rw-r--r--doc/20-script-debugger.md6
-rw-r--r--doc/21-development.md1291
-rw-r--r--doc/22-selinux.md30
-rw-r--r--doc/23-migrating-from-icinga-1x.md32
-rw-r--r--doc/24-appendix.md2
-rw-r--r--doc/CMakeLists.txt17
-rw-r--r--doc/icinga2.84
-rw-r--r--doc/images/api/icinga2_api_powershell_ise.pngbin0 -> 503887 bytes
-rw-r--r--doc/images/development/windows_boost_build_dev_cmd.pngbin0 -> 14058 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_endpoints.pngbin13374 -> 0 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_monitoring_agent_checks_command_endpoint.pngbin0 -> 91755 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_monitoring_endpoints.pngbin0 -> 75860 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_monitoring_roles.pngbin0 -> 114197 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_monitoring_satellite_config_sync.pngbin0 -> 88721 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_monitoring_scenario_ha_masters_with_agents.pngbin0 -> 137403 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_monitoring_scenarios_master_satellites_agents.pngbin0 -> 147103 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_monitoring_scenarios_master_with_agents.pngbin0 -> 127139 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_monitoring_zones.pngbin0 -> 120164 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_roles.pngbin19711 -> 0 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_scenarios_ha_master_clients.pngbin41392 -> 0 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_scenarios_master_clients.pngbin24345 -> 0 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_scenarios_master_satellite_client.pngbin60888 -> 0 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_top_down_command_endpoint.pngbin16443 -> 0 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_top_down_config_sync.pngbin19577 -> 0 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_windows_client_disk_icingaweb2.pngbin128430 -> 104924 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_windows_nscp.pngbin21112 -> 0 bytes
-rw-r--r--doc/images/distributed-monitoring/icinga2_distributed_zones.pngbin15201 -> 0 bytes
-rwxr-xr-xdoc/update-links.py17
-rw-r--r--etc/CMakeLists.txt17
-rw-r--r--etc/icinga2/conf.d/hosts.conf2
-rw-r--r--etc/icinga2/conf.d/notifications.conf2
-rw-r--r--etc/icinga2/conf.d/services.conf2
-rw-r--r--etc/icinga2/conf.d/win32/hosts.conf2
-rwxr-xr-xetc/icinga2/scripts/mail-host-notification.sh28
-rwxr-xr-xetc/icinga2/scripts/mail-service-notification.sh26
-rw-r--r--etc/initsystem/CMakeLists.txt17
-rw-r--r--etc/initsystem/icinga2.init.d.cmake7
-rw-r--r--etc/initsystem/icinga2.service.cmake2
-rw-r--r--etc/logrotate.d/icinga2.cmake6
-rw-r--r--icinga-app/CMakeLists.txt18
-rw-r--r--icinga-app/icinga.cpp27
-rw-r--r--icinga-app/icinga.rc6
-rw-r--r--icinga-installer/CMakeLists.txt17
-rw-r--r--icinga-installer/icinga-installer.cpp20
-rw-r--r--icinga-installer/icinga2.wixpatch.cmake5
-rw-r--r--itl/CMakeLists.txt17
-rw-r--r--itl/command-icinga.conf23
-rw-r--r--itl/command-nscp-local.conf23
-rw-r--r--itl/command-plugins-manubulon.conf30
-rw-r--r--itl/command-plugins-windows.conf33
-rw-r--r--itl/command-plugins.conf32
-rw-r--r--itl/hangman19
-rw-r--r--itl/itl19
-rw-r--r--itl/manubulon19
-rw-r--r--itl/nscp19
-rw-r--r--itl/plugins19
-rw-r--r--itl/plugins-contrib19
-rw-r--r--itl/plugins-contrib.d/CMakeLists.txt17
-rw-r--r--itl/plugins-contrib.d/big-data.conf85
-rw-r--r--itl/plugins-contrib.d/databases.conf136
-rw-r--r--itl/plugins-contrib.d/hardware.conf97
-rw-r--r--itl/plugins-contrib.d/icingacli.conf86
-rw-r--r--itl/plugins-contrib.d/ipmi.conf23
-rw-r--r--itl/plugins-contrib.d/logmanagement.conf122
-rw-r--r--itl/plugins-contrib.d/metrics.conf19
-rw-r--r--itl/plugins-contrib.d/network-components.conf185
-rw-r--r--itl/plugins-contrib.d/network-services.conf72
-rw-r--r--itl/plugins-contrib.d/operating-system.conf19
-rw-r--r--itl/plugins-contrib.d/raid-controller.conf4
-rw-r--r--itl/plugins-contrib.d/smart-attributes.conf2
-rw-r--r--itl/plugins-contrib.d/storage.conf55
-rw-r--r--itl/plugins-contrib.d/virtualization.conf24
-rw-r--r--itl/plugins-contrib.d/vmware.conf19
-rw-r--r--itl/plugins-contrib.d/web.conf210
-rw-r--r--itl/windows-plugins19
-rw-r--r--lib/CMakeLists.txt17
-rw-r--r--lib/base/CMakeLists.txt22
-rw-r--r--lib/base/application-environment.cpp19
-rw-r--r--lib/base/application-version.cpp19
-rw-r--r--lib/base/application.cpp243
-rw-r--r--lib/base/application.hpp38
-rw-r--r--lib/base/application.ti19
-rw-r--r--lib/base/array-script.cpp36
-rw-r--r--lib/base/array.cpp42
-rw-r--r--lib/base/array.hpp20
-rw-r--r--lib/base/atomic.hpp43
-rw-r--r--lib/base/base64.cpp19
-rw-r--r--lib/base/base64.hpp19
-rw-r--r--lib/base/boolean-script.cpp19
-rw-r--r--lib/base/boolean.cpp19
-rw-r--r--lib/base/boolean.hpp19
-rw-r--r--lib/base/configobject-script.cpp19
-rw-r--r--lib/base/configobject.cpp40
-rw-r--r--lib/base/configobject.hpp19
-rw-r--r--lib/base/configobject.ti19
-rw-r--r--lib/base/configtype.cpp19
-rw-r--r--lib/base/configtype.hpp19
-rw-r--r--lib/base/configuration.cpp19
-rw-r--r--lib/base/configuration.hpp19
-rw-r--r--lib/base/configuration.ti19
-rw-r--r--lib/base/configwriter.cpp19
-rw-r--r--lib/base/configwriter.hpp19
-rw-r--r--lib/base/console.cpp19
-rw-r--r--lib/base/console.hpp19
-rw-r--r--lib/base/context.cpp19
-rw-r--r--lib/base/context.hpp19
-rw-r--r--lib/base/convert.cpp19
-rw-r--r--lib/base/convert.hpp19
-rw-r--r--lib/base/datetime-script.cpp19
-rw-r--r--lib/base/datetime.cpp19
-rw-r--r--lib/base/datetime.hpp19
-rw-r--r--lib/base/datetime.ti19
-rw-r--r--lib/base/debug.hpp19
-rw-r--r--lib/base/debuginfo.cpp19
-rw-r--r--lib/base/debuginfo.hpp19
-rw-r--r--lib/base/dependencygraph.cpp19
-rw-r--r--lib/base/dependencygraph.hpp19
-rw-r--r--lib/base/dictionary-script.cpp19
-rw-r--r--lib/base/dictionary.cpp19
-rw-r--r--lib/base/dictionary.hpp19
-rw-r--r--lib/base/exception.cpp24
-rw-r--r--lib/base/exception.hpp21
-rw-r--r--lib/base/fifo.cpp19
-rw-r--r--lib/base/fifo.hpp19
-rw-r--r--lib/base/filelogger.cpp19
-rw-r--r--lib/base/filelogger.hpp19
-rw-r--r--lib/base/filelogger.ti19
-rw-r--r--lib/base/function-script.cpp19
-rw-r--r--lib/base/function.cpp19
-rw-r--r--lib/base/function.hpp19
-rw-r--r--lib/base/function.ti19
-rw-r--r--lib/base/functionwrapper.hpp19
-rw-r--r--lib/base/i2-base.hpp27
-rw-r--r--lib/base/initialize.cpp19
-rw-r--r--lib/base/initialize.hpp19
-rw-r--r--lib/base/io-engine.cpp145
-rw-r--r--lib/base/io-engine.hpp118
-rw-r--r--lib/base/json-script.cpp19
-rw-r--r--lib/base/json.cpp612
-rw-r--r--lib/base/json.hpp19
-rw-r--r--lib/base/lazy-init.hpp72
-rw-r--r--lib/base/library.cpp19
-rw-r--r--lib/base/library.hpp19
-rw-r--r--lib/base/loader.cpp19
-rw-r--r--lib/base/loader.hpp19
-rw-r--r--lib/base/logger.cpp19
-rw-r--r--lib/base/logger.hpp19
-rw-r--r--lib/base/logger.ti19
-rw-r--r--lib/base/math-script.cpp19
-rw-r--r--lib/base/namespace-script.cpp19
-rw-r--r--lib/base/namespace.cpp19
-rw-r--r--lib/base/namespace.hpp19
-rw-r--r--lib/base/netstring.cpp233
-rw-r--r--lib/base/netstring.hpp27
-rw-r--r--lib/base/networkstream.cpp19
-rw-r--r--lib/base/networkstream.hpp21
-rw-r--r--lib/base/number-script.cpp19
-rw-r--r--lib/base/number.cpp19
-rw-r--r--lib/base/number.hpp19
-rw-r--r--lib/base/object-packer.cpp45
-rw-r--r--lib/base/object-packer.hpp19
-rw-r--r--lib/base/object-script.cpp19
-rw-r--r--lib/base/object.cpp63
-rw-r--r--lib/base/object.hpp35
-rw-r--r--lib/base/objectlock.cpp97
-rw-r--r--lib/base/objectlock.hpp24
-rw-r--r--lib/base/objecttype.cpp19
-rw-r--r--lib/base/objecttype.hpp19
-rw-r--r--lib/base/perfdatavalue.cpp19
-rw-r--r--lib/base/perfdatavalue.hpp19
-rw-r--r--lib/base/perfdatavalue.ti19
-rw-r--r--lib/base/primitivetype.cpp19
-rw-r--r--lib/base/primitivetype.hpp19
-rw-r--r--lib/base/process.cpp59
-rw-r--r--lib/base/process.hpp19
-rw-r--r--lib/base/reference-script.cpp19
-rw-r--r--lib/base/reference.cpp19
-rw-r--r--lib/base/reference.hpp19
-rw-r--r--lib/base/registry.hpp19
-rw-r--r--lib/base/ringbuffer.cpp19
-rw-r--r--lib/base/ringbuffer.hpp19
-rw-r--r--lib/base/scriptframe.cpp23
-rw-r--r--lib/base/scriptframe.hpp19
-rw-r--r--lib/base/scriptglobal.cpp31
-rw-r--r--lib/base/scriptglobal.hpp19
-rw-r--r--lib/base/scriptutils.cpp25
-rw-r--r--lib/base/scriptutils.hpp20
-rw-r--r--lib/base/serializer.cpp19
-rw-r--r--lib/base/serializer.hpp20
-rw-r--r--lib/base/singleton.hpp19
-rw-r--r--lib/base/socket.cpp19
-rw-r--r--lib/base/socket.hpp19
-rw-r--r--lib/base/socketevents-epoll.cpp205
-rw-r--r--lib/base/socketevents-poll.cpp206
-rw-r--r--lib/base/socketevents.cpp158
-rw-r--r--lib/base/socketevents.hpp154
-rw-r--r--lib/base/stacktrace.cpp19
-rw-r--r--lib/base/stacktrace.hpp19
-rw-r--r--lib/base/statsfunction.hpp19
-rw-r--r--lib/base/stdiostream.cpp19
-rw-r--r--lib/base/stdiostream.hpp19
-rw-r--r--lib/base/stream.cpp19
-rw-r--r--lib/base/stream.hpp19
-rw-r--r--lib/base/streamlogger.cpp19
-rw-r--r--lib/base/streamlogger.hpp19
-rw-r--r--lib/base/streamlogger.ti19
-rw-r--r--lib/base/string-script.cpp19
-rw-r--r--lib/base/string.cpp19
-rw-r--r--lib/base/string.hpp19
-rw-r--r--lib/base/stringbuilder.cpp36
-rw-r--r--lib/base/stringbuilder.hpp36
-rw-r--r--lib/base/sysloglogger.cpp19
-rw-r--r--lib/base/sysloglogger.hpp19
-rw-r--r--lib/base/sysloglogger.ti19
-rw-r--r--lib/base/tcpsocket.cpp19
-rw-r--r--lib/base/tcpsocket.hpp87
-rw-r--r--lib/base/threadpool.cpp386
-rw-r--r--lib/base/threadpool.hpp141
-rw-r--r--lib/base/timer.cpp22
-rw-r--r--lib/base/timer.hpp19
-rw-r--r--lib/base/tlsstream.cpp442
-rw-r--r--lib/base/tlsstream.hpp134
-rw-r--r--lib/base/tlsutility.cpp176
-rw-r--r--lib/base/tlsutility.hpp34
-rw-r--r--lib/base/type.cpp19
-rw-r--r--lib/base/type.hpp19
-rw-r--r--lib/base/typetype-script.cpp19
-rw-r--r--lib/base/unix.hpp19
-rw-r--r--lib/base/unixsocket.cpp19
-rw-r--r--lib/base/unixsocket.hpp24
-rw-r--r--lib/base/utility.cpp249
-rw-r--r--lib/base/utility.hpp24
-rw-r--r--lib/base/value-operators.cpp19
-rw-r--r--lib/base/value.cpp19
-rw-r--r--lib/base/value.hpp19
-rw-r--r--lib/base/win32.hpp19
-rw-r--r--lib/base/workqueue.cpp23
-rw-r--r--lib/base/workqueue.hpp28
-rw-r--r--lib/checker/CMakeLists.txt17
-rw-r--r--lib/checker/checkercomponent.cpp63
-rw-r--r--lib/checker/checkercomponent.hpp19
-rw-r--r--lib/checker/checkercomponent.ti34
-rw-r--r--lib/cli/CMakeLists.txt20
-rw-r--r--lib/cli/apisetupcommand.cpp39
-rw-r--r--lib/cli/apisetupcommand.hpp22
-rw-r--r--lib/cli/apisetuputility.cpp49
-rw-r--r--lib/cli/apisetuputility.hpp19
-rw-r--r--lib/cli/calistcommand.cpp52
-rw-r--r--lib/cli/calistcommand.hpp19
-rw-r--r--lib/cli/caremovecommand.cpp93
-rw-r--r--lib/cli/caremovecommand.hpp30
-rw-r--r--lib/cli/carestorecommand.cpp88
-rw-r--r--lib/cli/carestorecommand.hpp30
-rw-r--r--lib/cli/casigncommand.cpp43
-rw-r--r--lib/cli/casigncommand.hpp19
-rw-r--r--lib/cli/clicommand.cpp19
-rw-r--r--lib/cli/clicommand.hpp19
-rw-r--r--lib/cli/consolecommand.cpp397
-rw-r--r--lib/cli/consolecommand.hpp35
-rw-r--r--lib/cli/daemoncommand.cpp618
-rw-r--r--lib/cli/daemoncommand.hpp19
-rw-r--r--lib/cli/daemonutility.cpp69
-rw-r--r--lib/cli/daemonutility.hpp19
-rw-r--r--lib/cli/editline.hpp19
-rw-r--r--lib/cli/featuredisablecommand.cpp21
-rw-r--r--lib/cli/featuredisablecommand.hpp19
-rw-r--r--lib/cli/featureenablecommand.cpp21
-rw-r--r--lib/cli/featureenablecommand.hpp19
-rw-r--r--lib/cli/featurelistcommand.cpp19
-rw-r--r--lib/cli/featurelistcommand.hpp19
-rw-r--r--lib/cli/featureutility.cpp19
-rw-r--r--lib/cli/featureutility.hpp19
-rw-r--r--lib/cli/i2-cli.hpp19
-rw-r--r--lib/cli/internalsignalcommand.cpp19
-rw-r--r--lib/cli/internalsignalcommand.hpp19
-rw-r--r--lib/cli/nodesetupcommand.cpp59
-rw-r--r--lib/cli/nodesetupcommand.hpp19
-rw-r--r--lib/cli/nodeutility.cpp95
-rw-r--r--lib/cli/nodeutility.hpp20
-rw-r--r--lib/cli/nodewizardcommand.cpp68
-rw-r--r--lib/cli/nodewizardcommand.hpp21
-rw-r--r--lib/cli/objectlistcommand.cpp19
-rw-r--r--lib/cli/objectlistcommand.hpp19
-rw-r--r--lib/cli/objectlistutility.cpp19
-rw-r--r--lib/cli/objectlistutility.hpp19
-rw-r--r--lib/cli/pkinewcacommand.cpp19
-rw-r--r--lib/cli/pkinewcacommand.hpp19
-rw-r--r--lib/cli/pkinewcertcommand.cpp19
-rw-r--r--lib/cli/pkinewcertcommand.hpp19
-rw-r--r--lib/cli/pkirequestcommand.cpp19
-rw-r--r--lib/cli/pkirequestcommand.hpp19
-rw-r--r--lib/cli/pkisavecertcommand.cpp19
-rw-r--r--lib/cli/pkisavecertcommand.hpp19
-rw-r--r--lib/cli/pkisigncsrcommand.cpp19
-rw-r--r--lib/cli/pkisigncsrcommand.hpp19
-rw-r--r--lib/cli/pkiticketcommand.cpp19
-rw-r--r--lib/cli/pkiticketcommand.hpp19
-rw-r--r--lib/cli/troubleshootcommand.cpp703
-rw-r--r--lib/cli/troubleshootcommand.hpp71
-rw-r--r--lib/cli/variablegetcommand.cpp19
-rw-r--r--lib/cli/variablegetcommand.hpp19
-rw-r--r--lib/cli/variablelistcommand.cpp19
-rw-r--r--lib/cli/variablelistcommand.hpp19
-rw-r--r--lib/cli/variableutility.cpp19
-rw-r--r--lib/cli/variableutility.hpp19
-rw-r--r--lib/compat/CMakeLists.txt17
-rw-r--r--lib/compat/checkresultreader.cpp35
-rw-r--r--lib/compat/checkresultreader.hpp19
-rw-r--r--lib/compat/checkresultreader.ti19
-rw-r--r--lib/compat/compatlogger.cpp27
-rw-r--r--lib/compat/compatlogger.hpp23
-rw-r--r--lib/compat/compatlogger.ti19
-rw-r--r--lib/compat/externalcommandlistener.cpp28
-rw-r--r--lib/compat/externalcommandlistener.hpp19
-rw-r--r--lib/compat/externalcommandlistener.ti19
-rw-r--r--lib/compat/statusdatawriter.cpp44
-rw-r--r--lib/compat/statusdatawriter.hpp19
-rw-r--r--lib/compat/statusdatawriter.ti19
-rw-r--r--lib/config/CMakeLists.txt17
-rw-r--r--lib/config/activationcontext.cpp19
-rw-r--r--lib/config/activationcontext.hpp19
-rw-r--r--lib/config/applyrule.cpp19
-rw-r--r--lib/config/applyrule.hpp19
-rw-r--r--lib/config/config_lexer.ll19
-rw-r--r--lib/config/config_parser.yy21
-rw-r--r--lib/config/configcompiler.cpp22
-rw-r--r--lib/config/configcompiler.hpp19
-rw-r--r--lib/config/configcompilercontext.cpp31
-rw-r--r--lib/config/configcompilercontext.hpp19
-rw-r--r--lib/config/configfragment.hpp19
-rw-r--r--lib/config/configitem.cpp20
-rw-r--r--lib/config/configitem.hpp19
-rw-r--r--lib/config/configitembuilder.cpp19
-rw-r--r--lib/config/configitembuilder.hpp19
-rw-r--r--lib/config/expression.cpp19
-rw-r--r--lib/config/expression.hpp19
-rw-r--r--lib/config/i2-config.hpp19
-rw-r--r--lib/config/objectrule.cpp19
-rw-r--r--lib/config/objectrule.hpp19
-rw-r--r--lib/config/vmops.hpp23
-rw-r--r--lib/db_ido/CMakeLists.txt17
-rw-r--r--lib/db_ido/commanddbobject.cpp19
-rw-r--r--lib/db_ido/commanddbobject.hpp19
-rw-r--r--lib/db_ido/db_ido-itl.conf19
-rw-r--r--lib/db_ido/dbconnection.cpp42
-rw-r--r--lib/db_ido/dbconnection.hpp19
-rw-r--r--lib/db_ido/dbconnection.ti23
-rw-r--r--lib/db_ido/dbevents.cpp68
-rw-r--r--lib/db_ido/dbevents.hpp23
-rw-r--r--lib/db_ido/dbobject.cpp19
-rw-r--r--lib/db_ido/dbobject.hpp19
-rw-r--r--lib/db_ido/dbquery.cpp19
-rw-r--r--lib/db_ido/dbquery.hpp19
-rw-r--r--lib/db_ido/dbreference.cpp19
-rw-r--r--lib/db_ido/dbreference.hpp19
-rw-r--r--lib/db_ido/dbtype.cpp19
-rw-r--r--lib/db_ido/dbtype.hpp19
-rw-r--r--lib/db_ido/dbvalue.cpp19
-rw-r--r--lib/db_ido/dbvalue.hpp19
-rw-r--r--lib/db_ido/endpointdbobject.cpp19
-rw-r--r--lib/db_ido/endpointdbobject.hpp19
-rw-r--r--lib/db_ido/hostdbobject.cpp23
-rw-r--r--lib/db_ido/hostdbobject.hpp19
-rw-r--r--lib/db_ido/hostgroupdbobject.cpp19
-rw-r--r--lib/db_ido/hostgroupdbobject.hpp19
-rw-r--r--lib/db_ido/i2-db_ido.hpp19
-rw-r--r--lib/db_ido/idochecktask.cpp25
-rw-r--r--lib/db_ido/idochecktask.hpp19
-rw-r--r--lib/db_ido/servicedbobject.cpp36
-rw-r--r--lib/db_ido/servicedbobject.hpp19
-rw-r--r--lib/db_ido/servicegroupdbobject.cpp19
-rw-r--r--lib/db_ido/servicegroupdbobject.hpp19
-rw-r--r--lib/db_ido/timeperioddbobject.cpp19
-rw-r--r--lib/db_ido/timeperioddbobject.hpp19
-rw-r--r--lib/db_ido/userdbobject.cpp19
-rw-r--r--lib/db_ido/userdbobject.hpp19
-rw-r--r--lib/db_ido/usergroupdbobject.cpp19
-rw-r--r--lib/db_ido/usergroupdbobject.hpp19
-rw-r--r--lib/db_ido/zonedbobject.cpp19
-rw-r--r--lib/db_ido/zonedbobject.hpp19
-rw-r--r--lib/db_ido_mysql/CMakeLists.txt17
-rw-r--r--lib/db_ido_mysql/idomysqlconnection.cpp93
-rw-r--r--lib/db_ido_mysql/idomysqlconnection.hpp19
-rw-r--r--lib/db_ido_mysql/idomysqlconnection.ti19
-rw-r--r--lib/db_ido_mysql/schema/mysql.sql34
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.0.2.sql2
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.1.0.sql2
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.11.0.sql40
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.2.0.sql2
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.3.0.sql2
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.4.0.sql2
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.5.0.sql2
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.6.0.sql2
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.8.0.sql2
-rw-r--r--lib/db_ido_mysql/schema/upgrade/2.8.1.sql2
-rw-r--r--lib/db_ido_pgsql/CMakeLists.txt17
-rw-r--r--lib/db_ido_pgsql/idopgsqlconnection.cpp74
-rw-r--r--lib/db_ido_pgsql/idopgsqlconnection.hpp19
-rw-r--r--lib/db_ido_pgsql/idopgsqlconnection.ti19
-rw-r--r--lib/db_ido_pgsql/schema/pgsql.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.0.2.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.1.0.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.2.0.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.3.0.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.4.0.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.5.0.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.6.0.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.8.0.sql2
-rw-r--r--lib/db_ido_pgsql/schema/upgrade/2.8.1.sql2
-rw-r--r--lib/icinga/CMakeLists.txt19
-rw-r--r--lib/icinga/apiactions.cpp94
-rw-r--r--lib/icinga/apiactions.hpp19
-rw-r--r--lib/icinga/apievents.cpp87
-rw-r--r--lib/icinga/apievents.hpp19
-rw-r--r--lib/icinga/checkable-check.cpp94
-rw-r--r--lib/icinga/checkable-comment.cpp19
-rw-r--r--lib/icinga/checkable-dependency.cpp26
-rw-r--r--lib/icinga/checkable-downtime.cpp19
-rw-r--r--lib/icinga/checkable-event.cpp19
-rw-r--r--lib/icinga/checkable-flapping.cpp19
-rw-r--r--lib/icinga/checkable-notification.cpp216
-rw-r--r--lib/icinga/checkable-script.cpp19
-rw-r--r--lib/icinga/checkable.cpp56
-rw-r--r--lib/icinga/checkable.hpp31
-rw-r--r--lib/icinga/checkable.ti31
-rw-r--r--lib/icinga/checkcommand.cpp19
-rw-r--r--lib/icinga/checkcommand.hpp19
-rw-r--r--lib/icinga/checkcommand.ti19
-rw-r--r--lib/icinga/checkresult.cpp19
-rw-r--r--lib/icinga/checkresult.hpp19
-rw-r--r--lib/icinga/checkresult.ti19
-rw-r--r--lib/icinga/cib.cpp19
-rw-r--r--lib/icinga/cib.hpp19
-rw-r--r--lib/icinga/clusterevents-check.cpp27
-rw-r--r--lib/icinga/clusterevents.cpp96
-rw-r--r--lib/icinga/clusterevents.hpp25
-rw-r--r--lib/icinga/command.cpp19
-rw-r--r--lib/icinga/command.hpp19
-rw-r--r--lib/icinga/command.ti19
-rw-r--r--lib/icinga/comment.cpp19
-rw-r--r--lib/icinga/comment.hpp19
-rw-r--r--lib/icinga/comment.ti19
-rw-r--r--lib/icinga/compatutility.cpp19
-rw-r--r--lib/icinga/compatutility.hpp19
-rw-r--r--lib/icinga/customvarobject.cpp19
-rw-r--r--lib/icinga/customvarobject.hpp19
-rw-r--r--lib/icinga/customvarobject.ti19
-rw-r--r--lib/icinga/dependency-apply.cpp19
-rw-r--r--lib/icinga/dependency.cpp19
-rw-r--r--lib/icinga/dependency.hpp19
-rw-r--r--lib/icinga/dependency.ti19
-rw-r--r--lib/icinga/downtime.cpp19
-rw-r--r--lib/icinga/downtime.hpp19
-rw-r--r--lib/icinga/downtime.ti19
-rw-r--r--lib/icinga/eventcommand.cpp19
-rw-r--r--lib/icinga/eventcommand.hpp19
-rw-r--r--lib/icinga/eventcommand.ti19
-rw-r--r--lib/icinga/externalcommandprocessor.cpp19
-rw-r--r--lib/icinga/externalcommandprocessor.hpp19
-rw-r--r--lib/icinga/host.cpp21
-rw-r--r--lib/icinga/host.hpp21
-rw-r--r--lib/icinga/host.ti19
-rw-r--r--lib/icinga/hostgroup.cpp19
-rw-r--r--lib/icinga/hostgroup.hpp19
-rw-r--r--lib/icinga/hostgroup.ti19
-rw-r--r--lib/icinga/i2-icinga.hpp19
-rw-r--r--lib/icinga/icinga-itl.conf19
-rw-r--r--lib/icinga/icingaapplication.cpp40
-rw-r--r--lib/icinga/icingaapplication.hpp21
-rw-r--r--lib/icinga/icingaapplication.ti21
-rw-r--r--lib/icinga/legacytimeperiod.cpp59
-rw-r--r--lib/icinga/legacytimeperiod.hpp22
-rw-r--r--lib/icinga/macroprocessor.cpp19
-rw-r--r--lib/icinga/macroprocessor.hpp19
-rw-r--r--lib/icinga/macroresolver.hpp19
-rw-r--r--lib/icinga/notification-apply.cpp19
-rw-r--r--lib/icinga/notification.cpp264
-rw-r--r--lib/icinga/notification.hpp34
-rw-r--r--lib/icinga/notification.ti27
-rw-r--r--lib/icinga/notificationcommand.cpp26
-rw-r--r--lib/icinga/notificationcommand.hpp23
-rw-r--r--lib/icinga/notificationcommand.ti19
-rw-r--r--lib/icinga/notificationresult.cpp13
-rw-r--r--lib/icinga/notificationresult.hpp27
-rw-r--r--lib/icinga/notificationresult.ti24
-rw-r--r--lib/icinga/objectutils.cpp19
-rw-r--r--lib/icinga/objectutils.hpp19
-rw-r--r--lib/icinga/pluginutility.cpp19
-rw-r--r--lib/icinga/pluginutility.hpp19
-rw-r--r--lib/icinga/scheduleddowntime-apply.cpp19
-rw-r--r--lib/icinga/scheduleddowntime.cpp23
-rw-r--r--lib/icinga/scheduleddowntime.hpp19
-rw-r--r--lib/icinga/scheduleddowntime.ti19
-rw-r--r--lib/icinga/service-apply.cpp19
-rw-r--r--lib/icinga/service.cpp28
-rw-r--r--lib/icinga/service.hpp22
-rw-r--r--lib/icinga/service.ti19
-rw-r--r--lib/icinga/servicegroup.cpp19
-rw-r--r--lib/icinga/servicegroup.hpp19
-rw-r--r--lib/icinga/servicegroup.ti19
-rw-r--r--lib/icinga/timeperiod.cpp19
-rw-r--r--lib/icinga/timeperiod.hpp19
-rw-r--r--lib/icinga/timeperiod.ti19
-rw-r--r--lib/icinga/user.cpp19
-rw-r--r--lib/icinga/user.hpp19
-rw-r--r--lib/icinga/user.ti19
-rw-r--r--lib/icinga/usergroup.cpp19
-rw-r--r--lib/icinga/usergroup.hpp19
-rw-r--r--lib/icinga/usergroup.ti19
-rw-r--r--lib/livestatus/CMakeLists.txt17
-rw-r--r--lib/livestatus/aggregator.cpp19
-rw-r--r--lib/livestatus/aggregator.hpp19
-rw-r--r--lib/livestatus/andfilter.cpp19
-rw-r--r--lib/livestatus/andfilter.hpp19
-rw-r--r--lib/livestatus/attributefilter.cpp19
-rw-r--r--lib/livestatus/attributefilter.hpp19
-rw-r--r--lib/livestatus/avgaggregator.cpp19
-rw-r--r--lib/livestatus/avgaggregator.hpp19
-rw-r--r--lib/livestatus/column.cpp19
-rw-r--r--lib/livestatus/column.hpp19
-rw-r--r--lib/livestatus/combinerfilter.cpp19
-rw-r--r--lib/livestatus/combinerfilter.hpp19
-rw-r--r--lib/livestatus/commandstable.cpp19
-rw-r--r--lib/livestatus/commandstable.hpp19
-rw-r--r--lib/livestatus/commentstable.cpp20
-rw-r--r--lib/livestatus/commentstable.hpp19
-rw-r--r--lib/livestatus/contactgroupstable.cpp19
-rw-r--r--lib/livestatus/contactgroupstable.hpp19
-rw-r--r--lib/livestatus/contactstable.cpp20
-rw-r--r--lib/livestatus/contactstable.hpp19
-rw-r--r--lib/livestatus/countaggregator.cpp19
-rw-r--r--lib/livestatus/countaggregator.hpp19
-rw-r--r--lib/livestatus/downtimestable.cpp20
-rw-r--r--lib/livestatus/downtimestable.hpp19
-rw-r--r--lib/livestatus/endpointstable.cpp20
-rw-r--r--lib/livestatus/endpointstable.hpp19
-rw-r--r--lib/livestatus/filter.hpp19
-rw-r--r--lib/livestatus/historytable.hpp19
-rw-r--r--lib/livestatus/hostgroupstable.cpp19
-rw-r--r--lib/livestatus/hostgroupstable.hpp19
-rw-r--r--lib/livestatus/hoststable.cpp20
-rw-r--r--lib/livestatus/hoststable.hpp19
-rw-r--r--lib/livestatus/i2-livestatus.hpp19
-rw-r--r--lib/livestatus/invavgaggregator.cpp19
-rw-r--r--lib/livestatus/invavgaggregator.hpp19
-rw-r--r--lib/livestatus/invsumaggregator.cpp19
-rw-r--r--lib/livestatus/invsumaggregator.hpp19
-rw-r--r--lib/livestatus/livestatuslistener.cpp19
-rw-r--r--lib/livestatus/livestatuslistener.hpp19
-rw-r--r--lib/livestatus/livestatuslistener.ti19
-rw-r--r--lib/livestatus/livestatuslogutility.cpp20
-rw-r--r--lib/livestatus/livestatuslogutility.hpp19
-rw-r--r--lib/livestatus/livestatusquery.cpp19
-rw-r--r--lib/livestatus/livestatusquery.hpp19
-rw-r--r--lib/livestatus/logtable.cpp20
-rw-r--r--lib/livestatus/logtable.hpp19
-rw-r--r--lib/livestatus/maxaggregator.cpp19
-rw-r--r--lib/livestatus/maxaggregator.hpp19
-rw-r--r--lib/livestatus/minaggregator.cpp19
-rw-r--r--lib/livestatus/minaggregator.hpp19
-rw-r--r--lib/livestatus/negatefilter.cpp19
-rw-r--r--lib/livestatus/negatefilter.hpp19
-rw-r--r--lib/livestatus/orfilter.cpp19
-rw-r--r--lib/livestatus/orfilter.hpp19
-rw-r--r--lib/livestatus/servicegroupstable.cpp19
-rw-r--r--lib/livestatus/servicegroupstable.hpp19
-rw-r--r--lib/livestatus/servicestable.cpp20
-rw-r--r--lib/livestatus/servicestable.hpp19
-rw-r--r--lib/livestatus/statehisttable.cpp20
-rw-r--r--lib/livestatus/statehisttable.hpp19
-rw-r--r--lib/livestatus/statustable.cpp19
-rw-r--r--lib/livestatus/statustable.hpp19
-rw-r--r--lib/livestatus/stdaggregator.cpp19
-rw-r--r--lib/livestatus/stdaggregator.hpp19
-rw-r--r--lib/livestatus/sumaggregator.cpp19
-rw-r--r--lib/livestatus/sumaggregator.hpp19
-rw-r--r--lib/livestatus/table.cpp20
-rw-r--r--lib/livestatus/table.hpp19
-rw-r--r--lib/livestatus/timeperiodstable.cpp19
-rw-r--r--lib/livestatus/timeperiodstable.hpp19
-rw-r--r--lib/livestatus/zonestable.cpp19
-rw-r--r--lib/livestatus/zonestable.hpp19
-rw-r--r--lib/methods/CMakeLists.txt18
-rw-r--r--lib/methods/clusterchecktask.cpp23
-rw-r--r--lib/methods/clusterchecktask.hpp19
-rw-r--r--lib/methods/clusterzonechecktask.cpp27
-rw-r--r--lib/methods/clusterzonechecktask.hpp19
-rw-r--r--lib/methods/dummychecktask.cpp24
-rw-r--r--lib/methods/dummychecktask.hpp19
-rw-r--r--lib/methods/exceptionchecktask.cpp19
-rw-r--r--lib/methods/exceptionchecktask.hpp19
-rw-r--r--lib/methods/i2-methods.hpp19
-rw-r--r--lib/methods/icingachecktask.cpp39
-rw-r--r--lib/methods/icingachecktask.hpp19
-rw-r--r--lib/methods/methods-itl.conf28
-rw-r--r--lib/methods/nullchecktask.cpp19
-rw-r--r--lib/methods/nullchecktask.hpp19
-rw-r--r--lib/methods/nulleventtask.cpp19
-rw-r--r--lib/methods/nulleventtask.hpp19
-rw-r--r--lib/methods/pluginchecktask.cpp19
-rw-r--r--lib/methods/pluginchecktask.hpp19
-rw-r--r--lib/methods/plugineventtask.cpp19
-rw-r--r--lib/methods/plugineventtask.hpp19
-rw-r--r--lib/methods/pluginnotificationtask.cpp47
-rw-r--r--lib/methods/pluginnotificationtask.hpp24
-rw-r--r--lib/methods/randomchecktask.cpp23
-rw-r--r--lib/methods/randomchecktask.hpp19
-rw-r--r--lib/methods/sleepchecktask.cpp54
-rw-r--r--lib/methods/sleepchecktask.hpp30
-rw-r--r--lib/methods/timeperiodtask.cpp19
-rw-r--r--lib/methods/timeperiodtask.hpp19
-rw-r--r--lib/mysql_shim/CMakeLists.txt17
-rw-r--r--lib/mysql_shim/mysqlinterface.cpp21
-rw-r--r--lib/mysql_shim/mysqlinterface.hpp21
-rw-r--r--lib/notification/CMakeLists.txt17
-rw-r--r--lib/notification/notificationcomponent.cpp97
-rw-r--r--lib/notification/notificationcomponent.hpp19
-rw-r--r--lib/notification/notificationcomponent.ti21
-rw-r--r--lib/perfdata/CMakeLists.txt17
-rw-r--r--lib/perfdata/elasticsearchwriter.cpp248
-rw-r--r--lib/perfdata/elasticsearchwriter.hpp29
-rw-r--r--lib/perfdata/elasticsearchwriter.ti5
-rw-r--r--lib/perfdata/gelfwriter.cpp187
-rw-r--r--lib/perfdata/gelfwriter.hpp33
-rw-r--r--lib/perfdata/gelfwriter.ti28
-rw-r--r--lib/perfdata/graphitewriter.cpp263
-rw-r--r--lib/perfdata/graphitewriter.hpp31
-rw-r--r--lib/perfdata/graphitewriter.ti22
-rw-r--r--lib/perfdata/influxdbwriter.cpp229
-rw-r--r--lib/perfdata/influxdbwriter.hpp29
-rw-r--r--lib/perfdata/influxdbwriter.ti22
-rw-r--r--lib/perfdata/opentsdbwriter.cpp205
-rw-r--r--lib/perfdata/opentsdbwriter.hpp32
-rw-r--r--lib/perfdata/opentsdbwriter.ti27
-rw-r--r--lib/perfdata/perfdatawriter.cpp91
-rw-r--r--lib/perfdata/perfdatawriter.hpp34
-rw-r--r--lib/perfdata/perfdatawriter.ti22
-rw-r--r--lib/pgsql_shim/CMakeLists.txt17
-rw-r--r--lib/pgsql_shim/pgsqlinterface.cpp19
-rw-r--r--lib/pgsql_shim/pgsqlinterface.hpp19
-rw-r--r--lib/remote/CMakeLists.txt25
-rw-r--r--lib/remote/actionshandler.cpp42
-rw-r--r--lib/remote/actionshandler.hpp31
-rw-r--r--lib/remote/apiaction.cpp19
-rw-r--r--lib/remote/apiaction.hpp19
-rw-r--r--lib/remote/apiclient.cpp181
-rw-r--r--lib/remote/apiclient.hpp60
-rw-r--r--lib/remote/apifunction.cpp19
-rw-r--r--lib/remote/apifunction.hpp19
-rw-r--r--lib/remote/apilistener-authority.cpp84
-rw-r--r--lib/remote/apilistener-configsync.cpp41
-rw-r--r--lib/remote/apilistener-filesync.cpp877
-rw-r--r--lib/remote/apilistener.cpp590
-rw-r--r--lib/remote/apilistener.hpp88
-rw-r--r--lib/remote/apilistener.ti25
-rw-r--r--lib/remote/apiuser.cpp19
-rw-r--r--lib/remote/apiuser.hpp19
-rw-r--r--lib/remote/apiuser.ti19
-rw-r--r--lib/remote/authority.cpp80
-rw-r--r--lib/remote/configfileshandler.cpp46
-rw-r--r--lib/remote/configfileshandler.hpp31
-rw-r--r--lib/remote/configobjectutility.cpp142
-rw-r--r--lib/remote/configobjectutility.hpp21
-rw-r--r--lib/remote/configpackageshandler.cpp104
-rw-r--r--lib/remote/configpackageshandler.hpp58
-rw-r--r--lib/remote/configpackageutility.cpp105
-rw-r--r--lib/remote/configpackageutility.hpp25
-rw-r--r--lib/remote/configstageshandler.cpp105
-rw-r--r--lib/remote/configstageshandler.hpp58
-rw-r--r--lib/remote/consolehandler.cpp53
-rw-r--r--lib/remote/consolehandler.hpp37
-rw-r--r--lib/remote/createobjecthandler.cpp46
-rw-r--r--lib/remote/createobjecthandler.hpp31
-rw-r--r--lib/remote/deleteobjecthandler.cpp46
-rw-r--r--lib/remote/deleteobjecthandler.hpp31
-rw-r--r--lib/remote/endpoint.cpp19
-rw-r--r--lib/remote/endpoint.hpp19
-rw-r--r--lib/remote/endpoint.ti19
-rw-r--r--lib/remote/eventqueue.cpp255
-rw-r--r--lib/remote/eventqueue.hpp129
-rw-r--r--lib/remote/eventshandler.cpp126
-rw-r--r--lib/remote/eventshandler.hpp31
-rw-r--r--lib/remote/filterutility.cpp20
-rw-r--r--lib/remote/filterutility.hpp19
-rw-r--r--lib/remote/httpchunkedencoding.cpp83
-rw-r--r--lib/remote/httpchunkedencoding.hpp54
-rw-r--r--lib/remote/httpclientconnection.cpp176
-rw-r--r--lib/remote/httpclientconnection.hpp78
-rw-r--r--lib/remote/httphandler.cpp42
-rw-r--r--lib/remote/httphandler.hpp45
-rw-r--r--lib/remote/httprequest.cpp265
-rw-r--r--lib/remote/httprequest.hpp86
-rw-r--r--lib/remote/httpresponse.cpp276
-rw-r--r--lib/remote/httpresponse.hpp83
-rw-r--r--lib/remote/httpserverconnection.cpp682
-rw-r--r--lib/remote/httpserverconnection.hpp64
-rw-r--r--lib/remote/httputility.cpp116
-rw-r--r--lib/remote/httputility.hpp35
-rw-r--r--lib/remote/i2-remote.hpp19
-rw-r--r--lib/remote/infohandler.cpp53
-rw-r--r--lib/remote/infohandler.hpp31
-rw-r--r--lib/remote/jsonrpc.cpp106
-rw-r--r--lib/remote/jsonrpc.hpp31
-rw-r--r--lib/remote/jsonrpcconnection-heartbeat.cpp64
-rw-r--r--lib/remote/jsonrpcconnection-pki.cpp79
-rw-r--r--lib/remote/jsonrpcconnection.cpp359
-rw-r--r--lib/remote/jsonrpcconnection.hpp59
-rw-r--r--lib/remote/messageorigin.cpp19
-rw-r--r--lib/remote/messageorigin.hpp19
-rw-r--r--lib/remote/modifyobjecthandler.cpp44
-rw-r--r--lib/remote/modifyobjecthandler.hpp31
-rw-r--r--lib/remote/objectqueryhandler.cpp44
-rw-r--r--lib/remote/objectqueryhandler.hpp31
-rw-r--r--lib/remote/pkiutility.cpp130
-rw-r--r--lib/remote/pkiutility.hpp21
-rw-r--r--lib/remote/statushandler.cpp42
-rw-r--r--lib/remote/statushandler.hpp31
-rw-r--r--lib/remote/templatequeryhandler.cpp44
-rw-r--r--lib/remote/templatequeryhandler.hpp31
-rw-r--r--lib/remote/typequeryhandler.cpp42
-rw-r--r--lib/remote/typequeryhandler.hpp31
-rw-r--r--lib/remote/url-characters.hpp19
-rw-r--r--lib/remote/url.cpp95
-rw-r--r--lib/remote/url.hpp29
-rw-r--r--lib/remote/variablequeryhandler.cpp42
-rw-r--r--lib/remote/variablequeryhandler.hpp31
-rw-r--r--lib/remote/zone.cpp19
-rw-r--r--lib/remote/zone.hpp19
-rw-r--r--lib/remote/zone.ti19
-rw-r--r--plugins/CMakeLists.txt20
-rw-r--r--plugins/README.md51
-rw-r--r--plugins/check_disk.cpp19
-rw-r--r--plugins/check_load.cpp19
-rw-r--r--plugins/check_memory.cpp19
-rw-r--r--plugins/check_network.cpp19
-rw-r--r--plugins/check_nscp_api.cpp392
-rw-r--r--plugins/check_perfmon.cpp21
-rw-r--r--plugins/check_ping.cpp129
-rw-r--r--plugins/check_procs.cpp19
-rw-r--r--plugins/check_service.cpp27
-rw-r--r--plugins/check_swap.cpp26
-rw-r--r--plugins/check_update.cpp77
-rw-r--r--plugins/check_uptime.cpp23
-rw-r--r--plugins/check_users.cpp19
-rw-r--r--plugins/thresholds.cpp19
-rw-r--r--plugins/thresholds.hpp19
-rw-r--r--test/CMakeLists.txt22
-rw-r--r--test/base-array.cpp19
-rw-r--r--test/base-base64.cpp19
-rw-r--r--test/base-convert.cpp19
-rw-r--r--test/base-dictionary.cpp19
-rw-r--r--test/base-fifo.cpp19
-rw-r--r--test/base-json.cpp104
-rw-r--r--test/base-match.cpp19
-rw-r--r--test/base-netstring.cpp19
-rw-r--r--test/base-object-packer.cpp19
-rw-r--r--test/base-object.cpp19
-rw-r--r--test/base-serialize.cpp19
-rw-r--r--test/base-shellescape.cpp19
-rw-r--r--test/base-stacktrace.cpp19
-rw-r--r--test/base-stream.cpp19
-rw-r--r--test/base-string.cpp19
-rw-r--r--test/base-timer.cpp19
-rw-r--r--test/base-type.cpp19
-rw-r--r--test/base-utility.cpp27
-rw-r--r--test/base-value.cpp19
-rw-r--r--test/config-ops.cpp19
-rw-r--r--test/icinga-checkable-fixture.cpp19
-rw-r--r--test/icinga-checkable-flapping.cpp19
-rw-r--r--test/icinga-checkresult.cpp19
-rw-r--r--test/icinga-legacytimeperiod.cpp272
-rw-r--r--test/icinga-macros.cpp19
-rw-r--r--test/icinga-notification.cpp34
-rw-r--r--test/icinga-perfdata.cpp19
-rw-r--r--test/icingaapplication-fixture.cpp19
-rw-r--r--test/icingaapplication-fixture.hpp19
-rw-r--r--test/livestatus-fixture.cpp19
-rw-r--r--test/livestatus.cpp19
-rw-r--r--test/remote-url.cpp74
-rw-r--r--test/test-runner.cpp37
-rw-r--r--third-party/CMakeLists.txt21
-rw-r--r--third-party/cmake/FindMySQL.cmake8
-rw-r--r--third-party/execvpe/CMakeLists.txt17
-rw-r--r--third-party/execvpe/execvpe.h19
-rw-r--r--third-party/mmatch/CMakeLists.txt17
-rw-r--r--third-party/nlohmann_json/LICENSE21
-rw-r--r--third-party/nlohmann_json/json.hpp20406
-rw-r--r--third-party/socketpair/CMakeLists.txt17
-rw-r--r--third-party/utf8cpp/.gitignore4
-rw-r--r--third-party/utf8cpp/CMakeLists.txt43
-rw-r--r--third-party/utf8cpp/LICENSE23
-rw-r--r--third-party/utf8cpp/README.md1090
-rw-r--r--third-party/utf8cpp/samples/docsample.cpp52
-rw-r--r--third-party/utf8cpp/source/utf8.h34
-rw-r--r--third-party/utf8cpp/source/utf8/checked.h327
-rw-r--r--third-party/utf8cpp/source/utf8/core.h332
-rw-r--r--third-party/utf8cpp/source/utf8/unchecked.h228
-rw-r--r--third-party/utf8cpp/test_data/negative/utf8_invalid.txtbin0 -> 20010 bytes
-rw-r--r--third-party/utf8cpp/test_data/utf8samples/UTF-8-demo.txt212
-rw-r--r--third-party/utf8cpp/test_data/utf8samples/Unicode_transcriptions.html167
-rw-r--r--third-party/utf8cpp/test_data/utf8samples/quickbrown.txt126
-rw-r--r--third-party/utf8cpp/test_drivers/negative/negative.cpp53
-rw-r--r--third-party/utf8cpp/test_drivers/smoke_test/test.cpp298
-rw-r--r--third-party/utf8cpp/test_drivers/utf8reader/utf8reader.cpp160
-rw-r--r--third-party/yajl/.gitignore3
-rw-r--r--third-party/yajl/BUILDING23
-rw-r--r--third-party/yajl/BUILDING.win3227
-rw-r--r--third-party/yajl/CMakeLists.txt46
-rw-r--r--third-party/yajl/COPYING13
-rw-r--r--third-party/yajl/ChangeLog189
-rw-r--r--third-party/yajl/README74
-rw-r--r--third-party/yajl/TODO9
-rw-r--r--third-party/yajl/src/CMakeLists.txt56
-rw-r--r--third-party/yajl/src/api/yajl_common.h75
-rw-r--r--third-party/yajl/src/api/yajl_gen.h165
-rw-r--r--third-party/yajl/src/api/yajl_parse.h226
-rw-r--r--third-party/yajl/src/api/yajl_tree.h186
-rw-r--r--third-party/yajl/src/api/yajl_version.h.cmake23
-rw-r--r--third-party/yajl/src/yajl.c175
-rw-r--r--third-party/yajl/src/yajl_alloc.c52
-rw-r--r--third-party/yajl/src/yajl_alloc.h34
-rw-r--r--third-party/yajl/src/yajl_buf.c103
-rw-r--r--third-party/yajl/src/yajl_buf.h57
-rw-r--r--third-party/yajl/src/yajl_bytestack.h69
-rw-r--r--third-party/yajl/src/yajl_encode.c220
-rw-r--r--third-party/yajl/src/yajl_encode.h34
-rw-r--r--third-party/yajl/src/yajl_gen.c362
-rw-r--r--third-party/yajl/src/yajl_lex.c763
-rw-r--r--third-party/yajl/src/yajl_lex.h117
-rw-r--r--third-party/yajl/src/yajl_parser.c498
-rw-r--r--third-party/yajl/src/yajl_parser.h78
-rw-r--r--third-party/yajl/src/yajl_tree.c503
-rw-r--r--third-party/yajl/src/yajl_version.c7
-rw-r--r--tools/CMakeLists.txt17
-rw-r--r--tools/debug/natvis/extension.vsixmanifest2
-rw-r--r--tools/mkclass/CMakeLists.txt17
-rw-r--r--tools/mkclass/class_lexer.ll19
-rw-r--r--tools/mkclass/class_parser.yy19
-rw-r--r--tools/mkclass/classcompiler.cpp19
-rw-r--r--tools/mkclass/classcompiler.hpp19
-rw-r--r--tools/mkclass/mkclass.cpp19
-rw-r--r--tools/mkembedconfig/CMakeLists.txt17
-rw-r--r--tools/mkembedconfig/mkembedconfig.c19
-rw-r--r--tools/mkunity/CMakeLists.txt17
-rw-r--r--tools/mkunity/mkunity.c19
-rw-r--r--tools/selinux/icinga2.te50
-rw-r--r--tools/syntax/nano/icinga2.nanorc2
-rw-r--r--tools/win32/build.ps111
-rw-r--r--tools/win32/configure.ps130
-rw-r--r--tools/win32/download-openssl.ps176
-rw-r--r--tools/win32/load-vsenv.ps158
-rw-r--r--tools/win32/test.ps18
905 files changed, 40395 insertions, 26818 deletions
diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md
index 488df7a..3938244 100644
--- a/.github/ISSUE_TEMPLATE.md
+++ b/.github/ISSUE_TEMPLATE.md
@@ -1,18 +1,6 @@
<!--- Provide a general summary of the issue in the Title above -->
-<!-- If you are reporting a problem or a bug, please ensure to read https://github.com/Icinga/icinga2/blob/master/doc/15-troubleshooting.md first. -->
-
-<!-- Formatting tips:
-
-GitHub supports Markdown: https://guides.github.com/features/mastering-markdown/
-Multi-line code blocks either with three back ticks, or four space indent.
-
-```
-object Host "myhost" {
- ...
-}
-```
--->
+<!-- If you are reporting a problem or a bug, please ensure to read https://github.com/Icinga/icinga2/blob/master/doc/15-troubleshooting.md first. Formatting tips: GitHub supports Markdown: https://guides.github.com/features/mastering-markdown/ -->
## Expected Behavior
<!--- If you're describing a bug, tell us what should happen -->
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
new file mode 100644
index 0000000..78472a2
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,40 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+## Describe the bug
+A clear and concise description of what the bug is.
+
+Please ensure to read https://github.com/Icinga/icinga2/blob/master/doc/15-troubleshooting.md first. Formatting tips: GitHub supports Markdown: https://guides.github.com/features/mastering-markdown/
+
+## To Reproduce
+Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include configuration, logs, etc. to reproduce, if relevant.
+
+1.
+2.
+3.
+4.
+
+## Expected behavior
+A clear and concise description of what you expected to happen.
+
+## Screenshots
+If applicable, add screenshots to help explain your problem.
+
+## Your Environment
+Include as many relevant details about the environment you experienced the problem in
+
+* Version used (`icinga2 --version`):
+* Operating System and version:
+* Enabled features (`icinga2 feature list`):
+* Icinga Web 2 version and modules (System - About):
+* Config validation (`icinga2 daemon -C`):
+* If you run multiple Icinga 2 instances, the `zones.conf` file (or `icinga2 object list --type Endpoint` and `icinga2 object list --type Zone`) from all affected nodes.
+
+## Additional context
+Add any other context about the problem here.
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
new file mode 100644
index 0000000..a7621fd
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+## Is your feature request related to a problem? Please describe.
+A clear and concise description of what the problem is. Ex. I'm always using this feature but am missing [...]
+
+## Describe the solution you'd like
+A clear and concise description of what you want to happen.
+
+## Describe alternatives you've considered
+A clear and concise description of any alternative solutions or features you've considered.
+
+## Additional context
+Add any other context or screenshots about the feature request here.
diff --git a/.gitignore b/.gitignore
index 0e2ed3f..b300b59 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,13 +1,14 @@
-## Editors
-.idea/
-*.komodoproject
-.*.sw[op]
-*~
+# Exclude all hidden files
+.*
+
+# Except those related to git and vagrant
+!.git*
+!.puppet*
+!.travis.yml
+!.mailmap
-## C++ and Tools
-*.patch
-*.playground
-.vagrant
+## Tools
+*~
tickets.pickle
## Build artifacts
diff --git a/.mailmap b/.mailmap
index 2db3df0..e37a5ac 100644
--- a/.mailmap
+++ b/.mailmap
@@ -6,9 +6,10 @@ Gunnar Beutner <gunnar.beutner@icinga.com> <icinga@net-icinga2.adm.netways.de>
<michael.friedrich@icinga.com> <Michael.Friedrich@netways.de>
Michael Insel <mcktr55@gmail.com> <mcktr55@gmail.com>
<tobias.vonderkrone@profitbricks.com> <tobias@vonderkrone.info>
-Jean Flach <jean-marcel.flach@icinga.com> <jean-marcel.flach@netways.de>
-Jean Flach <jean-marcel.flach@icinga.com> <Crunsher@users.noreply.github.com>
-Jean Flach <jean-marcel.flach@icinga.com> Jean Flach <jean-marcel.flach@icinga.com>
+Diana Flach <diana.flach@icinga.com> <jean-marcel.flach@netways.de>
+Diana Flach <diana.flach@icinga.com> <Crunsher@users.noreply.github.com>
+Diana Flach <diana.flach@icinga.com> Jean Flach <jean-marcel.flach@icinga.com>
+Diana Flach <diana.flach@icinga.com> <crunsher@bamberg.ccc.de>
Dolf Schimmel <dolf@transip.nl> <dolf@dolfschimmel.nl>
Markus Waldmüller <markus.waldmueller@netways.de>
Claudio Kuenzler <ck@claudiokuenzler.com>
@@ -36,4 +37,7 @@ Michael Insel <mcktr55@gmail.com> <michael@insel.email>
Marianne Spiller <github@spiller.me>
Robin O'Brien <robin@labs.epiuse.com> <robinjohnobrien@gmail.com>
<noah.hilverling@icinga.com> <noah@hilverling.com>
-<pe-git@hindenburgring.com> <pe-icinga2@hindenburgring.com>
+Jens Schanz <jens.schanz@mueller.de> <mail@jensschanz.de>
+Jens Schanz <jens.schanz@mueller.de> Schanz, Jens <jens.schanz@mueller.de>
+Henrik Triem <Henrik.Triem@icinga.com> Henrik Triem <43344334+htriem@users.noreply.github.com>
+nemtrif <ntrifunovic@hotmail.com> <nemtrif@users.noreply.github.com>
diff --git a/.travis.yml b/.travis.yml
index 6963d05..03f43f0 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,51 +1,42 @@
-dist: trusty
+dist: xenial
sudo: false
language: cpp
cache: ccache
-env:
- global:
- # The next declaration is the encrypted COVERITY_SCAN_TOKEN, created
- # via the "travis encrypt" command using the project repo's public key
- - secure: "eOnFdiRhB7VUZY7Of4Ff0px93HRWGcD4fXCPiy8V2OC2ER98CYCVw7PKt2Is6i/yTveFTps1kObOo0T03aUT8y/xeBy/wMuJYk1d6mVgmSXOjxcxjQVTUh4J+xB+k/R6FoP2dirNDbvSayCj9Fi9toN9hQHMM8oAZOZfiKmYTJc="
-
-before_install:
- - echo -n | openssl s_client -connect scan.coverity.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-
-
addons:
- apt_packages:
- - libboost-all-dev
- - flex
- - bison
- - libssl-dev
- - libpq-dev
- - libmysqlclient-dev
- - libedit-dev
- - libyajl-dev
- - libwxbase3.0-dev
- - libwxgtk3.0-dev
- coverity_scan:
- project:
- name: "Icinga/icinga2"
- notification_email: icinga2@icinga.com
- build_command_prepend: "cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/tmp/icinga2 -DICINGA2_PLUGINDIR=/tmp/icinga2/sbin -DICINGA2_UNITY_BUILD=ON"
- build_command: "make -j 2"
- branch_pattern: coverity_scan
-
+ apt:
+ sources:
+ - sourceline: 'deb http://packages.icinga.com/ubuntu icinga-xenial main'
+ key_url: 'https://packages.icinga.com/icinga.key'
+ packages:
+ - libboost1.67-icinga-all-dev
+ - flex
+ - bison
+ - libssl-dev
+ - libpq-dev
+ - libmysqlclient-dev
+ - libedit-dev
before_script:
- - if [ "$COVERITY_SCAN_BRANCH" != 1 ]; then
- mkdir build &&
- cd build &&
- cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/tmp/icinga2 -DICINGA2_PLUGINDIR=/tmp/icinga2/sbin;
- fi
+ - arch=$(uname -m)
+ - mkdir build
+ - cd build
+ - >
+ cmake ..
+ -DCMAKE_BUILD_TYPE=Debug
+ -DICINGA2_UNITY_BUILD=Off
+ -DCMAKE_INSTALL_PREFIX=/tmp/icinga2
+ -DICINGA2_PLUGINDIR=/tmp/icinga2/sbin
+ -DBoost_NO_BOOST_CMAKE=TRUE
+ -DBoost_NO_SYSTEM_PATHS=TRUE
+ -DBOOST_LIBRARYDIR=/usr/lib/${arch}-linux-gnu/icinga-boost
+ -DBOOST_INCLUDEDIR=/usr/include/icinga-boost
+ -DCMAKE_INSTALL_RPATH=/usr/lib/${arch}-linux-gnu/icinga-boost
script:
- - if [ "$COVERITY_SCAN_BRANCH" != 1 ]; then
- make &&
- make test &&
- make install &&
- /tmp/icinga2/sbin/icinga2 --version &&
- /tmp/icinga2/sbin/icinga2 daemon -C -DRunAsUser=$(id -u -n) -DRunAsGroup=$(id -g -n);
- fi
+ - make
+ - make test
+ - make install
+ - /tmp/icinga2/sbin/icinga2 --version
+ - /tmp/icinga2/sbin/icinga2 daemon -C -DRunAsUser=$(id -u -n) -DRunAsGroup=$(id -g -n)
diff --git a/AUTHORS b/AUTHORS
index a54157b..6cc8fe4 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -1,20 +1,27 @@
+Aaron Bishop <erroneous@gmail.com>
Adam Bolte <abolte@systemsaviour.com>
Adam James <adam.james@transitiv.co.uk>
Alan Jenkins <alan.christopher.jenkins@gmail.com>
+Alan Litster <alan.litster@twentyci.co.uk>
Alex <alexp710@hotmail.com>
+Alex Merry <alexander.merry@nanoporetech.com>
Alexander A. Klimov <alexander.klimov@icinga.com>
Alexander Fuhr <alexander.fuhr@netways.de>
Alexander Schomburg <script.acc@alex.schomb.org>
+Alexander Stoll <astoll@netways.de>
Alexander Wirt <formorer@debian.org>
Andrea Kao <eirinikos@gmail.com>
Andreas Scherbaum <andreas@scherbaum.biz>
Andres Ivanov <andres@andres.wtf>
+Andrew Jaffie <ajaffie@gmail.com>
Andrew Meyer <ameyer+secure@nodnetwork.org>
Andy Grunwald <andygrunwald@gmail.com>
Arnd Hannemann <arnd@arndnet.de>
Assaf Flatto <assaf@aikilinux.com>
+BarbUk <julien.virey@gmail.com>
Bas Couwenberg <sebastic@xs4all.nl>
Bastian Guse <bguse@nocopy.de>
+Bauerheim, Marcus <mbauerheim@spirit21.com>
Benedikt Heine <bebe@bebehei.de>
Bernd Erk <bernd.erk@icinga.com>
Berthold Cogel <cogel@uni-koeln.de>
@@ -43,6 +50,8 @@ Daniil Yaroslavtsev <dyaroslavtsev@confyrm.com>
David Beck <techiscool@gmail.com>
David Lublink <github.com@spam.lublink.net>
Denis <zaharden@gmail.com>
+Dennis Lichtenthäler <dennis.lichtenthaeler@stiftung-tannenhof.de>
+Diana Flach <diana.flach@icinga.com>
Dinesh Majrekar <dinesh.majrekar@serverchoice.com>
Dirk Goetz <dirk.goetz@icinga.com>
Dirk Melchers <dirk@dirk-melchers.de>
@@ -65,12 +74,14 @@ Georg Haas <hax404foogit@hax404.de>
Gerd von Egidy <gerd@egidy.de>
Gerhardt Roman <roman.gerhardt@cbc-x.com>
Glauco Vinicius <gl4uc0@gmail.com>
+Greg Hewgill <greg@hewgill.com>
Gunnar Beutner <gunnar.beutner@icinga.com>
Hannes Happle <info@h2-it.de>
Hannes Van de Vel <h@nnes.be>
Harald Laabs <github@dasr.de>
Heike Jurzik <icinga@huhnix.org>
Hendrik Röder <hendrik.biz@gmail.com>
+Henrik Triem <Henrik.Triem@icinga.com>
Ian Kelling <ian@iankelling.org>
Ildar Hizbulin <hizel@vyborg.ru>
Irina Kaprizkina <ikapriz@gmail.com>
@@ -79,11 +90,11 @@ James Pharaoh <james@pharaoh.uk>
Jan Andres <jan.andres@berenberg.de>
Jan Beich <jbeich@FreeBSD.org>
Jan Wagner <waja@cyconet.org>
+Janne Heß <janne@hess.ooo>
Jason Young <jason.young@velaspan.com>
-Jean Flach <jean-marcel.flach@icinga.com>
Jean-Louis Dupond <jean-louis@dupond.be>
Jens Link <jenslink@quux.de>
-Jens Schanz <mail@jensschanz.de>
+Jens Schanz <jens.schanz@mueller.de>
Jeon Sang Wan <maxswjeon@naver.com>
Jeremy Armstrong <lepubel@gmail.com>
Jesse Morgan <morgajel@gmail.com>
@@ -97,6 +108,7 @@ Jérôme Drouet <jerome.drouet@gmail.com>
Kai Goller <kai.goller@netways.de>
Konstantin Kelemen <konstantin@kel.mn>
Kálmán Szalai - KAMI <kami911@gmail.com>
+Kálmán „KAMI” Szalai <kami911@gmail.com>
Lars Engels <lars.engels@0x20.net>
Lars Krüger <krueger-lars@web.de>
Leah Oswald <mail@leahoswald.de>
@@ -106,6 +118,7 @@ Lennart Betz <lennart.betz@icinga.com>
Leon Stringer <leon@priorsvle.com>
Louis Sautier <sautier.louis@gmail.com>
Luca Lesinigo <luca@lm-net.it>
+Lucas Bremgartner <breml@users.noreply.github.com>
Lucas Fairchild-Madar <lucas.madar@gmail.com>
Luiz Amaral <luiz.amaral@innogames.com>
Magnus Bäck <magnus@noun.se>
@@ -116,16 +129,21 @@ MarcusCaepio <MarcusCaepio@users.noreply.github.com>
Marianne Spiller <github@spiller.me>
Marius Bergmann <marius@yeai.de>
Marius Sturm <marius@graylog.com>
+Mark Leary <mleary@mit.edu>
Markus Frosch <markus.frosch@icinga.com>
Markus Waldmüller <markus.waldmueller@netways.de>
+Martijn van Duren <m.vanduren@itisit.nl>
+Martin Neubert <martin.neubert@t-systems.com>
Martin Stiborsky <martin.stiborsky@gmail.com>
Mathieu Arnold <mat@mat.cc>
Mathieu Lutfy <mathieu@bidon.ca>
Matthaus Owens <matthaus@puppetlabs.com>
Matthias Schales <black-dragon131@web.de>
Maurice Meyer <morre@mor.re>
+Max Deparade <max.deparade@netways.de>
Max Rosin <git@hackrid.de>
Max Zhang <zhenzhan@tibco.com>
+Maximilian Falkenstein <maxf@njsm.de>
Mhd Sulhan <ms@kilabit.info>
Micha Ahrweiler <me@schnitzi.net>
Michael Friedrich <michael.friedrich@icinga.com>
@@ -137,11 +155,15 @@ Michal Petko <michal.petko@jumpshot.com>
Mikesch-mp <mikesch-mp@koebbes.de>
Mirco Bauer <meebey@meebey.net>
Mirko Nardin <mirko.nardin@gmx.net>
+Muhammad Mominul Huque <nahidbinbaten1995@gmail.com>
+Nemanja Trifunovic <ntrifunovic@hotmail.com>
Nicolai <nbuchwitz@users.noreply.github.com>
Nicolas Limage <github@xephon.org>
Nicole Lang <nicole.lang@icinga.com>
Niflou <dubuscyr@gmail.com>
Noah Hilverling <noah.hilverling@icinga.com>
+Obihörnchen <obihoernchende@gmail.com>
+Oleg Artenii <oleg@artenii.email>
Pall Sigurdsson <palli-github@minor.is>
Paolo Schiro <paolo.schiro@kpnqwest.it>
Patrick Huy <frz@frz.cc>
@@ -149,6 +171,7 @@ Paul Richards <paul@minimoo.org>
Pawel Szafer <pszafer@gmail.com>
Per von Zweigbergk <pvz@itassistans.se>
Peter Eckel <pe-git@hindenburgring.com>
+Peter Eckel <pe-icinga2@hindenburgring.com>
Petr Ruzicka <petr.ruzicka@gmail.com>
Phil Hutchinson <phil@volumedia.co.uk>
Philipp Dallig <philipp.dallig@gmail.com>
@@ -156,12 +179,14 @@ Ralph Breier <ralph.breier@roedl.com>
Reto Zeder <reto.zeder@arcade.ch>
Ricardo Bartels <ricardo@bitchbrothers.com>
Robert Lindgren <robert.lindgren@gmail.com>
+Robert Scheck <robert@fedoraproject.org>
Robin O'Brien <robin@labs.epiuse.com>
Roland Hopferwieser <rhopfer@ica.jku.at>
Roman Gerhardt <roman.gerhardt@cbc-x.com>
Rudy Gevaert <rudy.gevaert@ugent.be>
Rune Darrud <theflyingcorpse@gmail.com>
Sam Kottler <shk@linux.com>
+Sascha Westermann <sascha.westermann@hl-services.de>
Sebastian Brückner <mail@invlid.com>
Sebastian Chrostek <sebastian@chrostek.net>
Sebastian Eikenberg <eikese@mail.uni-paderborn.de>
@@ -194,6 +219,7 @@ Uwe Ebel <kobmaki@aol.com>
Valentin Hoebel <valentin@xenuser.org>
Vytenis Darulis <vytenis@uber.com>
Wenger Florian <wenger@unifox.at>
+Will Frey <will.frey@digitalreasoning.com>
Winfried Angele <winfried.angele@gmail.com>
Wolfgang Nieder <wnd@gmx.net>
Yannick Charton <tontonitch-pro@yahoo.fr>
@@ -210,11 +236,13 @@ dominik-r-s <43005480+dominik-r-s@users.noreply.github.com>
fbachmann <bachmann.f@gmail.com>
fluxX04 <alexp710@hotmail.com>
gitmopp <mopp@gmx.net>
+htriem <henrik.triem@netways.de>
jre3brg <jorge.rebelo@pt.bosch.com>
krishna <gskrishna44@gmail.com>
lihan <tclh123@gmail.com>
marxin <mliska@suse.cz>
mocruz <mocruz@theworkshop.com>
+nemtrif <ntrifunovic@hotmail.com>
noobahoi <20069422+noobahoi@users.noreply.github.com>
pv2b <pvz@pvz.pp.se>
ryanohnemus <ryan.ohnemus@tradingtechnologies.com>
diff --git a/CHANGELOG.md b/CHANGELOG.md
index acb7118..02c3a47 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,4 +1,72 @@
-# Icinga 2.x CHANGELOG
+# Icinga 2 CHANGELOG
+
+Please make sure to always read our [Upgrading](https://icinga.com/docs/icinga2/latest/doc/16-upgrading-icinga-2/)
+documentation before switching to a new version.
+
+Released closed milestones can be found [here](https://github.com/Icinga/icinga2/milestones?state=closed).
+
+
+## 2.11.0 RC1 (2019-07-25)
+
+[Issue and PRs](https://github.com/Icinga/icinga2/issues?utf8=%E2%9C%93&q=milestone%3A2.11.0)
+
+### Notes
+
+**This is the first release candidate for 2.11.**
+
+Upgrading docs: https://icinga.com/docs/icinga2/snapshot/doc/16-upgrading-icinga-2/
+
+Thanks to all contributors: [BarbUk](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3ABarbUk), [alanlitster](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Aalanlitster), [mcktr](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Amcktr), [KAMI911](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3AKAMI911), [peteeckel](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Apeteeckel), [breml](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Abreml), [episodeiv](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Aepisodeiv), [Crited](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3ACrited), [robert-scheck](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Arobert-scheck), [west0rmann](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Awest0rmann), [Napsty](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3ANapsty), [Elias481](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3AElias481), [uubk](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Auubk), [miso231](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Amiso231), [neubi4](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Aneubi4), [atj](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Aatj), [mvanduren-itisit](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Amvanduren-itisit), [jschanz](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Ajschanz), [MaBauMeBad](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3AMaBauMeBad), [markleary](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Amarkleary), [leeclemens](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Aleeclemens), [m4k5ym](https://github.com/Icinga/icinga2/pulls?q=is%3Apr+author%3Am4k5ym)
+
+### Enhancements
+
+* Core
+ * Rewrite Network Stack (cluster, REST API) based on Boost Asio, Beast, Coroutines
+ * Technical concept: #7041
+ * Requires package updates: Boost >1.66 (either from packages.icinga.com, EPEL or backports). SLES11 & Ubuntu 14 are EOL.
+ * Require TLS 1.2 and harden default cipher list
+ * Improved Reload Handling (umbrella process, now 3 processes at runtime)
+ * Support running Icinga 2 in (Docker) containers natively in foreground
+ * Quality: Use Modern JSON for C++ library instead of YAJL (dead project)
+ * Quality: Improve handling of invalid UTF8 strings
+* API
+ * Fix crashes and problems with permission filters from recent Namespace introduction #6785 (thanks Elias Ohm) #6874 (backported to 2.10.5)
+ * Locks and stalled waits are fixed with the core rewrite in #7071
+ * schedule-downtime action supports `all_services` for host downtimes
+ * Improve storage handling for runtime created objects in the `_api` package
+* Cluster
+ * HA aware features & improvements for failover handling #2941 #7062
+ * Improve cluster config sync with staging #6716
+* Checks & Notifications
+ * Ensure that notifications during a restart are sent
+ * Immediately notify about a problem after leaving a downtime and still NOT-OK
+ * Improve reload handling and wait for features/metrics
+ * Store notification command results and sync them in HA enabled zones #6722
+* DSL/Configuration
+ * Add getenv() function
+ * Fix TimePeriod range support over midnight
+ * `concurrent_checks` in the Checker feature has no effect, use the global MaxConcurrentChecks constant instead
+* CLI
+ * Permissions: node wizard/setup, feature, api setup now run in the Icinga user context, not root
+ * `ca list` shows pending CSRs by default, `ca remove/restore` allow to delete signing requests
+* ITL
+ * Add new commands and missing attributes - thanks to all contributors!
+* Windows
+ * Update bundled NSClient++ to 0.5.2.39
+ * Update agent installer and OpenSSL
+* Documentation
+ * Service Monitoring: How to create plugins by example, check commands and a modern version of the supported plugin API with best practices.
+ * Features: Better structure on metrics, and supported features.
+ * Basics: Rename `Custom Attributes` to `Custom Variables`.
+ * Basics: Refine explanation of command arguments.
+ * Distributed: Reword `Icinga client` into `Icinga agent` and add new images for scenarios and modes.
+ * Security: Add TLS v1.2+ requirement, hardened cipher lists
+ * Technical Concepts: TLS Network IO, Cluster Feature HA, Cluster Config Sync, Core Reload Handling.
+ * Development: Rewritten for better debugging and development experience for contributors including a style guide. Add nightly build setup instructions.
+ * Packaging: INSTALL.md was integrated into the Development chapter available at https://icinga.com/docs too.
+
+
+
## 2.10.5 (2019-05-23)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9c36642..29bc818 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,22 +1,7 @@
-# Icinga 2
-# Copyright (C) 2012-2018 Icinga Development Team (https://icinga.com/)
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software Foundation
-# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+# Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+
cmake_minimum_required(VERSION 2.8.8)
-set(BOOST_MIN_VERSION "1.48.0")
+set(BOOST_MIN_VERSION "1.66.0")
project(icinga2)
list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
@@ -42,9 +27,6 @@ option (USE_SYSTEMD
set(HAVE_SYSTEMD ${USE_SYSTEMD})
-file(STRINGS VERSION VERSION_LINE REGEX "^Version: ")
-string(REPLACE "Version: " "" ICINGA2_VERSION ${VERSION_LINE})
-
include(GNUInstallDirs)
include(InstallConfig)
include(SetFullDir)
@@ -119,15 +101,36 @@ else()
string(SUBSTRING ${SPEC_REVISION} 10 ${SPEC_REVISION_LENGTH} SPEC_REVISION)
set(GIT_VERSION "r${SPEC_VERSION}-${SPEC_REVISION}")
+ set(ICINGA2_VERSION "${SPEC_VERSION}")
+ else()
+ # use GIT version as ICINGA2_VERSION
+ string(REGEX REPLACE "^[rv]" "" ICINGA2_VERSION "${GIT_VERSION}")
endif()
configure_file(icinga-version.h.cmake icinga-version.h)
endif()
+# NuGet on Windows requires a semantic versioning, example: 2.10.4.123 (only 4 element, only numeric)
+string(REGEX REPLACE "-([0-9]+).*$" ".\\1" ICINGA2_VERSION_SAFE "${ICINGA2_VERSION}")
+
if(WIN32)
set(Boost_USE_STATIC_LIBS ON)
- add_definitions(-DBOOST_ALL_NO_LIB)
- set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /bigobj")
- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /bigobj")
+ # Disabled for linking issues for newer Boost versions, they link against Windows SDKs
+ #add_definitions(-DBOOST_ALL_NO_LIB)
+
+ # Disable optimization for Boost::context
+ # https://www.boost.org/doc/libs/1_69_0/libs/context/doc/html/context/overview.html
+ # https://docs.microsoft.com/en-us/cpp/build/reference/gl-whole-program-optimization?view=vs-2017
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /bigobj /GL- /EHs")
+ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /bigobj /GL- /EHs")
+
+ # detect if 32-bit target
+ if(CMAKE_VS_PLATFORM_NAME STREQUAL "Win32")
+ # SAFESEH is not supported in Boost on Windows x86
+ # maybe it is when Boost is compiled with it...
+ # https://lists.boost.org/Archives/boost/2013/10/206720.php
+ # https://docs.microsoft.com/en-us/cpp/build/reference/safeseh-image-has-safe-exception-handlers?view=vs-2017
+ set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SAFESEH:NO")
+ endif()
endif()
if(NOT DEFINED LOGROTATE_HAS_SU)
@@ -145,9 +148,18 @@ if(NOT DEFINED LOGROTATE_HAS_SU)
endif()
if(LOGROTATE_HAS_SU)
set(LOGROTATE_USE_SU "\n\tsu ${ICINGA2_USER} ${ICINGA2_GROUP}")
+else()
+ set(LOGROTATE_CREATE "\n\tcreate 644 ${ICINGA2_USER} ${ICINGA2_GROUP}")
endif()
-find_package(Boost ${BOOST_MIN_VERSION} COMPONENTS thread system program_options regex REQUIRED)
+find_package(Boost ${BOOST_MIN_VERSION} COMPONENTS context coroutine date_time filesystem thread system program_options regex REQUIRED)
+
+# Boost.Coroutine2 (the successor of Boost.Coroutine)
+# (1) doesn't even exist in old Boost versions and
+# (2) isn't supported by ASIO, yet.
+add_definitions(-DBOOST_COROUTINES_NO_DEPRECATION_WARNING)
+
+add_definitions(-DBOOST_FILESYSTEM_NO_DEPRECATED)
link_directories(${Boost_LIBRARY_DIRS})
include_directories(${Boost_INCLUDE_DIRS})
@@ -158,15 +170,13 @@ include_directories(${OPENSSL_INCLUDE_DIR})
set(base_DEPS ${CMAKE_DL_LIBS} ${Boost_LIBRARIES} ${OPENSSL_LIBRARIES})
set(base_OBJS $<TARGET_OBJECTS:mmatch> $<TARGET_OBJECTS:socketpair> $<TARGET_OBJECTS:base>)
-find_package(YAJL)
+# JSON
+find_package(JSON)
+include_directories(${JSON_INCLUDE})
-if(NOT YAJL_FOUND)
- include_directories(${icinga2_BINARY_DIR}/third-party/yajl/include)
- link_directories(${icinga2_BINARY_DIR}/third-party/yajl)
- list(APPEND base_OBJS $<TARGET_OBJECTS:yajl>)
-else()
- list(APPEND base_DEPS ${YAJL_LIBRARIES})
-endif()
+# UTF8CPP
+find_package(UTF8CPP)
+include_directories(${UTF8CPP_INCLUDE})
find_package(Editline)
set(HAVE_EDITLINE "${EDITLINE_FOUND}")
@@ -207,6 +217,7 @@ if(WIN32)
endif()
set(CMAKE_MACOSX_RPATH 1)
+set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_RPATH};${CMAKE_INSTALL_FULL_LIBDIR}/icinga2")
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Qunused-arguments -fcolor-diagnostics")
@@ -364,6 +375,54 @@ if(NOT MSVC)
endif()
endif()
+# Architecture specifics
+# - Log the target architecture
+# - ARM needs to link against atomic
+if(NOT MSVC)
+ # inspired by https://github.com/civetweb/civetweb/blob/master/cmake/DetermineTargetArchitecture.cmake
+ execute_process(
+ COMMAND ${CMAKE_C_COMPILER} -dumpmachine
+ RESULT_VARIABLE RESULT
+ OUTPUT_VARIABLE ARCH
+ ERROR_QUIET
+ )
+
+ if (RESULT)
+ message(FATAL_ERROR "Failed to detect target architecture: ${RESULT}")
+ endif()
+
+ string(REGEX MATCH "([^-]+).*" ARCH_MATCH ${ARCH})
+ if (NOT CMAKE_MATCH_1 OR NOT ARCH_MATCH)
+ message(FATAL_ERROR "Failed to match the target architecture: ${ARCH}")
+ endif()
+
+ set(ARCH ${CMAKE_MATCH_1})
+
+ message(STATUS "Target architecture - ${ARCH}")
+
+ # ARM settings
+ if("${ARCH}" STREQUAL "arm")
+ check_cxx_source_compiles( "include <atomic>; int main(){ std::atomic<uint_fast64_t> x; x.fetch_add(1); x.sub_add(1); }" CXX_ATOMIC)
+
+ set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -latomic")
+ set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -latomic")
+ set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -latomic")
+ endif()
+
+else()
+ if("${MSVC_C_ARCHITECTURE_ID}" STREQUAL "X86")
+ set(ARCH "i686")
+ elseif("${MSVC_C_ARCHITECTURE_ID}" STREQUAL "x64")
+ set(ARCH "x86_64")
+ elseif("${MSVC_C_ARCHITECTURE_ID}" STREQUAL "ARM")
+ set(ARCH "arm")
+ else()
+ message(FATAL_ERROR "Failed to determine the MSVC target architecture: ${MSVC_C_ARCHITECTURE_ID}")
+ endif()
+
+ message(STATUS "Target architecture - ${ARCH}")
+endif()
+
configure_file(config.h.cmake ${CMAKE_CURRENT_BINARY_DIR}/config.h ESCAPE_QUOTES)
install(
@@ -396,8 +455,8 @@ if(ICINGA2_WITH_TESTS)
endif()
set(CPACK_PACKAGE_NAME "Icinga 2")
-set(CPACK_PACKAGE_VENDOR "Icinga Development Team")
-set(CPACK_PACKAGE_VERSION ${ICINGA2_VERSION})
+set(CPACK_PACKAGE_VENDOR "Icinga GmbH")
+set(CPACK_PACKAGE_VERSION ${ICINGA2_VERSION_SAFE})
set(CPACK_PACKAGE_INSTALL_DIRECTORY "ICINGA2")
set(CPACK_PACKAGE_ICON "${CMAKE_CURRENT_SOURCE_DIR}/icinga-app\\\\icinga.ico")
set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_BINARY_DIR}/LICENSE.txt")
@@ -405,11 +464,11 @@ set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_BINARY_DIR}/LICENSE.txt")
set(CPACK_PACKAGE_EXECUTABLES "Icinga2SetupAgent;Icinga 2 Agent Wizard")
set(CPACK_WIX_PRODUCT_ICON "${CMAKE_CURRENT_SOURCE_DIR}/icinga-app\\\\icinga.ico")
set(CPACK_WIX_UPGRADE_GUID "52F2BEAA-4DF0-4C3E-ABDC-C0F61DE4DF8A")
-set(CPACK_WIX_EXTENSIONS "WixUtilExtension")
set(CPACK_WIX_UI_BANNER "${CMAKE_CURRENT_SOURCE_DIR}/icinga-installer/bannrbmp.bmp")
set(CPACK_WIX_UI_DIALOG "${CMAKE_CURRENT_SOURCE_DIR}/icinga-installer/dlgbmp.bmp")
set(CPACK_WIX_PATCH_FILE "${CMAKE_CURRENT_BINARY_DIR}/icinga-installer/icinga2.wixpatch.Debug")
set(CPACK_WIX_PATCH_FILE "${CMAKE_CURRENT_BINARY_DIR}/icinga-installer/icinga2.wixpatch")
+set(CPACK_WIX_EXTENSIONS "WixUtilExtension" "WixNetFxExtension")
set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION "sbin")
set(CMAKE_INSTALL_UCRT_LIBRARIES TRUE)
@@ -417,11 +476,11 @@ include(InstallRequiredSystemLibraries)
if(WIN32)
if(CMAKE_VS_PLATFORM_NAME STREQUAL "x64")
- set(NSCP_URL "https://github.com/mickem/nscp/releases/download/0.5.0.62/NSCP-0.5.0.62-x64.msi")
- set(NSCP_SHA256 "1854de86ad4fda3391f273de0f9985b702c014bdec01b26ad28a1343177f537f")
+ set(NSCP_URL "https://github.com/mickem/nscp/releases/download/0.5.2.39/NSCP-0.5.2.39-x64.msi")
+ set(NSCP_SHA256 "dfe93c293f30586b02510d8b7884e4e177b93a5fead8b5dc6de8103532e6e159")
else()
- set(NSCP_URL "https://github.com/mickem/nscp/releases/download/0.5.0.62/NSCP-0.5.0.62-Win32.msi")
- set(NSCP_SHA256 "2186b60d588fa0811344ce709332f9c63670019c62ae92eae49698bf76205a95")
+ set(NSCP_URL "https://github.com/mickem/nscp/releases/download/0.5.2.39/NSCP-0.5.2.39-Win32.msi")
+ set(NSCP_SHA256 "ca6a67fb01c1468f2b510fd2f9eb0750887db3fb49a0302732c1421c85c6627c")
endif()
set(NSCP_SHA256SUM "")
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 3bae78c..fc9a4bf 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -246,11 +246,8 @@ git push -f origin bugfix/notifications
## <a id="contributing-testing"></a> Testing
-Basic unit test coverage is provided by running `make test` during package builds.
-Read the [INSTALL.md](INSTALL.md) file for more information about development builds.
-
-Snapshot packages from the latest development branch are available inside the
-[package repository](https://packages.icinga.com).
+Please follow the [documentation](https://icinga.com/docs/icinga2/snapshot/doc/21-development/#test-icinga-2)
+for build and test instructions.
You can help test-drive the latest Icinga 2 snapshot packages inside the
[Icinga 2 Vagrant boxes](https://github.com/icinga/icinga-vagrant).
@@ -258,17 +255,11 @@ You can help test-drive the latest Icinga 2 snapshot packages inside the
## <a id="contributing-patches-source-code"></a> Source Code Patches
-Icinga 2 is written in C++ and uses the Boost libraries. We are also using the C++11 standard where applicable (please
-note the minimum required compiler versions in the [INSTALL.md](INSTALL.md) file.
-
Icinga 2 can be built on Linux/Unix nodes and Windows clients. In order to develop patches for Icinga 2,
you should prepare your own local build environment and know how to work with C++.
-More tips:
-
-* Requirements and source code installation for Linux/Unix is explained inside the [INSTALL.md](INSTALL.md) file.
-* Debug requirements and GDB instructions can be found in the [documentation](https://github.com/Icinga/icinga2/blob/master/doc/20-development.md).
-* If you are planning to develop and debug the Windows client, setup a Windows environment with [Visual Studio](https://www.visualstudio.com/vs/community/). An example can be found in [this blogpost](https://blog.netways.de/2015/08/24/developing-icinga-2-on-windows-10-using-visual-studio-2015/).
+Please follow the [development documentation](https://icinga.com/docs/icinga2/latest/doc/21-development/)
+for development environments, the style guide and more advanced insights.
## <a id="contributing-patches-documentation"></a> Documentation Patches
diff --git a/README.md b/README.md
index f81f6c9..1f0f5de 100644
--- a/README.md
+++ b/README.md
@@ -74,6 +74,10 @@ contribution is appreciated!
Please continue reading in the [contributing chapter](CONTRIBUTING.md).
+### Security Issues
+
+For reporting security issues please visit [this page](https://icinga.com/contact/security/).
+
<!-- TOC URLs -->
[About]: #about
[License]: #license
diff --git a/RELEASE.md b/RELEASE.md
index aa5f639..cbaed15 100644
--- a/RELEASE.md
+++ b/RELEASE.md
@@ -26,7 +26,7 @@
Specify the release version.
```
-VERSION=2.10.4
+VERSION=2.11.0-rc1
```
Add your signing key to your Git configuration file, if not already there.
@@ -68,28 +68,10 @@ sed -i "s/Version: .*/Version: $VERSION/g" VERSION
## Changelog <a id="changelog"></a>
-Update the [CHANGELOG.md](CHANGELOG.md) file.
-
-### Requirements
-
-Export these environment variables:
-
-```
-export ICINGA_GITHUB_AUTH_USERNAME='user'
-export ICINGA_GITHUB_AUTH_TOKEN='token'
-export ICINGA_GITHUB_PROJECT='icinga/icinga2'
-```
-
-### Generation
-
-**Close the version on [GitHub](https://github.com/Icinga/icinga2/milestones).**
-
-Run the script which updates the [CHANGELOG.md](CHANGELOG.md) file.
+Link to the milestone and closed=1 as filter.
-```
-./changelog.py
-git diff
-```
+Manually update the best of collected from the
+milestone description.
## Git Tag <a id="git-tag"></a>
@@ -120,18 +102,18 @@ git push --tags
git checkout master
git push
-git checkout -b support/2.11
-git push -u origin support/2.11
+git checkout -b support/2.12
+git push -u origin support/2.12
```
**For minor releases:** Push the support branch, cherry-pick the release commit
into master and merge the support branch:
```
-git push -u origin support/2.10
+git push -u origin support/2.11
git checkout master
-git cherry-pick support/2.10
-git merge --strategy=ours support/2.10
+git cherry-pick support/2.11
+git merge --strategy=ours support/2.11
git push origin master
```
@@ -162,7 +144,7 @@ git checkout release && git pull
Set the `Version`, `Revision` and `changelog` inside the spec file.
```
-VERSION=2.10.4
+VERSION=2.11.0-rc1
sed -i "s/Version: .*/Version: $VERSION/g" icinga2.spec
@@ -250,7 +232,7 @@ cd /mnt/packaging
git config --global user.name "Michael Friedrich"
git config --global user.email "michael.friedrich@icinga.com"
-VERSION=2.10.4
+VERSION=2.11.0-rc1
./dch $VERSION-1 "Update to $VERSION"
```
@@ -289,9 +271,9 @@ docker run -ti debian:stretch bash
apt-get update && apt-get install -y wget curl gnupg apt-transport-https
DIST=$(awk -F"[)(]+" '/VERSION=/ {print $2}' /etc/os-release); \
- echo "deb http://packages.icinga.com/debian icinga-${DIST} main" > \
+ echo "deb https://packages.icinga.com/debian icinga-${DIST} main" > \
/etc/apt/sources.list.d/${DIST}-icinga.list
- echo "deb-src http://packages.icinga.com/debian icinga-${DIST} main" >> \
+ echo "deb-src https://packages.icinga.com/debian icinga-${DIST} main" >> \
/etc/apt/sources.list.d/${DIST}-icinga.list
curl https://packages.icinga.com/icinga.key | apt-key add -
@@ -303,6 +285,13 @@ icinga2 daemon
Create a new release for the newly created Git tag: https://github.com/Icinga/icinga2/releases
+> Hint: Choose [tags](https://github.com/Icinga/icinga2/tags), pick one to edit and
+> make this a release. You can also create a draft release.
+
+The release body should contain a short changelog, with links
+into the roadmap, changelog and blogpost.
+
+
## Chocolatey <a id="chocolatey"></a>
Navigate to the git repository on your Windows box which
@@ -320,7 +309,7 @@ command line.
```
choco apikey --key xxx --source https://push.chocolatey.org/
-choco push Icinga2-v2.10.0.nupkg --source https://push.chocolatey.org/
+choco push Icinga2-v2.11.0.nupkg --source https://push.chocolatey.org/
```
@@ -328,6 +317,8 @@ choco push Icinga2-v2.10.0.nupkg --source https://push.chocolatey.org/
### Online Documentation <a id="online-documentation"></a>
+> Only required for major releases.
+
Navigate to `puppet-customer/icinga.git` and do the following steps:
#### Testing
@@ -336,12 +327,12 @@ Navigate to `puppet-customer/icinga.git` and do the following steps:
git checkout testing && git pull
vim files/var/www/docs/config/icinga2-latest.yml
-git commit -av -m "icinga-web1: Update docs for Icinga 2"
+git commit -av -m "icinga-web: Update docs for Icinga 2"
git push
```
-SSH into icinga-web1 and do a manual Puppet dry run with the testing environment.
+SSH into the webserver and do a manual Puppet dry run with the testing environment.
```
puppet agent -t --environment testing --noop
@@ -357,17 +348,25 @@ git merge testing
git push
```
-SSH into icinga-web2 and do a manual Puppet run from the production environment (default).
+SSH into the webserver and do a manual Puppet run from the production environment (default).
```
puppet agent -t
```
+#### Manual Generation
+
+SSH into the webserver or ask @bobapple.
+
+```
+cd /usr/local/icinga-docs-tools && ./build-docs.rb -c /var/www/docs/config/icinga2-latest.yml
+```
+
### Announcement <a id="announcement"></a>
* Create a new blog post on [icinga.com/blog](https://icinga.com/blog) including a featured image
* Create a release topic on [community.icinga.com](https://community.icinga.com)
-* Release email to team
+* Release email to net-tech & team
### Project Management <a id="project-management"></a>
diff --git a/VERSION b/VERSION
index d13d363..fc15dfc 100644
--- a/VERSION
+++ b/VERSION
@@ -1,2 +1,2 @@
-Version: 2.10.5
+Version: 2.11.0-rc1
Revision: 1
diff --git a/agent/CMakeLists.txt b/agent/CMakeLists.txt
index d59d31d..59c1e26 100644
--- a/agent/CMakeLists.txt
+++ b/agent/CMakeLists.txt
@@ -1,26 +1,10 @@
-# Icinga 2
-# Copyright (C) 2012-2018 Icinga Development Team (https://icinga.com/)
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software Foundation
-# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+# Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+
if(MSVC)
include_external_msproject(
icinga2setupagent
${CMAKE_CURRENT_SOURCE_DIR}/windows-setup-agent/Icinga2SetupAgent.csproj
TYPE FAE04EC0-301F-11D3-BF4B-00C04F79EFBC
- PLATFORM Win32
)
install(
diff --git a/agent/windows-setup-agent/App.config b/agent/windows-setup-agent/App.config
index 49c7a61..5669c35 100644
--- a/agent/windows-setup-agent/App.config
+++ b/agent/windows-setup-agent/App.config
@@ -1,7 +1,6 @@
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
- <startup>
- <supportedRuntime version="v2.0.50727" />
- <supportedRuntime version="v4.0" />
- </startup>
+ <startup>
+ <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/>
+ </startup>
</configuration> \ No newline at end of file
diff --git a/agent/windows-setup-agent/Icinga2SetupAgent.csproj b/agent/windows-setup-agent/Icinga2SetupAgent.csproj
index 0a5146d..17fe54f 100644
--- a/agent/windows-setup-agent/Icinga2SetupAgent.csproj
+++ b/agent/windows-setup-agent/Icinga2SetupAgent.csproj
@@ -3,13 +3,13 @@
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
- <Platform Condition=" '$(Platform)' == '' ">x86</Platform>
+ <Platform Condition=" '$(Platform)' == '' ">x64</Platform>
<ProjectGuid>{A86F1159-66E8-4BDB-BF28-A2BDAF76517C}</ProjectGuid>
<OutputType>WinExe</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>Icinga</RootNamespace>
<AssemblyName>Icinga2SetupAgent</AssemblyName>
- <TargetFrameworkVersion>v2.0</TargetFrameworkVersion>
+ <TargetFrameworkVersion>v4.6</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<TargetFrameworkProfile />
<PublishUrl>publish\</PublishUrl>
@@ -37,6 +37,7 @@
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<PlatformTarget>x86</PlatformTarget>
@@ -46,6 +47,7 @@
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'RelWithDebInfo|x86' ">
<PlatformTarget>x86</PlatformTarget>
@@ -55,6 +57,7 @@
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'MinSizeRel|x86' ">
<PlatformTarget>x86</PlatformTarget>
@@ -64,6 +67,48 @@
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
+ </PropertyGroup>
+ <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|Win32' ">
+ <PlatformTarget>x86</PlatformTarget>
+ <DebugSymbols>true</DebugSymbols>
+ <DebugType>full</DebugType>
+ <Optimize>false</Optimize>
+ <OutputPath>bin\Debug\</OutputPath>
+ <DefineConstants>DEBUG;TRACE</DefineConstants>
+ <ErrorReport>prompt</ErrorReport>
+ <WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
+ </PropertyGroup>
+ <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|Win32' ">
+ <PlatformTarget>x86</PlatformTarget>
+ <DebugType>pdbonly</DebugType>
+ <Optimize>true</Optimize>
+ <OutputPath>bin\Release\</OutputPath>
+ <DefineConstants>TRACE</DefineConstants>
+ <ErrorReport>prompt</ErrorReport>
+ <WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
+ </PropertyGroup>
+ <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'RelWithDebInfo|Win32' ">
+ <PlatformTarget>x86</PlatformTarget>
+ <DebugType>pdbonly</DebugType>
+ <Optimize>true</Optimize>
+ <OutputPath>bin\RelWithDebInfo\</OutputPath>
+ <DefineConstants>TRACE</DefineConstants>
+ <ErrorReport>prompt</ErrorReport>
+ <WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
+ </PropertyGroup>
+ <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'MinSizeRel|Win32' ">
+ <PlatformTarget>x86</PlatformTarget>
+ <DebugType>pdbonly</DebugType>
+ <Optimize>true</Optimize>
+ <OutputPath>bin\MinSizeRel\</OutputPath>
+ <DefineConstants>TRACE</DefineConstants>
+ <ErrorReport>prompt</ErrorReport>
+ <WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<PlatformTarget>x64</PlatformTarget>
@@ -74,6 +119,7 @@
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<PlatformTarget>x64</PlatformTarget>
@@ -83,6 +129,7 @@
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'RelWithDebInfo|x64' ">
<PlatformTarget>x64</PlatformTarget>
@@ -92,6 +139,7 @@
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'MinSizeRel|x64' ">
<PlatformTarget>x64</PlatformTarget>
@@ -101,6 +149,7 @@
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
+ <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup>
<ApplicationIcon>icinga.ico</ApplicationIcon>
@@ -203,7 +252,7 @@
</BootstrapperPackage>
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
- <!-- To modify your build process, add your task inside one of the targets below and uncomment it.
+ <!-- To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
diff --git a/agent/windows-setup-agent/Properties/AssemblyInfo.cs b/agent/windows-setup-agent/Properties/AssemblyInfo.cs
index 34d6184..d390a87 100644
--- a/agent/windows-setup-agent/Properties/AssemblyInfo.cs
+++ b/agent/windows-setup-agent/Properties/AssemblyInfo.cs
@@ -8,9 +8,9 @@ using System.Runtime.InteropServices;
[assembly: AssemblyTitle("Icinga 2 Agent Wizard")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
-[assembly: AssemblyCompany("Icinga Development Team")]
+[assembly: AssemblyCompany("Icinga GmbH")]
[assembly: AssemblyProduct("Icinga 2")]
-[assembly: AssemblyCopyright("Copyright © 2014-2018 Icinga Development Team")]
+[assembly: AssemblyCopyright("Copyright © 2014 Icinga GmbH")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
diff --git a/agent/windows-setup-agent/Properties/Resources.Designer.cs b/agent/windows-setup-agent/Properties/Resources.Designer.cs
index cb365d2..78be5e9 100644
--- a/agent/windows-setup-agent/Properties/Resources.Designer.cs
+++ b/agent/windows-setup-agent/Properties/Resources.Designer.cs
@@ -1,7 +1,7 @@
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
-// Runtime Version:4.0.30319.34011
+// Runtime Version:4.0.30319.42000
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
@@ -19,7 +19,7 @@ namespace Icinga.Properties {
// class via a tool like ResGen or Visual Studio.
// To add or remove a member, edit your .ResX file then rerun ResGen
// with the /str option, or rebuild your VS project.
- [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Resources.Tools.StronglyTypedResourceBuilder", "4.0.0.0")]
+ [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Resources.Tools.StronglyTypedResourceBuilder", "15.0.0.0")]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
internal class Resources {
diff --git a/agent/windows-setup-agent/Properties/Settings.Designer.cs b/agent/windows-setup-agent/Properties/Settings.Designer.cs
index f1515dd..ad169da 100644
--- a/agent/windows-setup-agent/Properties/Settings.Designer.cs
+++ b/agent/windows-setup-agent/Properties/Settings.Designer.cs
@@ -1,7 +1,7 @@
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
-// Runtime Version:4.0.30319.34011
+// Runtime Version:4.0.30319.42000
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
@@ -12,7 +12,7 @@ namespace Icinga.Properties {
[global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
- [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "12.0.0.0")]
+ [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "15.9.0.0")]
internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase {
private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings())));
diff --git a/agent/windows-setup-agent/SetupWizard.Designer.cs b/agent/windows-setup-agent/SetupWizard.Designer.cs
index e32c55e..090e34d 100644
--- a/agent/windows-setup-agent/SetupWizard.Designer.cs
+++ b/agent/windows-setup-agent/SetupWizard.Designer.cs
@@ -153,7 +153,7 @@
this.lblSetupCompleted.Name = "lblSetupCompleted";
this.lblSetupCompleted.Size = new System.Drawing.Size(259, 13);
this.lblSetupCompleted.TabIndex = 0;
- this.lblSetupCompleted.Text = "The Icinga 2 Windows client was set up successfully.";
+ this.lblSetupCompleted.Text = "The Icinga Windows agent was set up successfully.";
//
// tabConfigure
//
@@ -272,7 +272,7 @@
this.introduction1.Name = "introduction1";
this.introduction1.Size = new System.Drawing.Size(269, 13);
this.introduction1.TabIndex = 6;
- this.introduction1.Text = "Welcome to the Icinga 2 Windows Client Setup Wizard!";
+ this.introduction1.Text = "Welcome to the Icinga Windows Agent Setup Wizard!";
//
// groupBox3
//
@@ -437,7 +437,7 @@
this.groupBox1.Size = new System.Drawing.Size(601, 110);
this.groupBox1.TabIndex = 1;
this.groupBox1.TabStop = false;
- this.groupBox1.Text = "Parent master/satellite instance(s) for this client";
+ this.groupBox1.Text = "Parent master/satellite instance(s) for this agent";
//
// btnEditEndpoint
//
diff --git a/agent/windows-setup-agent/SetupWizard.cs b/agent/windows-setup-agent/SetupWizard.cs
index 018b2ab..b28fd53 100644
--- a/agent/windows-setup-agent/SetupWizard.cs
+++ b/agent/windows-setup-agent/SetupWizard.cs
@@ -290,7 +290,7 @@ namespace Icinga
SetConfigureStatus(100, "Finished.");
// Override the completed text
- lblSetupCompleted.Text = "The Icinga 2 Windows client was set up successfully.";
+ lblSetupCompleted.Text = "The Icinga Windows agent was set up successfully.";
// Add a note for the user for ticket-less signing
if (ticket.Length == 0) {
diff --git a/appveyor.yml b/appveyor.yml
index 9d1150f..92dfe7b 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -1,17 +1,20 @@
---
-version: 2.9.0.dev.{build}
+version: 2.11.0.dev.{build}
os: Visual Studio 2017
platform: x64
environment:
+ BITS: 64
+ CMAKE_BUILD_TYPE: Debug
CMAKE_GENERATOR: "Visual Studio 15 2017 Win64"
- VSCMD_VER: 15.0
- BOOST_ROOT: 'C:\Libraries\boost_1_65_1'
- BOOST_LIBRARYDIR: 'C:\Libraries\boost_1_65_1\lib64-msvc-14.1'
+ # https://www.appveyor.com/docs/windows-images-software/#boost
+ BOOST_ROOT: 'C:\Libraries\boost_1_67_0'
+ BOOST_LIBRARYDIR: 'C:\Libraries\boost_1_67_0\lib64-msvc-14.1'
+ # https://www.appveyor.com/docs/windows-images-software/#tools
+ OPENSSL_ROOT_DIR: 'C:\OpenSSL-v111-Win64'
BISON_BINARY: 'C:\ProgramData\chocolatey\lib\winflexbison3\tools\win_bison.exe'
FLEX_BINARY: 'C:\ProgramData\chocolatey\lib\winflexbison3\tools\win_flex.exe'
- CMAKE_BUILD_TYPE: Debug
branches:
only:
@@ -32,32 +35,21 @@ install:
# https://help.appveyor.com/discussions/questions/18777-how-to-use-vcvars64bat-from-powershell#comment_44999171
before_build:
- ps: |
- $bits = $env:PLATFORM -replace "^x", ""
- cmd.exe /c "call `"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars${bits}.bat`" && set > `"${env:TEMP}\vcvars.txt`""
- Get-Content "$env:TEMP\vcvars.txt" | Foreach-Object {
- if ($_ -match "^(VSCMD.*?)=(.*)$") {
- Set-Content ("env:" + $matches[1]) $matches[2]
- }
- }
-
- if (-not (Test-Path ".\build\vendor\OpenSSL")) {
- & .\tools\win32\download-openssl.ps1
- if ($LastExitCode -ne 0) { $host.SetShouldExit($LastExitCode) }
- }
+ & .\tools\win32\load-vsenv.ps1
- & .\tools\win32\configure.ps1
+ & powershell.exe .\tools\win32\configure.ps1
if ($LastExitCode -ne 0) { $host.SetShouldExit($LastExitCode) }
del build\Icinga*.msi
build_script:
- ps: |
- & .\tools\win32\build.ps1
+ & powershell.exe .\tools\win32\build.ps1
if ($LastExitCode -ne 0) { $host.SetShouldExit($LastExitCode) }
test_script:
- ps: |
- & .\tools\win32\test.ps1
+ & powershell.exe .\tools\win32\test.ps1
if ($LastExitCode -ne 0) { $host.SetShouldExit($LastExitCode) }
# Disable until we really need them
diff --git a/changelog.py b/changelog.py
deleted file mode 100755
index 79bdb0c..0000000
--- a/changelog.py
+++ /dev/null
@@ -1,233 +0,0 @@
-#!/usr/bin/env python
-# -*- coding:utf-8 -*-
-
-import requests
-import re
-import pickle
-import sys
-import os
-from datetime import datetime
-from collections import defaultdict
-from collections import OrderedDict
-
-#################################
-## Env Config
-
-try:
- github_auth_username = os.environ['ICINGA_GITHUB_AUTH_USERNAME']
-except KeyError:
- print "ERROR: Environment variable 'ICINGA_GITHUB_AUTH_USERNAME' is not set."
- sys.exit(1)
-
-try:
- github_auth_token = os.environ['ICINGA_GITHUB_AUTH_TOKEN']
-except:
- print "ERROR: Environment variable 'ICINGA_GITHUB_AUTH_TOKEN' is not set."
- sys.exit(1)
-
-try:
- project_name = os.environ['ICINGA_GITHUB_PROJECT']
-except:
- print "ERROR: Environment variable 'ICINGA_GITHUB_PROJECT' is not set."
- sys.exit(1)
-
-#################################
-## Config
-
-changelog_file = "CHANGELOG.md" # TODO: config param
-debug = 1
-
-# Keep this in sync with GitHub labels.
-ignored_labels = [
- "high-priority", "low-priority",
- "bug", "enhancement",
- "needs-feedback", "question", "duplicate", "invalid", "wontfix",
- "backported", "build-fix"
-]
-
-# Selectively show and collect specific categories
-#
-# (category, list of case sensitive matching labels)
-# The order is important!
-# Keep this in sync with GitHub labels.
-categories = OrderedDict(
-[
- ("Enhancement", ["enhancement"]),
- ("Bug", ["bug", "crash"]),
- ("ITL", ["ITL"]),
- ("Documentation", ["Documentation"]),
- ("Support", ["code-quality", "Tests", "Packages", "Installation"])
-]
-)
-
-#################################
-## Helpers
-
-def write_changelog(line):
- clfp.write(line + "\n")
-
-def log(level, msg):
- if level <= debug:
- print " " + msg
-
-def fetch_github_resources(uri, params = {}):
- resources = []
-
- url = 'https://api.github.com/repos/' + project_name + uri + "?per_page=100" # 100 is the maximum
-
- while True:
- log(2, "Requesting URL: " + url)
- resp = requests.get(url, auth=(github_auth_username, github_auth_token), params=params)
- try:
- resp.raise_for_status()
- except requests.exceptions.HTTPError as e:
- raise e
-
- data = resp.json()
-
- if len(data) == 0:
- break
-
- resources.extend(data)
-
- # fetch the next page from headers, do not count pages
- # http://engineering.hackerearth.com/2014/08/21/python-requests-module/
- if "next" in resp.links:
- url = resp.links['next']['url']
- log(2, "Found next link for Github pagination: " + url)
- else:
- break # no link found, we are done
- log(2, "No more pages to fetch, stop.")
-
- return resources
-
-def issue_type(issue):
- issue_labels = [label["name"] for label in issue["labels"]]
-
- # start with the least important first (e.g. "Support", "Documentation", "Bug", "Enhancement" as order)
- for category in reversed(categories):
- labels = categories[category]
-
- for label in labels:
- if label in issue_labels:
- return category
-
- return "Support"
-
-def escape_markdown(text):
- #tmp = text.replace('&', '&amp;').replace('<', '&lt;').replace('>', '&gt;')
- tmp = text
- tmp.replace('\\', '\\\\')
-
- return re.sub("([<>*_()\[\]#])", r"\\\1", tmp)
-
-def format_labels(issue):
- labels = filter(lambda label: label not in ignored_labels, [label["name"] for label in issue["labels"]])
-
- # Mark PRs as custom label
- if "pull_request" in issue:
- labels.append("PR")
-
- if len(labels):
- return " (" + ", ".join(labels) + ")"
- else:
- return ""
-
-def format_title(title):
- # Fix encoding
- try:
- issue_title = str(title.encode('ascii', 'ignore').encode('utf-8'))
- except Error:
- log(1, "Error: Cannot convert " + title + " to UTF-8")
-
- # Remove dev.icinga.com tag
- issue_title = re.sub('\[dev\.icinga\.com #\d+\] ', '', issue_title)
-
- #log(1, "Issue title: " + issue_title + "Type: " + str(type(issue_title)))
-
- return escape_markdown(issue_title)
-
-#################################
-## MAIN
-
-milestones = {}
-issues = defaultdict(lambda: defaultdict(list))
-
-log(1, "Fetching data from GitHub API for project " + project_name)
-
-try:
- tickets = fetch_github_resources("/issues", { "state": "all" })
-except requests.exceptions.HTTPError as e:
- log(1, "ERROR " + str(e.response.status_code) + ": " + e.response.text)
-
- sys.exit(1)
-
-clfp = open(changelog_file, "w+")
-
-with open('tickets.pickle', 'wb') as fp:
- pickle.dump(tickets, fp)
-
-with open('tickets.pickle', 'rb') as fp:
- cached_issues = pickle.load(fp)
-
-for issue in cached_issues: #fetch_github_resources("/issues", { "state": "all" }):
- milestone = issue["milestone"]
-
- if not milestone:
- continue
-
- ms_title = milestone["title"]
-
- if not re.match('^\d+\.\d+\.\d+$', ms_title):
- continue
-
- if ms_title.split(".")[0] != "2":
- continue
-
- milestones[ms_title] = milestone
-
- ms_tickets = issues[ms_title][issue_type(issue)]
- ms_tickets.append(issue)
-
-# TODO: Generic header based on project_name
-write_changelog("# Icinga 2.x CHANGELOG")
-write_changelog("")
-
-for milestone in sorted(milestones.values(), key=lambda ms: (ms["due_on"], ms["title"]), reverse=True):
- if milestone["state"] != "closed":
- continue
-
- if milestone["due_on"] == None:
- print "Warning: Milestone", milestone["title"], "does not have a due date."
-
- ms_due_on = datetime.strptime(milestone["due_on"], "%Y-%m-%dT%H:%M:%SZ")
-
- write_changelog("## %s (%s)" % (milestone["title"], ms_due_on.strftime("%Y-%m-%d")))
- write_changelog("")
-
- ms_description = milestone["description"]
- ms_description = re.sub('\r\n', '\n', ms_description)
-
- if len(ms_description) > 0:
- write_changelog("### Notes\n\n" + ms_description + "\n") # Don't escape anything, we take care on Github for valid Markdown
-
- for category, labels in categories.iteritems():
- try:
- ms_issues = issues[milestone["title"]][category]
- except KeyError:
- continue
-
- if len(ms_issues) == 0:
- continue
-
- write_changelog("### " + category)
- write_changelog("")
-
- for issue in ms_issues:
- write_changelog("* [#" + str(issue["number"]) + "](https://github.com/" + project_name
- + "/issues/" + str(issue["number"]) + ")" + format_labels(issue) + ": " + format_title(issue["title"]))
-
- write_changelog("")
-
-clfp.close()
-log(1, "Finished writing " + changelog_file)
diff --git a/choco/CMakeLists.txt b/choco/CMakeLists.txt
index 7460ddd..d7b90bb 100644
--- a/choco/CMakeLists.txt
+++ b/choco/CMakeLists.txt
@@ -1,19 +1,4 @@
-# Icinga 2
-# Copyright (C) 2012-2018 Icinga Development Team (https://icinga.com/)
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software Foundation
-# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+# Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+
if(WIN32)
find_program(CHOCO_BINARY choco)
@@ -23,7 +8,7 @@ if(WIN32)
add_custom_target(choco-pkg ALL
COMMAND choco pack
- COMMAND ${CMAKE_COMMAND} -E rename ${CMAKE_CURRENT_BINARY_DIR}/icinga2.${SPEC_VERSION}.nupkg ${CMAKE_CURRENT_BINARY_DIR}/icinga2.nupkg
+ COMMAND ${CMAKE_COMMAND} -E rename ${CMAKE_CURRENT_BINARY_DIR}/icinga2.${ICINGA2_VERSION_SAFE}.nupkg ${CMAKE_CURRENT_BINARY_DIR}/icinga2.nupkg
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/icinga2.nuspec ${CMAKE_CURRENT_BINARY_DIR}/chocolateyInstall.ps1 chocolateyUninstall.ps1
)
endif()
diff --git a/choco/chocolateyInstall.ps1.cmake b/choco/chocolateyInstall.ps1.cmake
index cbf4ca0..ab16603 100755
--- a/choco/chocolateyInstall.ps1.cmake
+++ b/choco/chocolateyInstall.ps1.cmake
@@ -1,7 +1,7 @@
$packageName = 'icinga2'
$installerType = 'msi'
-$url32 = 'https://packages.icinga.com/windows/Icinga2-v${SPEC_VERSION}-x86.msi'
-$url64 = 'https://packages.icinga.com/windows/Icinga2-v${SPEC_VERSION}-x86_64.msi'
+$url32 = 'https://packages.icinga.com/windows/Icinga2-v${ICINGA2_VERSION_SAFE}-x86.msi'
+$url64 = 'https://packages.icinga.com/windows/Icinga2-v${ICINGA2_VERSION_SAFE}-x86_64.msi'
$silentArgs = '/qn /norestart'
$validExitCodes = @(0)
diff --git a/choco/icinga2.nuspec.cmake b/choco/icinga2.nuspec.cmake
index 59af944..46225b5 100755
--- a/choco/icinga2.nuspec.cmake
+++ b/choco/icinga2.nuspec.cmake
@@ -6,9 +6,9 @@
<!-- Read this before publishing packages to chocolatey.org: https://github.com/chocolatey/chocolatey/wiki/CreatePackages -->
<id>icinga2</id>
<title>Icinga 2</title>
- <version>${SPEC_VERSION}</version>
- <authors>The Icinga Project</authors>
- <owners>Icinga Development Team</owners>
+ <version>${ICINGA2_VERSION_SAFE}</version>
+ <authors>Icinga GmbH</authors>
+ <owners>Icinga GmbH</owners>
<summary>icinga2 - Monitoring Agent for Windows</summary>
<description>Icinga 2 is an open source monitoring platform which notifies users about host and service outages.</description>
<projectUrl>https://icinga.com/</projectUrl>
diff --git a/cmake/FindJSON.cmake b/cmake/FindJSON.cmake
new file mode 100644
index 0000000..b7d5d79
--- /dev/null
+++ b/cmake/FindJSON.cmake
@@ -0,0 +1,9 @@
+FIND_PATH (JSON_INCLUDE json.hpp HINTS "${PROJECT_SOURCE_DIR}/third-party/nlohmann_json")
+
+if (JSON_INCLUDE)
+ set(JSON_BuildTests OFF CACHE INTERNAL "")
+
+ message(STATUS "Found JSON: ${JSON_INCLUDE}" )
+else ()
+ message(FATAL_ERROR "Unable to include json.hpp")
+endif ()
diff --git a/cmake/FindUTF8CPP.cmake b/cmake/FindUTF8CPP.cmake
new file mode 100644
index 0000000..b000353
--- /dev/null
+++ b/cmake/FindUTF8CPP.cmake
@@ -0,0 +1,7 @@
+FIND_PATH (UTF8CPP_INCLUDE utf8.h HINTS "${PROJECT_SOURCE_DIR}/third-party/utf8cpp/source")
+
+if (UTF8CPP_INCLUDE)
+ message(STATUS "Found UTF8CPP: ${UTF8CPP_INCLUDE}" )
+else ()
+ message(FATAL_ERROR "Unable to include utf8.h")
+endif ()
diff --git a/cmake/FindYAJL.cmake b/cmake/FindYAJL.cmake
deleted file mode 100644
index 186e319..0000000
--- a/cmake/FindYAJL.cmake
+++ /dev/null
@@ -1,28 +0,0 @@
-# - Try to find libyajl
-# Once done this will define
-# YAJL_FOUND - System has YAJL
-# YAJL_INCLUDE_DIRS - The YAJL include directories
-# YAJL_LIBRARIES - The libraries needed to use YAJL
-# YAJL_DEFINITIONS - Compiler switches required for using YAJL
-
-find_package(PkgConfig)
-pkg_check_modules(PC_YAJL QUIET yajl)
-set(YAJL_DEFINITIONS ${PC_YAJL_CFLAGS_OTHER})
-
-find_path(YAJL_INCLUDE_DIR yajl/yajl_version.h
- HINTS ${PC_YAJL_INCLUDEDIR} ${PC_YAJL_INCLUDE_DIRS}
- PATH_SUFFIXES libyajl)
-
-find_library(YAJL_LIBRARY NAMES yajl libyajl
- HINTS ${PC_YAJL_LIBDIR} ${PC_YAJL_LIBRARY_DIRS})
-
-set(YAJL_LIBRARIES ${YAJL_LIBRARY} )
-set(YAJL_INCLUDE_DIRS ${YAJL_INCLUDE_DIR})
-
-include(FindPackageHandleStandardArgs)
-# handle the QUIETLY and REQUIRED arguments and set YAJL_FOUND to TRUE
-# if all listed variables are TRUE
-find_package_handle_standard_args(yajl DEFAULT_MSG
- YAJL_LIBRARY YAJL_INCLUDE_DIR)
-
-mark_as_advanced(YAJL_INCLUDE_DIR YAJL_LIBRARY)
diff --git a/cmake/InstallConfig.cmake b/cmake/InstallConfig.cmake
index 3f24b39..70eae91 100644
--- a/cmake/InstallConfig.cmake
+++ b/cmake/InstallConfig.cmake
@@ -1,20 +1,5 @@
-# Icinga 2
-# Copyright (C) 2012-2018 Icinga Development Team (https://icinga.com)
+# Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+
#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software Foundation
-# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
-
# Install $src into directory $dest - usually only used for config files
#
# * similar to install() a non absolute path is prefixed with CMAKE_INSTALL_PREFIX on runtime
@@ -22,6 +7,7 @@
# * DESTDIR is prefixed as well
#
# also see https://cmake.org/cmake/help/latest/command/install.html
+
function(install_if_not_exists src dest)
if(NOT IS_ABSOLUTE "${src}")
set(src "${CMAKE_CURRENT_SOURCE_DIR}/${src}")
diff --git a/cmake/SetFullDir.cmake b/cmake/SetFullDir.cmake
index 3e9e223..8dce669 100644
--- a/cmake/SetFullDir.cmake
+++ b/cmake/SetFullDir.cmake
@@ -1,20 +1,5 @@
-# Icinga 2
-# Copyright (C) 2018 Icinga Development Team (https://icinga.com)
+# Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+
#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software Foundation
-# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
-
# Ensures a directory is absolute by prefixing CMAKE_INSTALL_PREFIX if it is not
# similar to CMAKE_INSTALL_FULL_... https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html
function(set_full_dir var path)
diff --git a/contrib/GPLHeader b/contrib/GPLHeader
index 3fd58b1..9b2cfd1 100644
--- a/contrib/GPLHeader
+++ b/contrib/GPLHeader
@@ -1,19 +1 @@
-/******************************************************************************
- * Icinga 2 *
- * Copyright (C) 2012-2018 Icinga Development Team (https://icinga.com/) *
- * *
- * This program is free software; you can redistribute it and/or *
- * modify it under the terms of the GNU General Public License *
- * as published by the Free Software Foundation; either version 2 *
- * of the License, or (at your option) any later version. *
- * *
- * This program is distributed in the hope that it will be useful, *
- * but WITHOUT ANY WARRANTY; without even the implied warranty of *
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
- * GNU General Public License for more details. *
- * *
- * You should have received a copy of the GNU General Public License *
- * along with this program; if not, write to the Free Software Foundation *
- * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. *
- ******************************************************************************/
-
+# Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+
diff --git a/contrib/discover-api.py b/contrib/discover-api.py
index 27f06e6..48be827 100755
--- a/contrib/discover-api.py
+++ b/contrib/discover-api.py
@@ -1,20 +1,5 @@
#!/usr/bin/env python
-# Icinga 2
-# Copyright (C) 2012-2018 Icinga Development Team (https://icinga.com/)
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software Foundation
-# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+# Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+
import sys
import subprocess
diff --git a/contrib/discover.py b/contrib/discover.py
index 2a8618a..8a7d0fe 100755
--- a/contrib/discover.py
+++ b/contrib/discover.py
@@ -1,20 +1,5 @@
#!/usr/bin/env python
-# Icinga 2
-# Copyright (C) 2012-2018 Icinga Development Team (https://icinga.com/)
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software Foundation
-# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+# Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+
import sys
import subprocess
diff --git a/doc/01-about.md b/doc/01-about.md
index 554c077..0284242 100644
--- a/doc/01-about.md
+++ b/doc/01-about.md
@@ -2,24 +2,43 @@
## What is Icinga 2? <a id="what-is-icinga2"></a>
-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.
+[Icinga 2](https://icinga.com/products/icinga-2/) is a 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.
-## Licensing <a id="licensing"></a>
+Icinga 2 as core requires [Icinga Web 2](https://icinga.com/products/icinga-web-2/)
+on top in your Icinga Stack.
-Icinga 2 and the Icinga 2 documentation are licensed under the terms of the GNU
-General Public License Version 2. You will find a copy of this license in the
-LICENSE file included in the source package.
-## Support <a id="support"></a>
+![Icinga 2 Distributed Master and Satellites with Agents](images/distributed-monitoring/icinga2_distributed_monitoring_scenarios_master_satellites_agents.png)
+
+## Start with Icinga <a id="start-icinga"></a>
+
+* [Installation](02-installation.md#installation)
+* [Monitoring Basics](03-monitoring-basics.md#monitoring-basics)
+* [Configuration](04-configuration.md#configuration)
+* [Distributed Monitoring](06-distributed-monitoring.md#distributed-monitoring)
+* [Addons, Integrations and Features](13-addons.md#addons)
+* [Troubleshooting](15-troubleshooting.md#troubleshooting)
+* [Upgrading](16-upgrading-icinga-2.md#upgrading-icinga-2)
+
+Once Icinga Core and Web are running in your distributed environment,
+make sure to check out the many [Icinga modules](https://icinga.com/docs/)
+for even better monitoring.
+
+## What's New <a id="whats-new"></a>
+
+You can follow the development and release milestones on [GitHub](https://github.com/icinga/icinga2/issues).
+Please follow our release announcements on [icinga.com](https://icinga.com/blog/) too.
+
+## Support <a id="support"></a>
Check the project website at [icinga.com](https://icinga.com) for status updates. Join the
[community channels](https://icinga.com/community/) for questions
-or ask an Icinga partner for [professional support](https://icinga.com/services/support/).
+or get in touch for [professional support](https://icinga.com/subscription/).
## Contribute <a id="contribute"></a>
@@ -29,15 +48,21 @@ contribution is appreciated!
Please continue reading in the [Contributing chapter](https://github.com/Icinga/icinga2/blob/master/CONTRIBUTING.md).
+### Security Issues <a id="security"></a>
+
+For reporting security issues please visit [this page](https://icinga.com/contact/security/).
+
### Icinga 2 Development <a id="development-info"></a>
The Git repository is located on [GitHub](https://github.com/Icinga/icinga2).
Icinga 2 is written in C++ and can be built on Linux/Unix and Windows.
-Read more about development builds in the [INSTALL.md](https://github.com/Icinga/icinga2/blob/master/INSTALL.md)
-file.
+Read more about development builds in the [development chapter](21-development.md#development).
-## What's New <a id="whats-new"></a>
-The Icinga 2 Changelog is located [here](https://github.com/Icinga/icinga2/blob/master/CHANGELOG.md).
-Please follow our release announcements on [icinga.com](https://icinga.com/blog/) too.
+## License <a id="license"></a>
+
+Icinga 2 and the Icinga 2 documentation are licensed under the terms of the GNU
+General Public License Version 2. You will find a copy of this license in the
+LICENSE file included in the source package.
+
diff --git a/doc/02-getting-started.md b/doc/02-installation.md
index e594995..3a99ef9 100644
--- a/doc/02-getting-started.md
+++ b/doc/02-installation.md
@@ -1,7 +1,7 @@
-# Getting Started <a id="getting-started"></a>
+# Installation <a id="installation"></a>
-This tutorial is a step-by-step introduction to installing [Icinga 2](02-getting-started.md#setting-up-icinga2)
-and [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2).
+This tutorial is a step-by-step introduction to installing [Icinga 2](02-installation.md#setting-up-icinga2)
+and [Icinga Web 2](02-installation.md#setting-up-icingaweb2).
It assumes that you are familiar with the operating system you're using to install Icinga 2.
In case you are upgrading an existing setup, please ensure to
@@ -19,7 +19,7 @@ Official repositories ([support matrix](https://icinga.com/support/details/)):
------------------------|---------------------------
Debian | [Icinga Repository](https://packages.icinga.com/debian/)
Ubuntu | [Icinga Repository](https://packages.icinga.com/ubuntu/)
- Raspbian | [Icinga Repository](https://packages.icinga.com/raspbian/)
+ Raspbian | [Icinga Repository](https://packages.icinga.com/raspbian/). Note that **Raspbian `icinga-buster` is required.**
RHEL/CentOS | [Icinga Repository](https://packages.icinga.com/epel/)
openSUSE | [Icinga Repository](https://packages.icinga.com/openSUSE/)
SLES | [Icinga Repository](https://packages.icinga.com/SUSE/)
@@ -83,7 +83,7 @@ wget -O - https://packages.icinga.com/icinga.key | apt-key add -
apt-get update
```
-Raspbian:
+Raspbian Buster:
```
apt-get update
@@ -102,6 +102,10 @@ apt-get update
##### Debian Backports Repository <a id="package-repositories-debian-backports"></a>
+> **Note**:
+>
+> This repository is required for Debian Stretch since v2.11.
+
Debian Stretch:
```
@@ -154,6 +158,9 @@ subscription-manager repos --enable rhel-6-server-optional-rpms
#### SLES/OpenSUSE Repositories <a id="package-repositories-sles-opensuse"></a>
+The release repository also provides the required Boost 1.66+ packages
+since v2.11.
+
SLES 15/12:
```
@@ -299,7 +306,7 @@ Without plugins Icinga 2 does not know how to check external services. The
an extensive set of plugins which can be used with Icinga 2 to check whether
services are working properly.
-These plugins are required to make the [example configuration](04-configuring-icinga-2.md#configuring-icinga2-overview)
+These plugins are required to make the [example configuration](04-configuration.md#configuring-icinga2-overview)
work out-of-the-box.
For your convenience here is a list of package names for some of the more
@@ -330,7 +337,7 @@ yum install nagios-plugins-all
```
The packages for RHEL/CentOS depend on other packages which are distributed
-as part of the [EPEL repository](02-getting-started.md#package-repositories-rhel-epel).
+as part of the [EPEL repository](02-installation.md#package-repositories-rhel-epel).
Fedora:
@@ -364,7 +371,7 @@ Note: For Alpine you don't need to explicitly add the `monitoring-plugins` packa
`icinga2` and is pulled automatically.
Depending on which directory your plugins are installed into you may need to
-update the global `PluginDir` constant in your [Icinga 2 configuration](04-configuring-icinga-2.md#constants-conf).
+update the global `PluginDir` constant in your [Icinga 2 configuration](04-configuration.md#constants-conf).
This constant is used by the check command definitions contained in the Icinga Template Library
to determine where to find the plugin binaries.
@@ -596,8 +603,8 @@ This chapter explains how to set up Icinga Web 2.
The DB IDO (Database Icinga Data Output) feature for Icinga 2 take care of
exporting all configuration and status information into a database.
-Please choose whether to install [MySQL](02-getting-started.md#configuring-db-ido-mysql) or
-[PostgreSQL](02-getting-started.md#configuring-db-ido-postgresql).
+Please choose whether to install [MySQL](02-installation.md#configuring-db-ido-mysql) or
+[PostgreSQL](02-installation.md#configuring-db-ido-postgresql).
### Configuring DB IDO MySQL <a id="configuring-db-ido-mysql"></a>
@@ -737,7 +744,7 @@ Alpine Linux:
rc-service icinga2 restart
```
-Continue with the [webserver setup](02-getting-started.md#icinga2-user-interface-webserver).
+Continue with the [webserver setup](02-installation.md#icinga2-user-interface-webserver).
### Configuring DB IDO PostgreSQL <a id="configuring-db-ido-postgresql"></a>
@@ -903,7 +910,7 @@ Alpine Linux:
rc-service icinga2 restart
```
-Continue with the [webserver setup](02-getting-started.md#icinga2-user-interface-webserver).
+Continue with the [webserver setup](02-installation.md#icinga2-user-interface-webserver).
### Webserver <a id="icinga2-user-interface-webserver"></a>
diff --git a/doc/03-monitoring-basics.md b/doc/03-monitoring-basics.md
index 3c80535..4fad3c2 100644
--- a/doc/03-monitoring-basics.md
+++ b/doc/03-monitoring-basics.md
@@ -208,10 +208,10 @@ You can also import existing non-template objects.
### Multiple Templates <a id="object-inheritance-using-multiple-templates"></a>
-The following example uses [custom attributes](03-monitoring-basics.md#custom-attributes) which
+The following example uses [custom variables](03-monitoring-basics.md#custom-variables) which
are provided in each template. The `web-server` template is used as the
base template for any host providing web services. In addition to that it
-specifies the custom attribute `webserver_type`, e.g. `apache`. Since this
+specifies the custom variable `webserver_type`, e.g. `apache`. Since this
template is also the base template, we import the `generic-host` template here.
This provides the `check_command` attribute by default and we don't need
to set it anywhere later on.
@@ -226,7 +226,7 @@ template Host "web-server" {
```
The `wp-server` host template specifies a Wordpress instance and sets
-the `application_type` custom attribute. Please note the `+=` [operator](17-language-reference.md#dictionary-operators)
+the `application_type` custom variable. Please note the `+=` [operator](17-language-reference.md#dictionary-operators)
which adds [dictionary](17-language-reference.md#dictionary) items,
but does not override any previous `vars` attribute.
@@ -265,10 +265,22 @@ object Host "wp1.example.com" {
}
```
-## Custom Attributes <a id="custom-attributes"></a>
+<!-- Keep this for compatibility -->
+<a id="custom-attributes"></a>
-In addition to built-in attributes you can define your own attributes
-inside the `vars` attribute:
+## Custom Variables <a id="custom-variables"></a>
+
+In addition to built-in object attributes you can define your own custom
+attributes inside the `vars` attribute.
+
+> **Tip**
+>
+> This is called `custom variables` throughout the documentation, backends and web interfaces.
+>
+> Older documentation versions referred to this as `custom attribute`.
+
+The following example specifies the key `ssh_port` as custom
+variable and assigns an integer value.
```
object Host "localhost" {
@@ -295,17 +307,17 @@ or
vars["ssh_port"] = 2222
```
-### Custom Attribute Values <a id="custom-attributes-values"></a>
+### Custom Variable Values <a id="custom-variables-values"></a>
-Valid values for custom attributes include:
+Valid values for custom variables include:
* [Strings](17-language-reference.md#string-literals), [numbers](17-language-reference.md#numeric-literals) and [booleans](17-language-reference.md#boolean-literals)
* [Arrays](17-language-reference.md#array) and [dictionaries](17-language-reference.md#dictionary)
-* [Functions](03-monitoring-basics.md#custom-attributes-functions)
+* [Functions](03-monitoring-basics.md#custom-variables-functions)
You can also define nested values such as dictionaries in dictionaries.
-This example defines the custom attribute `disks` as dictionary.
+This example defines the custom variable `disks` as dictionary.
The first key is set to `disk /` is itself set to a dictionary
with one key-value pair.
@@ -338,7 +350,7 @@ Another example which is shown in the example configuration:
}
```
-This defines the `notification` custom attribute as dictionary
+This defines the `notification` custom variable as dictionary
with the key `mail`. Its value is a dictionary with the key `groups`
which itself has an array as value. Note: This array is the exact
same as the `user_groups` attribute for [notification apply rules](#03-monitoring-basics.md#using-apply-notifications)
@@ -354,11 +366,13 @@ expects.
}
```
+<!-- Keep this for compatibility -->
+<a id="custom-attributes-functions"></a>
-### Functions as Custom Attributes <a id="custom-attributes-functions"></a>
+### Functions as Custom Variables <a id="custom-variables-functions"></a>
-Icinga 2 lets you specify [functions](17-language-reference.md#functions) for custom attributes.
-The special case here is that whenever Icinga 2 needs the value for such a custom attribute it runs
+Icinga 2 lets you specify [functions](17-language-reference.md#functions) for custom variables.
+The special case here is that whenever Icinga 2 needs the value for such a custom variable it runs
the function and uses whatever value the function returns:
```
@@ -430,22 +444,25 @@ Accessing object attributes at runtime inside these functions is described in th
## Runtime Macros <a id="runtime-macros"></a>
-Macros can be used to access other objects' attributes at runtime. For example they
-are used in command definitions to figure out which IP address a check should be
-run against:
+Macros can be used to access other objects' attributes and [custom variables](03-monitoring-basics.md#custom-variables)
+at runtime. For example they are used in command definitions to figure out
+which IP address a check should be run against:
```
object CheckCommand "my-ping" {
- command = [ PluginDir + "/check_ping", "-H", "$ping_address$" ]
+ command = [ PluginDir + "/check_ping" ]
arguments = {
+ "-H" = "$ping_address$"
"-w" = "$ping_wrta$,$ping_wpl$%"
"-c" = "$ping_crta$,$ping_cpl$%"
"-p" = "$ping_packets$"
}
+ // Resolve from a host attribute, or custom variable.
vars.ping_address = "$address$"
+ // Default values
vars.ping_wrta = 100
vars.ping_wpl = 5
@@ -464,7 +481,7 @@ object Host "router" {
In this example we are using the `$address$` macro to refer to the host's `address`
attribute.
-We can also directly refer to custom attributes, e.g. by using `$ping_wrta$`. Icinga
+We can also directly refer to custom variables, e.g. by using `$ping_wrta$`. Icinga
automatically tries to find the closest match for the attribute you specified. The
exact rules for this are explained in the next section.
@@ -483,12 +500,12 @@ up macros and their respective values:
2. Service object
3. Host object
4. Command object
-5. Global custom attributes in the `Vars` constant
+5. Global custom variables in the `Vars` constant
-This execution order allows you to define default values for custom attributes
+This execution order allows you to define default values for custom variables
in your command objects.
-Here's how you can override the custom attribute `ping_packets` from the previous
+Here's how you can override the custom variable `ping_packets` from the previous
example:
```
@@ -500,7 +517,7 @@ object Service "ping" {
}
```
-If a custom attribute isn't defined anywhere, an empty value is used and a warning is
+If a custom variable isn't defined anywhere, an empty value is used and a warning is
written to the Icinga 2 log.
You can also directly refer to a specific attribute -- thereby ignoring these evaluation
@@ -510,14 +527,14 @@ rules -- by specifying the full attribute name:
$service.vars.ping_wrta$
```
-This retrieves the value of the `ping_wrta` custom attribute for the service. This
-returns an empty value if the service does not have such a custom attribute no matter
+This retrieves the value of the `ping_wrta` custom variable for the service. This
+returns an empty value if the service does not have such a custom variable no matter
whether another object such as the host has this attribute.
### Host Runtime Macros <a id="host-runtime-macros"></a>
-The following host custom attributes are available in all commands that are executed for
+The following host custom variables are available in all commands that are executed for
hosts or services:
Name | Description
@@ -583,7 +600,7 @@ attributes can be accessed too.
### Command Runtime Macros <a id="command-runtime-macros"></a>
-The following custom attributes are available in all commands:
+The following custom variables are available in all commands:
Name | Description
-----------------------|--------------
@@ -591,7 +608,7 @@ The following custom attributes are available in all commands:
### User Runtime Macros <a id="user-runtime-macros"></a>
-The following custom attributes are available in all commands that are executed for
+The following custom variables are available in all commands that are executed for
users:
Name | Description
@@ -661,7 +678,7 @@ attribute and reference an existing host attribute.
```
object Service "ping4" {
check_command = "ping4"
- host_name = "icinga2-client1.localdomain"
+ host_name = "icinga2-agent1.localdomain"
}
```
@@ -688,7 +705,7 @@ More explanations on assign where expressions can be found [here](03-monitoring-
Before you start with apply rules keep the following in mind:
* Define the best match.
- * A set of unique [custom attributes](03-monitoring-basics.md#custom-attributes) for these hosts/services?
+ * A set of unique [custom variables](03-monitoring-basics.md#custom-variables) for these hosts/services?
* Or [group](03-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup which should have a service set?
* A generic pattern [match](18-library-reference.md#global-functions-match) on the host/service name?
* [Multiple expressions combined](03-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](17-language-reference.md#expression-operators)
@@ -710,12 +727,12 @@ objects in that scope (host and/or service objects).
vars.application_type = host.vars.application_type
```
-[Custom attributes](03-monitoring-basics.md#custom-attributes) can also store
+[Custom variables](03-monitoring-basics.md#custom-variables) can also store
nested dictionaries and arrays. That way you can use them for not only matching
for their existence or values in apply expressions, but also assign
("inherit") their values into the generated objected from apply rules.
-Remember the examples shown for [custom attribute values](03-monitoring-basics.md#custom-attributes-values):
+Remember the examples shown for [custom variable values](03-monitoring-basics.md#custom-variables-values):
```
vars.notification["mail"] = {
@@ -725,7 +742,7 @@ Remember the examples shown for [custom attribute values](03-monitoring-basics.m
You can do two things here:
-* Check for the existence of the `notification` custom attribute and its nested dictionary key `mail`.
+* Check for the existence of the `notification` custom variable and its nested dictionary key `mail`.
If this is boolean true, the notification object will be generated.
* Assign the value of the `groups` key to the `user_groups` attribute.
@@ -742,9 +759,9 @@ apply Notification "mail-icingaadmin" to Host {
A more advanced example is to use [apply rules with for loops on arrays or
dictionaries](03-monitoring-basics.md#using-apply-for) provided by
-[custom atttributes](03-monitoring-basics.md#custom-attributes) or groups.
+[custom atttributes](03-monitoring-basics.md#custom-variables) or groups.
-Remember the examples shown for [custom attribute values](03-monitoring-basics.md#custom-attributes-values):
+Remember the examples shown for [custom variable values](03-monitoring-basics.md#custom-variables-values):
```
vars.disks["disk /"] = {
@@ -801,7 +818,7 @@ Assign a service to a specific host in a host group [array](18-library-reference
assign where "hostgroup-dev" in host.groups
```
-Assign an object when a custom attribute is [equal](17-language-reference.md#expression-operators) to a value:
+Assign an object when a custom variable is [equal](17-language-reference.md#expression-operators) to a value:
```
assign where host.vars.application_type == "database"
@@ -827,8 +844,8 @@ Match the host name by using a [regular expression](18-library-reference.md#glob
assign where regex("^webserver-[\\d+]", host.name)
```
-[Match](18-library-reference.md#global-functions-match) all `*mysql*` patterns in the host name and (`&&`) custom attribute `prod_mysql_db`
-matches the `db-*` pattern. All hosts with the custom attribute `test_server` set to `true`
+[Match](18-library-reference.md#global-functions-match) all `*mysql*` patterns in the host name and (`&&`) custom variable `prod_mysql_db`
+matches the `db-*` pattern. All hosts with the custom variable `test_server` set to `true`
should be ignored, or any host name ending with `*internal` pattern.
```
@@ -843,11 +860,11 @@ object HostGroup "mysql-server" {
Similar example for advanced notification apply rule filters: If the service
attribute `notes` [matches](18-library-reference.md#global-functions-match) the `has gold support 24x7` string `AND` one of the
-two condition passes, either the `customer` host custom attribute is set to `customer-xy`
-`OR` the host custom attribute `always_notify` is set to `true`.
+two condition passes, either the `customer` host custom variable is set to `customer-xy`
+`OR` the host custom variable `always_notify` is set to `true`.
The notification is ignored for services whose host name ends with `*internal`
-`OR` the `priority` custom attribute is [less than](17-language-reference.md#expression-operators) `2`.
+`OR` the `priority` custom variable is [less than](17-language-reference.md#expression-operators) `2`.
```
template Notification "cust-xy-notification" {
@@ -867,11 +884,11 @@ More advanced examples are covered [here](08-advanced-topics.md#use-functions-as
### Apply Services to Hosts <a id="using-apply-services"></a>
-The sample configuration already includes a detailed example in [hosts.conf](04-configuring-icinga-2.md#hosts-conf)
-and [services.conf](04-configuring-icinga-2.md#services-conf) for this use case.
+The sample configuration already includes a detailed example in [hosts.conf](04-configuration.md#hosts-conf)
+and [services.conf](04-configuration.md#services-conf) for this use case.
The example for `ssh` applies a service object to all hosts with the `address`
-attribute being defined and the custom attribute `os` set to the string `Linux` in `vars`.
+attribute being defined and the custom variable `os` set to the string `Linux` in `vars`.
```
apply Service "ssh" {
@@ -902,17 +919,17 @@ apply Notification "mail-noc" to Service {
```
In this example the `mail-noc` notification will be created as object for all services having the
-`notification.mail` custom attribute defined. The notification command is set to `mail-service-notification`
+`notification.mail` custom variable defined. The notification command is set to `mail-service-notification`
and all members of the user group `noc` will get notified.
It is also possible to generally apply a notification template and dynamically overwrite values from
-the template by checking for custom attributes. This can be achieved by using [conditional statements](17-language-reference.md#conditional-statements):
+the template by checking for custom variables. This can be achieved by using [conditional statements](17-language-reference.md#conditional-statements):
```
apply Notification "host-mail-noc" to Host {
import "mail-host-notification"
- // replace interval inherited from `mail-host-notification` template with new notfication interval set by a host custom attribute
+ // replace interval inherited from `mail-host-notification` template with new notfication interval set by a host custom variable
if (host.vars.notification_interval) {
interval = host.vars.notification_interval
}
@@ -922,7 +939,7 @@ apply Notification "host-mail-noc" to Host {
period = host.vars.notification_period
}
- // Send SMS instead of email if the host's custom attribute `notification_type` is set to `sms`
+ // Send SMS instead of email if the host's custom variable `notification_type` is set to `sms`
if (host.vars.notification_type == "sms") {
command = "sms-host-notification"
} else {
@@ -939,7 +956,7 @@ In the example above the notification template `mail-host-notification`
contains all relevant notification settings.
The apply rule is applied on all host objects where the `host.address` is defined.
-If the host object has a specific custom attribute set, its value is inherited
+If the host object has a specific custom variable set, its value is inherited
into the local notification object scope, e.g. `host.vars.notification_interval`,
`host.vars.notification_period` and `host.vars.notification_type`.
This overwrites attributes already specified in the imported `mail-host-notification`
@@ -964,7 +981,7 @@ Detailed examples can be found in the [dependencies](03-monitoring-basics.md#dep
### Apply Recurring Downtimes to Hosts and Services <a id="using-apply-scheduledowntimes"></a>
-The sample configuration includes an example in [downtimes.conf](04-configuring-icinga-2.md#downtimes-conf).
+The sample configuration includes an example in [downtimes.conf](04-configuration.md#downtimes-conf).
Detailed examples can be found in the [recurring downtimes](08-advanced-topics.md#recurring-downtimes) chapter.
@@ -975,8 +992,8 @@ Next to the standard way of using [apply rules](03-monitoring-basics.md#using-ap
there is the requirement of applying objects based on a set (array or
dictionary) using [apply for](17-language-reference.md#apply-for) expressions.
-The sample configuration already includes a detailed example in [hosts.conf](04-configuring-icinga-2.md#hosts-conf)
-and [services.conf](04-configuring-icinga-2.md#services-conf) for this use case.
+The sample configuration already includes a detailed example in [hosts.conf](04-configuration.md#hosts-conf)
+and [services.conf](04-configuration.md#services-conf) for this use case.
Take the following example: A host provides the snmp oids for different service check
types. This could look like the following example:
@@ -993,7 +1010,7 @@ object Host "router-v6" {
```
The idea is to create service objects for `if01` and `temp` but not `bgp`.
-The oid value should also be used as service custom attribute `snmp_oid`.
+The oid value should also be used as service custom variable `snmp_oid`.
This is the command argument required by the [snmp](10-icinga-template-library.md#plugin-check-command-snmp)
check command.
The service's `display_name` should be set to the identifier inside the dictionary,
@@ -1009,7 +1026,7 @@ apply Service for (identifier => oid in host.vars.oids) {
}
```
-Icinga 2 evaluates the `apply for` rule for all objects with the custom attribute
+Icinga 2 evaluates the `apply for` rule for all objects with the custom variable
`oids` set.
It iterates over all dictionary items inside the `for` loop and evaluates the
`assign/ignore where` expressions. You can access the loop variable
@@ -1026,13 +1043,15 @@ unwanted services. A different approach would be to match the `oid` value with a
> **Note**
>
> You don't need an `assign where` expression which checks for the existence of the
-> `oids` custom attribute.
+> `oids` custom variable.
This method saves you from creating multiple apply rules. It also moves
the attribute specification logic from the service to the host.
+<!-- Keep this for compatibility -->
+<a id="using-apply-for-custom-attribute-override"></a>
-#### Apply For and Custom Attribute Override <a id="using-apply-for-custom-attribute-override"></a>
+#### Apply For and Custom Variable Override <a id="using-apply-for-custom-variable-override"></a>
Imagine a different more advanced example: You are monitoring your network device (host)
with many interfaces (services). The following requirements/problems apply:
@@ -1046,17 +1065,17 @@ dynamically generated.
> **Tip**
>
-> Define the SNMP community as global constant in your [constants.conf](04-configuring-icinga-2.md#constants-conf) file.
+> Define the SNMP community as global constant in your [constants.conf](04-configuration.md#constants-conf) file.
```
const IftrafficSnmpCommunity = "public"
```
-Define the `interfaces` [custom attribute](03-monitoring-basics.md#custom-attributes)
+Define the `interfaces` [custom variable](03-monitoring-basics.md#custom-variables)
on the `cisco-catalyst-6509-34` host object and add three example interfaces as dictionary keys.
Specify additional attributes inside the nested dictionary
-as learned with [custom attribute values](03-monitoring-basics.md#custom-attributes-values):
+as learned with [custom variable values](03-monitoring-basics.md#custom-variables-values):
```
object Host "cisco-catalyst-6509-34" {
@@ -1068,7 +1087,7 @@ object Host "cisco-catalyst-6509-34" {
* and key name in service apply for later on
*/
vars.interfaces["GigabitEthernet0/2"] = {
- /* define all custom attributes with the
+ /* define all custom variables with the
* same name required for command parameters/arguments
* in service apply (look into your CheckCommand definition)
*/
@@ -1141,17 +1160,17 @@ interface_config = {
```
Access the dictionary keys with the [indexer](17-language-reference.md#indexer) syntax
-and assign them to custom attributes used as command parameters for the `iftraffic`
+and assign them to custom variables used as command parameters for the `iftraffic`
check command.
```
- /* map the custom attributes as command arguments */
+ /* map the custom variables as command arguments */
vars.iftraffic_units = interface_config.iftraffic_units
vars.iftraffic_community = interface_config.iftraffic_community
```
If you just want to inherit all attributes specified inside the `interface_config`
-dictionary, add it to the generated service custom attributes like this:
+dictionary, add it to the generated service custom variables like this:
```
/* the above can be achieved in a shorter fashion if the names inside host.vars.interfaces
@@ -1161,7 +1180,7 @@ dictionary, add it to the generated service custom attributes like this:
vars += interface_config
```
-If the user did not specify default values for required service custom attributes,
+If the user did not specify default values for required service custom variables,
add them here. This also helps to avoid unwanted configuration validation errors or
runtime failures. Please read more about conditional statements [here](17-language-reference.md#conditional-statements).
@@ -1211,7 +1230,7 @@ more object attributes which can be e.g. seen in external interfaces.
> after successful [configuration validation](11-cli-commands.md#config-validation).
Verify that the apply-for-rule successfully created the service objects with the
-inherited custom attributes:
+inherited custom variables:
```
# icinga2 daemon -C
@@ -1292,7 +1311,7 @@ object Host "opennebula-host" {
}
```
-`hosting` is a custom attribute with the Dictionary value type.
+`hosting` is a custom variable with the Dictionary value type.
This is mandatory to iterate with the `key => value` notation
in the below apply for rule.
@@ -1567,20 +1586,20 @@ A common pattern is to store the users and user groups
on the host or service objects instead of the notification
object itself.
-The sample configuration provided in [hosts.conf](04-configuring-icinga-2.md#hosts-conf) and [notifications.conf](notifications-conf)
+The sample configuration provided in [hosts.conf](04-configuration.md#hosts-conf) and [notifications.conf](notifications-conf)
already provides an example for this question.
> **Tip**
>
> Please make sure to read the [apply](03-monitoring-basics.md#using-apply) and
-> [custom attribute values](03-monitoring-basics.md#custom-attributes-values) chapter to
+> [custom variable values](03-monitoring-basics.md#custom-variables-values) chapter to
> fully understand these examples.
-Specify the user and groups as nested custom attribute on the host object:
+Specify the user and groups as nested custom variable on the host object:
```
-object Host "icinga2-client1.localdomain" {
+object Host "icinga2-agent1.localdomain" {
[...]
vars.notification["mail"] = {
@@ -1597,7 +1616,7 @@ As you can see, there is the option to use two different notification
apply rules here: One for `mail` and one for `sms`.
This example assigns the `users` and `groups` nested keys from the `notification`
-custom attribute to the actual notification object attributes.
+custom variable to the actual notification object attributes.
Since errors are hard to debug if host objects don't specify the required
configuration attributes, you can add a safety condition which logs which
@@ -1874,7 +1893,7 @@ using the `check_command` attribute.
#### Integrate the Plugin with a CheckCommand Definition <a id="command-plugin-integration"></a>
Unless you have done so already, download your check plugin and put it
-into the [PluginDir](04-configuring-icinga-2.md#constants-conf) directory. The following example uses the
+into the [PluginDir](04-configuration.md#constants-conf) directory. The following example uses the
`check_mysql` plugin contained in the Monitoring Plugins package.
The plugin path and all command arguments are made a list of
@@ -1904,7 +1923,7 @@ Please continue reading in the [plugins section](05-service-monitoring.md#servic
#### Passing Check Command Parameters from Host or Service <a id="command-passing-parameters"></a>
-Check command parameters are defined as custom attributes which can be accessed as runtime macros
+Check command parameters are defined as custom variables which can be accessed as runtime macros
by the executed check command.
The check command parameters for ITL provided plugin check command definitions are documented
@@ -1913,11 +1932,11 @@ The check command parameters for ITL provided plugin check command definitions a
In order to practice passing command parameters you should [integrate your own plugin](03-monitoring-basics.md#command-plugin-integration).
-The following example will use `check_mysql` provided by the [Monitoring Plugins installation](02-getting-started.md#setting-up-check-plugins).
+The following example will use `check_mysql` provided by the [Monitoring Plugins installation](02-installation.md#setting-up-check-plugins).
-Define the default check command custom attributes, for example `mysql_user` and `mysql_password`
+Define the default check command custom variables, for example `mysql_user` and `mysql_password`
(freely definable naming schema) and optional their default threshold values. You can
-then use these custom attributes as runtime macros for [command arguments](03-monitoring-basics.md#command-arguments)
+then use these custom variables as runtime macros for [command arguments](03-monitoring-basics.md#command-arguments)
on the command line.
> **Tip**
@@ -1926,8 +1945,8 @@ on the command line.
> readability. `mysql_user` helps understanding the context better than just
> `user` as argument.
-The default custom attributes can be overridden by the custom attributes
-defined in the host or service using the check command `my-mysql`. The custom attributes
+The default custom variables can be overridden by the custom variables
+defined in the host or service using the check command `my-mysql`. The custom variables
can also be inherited from a parent template using additive inheritance (`+=`).
```
@@ -1973,7 +1992,7 @@ The check command definition also sets `mysql_host` to the `$address$` default v
this command parameter if for example your MySQL host is not running on the same server's ip address.
Make sure pass all required command parameters, such as `mysql_user`, `mysql_password` and `mysql_database`.
-`MysqlUsername` and `MysqlPassword` are specified as [global constants](04-configuring-icinga-2.md#constants-conf)
+`MysqlUsername` and `MysqlPassword` are specified as [global constants](04-configuration.md#constants-conf)
in this example.
```
@@ -1996,10 +2015,10 @@ apply Service "mysql-icinga-db-health" {
```
-Take a different example: The example host configuration in [hosts.conf](04-configuring-icinga-2.md#hosts-conf)
+Take a different example: The example host configuration in [hosts.conf](04-configuration.md#hosts-conf)
also applies an `ssh` service check. Your host's ssh port is not the default `22`, but set to `2022`.
-You can pass the command parameter as custom attribute `ssh_port` directly inside the service apply rule
-inside [services.conf](04-configuring-icinga-2.md#services-conf):
+You can pass the command parameter as custom variable `ssh_port` directly inside the service apply rule
+inside [services.conf](04-configuration.md#services-conf):
```
apply Service "ssh" {
@@ -2016,7 +2035,7 @@ If you prefer this being configured at the host instead of the service, modify t
object instead. The runtime macro resolving order is described [here](03-monitoring-basics.md#macro-evaluation-order).
```
-object Host "icinga2-client1.localdomain {
+object Host "icinga2-agent1.localdomain {
...
vars.ssh_port = 2022
}
@@ -2026,10 +2045,10 @@ object Host "icinga2-client1.localdomain {
The host `localhost` with the generated services from the `basic-partitions` dictionary (see
[apply for](03-monitoring-basics.md#using-apply-for) for details) checks a basic set of disk partitions
-with modified custom attributes (warning thresholds at `10%`, critical thresholds at `5%`
+with modified custom variables (warning thresholds at `10%`, critical thresholds at `5%`
free disk space).
-The custom attribute `disk_partition` can either hold a single string or an array of
+The custom variable `disk_partition` can either hold a single string or an array of
string values for passing multiple partitions to the `check_disk` check plugin.
```
@@ -2055,121 +2074,360 @@ apply Service for (disk => config in host.vars.local_disks) {
```
-More details on using arrays in custom attributes can be found in
-[this chapter](03-monitoring-basics.md#custom-attributes).
+More details on using arrays in custom variables can be found in
+[this chapter](03-monitoring-basics.md#custom-variables).
#### Command Arguments <a id="command-arguments"></a>
-By defining a check command line using the `command` attribute Icinga 2
-will resolve all macros in the static string or array. Sometimes it is
-required to extend the arguments list based on a met condition evaluated
-at command execution. Or making arguments optional -- only set if the
-macro value can be resolved by Icinga 2.
+Next to the short `command` array specified in the command object,
+it is advised to define plugin/script parameters in the `arguments`
+dictionary attribute.
+
+The value of the `--parameter` key itself is a dictionary with additional
+keys. They allow to create generic command objects and are also for documentation
+purposes, e.g. with the `description` field copying the plugin's help text in there.
+The Icinga Director uses this field to show the argument's purpose when selecting it.
+
+```
+ arguments = {
+ "--parameter" = {
+ description = "..."
+ value = "..."
+ }
+ }
+```
+
+Each argument is optional by default and is omitted if
+the value is not set.
+
+Learn more about integrating plugins with CheckCommand
+objects in [this chapter](05-service-monitoring.md#service-monitoring-plugin-checkcommand).
+
+There are additional possibilities for creating a command only once,
+with different parameters and arguments, shown below.
+
+##### Command Arguments: Value <a id="command-arguments-value"></a>
+
+In order to find out about the command argument, call the plugin's help
+or consult the README.
```
-object CheckCommand "http" {
- command = [ PluginDir + "/check_http" ]
+./check_systemd.py --help
+...
+
+ -u UNIT, --unit UNIT Name of the systemd unit that is beeing tested.
+```
+
+Whenever the long parameter name is available, prefer this over the short one.
+
+```
arguments = {
- "-H" = "$http_vhost$"
- "-I" = "$http_address$"
- "-u" = "$http_uri$"
- "-p" = "$http_port$"
- "-S" = {
- set_if = "$http_ssl$"
+ "--unit" = {
+
}
- "--sni" = {
- set_if = "$http_sni$"
+ }
+```
+
+Define a unique `prefix` for the command's specific arguments. Best practice is to follow this schema:
+
+```
+<command name>_<parameter name>
+```
+
+Therefore use `systemd_` as prefix, and use the long plugin parameter name `unit` inside the [runtime macro](03-monitoring-basics.md#runtime-macros)
+syntax.
+
+```
+ arguments = {
+ "--unit" = {
+ value = "$systemd_unit$"
}
- "-a" = {
- value = "$http_auth_pair$"
- description = "Username:password on sites with basic authentication"
+ }
+```
+
+In order to specify a default value, specify
+a [custom variable](03-monitoring-basics.md#custom-variables) inside
+the CheckCommand object.
+
+```
+ vars.systemd_unit = "icinga2"
+```
+
+This value can be overridden from the host/service
+object as command parameters.
+
+
+##### Command Arguments: Description <a id="command-arguments-description"></a>
+
+Best practice, also inside the [ITL](10-icinga-template-library.md#icinga-template-library), is to always
+copy the command parameter help output into the `description`
+field of your check command.
+
+Learn more about integrating plugins with CheckCommand
+objects in [this chapter](05-service-monitoring.md#service-monitoring-plugin-checkcommand).
+
+With the [example above](03-monitoring-basics.md#command-arguments-value),
+inspect the parameter's help text.
+
+```
+./check_systemd.py --help
+
+...
+
+ -u UNIT, --unit UNIT Name of the systemd unit that is beeing tested.
+```
+
+Copy this into the command arguments `description` entry.
+
+```
+ arguments = {
+ "--unit" = {
+ value = "$systemd_unit$"
+ description = "Name of the systemd unit that is beeing tested."
}
- "--no-body" = {
- set_if = "$http_ignore_body$"
+ }
+```
+
+##### Command Arguments: Required <a id="command-arguments-required"></a>
+
+Specifies whether this command argument is required, or not. By
+default all arguments are optional.
+
+> **Tip**
+>
+> Good plugins provide optional parameters in square brackets, e.g. `[-w SECONDS]`.
+
+The `required` field can be toggled with a [boolean](17-language-reference.md#boolean-literals) value.
+
+```
+ arguments = {
+ "--host" = {
+ value = "..."
+ description = "..."
+ required = true
}
- "-r" = "$http_expect_body_regex$"
- "-w" = "$http_warn_time$"
- "-c" = "$http_critical_time$"
- "-e" = "$http_expect$"
}
+```
+
+Whenever the check is executed and the argument is missing, Icinga
+logs an error. This allows to better debug configuration errors
+instead of sometimes unreadable plugin errors when parameters are
+missing.
+
+##### Command Arguments: Skip Key <a id="command-arguments-skip-key"></a>
+
+The `arguments` attribute requires a key, empty values are not allowed.
+To overcome this for parameters which don't need the name in front of
+the value, use the `skip_key` [boolean](17-language-reference.md#boolean-literals) toggle.
- vars.http_address = "$address$"
- vars.http_ssl = false
- vars.http_sni = false
-}
```
+ command = [ PrefixDir + "/bin/icingacli", "businessprocess", "process", "check" ]
-The example shows the `check_http` check command defining the most common
-arguments. Each of them is optional by default and is omitted if
-the value is not set. For example, if the service calling the check command
-does not have `vars.http_port` set, it won't get added to the command
-line.
+ arguments = {
+ "--process" = {
+ value = "$icingacli_businessprocess_process$"
+ description = "Business process to monitor"
+ skip_key = true
+ required = true
+ order = -1
+ }
+ }
+```
-If the `vars.http_ssl` custom attribute is set in the service, host or command
-object definition, Icinga 2 will add the `-S` argument based on the `set_if`
-numeric value to the command line. String values are not supported.
+The service specifies the [custom variable](03-monitoring-basics.md#custom-variables) `icingacli_businessprocess_process`.
-If the macro value cannot be resolved, Icinga 2 will not add the defined argument
-to the final command argument array. Empty strings for macro values won't omit
-the argument.
+```
+ vars.icingacli_businessprocess_process = "bp-shop-web"
+```
-That way you can use the `check_http` command definition for both, with and
-without SSL enabled checks saving you duplicated command definitions.
+This results in this command line without the `--process` parameter:
-Details on all available options can be found in the
-[CheckCommand object definition](09-object-types.md#objecttype-checkcommand).
+```
+'/bin/icingacli' 'businessprocess' 'process' 'check' 'bp-shop-web'
+```
-##### Command Arguments: set_if <a id="command-arguments-set-if"></a>
+You can use this method to put everything into the `arguments` attribute
+in a defined order and without keys. This avoids entries in the `command`
+attributes too.
-The `set_if` attribute in command arguments can be used to only add
-this parameter if the runtime macro value is boolean `true`.
-Best practice is to define and pass only [boolean](17-language-reference.md#boolean-literals) values here.
-[Numeric](17-language-reference.md#numeric-literals) values are allowed too.
+##### Command Arguments: Set If <a id="command-arguments-set-if"></a>
+
+This can be used for the following scenarios:
-Examples:
+**Parameters without value, e.g. `--sni`.**
```
-vars.test_b = true
-vars.test_n = 3.0
+ command = [ PluginDir + "/check_http"]
-arguments = {
- "-x" = {
- set_if = "$test_b$"
+ arguments = {
+ "--sni" = {
+ set_if = "$http_sni$"
+ }
}
- "-y" = {
- set_if = "$test_n$"
+```
+
+Whenever a host/service object sets the `http_sni` [custom variable](03-monitoring-basics.md#custom-variables)
+to `true`, the parameter is added to the command line.
+
+```
+'/usr/lib64/nagios/plugins/check_http' '--sni'
+```
+
+[Numeric](17-language-reference.md#numeric-literals) values are allowed too.
+
+**Parameters with value, but additionally controlled with an extra custom variable boolean flag.**
+
+The following example is taken from the [postgres]() CheckCommand. The host
+parameter should use a `value` but only whenever the `postgres_unixsocket`
+[custom variable](03-monitoring-basics.md#custom-variables) is set to false.
+
+Note: `set_if` is using a runtime lambda function because the value
+is evaluated at runtime. This is explained in [this chapter](08-advanced-topics.md#use-functions-object-config).
+
+```
+ command = [ PluginContribDir + "/check_postgres.pl" ]
+
+ arguments = {
+ "-H" = {
+ value = "$postgres_host$"
+ set_if = {{ macro("$postgres_unixsocket$") == false }}
+ description = "hostname(s) to connect to; defaults to none (Unix socket)"
}
+```
+
+An executed check for this host and services ...
+
+```
+object Host "postgresql-cluster" {
+ // ...
+
+ vars.postgres_host = "192.168.56.200"
+ vars.postgres_unixsocket = false
}
```
-If you accidentally used a [String](17-language-reference.md#string-literals) value, this could lead into
-an undefined behaviour.
+... use the following command line:
-If you still want to work with String values and other variants, you can also
-use runtime evaluated functions for `set_if`.
+```
+'/usr/lib64/nagios/plugins/check_postgres.pl' '-H' '192.168.56.200'
+```
+
+Host/service objects which set `postgres_unixsocket` to `false` don't add the `-H` parameter
+and its value to the command line.
+
+References: [abbreviated lambda syntax](17-language-reference.md#nullary-lambdas), [macro](18-library-reference.md#scoped-functions-macro).
+
+##### Command Arguments: Order <a id="command-arguments-order"></a>
+
+Plugin may require parameters in a special order. One after the other,
+or e.g. one parameter always in the first position.
```
-vars.test_s = "1.1.2.1"
-arguments = {
- "-z" = {
- set_if = {{
- var str = macro("$test_s$")
+ arguments = {
+ "--first" = {
+ value = "..."
+ description = "..."
+ order = -5
+ }
+ "--second" = {
+ value = "..."
+ description = "..."
+ order = -4
+ }
+ "--last" = {
+ value = "..."
+ description = "..."
+ order = 99
+ }
+ }
+```
+
+Keep in mind that positional arguments need to be tested thoroughly.
+
+##### Command Arguments: Repeat Key <a id="command-arguments-repeat-key"></a>
+
+Parameters can use [Array](17-language-reference.md#array) as value type. Whenever Icinga encounters
+an array, it repeats the parameter key and each value element by default.
+
+```
+ command = [ NscpPath + "\\nscp.exe", "client" ]
+
+ arguments = {
+ "-a" = {
+ value = "$nscp_arguments$"
+ description = "..."
+ repeat_key = true
+ }
+ }
+```
+
+On a host/service object, specify the `nscp_arguments` [custom variable](03-monitoring-basics.md#custom-variables)
+as an array.
+
+```
+ vars.nscp_arguments = [ "exclude=sppsvc", "exclude=ShellHWDetection" ]
+```
+
+This translates into the following command line:
+
+```
+nscp.exe 'client' '-a' 'exclude=sppsvc' '-a' 'exclude=ShellHWDetection'
+```
+
+If the plugin requires you to pass the list without repeating the key,
+set `repeat_key = false` in the argument definition.
+
+```
+ command = [ NscpPath + "\\nscp.exe", "client" ]
+
+ arguments = {
+ "-a" = {
+ value = "$nscp_arguments$"
+ description = "..."
+ repeat_key = false
+ }
+ }
+```
+
+This translates into the following command line:
+
+```
+nscp.exe 'client' '-a' 'exclude=sppsvc' 'exclude=ShellHWDetection'
+```
+
- return regex("^\d.\d.\d.\d$", str)
- }}
+##### Command Arguments: Key <a id="command-arguments-key"></a>
+
+The `arguments` attribute requires unique keys. Sometimes, you'll
+need to override this in the resulting command line with same key
+names. Therefore you can specifically override the arguments key.
+
+```
+arguments = {
+ "--key1" = {
+ value = "..."
+ key = "-specialkey"
+ }
+ "--key2" = {
+ value = "..."
+ key = "-specialkey"
}
+}
```
-References: [abbreviated lambda syntax](17-language-reference.md#nullary-lambdas), [macro](18-library-reference.md#scoped-functions-macro), [regex](18-library-reference.md#global-functions-regex).
+This results in the following command line:
+```
+ '-specialkey' '...' '-specialkey' '...'
+```
#### Environment Variables <a id="command-environment-variables"></a>
The `env` command object attribute specifies a list of environment variables with values calculated
-from custom attributes which should be exported as environment variables prior to executing the command.
+from custom variables which should be exported as environment variables prior to executing the command.
This is useful for example for hiding sensitive information on the command line output
when passing credentials to database checks:
@@ -2203,7 +2461,7 @@ the database credentials in the user's environment.
> **Note**
>
> If the CheckCommand also supports setting the parameter in the command line,
-> ensure to use a different name for the custom attribute. Otherwise Icinga 2
+> ensure to use a different name for the custom variable. Otherwise Icinga 2
> adds the command line parameter.
If a specific CheckCommand object provided with the [Icinga Template Library](10-icinga-template-library.md#icinga-template-library)
@@ -2221,7 +2479,7 @@ object CheckCommand "mysql_health_env" {
}
```
-Specify the custom attributes `mysql_health_env_username` and `mysql_health_env_password`
+Specify the custom variables `mysql_health_env_username` and `mysql_health_env_password`
in the service object then.
> **Note**
@@ -2273,54 +2531,13 @@ defaults can always be overwritten locally.
>
> This example requires the `mail` binary installed on the Icinga 2
> master.
-
-#### Notification Commands in 2.7 <a id="notification-command-2-7"></a>
-
-Icinga 2 v2.7.0 introduced new notification scripts which support both
-environment variables and command line parameters.
-
-Therefore the `NotificationCommand` objects inside the [commands.conf](04-configuring-icinga-2.md#commands-conf)
-and `Notification` apply rules inside the [notifications.conf](04-configuring-icinga-2.md#notifications-conf)
-configuration files have been updated. Your configuration needs to be
-updated next to the notification scripts themselves.
-
-> **Note**
>
-> Several parameters have been changed. Please review the notification
-> script parameters and configuration objects before updating your production
-> environment.
-
-The safest way is to incorporate the configuration updates from
-v2.7.0 inside the [commands.conf](04-configuring-icinga-2.md#commands-conf) and [notifications.conf](04-configuring-icinga-2.md#notifications-conf)
-configuration files.
-
-A quick-fix is shown below:
-
-```
-@@ -5,7 +5,8 @@ object NotificationCommand "mail-host-notification" {
-
- env = {
- NOTIFICATIONTYPE = "$notification.type$"
-- HOSTALIAS = "$host.display_name$"
-+ HOSTNAME = "$host.name$"
-+ HOSTDISPLAYNAME = "$host.display_name$"
- HOSTADDRESS = "$address$"
- HOSTSTATE = "$host.state$"
- LONGDATETIME = "$icinga.long_date_time$"
-@@ -22,8 +23,9 @@ object NotificationCommand "mail-service-notification" {
-
- env = {
- NOTIFICATIONTYPE = "$notification.type$"
-- SERVICEDESC = "$service.name$"
-- HOSTALIAS = "$host.display_name$"
-+ SERVICENAME = "$service.name$"
-+ HOSTNAME = "$host.name$"
-+ HOSTDISPLAYNAME = "$host.display_name$"
- HOSTADDRESS = "$address$"
- SERVICESTATE = "$service.state$"
- LONGDATETIME = "$icinga.long_date_time$"
-```
-
+> Depending on the distribution, you need a local mail transfer
+> agent (MTA) such as Postfix, Exim or Sendmail in order
+> to send emails.
+>
+> These tools virtually provide the `mail` binary executed
+> by the notification scripts below.
#### mail-host-notification <a id="mail-host-notification"></a>
@@ -2391,7 +2608,7 @@ account but all parents are inherited.
The `parent_host_name` and `parent_service_name` attributes are mandatory for
service dependencies, `parent_host_name` is required for host dependencies.
[Apply rules](03-monitoring-basics.md#using-apply) will allow you to
-[determine these attributes](03-monitoring-basics.md#dependencies-apply-custom-attributes) in a more
+[determine these attributes](03-monitoring-basics.md#dependencies-apply-custom-variables) in a more
dynamic fashion if required.
```
@@ -2498,7 +2715,10 @@ apply Dependency "internet" to Service {
}
```
-### Apply Dependencies based on Custom Attributes <a id="dependencies-apply-custom-attributes"></a>
+<!-- Keep this for compatibility -->
+<a id="dependencies-apply-custom-attríbutes"></a>
+
+### Apply Dependencies based on Custom Variables <a id="dependencies-apply-custom-variables"></a>
You can use [apply rules](03-monitoring-basics.md#using-apply) to set parent or
child attributes, e.g. `parent_host_name` to other objects'
@@ -2506,7 +2726,7 @@ attributes.
A common example are virtual machines hosted on a master. The object
name of that master is auto-generated from your CMDB or VMWare inventory
-into the host's custom attributes (or a generic template for your
+into the host's custom variables (or a generic template for your
cloud).
Define your master host object:
@@ -2528,7 +2748,7 @@ template Host "generic-vm" {
```
Add a template for all hosts on your example.com cloud setting
-custom attribute `vm_parent` to `master.example.com`:
+custom variable `vm_parent` to `master.example.com`:
```
template Host "generic-vm-example.com" {
@@ -2551,7 +2771,7 @@ object Host "www.example2.com" {
Apply the host dependency to all child hosts importing the
`generic-vm` template and set the `parent_host_name`
-to the previously defined custom attribute `host.vars.vm_parent`.
+to the previously defined custom variable `host.vars.vm_parent`.
```
apply Dependency "vm-host-to-parent-master" to Host {
@@ -2782,7 +3002,7 @@ The script only is executed if the service state is `CRITICAL`. Warning and Unkn
are ignored as they indicate not an immediate failure.
```
-[root@icinga2-client1.localdomain /]# vim /usr/lib64/nagios/plugins/restart_service
+[root@icinga2-agent1.localdomain /]# vim /usr/lib64/nagios/plugins/restart_service
#!/bin/bash
@@ -2813,7 +3033,7 @@ else
fi
fi
-[root@icinga2-client1.localdomain /]# chmod +x /usr/lib64/nagios/plugins/restart_service
+[root@icinga2-agent1.localdomain /]# chmod +x /usr/lib64/nagios/plugins/restart_service
```
Add a service on the master node which is executed via command endpoint on the client.
@@ -2821,15 +3041,15 @@ Set the `event_command` attribute to `restart_service`, the name of the previous
EventCommand object.
```
-[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-client1.localdomain.conf
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-agent1.localdomain.conf
object Service "Process httpd" {
check_command = "procs"
event_command = "restart_service"
max_check_attempts = 4
- host_name = "icinga2-client1.localdomain"
- command_endpoint = "icinga2-client1.localdomain"
+ host_name = "icinga2-agent1.localdomain"
+ command_endpoint = "icinga2-agent1.localdomain"
vars.procs_command = "httpd"
vars.procs_warning = "1:10"
@@ -2837,17 +3057,17 @@ object Service "Process httpd" {
}
```
-In order to test this configuration just stop the `httpd` on the remote host `icinga2-client1.localdomain`.
+In order to test this configuration just stop the `httpd` on the remote host `icinga2-agent1.localdomain`.
```
-[root@icinga2-client1.localdomain /]# systemctl stop httpd
+[root@icinga2-agent1.localdomain /]# systemctl stop httpd
```
You can enable the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) and search for the
executed command line.
```
-[root@icinga2-client1.localdomain /]# tail -f /var/log/icinga2/debug.log | grep restart_service
+[root@icinga2-agent1.localdomain /]# tail -f /var/log/icinga2/debug.log | grep restart_service
```
#### Use Event Commands to Restart Service Daemon via Command Endpoint on Windows <a id="event-command-restart-service-daemon-command-endpoint-windows"></a>
@@ -2923,21 +3143,21 @@ Set the `event_command` attribute to `restart_service-windows`, the name of the
EventCommand object.
```
-[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-client2.localdomain.conf
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-agent2.localdomain.conf
object Service "Service httpd" {
check_command = "service-windows"
event_command = "restart_service-windows"
max_check_attempts = 4
- host_name = "icinga2-client2.localdomain"
- command_endpoint = "icinga2-client2.localdomain"
+ host_name = "icinga2-agent2.localdomain"
+ command_endpoint = "icinga2-agent2.localdomain"
vars.service_win_service = "httpd"
}
```
-In order to test this configuration just stop the `httpd` on the remote host `icinga2-client1.localdomain`.
+In order to test this configuration just stop the `httpd` on the remote host `icinga2-agent1.localdomain`.
```
C:> net stop httpd
@@ -2998,7 +3218,7 @@ object EventCommand "event_by_ssh" {
```
The actual event command only passes the `event_by_ssh_command` attribute.
-The `event_by_ssh_service` custom attribute takes care of passing the correct
+The `event_by_ssh_service` custom variable takes care of passing the correct
daemon name, while `test $service.state_id$ -gt 0` makes sure that the daemon
is only restarted when the service is not in an `OK` state.
@@ -3031,7 +3251,7 @@ apply Service "http" {
}
```
-Specify the `httpd_name` custom attribute on the host to assign the
+Specify the `httpd_name` custom variable on the host to assign the
service and set the event handler service.
```
@@ -3043,15 +3263,15 @@ object Host "remote-http-host" {
}
```
-In order to test this configuration just stop the `httpd` on the remote host `icinga2-client1.localdomain`.
+In order to test this configuration just stop the `httpd` on the remote host `icinga2-agent1.localdomain`.
```
-[root@icinga2-client1.localdomain /]# systemctl stop httpd
+[root@icinga2-agent1.localdomain /]# systemctl stop httpd
```
You can enable the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) and search for the
executed command line.
```
-[root@icinga2-client1.localdomain /]# tail -f /var/log/icinga2/debug.log | grep by_ssh
+[root@icinga2-agent1.localdomain /]# tail -f /var/log/icinga2/debug.log | grep by_ssh
```
diff --git a/doc/04-configuring-icinga-2.md b/doc/04-configuration.md
index 434b8c9..4d4fd05 100644
--- a/doc/04-configuring-icinga-2.md
+++ b/doc/04-configuration.md
@@ -1,4 +1,4 @@
-# Configuring Icinga 2: First Steps <a id="configuring-icinga2-first-steps"></a>
+# Configuration: First Steps <a id="configuration"></a>
This chapter provides an introduction into best practices for your Icinga 2 configuration.
The configuration files which are automatically created when installing the Icinga 2 packages
@@ -36,7 +36,7 @@ host and service basis.
Then you should look for the object specific configuration setting `host_name` etc. accordingly.
You decide on the "best" layout for configuration files and directories. Ensure that
-the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file includes them.
+the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file includes them.
Consider these ideas:
@@ -48,12 +48,12 @@ Consider these ideas:
In either way of choosing the right strategy you should additionally check the following:
-* Are there any specific attributes describing the host/service you could set as `vars` custom attributes?
+* Are there any specific attributes describing the host/service you could set as `vars` custom variables?
You can later use them for applying assign/ignore rules, or export them into external interfaces.
* Put hosts into hostgroups, services into servicegroups and use these attributes for your apply rules.
* Use templates to store generic attributes for your objects and apply rules making your configuration more readable.
Details can be found in the [using templates](03-monitoring-basics.md#object-inheritance-using-templates) chapter.
-* Apply rules may overlap. Keep a central place (for example, [services.conf](04-configuring-icinga-2.md#services-conf) or [notifications.conf](04-configuring-icinga-2.md#notifications-conf)) storing
+* Apply rules may overlap. Keep a central place (for example, [services.conf](04-configuration.md#services-conf) or [notifications.conf](04-configuration.md#notifications-conf)) storing
the configuration instead of defining apply rules deep in your configuration tree.
* Every plugin used as check, notification or event command requires a `Command` definition.
Further details can be looked up in the [check commands](03-monitoring-basics.md#check-commands) chapter.
@@ -176,7 +176,7 @@ the features which have been enabled with `icinga2 feature enable`. See
include_recursive "conf.d"
```
-You can put your own configuration files in the [conf.d](04-configuring-icinga-2.md#conf-d) directory. This
+You can put your own configuration files in the [conf.d](04-configuration.md#conf-d) directory. This
directive makes sure that all of your own configuration files are included.
### constants.conf <a id="constants-conf"></a>
@@ -185,7 +185,7 @@ The `constants.conf` configuration file can be used to define global constants.
By default, you need to make sure to set these constants:
-* The `PluginDir` constant must be set to the path where the [Monitoring Project plugins](02-getting-started.md#setting-up-check-plugins) are installed.
+* The `PluginDir` constant must be set to the path where the [Monitoring Project plugins](02-installation.md#setting-up-check-plugins) are installed.
This constant is used by a number of
[built-in check command definitions](10-icinga-template-library.md#icinga-template-library).
* The `NodeName` constant defines your local node name. Should be set to FQDN which is the default
@@ -224,7 +224,7 @@ This file can be used to specify the required [Zone](09-object-types.md#objectty
and [Endpoint](09-object-types.md#objecttype-endpoint) configuration object for
[distributed monitoring](06-distributed-monitoring.md#distributed-monitoring).
-By default the `NodeName` and `ZoneName` [constants](04-configuring-icinga-2.md#constants-conf) will be used.
+By default the `NodeName` and `ZoneName` [constants](04-configuration.md#constants-conf) will be used.
It also contains several [global zones](06-distributed-monitoring.md#distributed-monitoring-global-zone-config-sync)
for distributed monitoring environments.
@@ -237,38 +237,38 @@ for your `Zone` and `Endpoint` object names.
This directory contains **example configuration** which should help you get started
with monitoring the local host and its services. It is included in the
-[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file by default.
+[icinga2.conf](04-configuration.md#icinga2-conf) configuration file by default.
It can be used as reference example for your own configuration strategy.
Just keep in mind to include the main directories in the
-[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) file.
+[icinga2.conf](04-configuration.md#icinga2-conf) file.
> **Note**
>
-> You can remove the include directive in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf)
+> You can remove the include directive in [icinga2.conf](04-configuration.md#icinga2-conf)
> if you prefer your own way of deploying Icinga 2 configuration.
Further details on configuration best practice and how to build your
-own strategy is described in [this chapter](04-configuring-icinga-2.md#configuration-best-practice).
+own strategy is described in [this chapter](04-configuration.md#configuration-best-practice).
Available configuration files which are installed by default:
-* [hosts.conf](04-configuring-icinga-2.md#hosts-conf)
-* [services.conf](04-configuring-icinga-2.md#services-conf)
-* [users.conf](04-configuring-icinga-2.md#users-conf)
-* [notifications.conf](04-configuring-icinga-2.md#notifications-conf)
-* [commands.conf](04-configuring-icinga-2.md#commands-conf)
-* [groups.conf](04-configuring-icinga-2.md#groups-conf)
-* [templates.conf](04-configuring-icinga-2.md#templates-conf)
-* [downtimes.conf](04-configuring-icinga-2.md#downtimes-conf)
-* [timeperiods.conf](04-configuring-icinga-2.md#timeperiods-conf)
-* [api-users.conf](04-configuring-icinga-2.md#api-users-conf)
-* [app.conf](04-configuring-icinga-2.md#app-conf)
+* [hosts.conf](04-configuration.md#hosts-conf)
+* [services.conf](04-configuration.md#services-conf)
+* [users.conf](04-configuration.md#users-conf)
+* [notifications.conf](04-configuration.md#notifications-conf)
+* [commands.conf](04-configuration.md#commands-conf)
+* [groups.conf](04-configuration.md#groups-conf)
+* [templates.conf](04-configuration.md#templates-conf)
+* [downtimes.conf](04-configuration.md#downtimes-conf)
+* [timeperiods.conf](04-configuration.md#timeperiods-conf)
+* [api-users.conf](04-configuration.md#api-users-conf)
+* [app.conf](04-configuration.md#app-conf)
#### hosts.conf <a id="hosts-conf"></a>
The `hosts.conf` file contains an example host based on your
-`NodeName` setting in [constants.conf](04-configuring-icinga-2.md#constants-conf). You
+`NodeName` setting in [constants.conf](04-configuration.md#constants-conf). You
can use global constants for your object names instead of string
values.
@@ -276,25 +276,25 @@ The `import` keyword is used to import the `generic-host` template which
takes care of setting up the host check command to `hostalive`. If you
require a different check command, you can override it in the object definition.
-The `vars` attribute can be used to define custom attributes which are available
+The `vars` attribute can be used to define custom variables which are available
for check and notification commands. Most of the [Plugin Check Commands](10-icinga-template-library.md#icinga-template-library)
in the Icinga Template Library require an `address` attribute.
-The custom attribute `os` is evaluated by the `linux-servers` group in
-[groups.conf](04-configuring-icinga-2.md#groups-conf) making the local host a member.
+The custom variable `os` is evaluated by the `linux-servers` group in
+[groups.conf](04-configuration.md#groups-conf) making the local host a member.
The example host will show you how to:
* define http vhost attributes for the `http` service apply rule defined
-in [services.conf](04-configuring-icinga-2.md#services-conf).
+in [services.conf](04-configuration.md#services-conf).
* define disks (all, specific `/`) and their attributes for the `disk`
-service apply rule defined in [services.conf](04-configuring-icinga-2.md#services-conf).
+service apply rule defined in [services.conf](04-configuration.md#services-conf).
* define notification types (`mail`) and set the groups attribute. This
-will be used by notification apply rules in [notifications.conf](04-configuring-icinga-2.md#notifications-conf).
+will be used by notification apply rules in [notifications.conf](04-configuration.md#notifications-conf).
-If you've installed [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2), you can
+If you've installed [Icinga Web 2](02-installation.md#setting-up-icingaweb2), you can
uncomment the http vhost attributes and reload Icinga 2. The apply
-rules in [services.conf](04-configuring-icinga-2.md#services-conf) will automatically
+rules in [services.conf](04-configuration.md#services-conf) will automatically
generate a new service checking the `/icingaweb2` URI using the `http`
check.
@@ -324,7 +324,7 @@ object Host NodeName {
address = "127.0.0.1"
address6 = "::1"
- /* Set custom attribute `os` for hostgroup assignment in `groups.conf`. */
+ /* Set custom variable `os` for hostgroup assignment in `groups.conf`. */
vars.os = "Linux"
/* Define http vhost attributes for service apply rules in `services.conf`. */
@@ -353,7 +353,7 @@ object Host NodeName {
```
This is only the host object definition. Now we'll need to make sure that this
-host and your additional hosts are getting [services](04-configuring-icinga-2.md#services-conf) applied.
+host and your additional hosts are getting [services](04-configuration.md#services-conf) applied.
> **Tip**
>
@@ -377,8 +377,8 @@ Service(s) | Applied on host(s)
`load`, `procs`, `swap`, `users`, `icinga` | The `NodeName` host only.
`ping4`, `ping6` | All hosts with `address` resp. `address6` attribute.
`ssh` | All hosts with `address` and `vars.os` set to `Linux`
-`http`, optional: `Icinga Web 2` | All hosts with custom attribute `http_vhosts` defined as dictionary.
-`disk`, `disk /` | All hosts with custom attribute `disks` defined as dictionary.
+`http`, optional: `Icinga Web 2` | All hosts with custom variable `http_vhosts` defined as dictionary.
+`disk`, `disk /` | All hosts with custom variable `disks` defined as dictionary.
The Debian packages also include an additional `apt` service check applied to the local host.
@@ -407,9 +407,9 @@ The `apply` keyword can be used to create new objects which are associated with
another group of objects. You can `import` existing templates, define (custom)
attributes.
-The custom attribute `backup_downtime` is defined to a specific timerange string.
+The custom variable `backup_downtime` is defined to a specific timerange string.
This variable value will be used for applying a `ScheduledDowntime` object to
-these services in [downtimes.conf](04-configuring-icinga-2.md#downtimes-conf).
+these services in [downtimes.conf](04-configuration.md#downtimes-conf).
In this example the `assign where` condition is a boolean expression which is
evaluated for all objects of type `Host` and a new service with name "load"
@@ -430,7 +430,7 @@ apply Service "ssh" {
```
In this example, the service `ssh` is applied to all hosts having the `address`
-attribute defined `AND` having the custom attribute `os` set to the string
+attribute defined `AND` having the custom variable `os` set to the string
`Linux`.
You can modify this condition to match multiple expressions by combining `AND`
and `OR` using `&&` and `||` [operators](17-language-reference.md#expression-operators), for example
@@ -442,10 +442,10 @@ rules. While one `apply` rule for `ssh` will only create a service for matching
hosts, you can go one step further: Generate apply rules based on array items
or dictionary key-value pairs.
-The idea is simple: Your host in [hosts.conf](04-configuring-icinga-2.md#hosts-conf) defines the
-`disks` dictionary as custom attribute in `vars`.
+The idea is simple: Your host in [hosts.conf](04-configuration.md#hosts-conf) defines the
+`disks` dictionary as custom variable in `vars`.
-Remember the example from [hosts.conf](04-configuring-icinga-2.md#hosts-conf):
+Remember the example from [hosts.conf](04-configuration.md#hosts-conf):
```
...
@@ -499,11 +499,11 @@ A similar example is used for the `http` services. That way you can make your
host the information provider for all apply rules. Define them once, and only
manage your hosts.
-Look into [notifications.conf](04-configuring-icinga-2.md#notifications-conf) how this technique is used
+Look into [notifications.conf](04-configuration.md#notifications-conf) how this technique is used
for applying notifications to hosts and services using their type and user
attributes.
-Don't forget to install the [check plugins](02-getting-started.md#setting-up-check-plugins) required by
+Don't forget to install the [check plugins](02-installation.md#setting-up-check-plugins) required by
the hosts and services and their check commands.
Further details on the monitoring configuration can be found in the
@@ -512,8 +512,8 @@ Further details on the monitoring configuration can be found in the
#### users.conf <a id="users-conf"></a>
Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in
-[hosts.conf](04-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
-[notifications.conf](04-configuring-icinga-2.md#notifications-conf) for notification apply rules.
+[hosts.conf](04-configuration.md#hosts-conf) for defining a custom host attribute later used in
+[notifications.conf](04-configuration.md#notifications-conf) for notification apply rules.
```
object User "icingaadmin" {
@@ -541,13 +541,13 @@ nested dictionary attribute `notification.mail` is set.
Please note that the `to` keyword is important in [notification apply rules](03-monitoring-basics.md#using-apply-notifications)
defining whether these notifications are applies to hosts or services.
-The `import` keyword imports the specific mail templates defined in [templates.conf](04-configuring-icinga-2.md#templates-conf).
+The `import` keyword imports the specific mail templates defined in [templates.conf](04-configuration.md#templates-conf).
The `interval` attribute is not explicitly set -- it [defaults to 30 minutes](09-object-types.md#objecttype-notification).
By setting the `user_groups` to the value provided by the
-respective [host.vars.notification.mail](04-configuring-icinga-2.md#hosts-conf) attribute we'll
-implicitely use the `icingaadmins` UserGroup defined in [users.conf](04-configuring-icinga-2.md#users-conf).
+respective [host.vars.notification.mail](04-configuration.md#hosts-conf) attribute we'll
+implicitely use the `icingaadmins` UserGroup defined in [users.conf](04-configuration.md#users-conf).
```
apply Notification "mail-icingaadmin" to Host {
@@ -575,7 +575,7 @@ filters can be read in [this chapter](03-monitoring-basics.md#alert-notification
#### commands.conf <a id="commands-conf"></a>
This is the place where your own command configuration can be defined. By default
-only the notification commands used by the notification templates defined in [templates.conf](04-configuring-icinga-2.md#templates-conf).
+only the notification commands used by the notification templates defined in [templates.conf](04-configuration.md#templates-conf).
You can freely customize these notification commands, and adapt them for your needs.
Read more on that topic [here](03-monitoring-basics.md#notification-commands).
@@ -583,7 +583,7 @@ Read more on that topic [here](03-monitoring-basics.md#notification-commands).
#### groups.conf <a id="groups-conf"></a>
The example host defined in [hosts.conf](hosts-conf) already has the
-custom attribute `os` set to `Linux` and is therefore automatically
+custom variable `os` set to `Linux` and is therefore automatically
a member of the host group `linux-servers`.
This is done by using the [group assign](17-language-reference.md#group-assign) expressions similar
@@ -680,8 +680,8 @@ More details on `Notification` object attributes can be found [here](09-object-t
#### downtimes.conf <a id="downtimes-conf"></a>
-The `load` service apply rule defined in [services.conf](04-configuring-icinga-2.md#services-conf) defines
-the `backup_downtime` custom attribute.
+The `load` service apply rule defined in [services.conf](04-configuration.md#services-conf) defines
+the `backup_downtime` custom variable.
The ScheduledDowntime apply rule uses this attribute to define the default value
for the time ranges required for recurring downtime slots.
diff --git a/doc/05-service-monitoring.md b/doc/05-service-monitoring.md
index aeeeb48..b19e284 100644
--- a/doc/05-service-monitoring.md
+++ b/doc/05-service-monitoring.md
@@ -4,48 +4,142 @@ The power of Icinga 2 lies in its modularity. There are thousands of
community plugins available next to the standard plugins provided by
the [Monitoring Plugins project](https://www.monitoring-plugins.org).
+Start your research on [Icinga Exchange](https://exchange.icinga.com)
+and look which services are already [covered](05-service-monitoring.md#service-monitoring-overview).
+
+The [requirements chapter](05-service-monitoring.md#service-monitoring-requirements) guides you
+through the plugin setup, tests and their integration with an [existing](05-service-monitoring.md#service-monitoring-plugin-checkcommand)
+or [new](05-service-monitoring.md#service-monitoring-plugin-checkcommand-new) CheckCommand object
+and host/service objects inside the [Director](05-service-monitoring.md#service-monitoring-plugin-checkcommand-integration-director)
+or [Icinga config files](05-service-monitoring.md#service-monitoring-plugin-checkcommand-integration-config-files).
+It also adds hints on [modifying](05-service-monitoring.md#service-monitoring-plugin-checkcommand-modify) existing commands.
+
+Plugins follow the [Plugin API specification](05-service-monitoring.md#service-monitoring-plugin-api)
+which is enriched with examples and also code examples to get you started with
+[your own plugin](05-service-monitoring.md#service-monitoring-plugin-new).
+
+
+
## Requirements <a id="service-monitoring-requirements"></a>
### Plugins <a id="service-monitoring-plugins"></a>
-All existing Nagios or Icinga 1.x plugins work with Icinga 2. Community
+All existing Icinga or Nagios plugins work with Icinga 2. Community
plugins can be found for example on [Icinga Exchange](https://exchange.icinga.com).
-The recommended way of setting up these plugins is to copy them to a common directory
-and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](04-configuring-icinga-2.md#constants-conf)
-configuration file:
+The recommended way of setting up these plugins is to copy them
+into the `PluginDir` directory.
-```
-# cp check_snmp_int.pl /opt/monitoring/plugins
-# chmod +x /opt/monitoring/plugins/check_snmp_int.pl
+If you have plugins with many dependencies, consider creating a
+custom RPM/DEB package which handles the required libraries and binaries.
-# cat /etc/icinga2/constants.conf
-/**
- * This file defines global constants which can be used in
- * the other configuration files. At a minimum the
- * PluginDir constant should be defined.
- */
+Configuration management tools such as Puppet, Ansible, Chef or Saltstack
+also help with automatically installing the plugins on different
+operating systems. They can also help with installing the required
+dependencies, e.g. Python libraries, Perl modules, etc.
-const PluginDir = "/usr/lib/nagios/plugins"
-const CustomPluginDir = "/opt/monitoring/plugins"
-```
+### Plugin Setup <a id="service-monitoring-plugins-setup"></a>
+
+Good plugins provide installations and configuration instructions
+in their docs and/or README on GitHub.
+
+Sometimes dependencies are not listed, or your distribution differs from the one
+described. Try running the plugin after setup and [ensure it works](05-service-monitoring.md#service-monitoring-plugins-it-works).
+
+#### Ensure it works <a id="service-monitoring-plugins-it-works"></a>
Prior to using the check plugin with Icinga 2 you should ensure that it is working properly
by trying to run it on the console using whichever user Icinga 2 is running as:
+RHEL/CentOS/Fedora
+
```
-# su - icinga -s /bin/bash
-$ /opt/monitoring/plugins/check_snmp_int.pl --help
+sudo -u icinga /usr/lib64/nagios/plugins/check_mysql_health --help
+```
+
+Debian/Ubuntu
+
+```
+sudo -u nagios /usr/lib/nagios/plugins/check_mysql_health --help
```
Additional libraries may be required for some plugins. Please consult the plugin
documentation and/or the included README file for installation instructions.
Sometimes plugins contain hard-coded paths to other components. Instead of changing
-the plugin it might be easier to create a symbolic link to make sure it doesn't get overwritten during the next update.
+the plugin it might be easier to create a symbolic link to make sure it doesn't get
+overwritten during the next update.
Sometimes there are plugins which do not exactly fit your requirements.
In that case you can modify an existing plugin or just write your own.
+#### Plugin Dependency Errors <a id="service-monitoring-plugins-setup-dependency-errors"></a>
+
+Plugins can be scripts (Shell, Python, Perl, Ruby, PHP, etc.)
+or compiled binaries (C, C++, Go).
+
+These scripts/binaries may require additional libraries
+which must be installed on every system they are executed.
+
+> **Tip**
+>
+> Don't test the plugins on your master instance, instead
+> do that on the satellites and clients which execute the
+> checks.
+
+There are errors, now what? Typical errors are missing libraries,
+binaries or packages.
+
+##### Python Example
+
+Example for a Python plugin which uses the `tinkerforge` module
+to query a network service:
+
+```
+ImportError: No module named tinkerforge.ip_connection
+```
+
+Its [documentation](https://github.com/NETWAYS/check_tinkerforge#installation)
+points to installing the `tinkerforge` Python module.
+
+##### Perl Example
+
+Example for a Perl plugin which uses SNMP:
+
+```
+Can't locate Net/SNMP.pm in @INC (you may need to install the Net::SNMP module)
+```
+
+Prior to installing the Perl module via CPAN, look for a distribution
+specific package, e.g. `libnet-snmp-perl` on Debian/Ubuntu or `perl-Net-SNMP`
+on RHEL/CentOS.
+
+
+#### Optional: Custom Path <a id="service-monitoring-plugins-custom-path"></a>
+
+If you are not using the default `PluginDir` directory, you
+can create a custom plugin directory and constant
+and reference this in the created CheckCommand objects.
+
+Create a common directory e.g. `/opt/monitoring/plugins`
+and install the plugin there.
+
+```
+mkdir -p /opt/monitoring/plugins
+cp check_snmp_int.pl /opt/monitoring/plugins
+chmod +x /opt/monitoring/plugins/check_snmp_int.pl
+```
+
+Next create a new global constant, e.g. `CustomPluginDir`
+in your [constants.conf](04-configuration.md#constants-conf)
+configuration file:
+
+```
+vim /etc/icinga2/constants.conf
+
+const PluginDir = "/usr/lib/nagios/plugins"
+const CustomPluginDir = "/opt/monitoring/plugins"
+```
+
### CheckCommand Definition <a id="service-monitoring-plugin-checkcommand"></a>
Each plugin requires a [CheckCommand](09-object-types.md#objecttype-checkcommand) object in your
@@ -54,55 +148,617 @@ configuration which can be used in the [Service](09-object-types.md#objecttype-s
Please check if the Icinga 2 package already provides an
[existing CheckCommand definition](10-icinga-template-library.md#icinga-template-library).
-If that's the case, throroughly check the required parameters and integrate the check command
-into your host and service objects.
+
+If that's the case, thoroughly check the required parameters and integrate the check command
+into your host and service objects. Best practice is to run the plugin on the CLI
+with the required parameters first.
+
+Example for database size checks with [check_mysql_health](10-icinga-template-library.md#plugin-contrib-command-mysql_health).
+
+```
+/usr/lib64/nagios/plugins/check_mysql_health --hostname '127.0.0.1' --username root --password icingar0xx --mode sql --name 'select sum(data_length + index_length) / 1024 / 1024 from information_schema.tables where table_schema = '\''icinga'\'';' '--name2' 'db_size' --units 'MB' --warning 4096 --critical 8192
+```
+
+The parameter names inside the ITL commands follow the
+`<command name>_<parameter name>` schema.
+
+#### Icinga Director Integration <a id="service-monitoring-plugin-checkcommand-integration-director"></a>
+
+Navigate into `Commands > External Commands` and search for `mysql_health`.
+Select `mysql_health` and navigate into the `Fields` tab.
+
+In order to access the parameters, the Director requires you to first
+define the needed custom data fields:
+
+* `mysql_health_hostname`
+* `mysql_health_username` and `mysql_health_password`
+* `mysql_health_mode`
+* `mysql_health_name`, `mysql_health_name2` and `mysql_health_units`
+* `mysql_health_warning` and `mysql_health_critical`
+
+Create a new host template and object where you'll generic
+settings like `mysql_health_hostname` (if it differs from the host's
+`address` attribute) and `mysql_health_username` and `mysql_health_password`.
+
+Create a new service template for `mysql-health` and set the `mysql_health`
+as check command. You can also define a default for `mysql_health_mode`.
+
+Next, create a service apply rule or a new service set which gets assigned
+to matching host objects.
+
+
+#### Icinga Config File Integration <a id="service-monitoring-plugin-checkcommand-integration-config-files"></a>
+
+Create or modify a host object which stores
+the generic database defaults and prepares details
+for a service apply for rule.
+
+```
+object Host "icinga2-master1.localdomain" {
+ check_command = "hostalive"
+ address = "..."
+
+ // Database listens locally, not external
+ vars.mysql_health_hostname = "127.0.0.1"
+
+ // Basic database size checks for Icinga DBs
+ vars.databases["icinga"] = {
+ mysql_health_warning = 4096 //MB
+ mysql_health_critical = 8192 //MB
+ }
+ vars.databases["icingaweb2"] = {
+ mysql_health_warning = 4096 //MB
+ mysql_health_critical = 8192 //MB
+ }
+}
+```
+
+The host object prepares the database details and thresholds already
+for advanced [apply for](03-monitoring-basics.md#using-apply-for) rules. It also uses
+conditions to fetch host specified values, or set default values.
+
+```
+apply Service "db-size-" for (db_name => config in host.vars.databases) {
+ check_interval = 1m
+ retry_interval = 30s
+
+ check_command = "mysql_health"
+
+ if (config.mysql_health_username) {
+ vars.mysql_healt_username = config.mysql_health_username
+ } else {
+ vars.mysql_health_username = "root"
+ }
+ if (config.mysql_health_password) {
+ vars.mysql_healt_password = config.mysql_health_password
+ } else {
+ vars.mysql_health_password = "icingar0xx"
+ }
+
+ vars.mysql_health_mode = "sql"
+ vars.mysql_health_name = "select sum(data_length + index_length) / 1024 / 1024 from information_schema.tables where table_schema = '" + db_name + "';"
+ vars.mysql_health_name2 = "db_size"
+ vars.mysql_health_units = "MB"
+
+ if (config.mysql_health_warning) {
+ vars.mysql_health_warning = config.mysql_health_warning
+ }
+ if (config.mysql_health_critical) {
+ vars.mysql_health_critical = config.mysql_health_critical
+ }
+
+ vars += config
+}
+```
+
+#### New CheckCommand <a id="service-monitoring-plugin-checkcommand-new"></a>
+
+This chapter describes how to add a new CheckCommand object for a plugin.
Please make sure to follow these conventions when adding a new command object definition:
* Use [command arguments](03-monitoring-basics.md#command-arguments) whenever possible. The `command` attribute
must be an array in `[ ... ]` for shell escaping.
-* Define a unique `prefix` for the command's specific arguments. That way you can safely
-set them on host/service level and you'll always know which command they control.
+* Define a unique `prefix` for the command's specific arguments. Best practice is to follow this schema:
+
+```
+<command name>_<parameter name>
+```
+
+That way you can safely set them on host/service level and you'll always know which command they control.
* Use command argument default values, e.g. for thresholds.
* Use [advanced conditions](09-object-types.md#objecttype-checkcommand) like `set_if` definitions.
-This is an example for a custom `my-snmp-int` check command:
+Before starting with the CheckCommand definition, please check
+the existing objects available inside the ITL. They follow best
+practices and are maintained by developers and our community.
+
+This example picks a new plugin called [check_systemd](https://exchange.icinga.com/joseffriedrich/check_systemd)
+uploaded to Icinga Exchange in June 2019.
+
+First, [install](05-service-monitoring.md#service-monitoring-plugins-setup) the plugin and ensure
+that [it works](05-service-monitoring.md#service-monitoring-plugins-it-works). Then run it with the
+`--help` parameter to see the actual parameters (docs might be outdated).
+
+```
+./check_systemd.py --help
+
+usage: check_systemd.py [-h] [-c SECONDS] [-e UNIT | -u UNIT] [-v] [-V]
+ [-w SECONDS]
+
+...
+
+optional arguments:
+ -h, --help show this help message and exit
+ -c SECONDS, --critical SECONDS
+ Startup time in seconds to result in critical status.
+ -e UNIT, --exclude UNIT
+ Exclude a systemd unit from the checks. This option
+ can be applied multiple times. For example: -e mnt-
+ data.mount -e task.service.
+ -u UNIT, --unit UNIT Name of the systemd unit that is beeing tested.
+ -v, --verbose Increase output verbosity (use up to 3 times).
+ -V, --version show program's version number and exit
+ -w SECONDS, --warning SECONDS
+ Startup time in seconds to result in warning status.
+```
+
+The argument description is important, based on this you need to create the
+command arguments.
+
+> **Tip**
+>
+> When you are using the Director, you can prepare the commands as files
+> e.g. inside the `global-templates` zone. Then run the kickstart wizard
+> again to import the commands as external reference.
+>
+> If you prefer to use the Director GUI/CLI, please apply the steps
+> in the `Add Command` form.
+
+Start with the basic plugin call without any parameters.
+
+```
+object CheckCommand "systemd" { // Plugin name without 'check_' prefix
+ command = [ PluginContribDir + "/check_systemd.py" ] // Use the 'PluginContribDir' constant, see the contributed ITL commands
+}
+```
+
+Run a config validation to see if that works, `icinga2 daemon -C`
+
+Next, analyse the plugin parameters. Plugins with a good help output show
+optional parameters in square brackes. This is the case for all parameters
+for this plugin. If there are required parameters, use the `required` key
+inside the argument.
+
+The `arguments` attribute is a dictionary which takes the parameters as keys.
```
-object CheckCommand "my-snmp-int" {
- command = [ CustomPluginDir + "/check_snmp_int.pl" ]
+ arguments = {
+ "--unit" = { ... }
+ }
+```
+
+If there a long parameter names available, prefer them. This increases
+readability in both the configuration as well as the executed command line.
+
+The argument value itself is a sub dictionary which has additional keys:
+
+* `value` which references the runtime macro string
+* `description` where you copy the plugin parameter help text into
+* `required`, `set_if`, etc. for advanced parameters, check the [CheckCommand object](09-object-types.md#objecttype-checkcommand) chapter.
+The runtime macro syntax is required to allow value extraction when
+the command is executed.
+
+> **Tip**
+>
+> Inside the Director, store the new command first in order to
+> unveil the `Arguments` tab.
+
+Best practice is to use the command name as prefix, in this specific
+case e.g. `systemd_unit`.
+
+```
arguments = {
- "-H" = "$snmp_address$"
- "-C" = "$snmp_community$"
- "-p" = "$snmp_port$"
- "-2" = {
- set_if = "$snmp_v2$"
+ "--unit" = {
+ value = "$systemd_unit$" // The service parameter would then be defined as 'vars.systemd_unit = "icinga2"'
+ description = "Name of the systemd unit that is beeing tested."
}
- "-n" = "$snmp_interface$"
- "-f" = {
- set_if = "$snmp_perf$"
+ "--warning" = {
+ value = "$systemd_warning$"
+ description = "Startup time in seconds to result in warning status."
+ }
+ "--critical" = {
+ value = "$systemd_critical$"
+ description = "Startup time in seconds to result in critical status."
+ }
+ }
+```
+
+This may take a while -- validate the configuration in between up until
+the CheckCommand definition is done.
+
+Then test and integrate it into your monitoring configuration.
+
+Remember: Do it once and right, and never touch the CheckCommand again.
+Optional arguments allow different use cases and scenarios.
+
+
+Once you have created your really good CheckCommand, please consider
+sharing it with our community by creating a new PR on [GitHub](https://github.com/Icinga/icinga2/blob/master/CONTRIBUTING.md).
+_Please also update the documentation for the ITL._
+
+
+> **Tip**
+>
+> Inside the Director, you can render the configuration in the Deployment
+> section. Extract the static configuration object and use that as a source
+> for sending it upstream.
+
+
+
+#### Modify Existing CheckCommand <a id="service-monitoring-plugin-checkcommand-modify"></a>
+
+Sometimes an existing CheckCommand inside the ITL is missing a parameter.
+Or you don't need a default parameter value being set.
+
+Instead of copying the entire configuration object, you can import
+an object into another new object.
+
+```
+object CheckCommand "http-custom" {
+ import "http" // Import existing http object
+
+ arguments += { // Use additive assignment to add missing parameters
+ "--key" = {
+ value = "$http_..." // Keep the parameter name the same as with http
}
- "-w" = "$snmp_warn$"
- "-c" = "$snmp_crit$"
}
- vars.snmp_v2 = true
- vars.snmp_perf = true
- vars.snmp_warn = "300,400"
- vars.snmp_crit = "0,600"
+ // Override default parameters
+ vars.http_address = "..."
}
```
-For further information on your monitoring configuration read the
-[Monitoring Basics](03-monitoring-basics.md#monitoring-basics) chapter.
+This CheckCommand can then be referenced in your host/service object
+definitions.
-If you have created your own `CheckCommand` definition, please kindly
-[send it upstream](https://github.com/Icinga/icinga2/blob/master/CONTRIBUTING.md).
### Plugin API <a id="service-monitoring-plugin-api"></a>
-Currently Icinga 2 supports the native plugin API specification from the Monitoring Plugins project. It is defined in the [Monitoring Plugins Development Guidelines](https://www.monitoring-plugins.org/doc/guidelines.html).
+Icinga 2 supports the native plugin API specification from the Monitoring Plugins project.
+It is defined in the [Monitoring Plugins](https://www.monitoring-plugins.org) guidelines.
+
+The Icinga documentation revamps the specification into our
+own guideline enriched with examples and best practices.
+
+#### Output <a id="service-monitoring-plugin-api-output"></a>
+
+The output should be as short and as detailed as possible. The
+most common cases include:
+
+- Viewing a problem list in Icinga Web and dashboards
+- Getting paged about a problem
+- Receiving the alert on the CLI or forwarding it to external (ticket) systems
+
+Examples:
+
+```
+<STATUS>: <A short description what happened>
+
+OK: MySQL connection time is fine (0.0002s)
+WARNING: MySQL connection time is slow (0.5s > 0.1s threshold)
+CRITICAL: MySQL connection time is causing degraded performance (3s > 0.5s threshold)
+```
+
+Icinga supports reading multi-line output where Icinga Web
+only shows the first line in the listings and everything in the detail view.
+
+Example for an end2end check with many smaller test cases integrated:
+
+```
+OK: Online banking works.
+Testcase 1: Site reached.
+Testcase 2: Attempted login, JS loads.
+Testcase 3: Login succeeded.
+Testcase 4: View current state works.
+Testcase 5: Transactions fine.
+```
+
+If the extended output shouldn't be visible in your monitoring, but only for testing,
+it is recommended to implement the `--verbose` plugin parameter to allow
+developers and users to debug further. Check [here](05-service-monitoring.md#service-monitoring-plugin-api-verbose)
+for more implementation tips.
+
+> **Tip**
+>
+> More debug output also helps when implementing your plugin.
+>
+> Best practice is to have the plugin parameter and handling implemented first,
+> then add it anywhere you want to see more, e.g. from initial database connections
+> to actual query results.
+
+
+#### Status <a id="service-monitoring-plugin-api-status"></a>
+
+Value | Status | Description
+------|-----------|-------------------------------
+0 | OK | The check went fine and everything is considered working.
+1 | Warning | The check is above the given warning threshold, or anything else is suspicious requiring attention before it breaks.
+2 | Critical | The check exceeded the critical threshold, or something really is broken and will harm the production environment.
+3 | Unknown | Invalid parameters, low level resource errors (IO device busy, no fork resources, TCP sockets, etc.) preventing the actual check. Higher level errors such as DNS resolving, TCP connection timeouts should be treated as `Critical` instead. Whenever the plugin reaches its timeout (best practice) it should also terminate with `Unknown`.
+
+Keep in mind that these are service states. Icinga automatically maps
+the [host state](03-monitoring-basics.md#check-result-state-mapping) from the returned plugin states.
+
+#### Thresholds <a id="service-monitoring-plugin-api-thresholds"></a>
+
+A plugin calculates specific values and may decide about the exit state on its own.
+This is done with thresholds - warning and critical values which are compared with
+the actual value. Upon this logic, the exit state is determined.
+
+Imagine the following value and defined thresholds:
+
+```
+ptc_value = 57.8
+
+warning = 50
+critical = 60
+```
+
+Whenever `ptc_value` is higher than warning or critical, it should return
+the appropriate [state](05-service-monitoring.md#service-monitoring-plugin-api-status).
+
+The threshold evaluation order also is important:
+
+* Critical thresholds are evaluated first and superseed everything else.
+* Warning thresholds are evaluated second
+* If no threshold is matched, return the OK state
+
+Avoid using hardcoded threshold values in your plugins, always
+add them to the argument parser.
+
+Example for Python:
+
+```
+import argparse
+import signal
+import sys
+
+if __name__ == '__main__':
+ parser = argparse.ArgumentParser()
+
+ parser.add_argument("-w", "--warning", help="Warning threshold. Single value or range, e.g. '20:50'.")
+ parser.add_argument("-c", "--critical", help="Critical threshold. Single vluae or range, e.g. '25:45'.")
+
+ args = parser.parse_args()
+```
+
+Users might call plugins only with the critical threshold parameter,
+leaving out the warning parameter. Keep this in mind when evaluating
+the thresholds, always check if the parameters have been defined before.
+
+```
+ if args.critical:
+ if ptc_value > args.critical:
+ print("CRITICAL - ...")
+ sys.exit(2) # Critical
+
+ if args.warning:
+ if ptc_value > args.warning:
+ print("WARNING - ...")
+ sys.exit(1) # Warning
+
+ print("OK - ...")
+ sys.exit(0) # OK
+```
+
+The above is a simplified example for printing the [output](05-service-monitoring.md#service-monitoring-plugin-api-output)
+and using the [state](05-service-monitoring.md#service-monitoring-plugin-api-status)
+as exit code.
+
+Before diving into the implementation, learn more about required
+[performance data metrics](05-service-monitoring.md#service-monitoring-plugin-api-performance-data-metrics)
+and more best practices below.
+
+##### Threshold Ranges <a id="service-monitoring-plugin-api-thresholds-ranges"></a>
+
+Threshold ranges can be used to specify an alert window, e.g. whenever a calculated
+value is between a lower and higher critical threshold.
+
+The schema for threshold ranges looks as follows. The `@` character in square brackets
+is optional.
+
+```
+[@]start:end
+```
+
+There are a few requirements for ranges:
+
+* `start <= end`. Add a check in your code and let the user know about problematic values.
+
+```
+10:20 # OK
+
+30:10 # Error
+```
+
+* `start:` can be omitted if its value is 0. This is the default handling for single threshold values too.
+
+```
+10 # Every value > 10 and < 0, outside of 0..10
+```
+
+* If `end` is omitted, assume end is infinity.
+
+```
+10: # < 10, outside of 10..∞
+```
+
+* In order to specify negative infinity, use the `~` character.
+
+```
+~:10 # > 10, outside of -∞..10
+```
+
+* Raise alert if value is outside of the defined range.
+
+```
+10:20 # < 10 or > 20, outside of 10..20
+```
+
+* Start with `@` to raise an alert if the value is **inside** the defined range, inclusive start/end values.
+
+```
+@10:20 # >= 10 and <= 20, inside of 10..20
+```
+
+Best practice is to either implement single threshold values, or fully support ranges.
+This requires parsing the input parameter values, therefore look for existing libraries
+already providing this functionality.
+
+[check_tinkerforge](https://github.com/NETWAYS/check_tinkerforge/blob/master/check_tinkerforge.py)
+implements a simple parser to avoid dependencies.
+
+
+#### Performance Data Metrics <a id="service-monitoring-plugin-api-performance-data-metrics"></a>
+
+Performance data metrics must be appended to the plugin output with a preceding `|` character.
+The schema is as follows:
+
+```
+<output> | 'label'=value[UOM];[warn];[crit];[min];[max]
+```
+
+The label should be encapsulated with single quotes. Avoid spaces or special characters such
+as `%` in there, this could lead to problems with metric receivers such as Graphite.
+
+Labels must not include `'` and `=` characters. Keep the label length as short and unique as possible.
+
+Example:
+
+```
+'load1'=4.7
+```
+
+Values must respect the C/POSIX locale and not implement e.g. German locale for floating point numbers with `,`.
+Icinga sets `LC_NUMERIC=C` to enforce this locale on plugin execution.
+
+##### Unit of Measurement (UOM) <a id="service-monitoring-plugin-api-performance-data-metrics-uom"></a>
+
+Unit | Description
+---------|---------------------------------
+None | Integer or floating point number for any type (processes, users, etc.).
+`s` | Seconds, can be `s`, `ms`, `us`.
+`%` | Percentage.
+`B` | Bytes, can be `KB`, `MB`, `GB`, `TB`. Lowercase is also possible.
+`c` | A continuous counter (e.g. interface traffic counters).
+
+Icinga metric writers normalize these values to the lowest common base, e.g. seconds and bytes.
+Bad plugins change the UOM for different sizing, e.g. returning the disk usage in MB and later GB
+for the same performance data label. This is to ensure that graphs always look the same.
+
+```
+'rta'=12.445000ms 'pl'=0%
+```
+
+##### Thresholds and Min/Max <a id="service-monitoring-plugin-api-performance-data-metrics-thresholds-min-max"></a>
+
+Next to the performance data value, warn, crit, min, max can optionally be provided. They must be separated
+with the semi-colon `;` character. They share the same UOM with the performance data value.
+
+```
+$ check_ping -4 -H icinga.com -c '200,15%' -w '100,5%'
+
+PING OK - Packet loss = 0%, RTA = 12.44 ms|rta=12.445000ms;100.000000;200.000000;0.000000 pl=0%;5;15;0
+```
+
+##### Multiple Performance Data Values <a id="service-monitoring-plugin-api-performance-data-metrics-multiple"></a>
+
+Multiple performance data values must be joined with a space character. The below example
+is from the [check_load](10-icinga-template-library.md#plugin-check-command-load) plugin.
+
+```
+load1=4.680;1.000;2.000;0; load5=0.000;5.000;10.000;0; load15=0.000;10.000;20.000;0;
+```
+
+#### Timeout <a id="service-monitoring-plugin-api-timeout"></a>
+
+Icinga has a safety mechanism where it kills processes running for too
+long. The timeout can be specified in [CheckCommand objects](09-object-types.md#objecttype-checkcommand)
+or on the host/service object.
+
+Best practice is to control the timeout in the plugin itself
+and provide a clear message followed by the Unknown state.
+
+Example in Python taken from [check_tinkerforge](https://github.com/NETWAYS/check_tinkerforge/blob/master/check_tinkerforge.py):
+
+```
+import argparse
+import signal
+import sys
+
+def handle_sigalrm(signum, frame, timeout=None):
+ output('Plugin timed out after %d seconds' % timeout, 3)
+
+if __name__ == '__main__':
+ parser = argparse.ArgumentParser()
+ # ... add more arguments
+ parser.add_argument("-t", "--timeout", help="Timeout in seconds (default 10s)", type=int, default=10)
+ args = parser.parse_args()
+
+ signal.signal(signal.SIGALRM, partial(handle_sigalrm, timeout=args.timeout))
+ signal.alarm(args.timeout)
+
+ # ... perform the check and generate output/status
+```
+
+#### Versions <a id="service-monitoring-plugin-api-versions"></a>
+
+Plugins should provide a version via `-V` or `--version` parameter
+which is bumped on releases. This allows to identify problems with
+too old or new versions on the community support channels.
+
+Example in Python taken from [check_tinkerforge](https://github.com/NETWAYS/check_tinkerforge/blob/master/check_tinkerforge.py):
+
+```
+import argparse
+import signal
+import sys
+
+__version__ = '0.9.1'
+
+if __name__ == '__main__':
+ parser = argparse.ArgumentParser()
+
+ parser.add_argument('-V', '--version', action='version', version='%(prog)s v' + sys.modules[__name__].__version__)
+```
+
+#### Verbose <a id="service-monitoring-plugin-api-verbose"></a>
+
+Plugins should provide a verbose mode with `-v` or `--verbose` in order
+to show more detailed log messages. This helps to debug and analyse the
+flow and execution steps inside the plugin.
+
+Ensure to add the parameter prior to implementing the check logic into
+the plugin.
+
+Example in Python taken from [check_tinkerforge](https://github.com/NETWAYS/check_tinkerforge/blob/master/check_tinkerforge.py):
+
+```
+import argparse
+import signal
+import sys
+
+if __name__ == '__main__':
+ parser = argparse.ArgumentParser()
+
+ parser.add_argument('-v', '--verbose', action='store_true')
+
+ if args.verbose:
+ print("Verbose debug output")
+```
+
### Create a new Plugin <a id="service-monitoring-plugin-new"></a>
@@ -118,17 +774,28 @@ its output/exit code and return your specified output/exit code.
On the other hand plugins for specific services and hardware might not yet
exist.
-Common best practices when creating a new plugin are for example:
+> **Tip**
+>
+> Watch this presentation from Icinga Camp Berlin to learn more
+> about [How to write checks that don't suck](https://www.youtube.com/watch?v=Ey_APqSCoFQ).
+
+Common best practices:
* Choose the programming language wisely
* Scripting languages (Bash, Python, Perl, Ruby, PHP, etc.) are easier to write and setup but their check execution might take longer (invoking the script interpreter as overhead, etc.).
* Plugins written in C/C++, Go, etc. improve check execution time but may generate an overhead with installation and packaging.
-* Use a modern VCS such as Git for developing the plugin (e.g. share your plugin on GitHub).
+* Use a modern VCS such as Git for developing the plugin, e.g. share your plugin on GitHub and let it sync to [Icinga Exchange](https://exchange.icinga.com).
+* **Look into existing plugins endorsed by community members.**
+
+Implementation hints:
+
* Add parameters with key-value pairs to your plugin. They should allow long names (e.g. `--host localhost`) and also short parameters (e.g. `-H localhost`)
- * `-h|--help` should print the version and all details about parameters and runtime invocation.
-* Add a verbose/debug output functionality for detailed on-demand logging.
+ * `-h|--help` should print the version and all details about parameters and runtime invocation. Note: Python's ArgParse class provides this OOTB.
+ * `--version` should print the plugin [version](05-service-monitoring.md#service-monitoring-plugin-api-versions).
+* Add a [verbose/debug output](05-service-monitoring.md#service-monitoring-plugin-api-verbose) functionality for detailed on-demand logging.
* Respect the exit codes required by the [Plugin API](05-service-monitoring.md#service-monitoring-plugin-api).
-* Always add performance data to your plugin output
+* Always add [performance data](05-service-monitoring.md#service-monitoring-plugin-api-performance-data-metrics) to your plugin output.
+* Allow to specify [warning/critical thresholds](05-service-monitoring.md#service-monitoring-plugin-api-thresholds) as parameters.
Example skeleton:
@@ -169,12 +836,17 @@ with plugin execution and output formatting too, for example
Once you've finished your plugin please upload/sync it to [Icinga Exchange](https://exchange.icinga.com/new).
Thanks in advance!
+
## Service Monitoring Overview <a id="service-monitoring-overview"></a>
The following examples should help you to start implementing your own ideas.
There is a variety of plugins available. This collection is not complete --
if you have any updates, please send a documentation patch upstream.
+Please visit our [community forum](https://community.icinga.com) which
+may provide an answer to your use case already. If not, do not hesitate
+to create a new topic.
+
### General Monitoring <a id="service-monitoring-general"></a>
If the remote service is available (via a network protocol and port),
diff --git a/doc/06-distributed-monitoring.md b/doc/06-distributed-monitoring.md
index 2a4f07d..1ce5c15 100644
--- a/doc/06-distributed-monitoring.md
+++ b/doc/06-distributed-monitoring.md
@@ -1,42 +1,51 @@
-# Distributed Monitoring with Master, Satellites, and Clients <a id="distributed-monitoring"></a>
+# Distributed Monitoring with Master, Satellites and Agents <a id="distributed-monitoring"></a>
This chapter will guide you through the setup of a distributed monitoring
environment, including high-availability clustering and setup details
-for the Icinga 2 client.
+for Icinga masters, satellites and agents.
-## Roles: Master, Satellites, and Clients <a id="distributed-monitoring-roles"></a>
+## Roles: Master, Satellites and Agents <a id="distributed-monitoring-roles"></a>
Icinga 2 nodes can be given names for easier understanding:
* A `master` node which is on top of the hierarchy.
* A `satellite` node which is a child of a `satellite` or `master` node.
-* A `client` node which works as an `agent` connected to `master` and/or `satellite` nodes.
+* An `agent` node which is connected to `master` and/or `satellite` nodes.
-![Icinga 2 Distributed Roles](images/distributed-monitoring/icinga2_distributed_roles.png)
+![Icinga 2 Distributed Roles](images/distributed-monitoring/icinga2_distributed_monitoring_roles.png)
Rephrasing this picture into more details:
* A `master` node has no parent node.
- * A `master`node is where you usually install Icinga Web 2.
- * A `master` node can combine executed checks from child nodes into backends and notifications.
+ * A `master`node is where you usually install Icinga Web 2.
+ * A `master` node can combine executed checks from child nodes into backends and notifications.
* A `satellite` node has a parent and a child node.
- * A `satellite` node may execute checks on its own or delegate check execution to child nodes.
- * A `satellite` node can receive configuration for hosts/services, etc. from the parent node.
- * A `satellite` node continues to run even if the master node is temporarily unavailable.
-* A `client` node only has a parent node.
- * A `client` node will either run its own configured checks or receive command execution events from the parent node.
+ * A `satellite` node may execute checks on its own or delegate check execution to child nodes.
+ * A `satellite` node can receive configuration for hosts/services, etc. from the parent node.
+ * A `satellite` node continues to run even if the master node is temporarily unavailable.
+* An `agent` node only has a parent node.
+ * An `agent` node will either run its own configured checks or receive command execution events from the parent node.
+
+A client can be a secondary master, a satellite or an agent. It
+typically requests something from the primary master or parent node.
The following sections will refer to these roles and explain the
differences and the possibilities this kind of setup offers.
+> **Note**
+>
+> Previous versions of this documentation used the term `Icinga client`.
+> This has been refined into `Icinga agent` and is visible in the docs,
+> backends and web interfaces.
+
**Tip**: If you just want to install a single master node that monitors several hosts
-(i.e. Icinga 2 clients), continue reading -- we'll start with
+(i.e. Icinga agents), continue reading -- we'll start with
simple examples.
In case you are planning a huge cluster setup with multiple levels and
-lots of clients, read on -- we'll deal with these cases later on.
+lots of satellites and agents, read on -- we'll deal with these cases later on.
The installation on each system is the same: You need to install the
-[Icinga 2 package](02-getting-started.md#setting-up-icinga2) and the required [plugins](02-getting-started.md#setting-up-check-plugins).
+[Icinga 2 package](02-installation.md#setting-up-icinga2) and the required [plugins](02-installation.md#setting-up-check-plugins).
The required configuration steps are mostly happening
on the command line. You can also [automate the setup](06-distributed-monitoring.md#distributed-monitoring-automation).
@@ -48,7 +57,7 @@ The first thing you need learn about a distributed setup is the hierarchy of the
The Icinga 2 hierarchy consists of so-called [zone](09-object-types.md#objecttype-zone) objects.
Zones depend on a parent-child relationship in order to trust each other.
-![Icinga 2 Distributed Zones](images/distributed-monitoring/icinga2_distributed_zones.png)
+![Icinga 2 Distributed Zones](images/distributed-monitoring/icinga2_distributed_monitoring_zones.png)
Have a look at this example for the `satellite` zones which have the `master` zone as a parent zone:
@@ -74,14 +83,14 @@ trust hierarchy allows for example the `master` zone to send
configuration files to the `satellite` zone. Read more about this
in the [security section](06-distributed-monitoring.md#distributed-monitoring-security).
-`client` nodes also have their own unique zone. By convention you
-can use the FQDN for the zone name.
+`agent` nodes also have their own unique zone. By convention you
+must use the FQDN for the zone name.
## Endpoints <a id="distributed-monitoring-endpoints"></a>
Nodes which are a member of a zone are so-called [Endpoint](09-object-types.md#objecttype-endpoint) objects.
-![Icinga 2 Distributed Endpoints](images/distributed-monitoring/icinga2_distributed_endpoints.png)
+![Icinga 2 Distributed Endpoints](images/distributed-monitoring/icinga2_distributed_monitoring_endpoints.png)
Here is an example configuration for two endpoints in different zones:
@@ -108,7 +117,7 @@ All endpoints in the same zone work as high-availability setup. For
example, if you have two nodes in the `master` zone, they will load-balance the check execution.
Endpoint objects are important for specifying the connection
-information, e.g. if the master should actively try to connect to a client.
+information, e.g. if the master should actively try to connect to an agent.
The zone membership is defined inside the `Zone` object definition using
the `endpoints` attribute with an array of `Endpoint` names.
@@ -164,8 +173,10 @@ While there are certain mechanisms to ensure a secure communication between all
nodes (firewalls, policies, software hardening, etc.), Icinga 2 also provides
additional security:
-* SSL certificates are mandatory for communication between nodes. The CLI commands
-help you create those certificates.
+* TLS v1.2+ is required.
+* TLS cipher lists are hardened [by default](09-object-types.md#objecttype-apilistener).
+* TLS certificates are mandatory for communication between nodes. The CLI command wizards
+help you create these certificates.
* Child zones only receive updates (check results, commands, etc.) for their configured objects.
* Child zones are not allowed to push configuration updates to parent zones.
* Zones cannot interfere with other zones and influence each other. Each checkable host or service object is assigned to **one zone** only.
@@ -177,22 +188,22 @@ The connection is secured by TLS. The message protocol uses an internal API,
and as such message types and names may change internally and are not documented.
Zones build the trust relationship in a distributed environment. If you do not specify
-a zone for a client and specify the parent zone, its zone members e.g. the master instance
-won't trust the client.
+a zone for an agent/satellite and specify the parent zone, its zone members e.g. the master instance
+won't trust the agent/satellite.
Building this trust is key in your distributed environment. That way the parent node
knows that it is able to send messages to the child zone, e.g. configuration objects,
configuration in global zones, commands to be executed in this zone/for this endpoint.
It also receives check results from the child zone for checkable objects (host/service).
-Vice versa, the client trusts the master and accepts configuration and commands if enabled
-in the api feature. If the client would send configuration to the parent zone, the parent nodes
-will deny it. The parent zone is the configuration entity, and does not trust clients in this matter.
-A client could attempt to modify a different client for example, or inject a check command
+Vice versa, the agent/satellite trusts the master and accepts configuration and commands if enabled
+in the api feature. If the agent/satellite would send configuration to the parent zone, the parent nodes
+will deny it. The parent zone is the configuration entity, and does not trust agents/satellites in this matter.
+An agent/satellite could attempt to modify a different agent/satellite for example, or inject a check command
with malicious code.
-While it may sound complicated for client setups, it removes the problem with different roles
-and configurations for a master and a client. Both of them work the same way, are configured
+While it may sound complicated for agent/satellite setups, it removes the problem with different roles
+and configurations for a master and child nodes. Both of them work the same way, are configured
in the same way (Zone, Endpoint, ApiListener), and you can troubleshoot and debug them in just one go.
## Versions and Upgrade <a id="distributed-monitoring-versions-upgrade"></a>
@@ -203,15 +214,15 @@ Prior to upgrading, make sure to plan a maintenance window.
The Icinga project aims to allow the following compatibility:
```
-master (2.9) >= satellite (2.8) >= clients (2.7)
+master (2.11) >= satellite (2.10) >= agent (2.9)
```
-Older client versions may work, but there's no guarantee. Always keep in mind that
+Older agent versions may work, but there's no guarantee. Always keep in mind that
older versions are out of support and can contain bugs.
In terms of an upgrade, ensure that the master is upgraded first, then
-involved satellites, and last the Icinga 2 clients. If you are on v2.8
-currently, first upgrade the master instance(s) to 2.9, and then proceed
+involved satellites, and last the Icinga agents. If you are on v2.10
+currently, first upgrade the master instance(s) to 2.11, and then proceed
with the satellites. Things are getting easier with any sort of automation
tool (Puppet, Ansible, etc.).
@@ -227,8 +238,8 @@ This section explains how to install a central single master node using
the `node wizard` command. If you prefer to do an automated installation, please
refer to the [automated setup](06-distributed-monitoring.md#distributed-monitoring-automation) section.
-Install the [Icinga 2 package](02-getting-started.md#setting-up-icinga2) and setup
-the required [plugins](02-getting-started.md#setting-up-check-plugins) if you haven't done
+Install the [Icinga 2 package](02-installation.md#setting-up-icinga2) and setup
+the required [plugins](02-installation.md#setting-up-check-plugins) if you haven't done
so already.
**Note**: Windows is not supported for a master node setup.
@@ -250,9 +261,9 @@ The setup wizard will ensure that the following steps are taken:
* Enable the `api` feature.
* Generate a new certificate authority (CA) in `/var/lib/icinga2/ca` if it doesn't exist.
* Create a certificate for this node signed by the CA key.
-* Update the [zones.conf](04-configuring-icinga-2.md#zones-conf) file with the new zone hierarchy.
-* Update the [ApiListener](06-distributed-monitoring.md#distributed-monitoring-apilistener) and [constants](04-configuring-icinga-2.md#constants-conf) configuration.
-* Update the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) to disable the `conf.d` inclusion, and add the `api-users.conf` file inclusion.
+* Update the [zones.conf](04-configuration.md#zones-conf) file with the new zone hierarchy.
+* Update the [ApiListener](06-distributed-monitoring.md#distributed-monitoring-apilistener) and [constants](04-configuration.md#constants-conf) configuration.
+* Update the [icinga2.conf](04-configuration.md#icinga2-conf) to disable the `conf.d` inclusion, and add the `api-users.conf` file inclusion.
Here is an example of a master setup for the `icinga2-master1.localdomain` node on CentOS 7:
@@ -263,7 +274,7 @@ Welcome to the Icinga 2 Setup Wizard!
We will guide you through all required configuration details.
-Please specify if this is a satellite/client setup ('n' installs a master setup) [Y/n]: n
+Please specify if this is a satellite/agent setup ('n' installs a master setup) [Y/n]: n
Starting the Master setup routine...
@@ -293,9 +304,9 @@ Now restart your Icinga 2 daemon to finish the installation!
```
You can verify that the CA public and private keys are stored in the `/var/lib/icinga2/ca` directory.
-Keep this path secure and include it in your [backups](02-getting-started.md#install-backup).
+Keep this path secure and include it in your [backups](02-installation.md#install-backup).
-In case you lose the CA private key you have to generate a new CA for signing new client
+In case you lose the CA private key you have to generate a new CA for signing new agent/satellite
certificate requests. You then have to also re-create new signed certificates for all
existing nodes.
@@ -314,7 +325,7 @@ and should be the same on all master instances.
You can avoid signing and deploying certificates [manually](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates-manual)
by using built-in methods for auto-signing certificate signing requests (CSR):
-* [CSR Auto-Signing](06-distributed-monitoring.md#distributed-monitoring-setup-csr-auto-signing) which uses a client ticket generated on the master as trust identifier.
+* [CSR Auto-Signing](06-distributed-monitoring.md#distributed-monitoring-setup-csr-auto-signing) which uses a client (an agent or a satellite) ticket generated on the master as trust identifier.
* [On-Demand CSR Signing](06-distributed-monitoring.md#distributed-monitoring-setup-on-demand-csr-signing) which allows to sign pending certificate requests on the master.
Both methods are described in detail below.
@@ -325,21 +336,21 @@ Both methods are described in detail below.
### CSR Auto-Signing <a id="distributed-monitoring-setup-csr-auto-signing"></a>
-A client which sends a certificate signing request (CSR) must authenticate itself
-in a trusted way. The master generates a client ticket which is included in this request.
+A client can be a secondary master, a satellite or an agent. It sends a certificate signing request (CSR)
+and must authenticate itself in a trusted way. The master generates a client ticket which is included in this request.
That way the master can verify that the request matches the previously trusted ticket
and sign the request.
> **Note**
>
-> Icinga 2 v2.8 adds the possibility to forward signing requests on a satellite
+> Icinga 2 v2.8 added the possibility to forward signing requests on a satellite
> to the master node. This is called `CA Proxy` in blog posts and design drafts.
-> This functionality helps with the setup of [three level clusters](#06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-client)
+> This functionality helps with the setup of [three level clusters](06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-agents)
> and more.
Advantages:
-* Nodes can be installed by different users who have received the client ticket.
+* Nodes (secondary master, satellites, agents) can be installed by different users who have received the client ticket.
* No manual interaction necessary on the master node.
* Automation tools like Puppet, Ansible, etc. can retrieve the pre-generated ticket in their client catalog
and run the node setup directly.
@@ -350,7 +361,7 @@ Disadvantages:
* No central signing management.
-Setup wizards for satellite/client nodes will ask you for this specific client ticket.
+Setup wizards for agent/satellite nodes will ask you for this specific client ticket.
There are two possible ways to retrieve the ticket:
@@ -361,12 +372,12 @@ Required information:
Parameter | Description
--------------------|--------------------
- Common name (CN) | **Required.** The common name for the satellite/client. By convention this should be the FQDN.
+ Common name (CN) | **Required.** The common name for the agent/satellite. By convention this should be the FQDN.
-The following example shows how to generate a ticket on the master node `icinga2-master1.localdomain` for the client `icinga2-client1.localdomain`:
+The following example shows how to generate a ticket on the master node `icinga2-master1.localdomain` for the agent `icinga2-agent1.localdomain`:
```
-[root@icinga2-master1.localdomain /]# icinga2 pki ticket --cn icinga2-client1.localdomain
+[root@icinga2-master1.localdomain /]# icinga2 pki ticket --cn icinga2-agent1.localdomain
```
Querying the [Icinga 2 API](12-icinga2-api.md#icinga2-api) on the master requires an [ApiUser](12-icinga2-api.md#icinga2-api-authentication)
@@ -385,10 +396,10 @@ object ApiUser "client-pki-ticket" {
Retrieve the ticket on the master node `icinga2-master1.localdomain` with `curl`, for example:
[root@icinga2-master1.localdomain /]# curl -k -s -u client-pki-ticket:bea11beb7b810ea9ce6ea -H 'Accept: application/json' \
- -X POST 'https://localhost:5665/v1/actions/generate-ticket' -d '{ "cn": "icinga2-client1.localdomain" }'
+ -X POST 'https://localhost:5665/v1/actions/generate-ticket' -d '{ "cn": "icinga2-agent1.localdomain" }'
```
-Store that ticket number for the satellite/client setup below.
+Store that ticket number for the agent/satellite setup below.
> **Note**
>
@@ -399,8 +410,9 @@ Store that ticket number for the satellite/client setup below.
### On-Demand CSR Signing <a id="distributed-monitoring-setup-on-demand-csr-signing"></a>
-The client sends a certificate signing request to specified parent node without any
-ticket. The admin on the master is responsible for reviewing and signing the requests
+The client can be a secondary master, satellite or agent.
+It sends a certificate signing request to specified parent node without any
+ticket. The admin on the primary master is responsible for reviewing and signing the requests
with the private CA key.
This could either be directly the master, or a satellite which forwards the request
@@ -417,15 +429,23 @@ Disadvantages:
* Needs client verification on the master.
-You can list certificate requests by using the `ca list` CLI command. This also shows
-which requests already have been signed.
+You can list pending certificate signing requests with the `ca list` CLI command.
```
[root@icinga2-master1.localdomain /]# icinga2 ca list
Fingerprint | Timestamp | Signed | Subject
-----------------------------------------------------------------|---------------------|--------|--------
-403da5b228df384f07f980f45ba50202529cded7c8182abf96740660caa09727 | 2017/09/06 17:02:40 | * | CN = icinga2-client1.localdomain
-71700c28445109416dd7102038962ac3fd421fbb349a6e7303b6033ec1772850 | 2017/09/06 17:20:02 | | CN = icinga2-client2.localdomain
+71700c28445109416dd7102038962ac3fd421fbb349a6e7303b6033ec1772850 | 2017/09/06 17:20:02 | | CN = icinga2-agent2.localdomain
+```
+
+In order to show all requests, use the `--all` parameter.
+
+```
+[root@icinga2-master1.localdomain /]# icinga2 ca list --all
+Fingerprint | Timestamp | Signed | Subject
+-----------------------------------------------------------------|---------------------|--------|--------
+403da5b228df384f07f980f45ba50202529cded7c8182abf96740660caa09727 | 2017/09/06 17:02:40 | * | CN = icinga2-agent1.localdomain
+71700c28445109416dd7102038962ac3fd421fbb349a6e7303b6033ec1772850 | 2017/09/06 17:20:02 | | CN = icinga2-agent2.localdomain
```
**Tip**: Add `--json` to the CLI command to retrieve the details in JSON format.
@@ -435,7 +455,7 @@ and pass its fingerprint as argument.
```
[root@icinga2-master1.localdomain /]# icinga2 ca sign 71700c28445109416dd7102038962ac3fd421fbb349a6e7303b6033ec1772850
-information/cli: Signed certificate for 'CN = icinga2-client2.localdomain'.
+information/cli: Signed certificate for 'CN = icinga2-agent2.localdomain'.
```
> **Note**
@@ -443,56 +463,70 @@ information/cli: Signed certificate for 'CN = icinga2-client2.localdomain'.
> `ca list` cannot be used as historical inventory. Certificate
> signing requests older than 1 week are automatically deleted.
-## Client/Satellite Setup <a id="distributed-monitoring-setup-satellite-client"></a>
+You can also remove an undesired CSR using the `ca remove` command using the
+syntax as the `ca sign` command.
+
+```
+[root@pym ~]# icinga2 ca remove 5c31ca0e2269c10363a97e40e3f2b2cd56493f9194d5b1852541b835970da46e
+information/cli: Certificate 5c31ca0e2269c10363a97e40e3f2b2cd56493f9194d5b1852541b835970da46e removed.
+```
+If you want to restore a certificate you have removed, you can use `ca restore`.
+
+<!-- Keep this for compatibility -->
+<a id="distributed-monitoring-setup-satellite-client"></a>
-This section describes the setup of a satellite and/or client connected to an
+## Agent/Satellite Setup <a id="distributed-monitoring-setup-agent-satellite"></a>
+
+This section describes the setup of an agent or satellite connected to an
existing master node setup. If you haven't done so already, please [run the master setup](06-distributed-monitoring.md#distributed-monitoring-setup-master).
Icinga 2 on the master node must be running and accepting connections on port `5665`.
+<!-- Keep this for compatibility -->
+<a id="distributed-monitoring-setup-client-linux"></a>
-### Client/Satellite Setup on Linux <a id="distributed-monitoring-setup-client-linux"></a>
+### Agent/Satellite Setup on Linux <a id="distributed-monitoring-setup-agent-satellite-linux"></a>
-Please ensure that you've run all the steps mentioned in the [client/satellite section](06-distributed-monitoring.md#distributed-monitoring-setup-satellite-client).
+Please ensure that you've run all the steps mentioned in the [agent/satellite section](06-distributed-monitoring.md#distributed-monitoring-setup-agent-satellite).
-Install the [Icinga 2 package](02-getting-started.md#setting-up-icinga2) and setup
-the required [plugins](02-getting-started.md#setting-up-check-plugins) if you haven't done
+Install the [Icinga 2 package](02-installation.md#setting-up-icinga2) and setup
+the required [plugins](02-installation.md#setting-up-check-plugins) if you haven't done
so already.
The next step is to run the `node wizard` CLI command.
-In this example we're generating a ticket on the master node `icinga2-master1.localdomain` for the client `icinga2-client1.localdomain`:
+In this example we're generating a ticket on the master node `icinga2-master1.localdomain` for the agent `icinga2-agent1.localdomain`:
```
-[root@icinga2-master1.localdomain /]# icinga2 pki ticket --cn icinga2-client1.localdomain
+[root@icinga2-master1.localdomain /]# icinga2 pki ticket --cn icinga2-agent1.localdomain
4f75d2ecd253575fe9180938ebff7cbca262f96e
```
Note: You don't need this step if you have chosen to use [On-Demand CSR Signing](06-distributed-monitoring.md#distributed-monitoring-setup-on-demand-csr-signing).
-Start the wizard on the client `icinga2-client1.localdomain`:
+Start the wizard on the agent `icinga2-agent1.localdomain`:
```
-[root@icinga2-client1.localdomain /]# icinga2 node wizard
+[root@icinga2-agent1.localdomain /]# icinga2 node wizard
Welcome to the Icinga 2 Setup Wizard!
We will guide you through all required configuration details.
```
-Press `Enter` or add `y` to start a satellite or client setup.
+Press `Enter` or add `y` to start a satellite or agent setup.
```
-Please specify if this is a satellite/client setup ('n' installs a master setup) [Y/n]:
+Please specify if this is an agent/satellite setup ('n' installs a master setup) [Y/n]:
```
Press `Enter` to use the proposed name in brackets, or add a specific common name (CN). By convention
this should be the FQDN.
```
-Starting the Client/Satellite setup routine...
+Starting the Agent/Satellite setup routine...
-Please specify the common name (CN) [icinga2-client1.localdomain]: icinga2-client1.localdomain
+Please specify the common name (CN) [icinga2-agent1.localdomain]: icinga2-agent1.localdomain
```
Specify the direct parent for this node. This could be your primary master `icinga2-master1.localdomain`
@@ -555,7 +589,7 @@ Proceed with adding the optional client ticket for [CSR auto-signing](06-distrib
```
Please specify the request ticket generated on your Icinga 2 master (optional).
- (Hint: # icinga2 pki ticket --cn 'icinga2-client1.localdomain'):
+ (Hint: # icinga2 pki ticket --cn 'icinga2-agent1.localdomain'):
4f75d2ecd253575fe9180938ebff7cbca262f96e
```
@@ -591,10 +625,10 @@ in the generated zone configuration file.
Set the local zone name to something else, if you are installing a satellite or secondary master instance.
```
-Local zone name [icinga2-client1.localdomain]:
+Local zone name [icinga2-agent1.localdomain]:
```
-Set the parent zone name to something else than `master` if this client connects to a satellite instance instead of the master.
+Set the parent zone name to something else than `master` if this agents connects to a satellite instance instead of the master.
```
Parent zone name [master]:
@@ -611,7 +645,7 @@ Do you want to specify additional global zones? [y/N]: N
```
Last but not least the wizard asks you whether you want to disable the inclusion of the local configuration
-directory in `conf.d`, or not. Defaults to disabled, as clients either are checked via command endpoint, or
+directory in `conf.d`, or not. Defaults to disabled, as agents either are checked via command endpoint, or
they receive configuration synced from the parent zone.
```
@@ -639,7 +673,7 @@ Now restart your Icinga 2 daemon to finish the installation!
Restart Icinga 2 as requested.
```
-[root@icinga2-client1.localdomain /]# systemctl restart icinga2
+[root@icinga2-agent1.localdomain /]# systemctl restart icinga2
```
Here is an overview of all parameters in detail:
@@ -649,8 +683,8 @@ Here is an overview of all parameters in detail:
Common name (CN) | **Required.** By convention this should be the host's FQDN. Defaults to the FQDN.
Master common name | **Required.** Use the common name you've specified for your master node before.
Establish connection to the parent node | **Optional.** Whether the node should attempt to connect to the parent node or not. Defaults to `y`.
- Master/Satellite endpoint host | **Required if the the client needs to connect to the master/satellite.** The parent endpoint's IP address or FQDN. This information is included in the `Endpoint` object configuration in the `zones.conf` file.
- Master/Satellite endpoint port | **Optional if the the client needs to connect to the master/satellite.** The parent endpoints's listening port. This information is included in the `Endpoint` object configuration.
+ Master/Satellite endpoint host | **Required if the the agent needs to connect to the master/satellite.** The parent endpoint's IP address or FQDN. This information is included in the `Endpoint` object configuration in the `zones.conf` file.
+ Master/Satellite endpoint port | **Optional if the the agent needs to connect to the master/satellite.** The parent endpoints's listening port. This information is included in the `Endpoint` object configuration.
Add more master/satellite endpoints | **Optional.** If you have multiple master/satellite nodes configured, add them here.
Parent Certificate information | **Required.** Verify that the connecting host really is the requested master node.
Request ticket | **Optional.** Add the [ticket](06-distributed-monitoring.md#distributed-monitoring-setup-csr-auto-signing) generated on the master.
@@ -658,8 +692,8 @@ Here is an overview of all parameters in detail:
API bind port | **Optional.** Allows to specify the port the ApiListener is bound to. For advanced usage only (requires changing the default port 5665 everywhere).
Accept config | **Optional.** Whether this node accepts configuration sync from the master node (required for [config sync mode](06-distributed-monitoring.md#distributed-monitoring-top-down-config-sync)). For [security reasons](06-distributed-monitoring.md#distributed-monitoring-security) this defaults to `n`.
Accept commands | **Optional.** Whether this node accepts command execution messages from the master node (required for [command endpoint mode](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)). For [security reasons](06-distributed-monitoring.md#distributed-monitoring-security) this defaults to `n`.
- Local zone name | **Optional.** Allows to specify the name for the local zone. This comes in handy when this instance is a satellite, not a client. Defaults to the FQDN.
- Parent zone name | **Optional.** Allows to specify the name for the parent zone. This is important if the client has a satellite instance as parent, not the master. Defaults to `master`.
+ Local zone name | **Optional.** Allows to specify the name for the local zone. This comes in handy when this instance is a satellite, not an agent. Defaults to the FQDN.
+ Parent zone name | **Optional.** Allows to specify the name for the parent zone. This is important if the agent has a satellite instance as parent, not the master. Defaults to `master`.
Global zones | **Optional.** Allows to specify more global zones in addition to `global-templates` and `director-global`. Defaults to `n`.
Disable conf.d | **Optional.** Allows to disable the inclusion of the `conf.d` directory which holds local example configuration. Clients should retrieve their configuration from the parent node, or act as command endpoint execution bridge. Defaults to `y`.
@@ -669,7 +703,7 @@ The setup wizard will ensure that the following steps are taken:
* Create a certificate signing request (CSR) for the local node.
* Request a signed certificate i(optional with the provided ticket number) on the master node.
* Allow to verify the parent node's certificate.
-* Store the signed client certificate and ca.crt in `/var/lib/icinga2/certs`.
+* Store the signed agent/satellite certificate and ca.crt in `/var/lib/icinga2/certs`.
* Update the `zones.conf` file with the new zone hierarchy.
* Update `/etc/icinga2/features-enabled/api.conf` (`accept_config`, `accept_commands`) and `constants.conf`.
* Update `/etc/icinga2/icinga2.conf` and comment out `include_recursive "conf.d"`.
@@ -678,18 +712,20 @@ You can verify that the certificate files are stored in the `/var/lib/icinga2/ce
> **Note**
>
-> If the client is not directly connected to the certificate signing master,
-> signing requests and responses might need some minutes to fully update the client certificates.
+> If the agent is not directly connected to the certificate signing master,
+> signing requests and responses might need some minutes to fully update the agent certificates.
>
> If you have chosen to use [On-Demand CSR Signing](06-distributed-monitoring.md#distributed-monitoring-setup-on-demand-csr-signing)
> certificates need to be signed on the master first. Ticket-less setups require at least Icinga 2 v2.8+ on all involved instances.
-Now that you've successfully installed a Linux/Unix satellite/client instance, please proceed to
+Now that you've successfully installed a Linux/Unix agent/satellite instance, please proceed to
the [configuration modes](06-distributed-monitoring.md#distributed-monitoring-configuration-modes).
+<!-- Keep this for compatibility -->
+<a id="distributed-monitoring-setup-client-windows"></a>
-### Client Setup on Windows <a id="distributed-monitoring-setup-client-windows"></a>
+### Agent Setup on Windows <a id="distributed-monitoring-setup-agent-windows"></a>
Download the MSI-Installer package from [https://packages.icinga.com/windows/](https://packages.icinga.com/windows/).
@@ -697,7 +733,7 @@ Requirements:
* Windows Vista/Server 2008 or higher
* Versions older than Windows 10/Server 2016 require the [Universal C Runtime for Windows](https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows)
-* [Microsoft .NET Framework 2.0](https://www.microsoft.com/de-de/download/details.aspx?id=1639) for the setup wizard
+* [Microsoft .NET Framework 4.6] or higher (https://www.microsoft.com/en-US/download/details.aspx?id=53344) for the setup wizard
The installer package includes the [NSClient++](https://www.nsclient.org/) package
so that Icinga 2 can use its built-in plugins. You can find more details in
@@ -707,10 +743,10 @@ to get you started more easily.
> **Note**
>
-> Please note that Icinga 2 was designed to run as light-weight client on Windows.
+> Please note that Icinga 2 was designed to run as light-weight agent on Windows.
> There is no support for satellite instances.
-#### Windows Client Setup Start <a id="distributed-monitoring-setup-client-windows-start"></a>
+#### Windows Agent Setup Start <a id="distributed-monitoring-setup-agent-windows-start"></a>
Run the MSI-Installer package and follow the instructions shown in the screenshots.
@@ -745,7 +781,7 @@ Add the following details:
Parameter | Description
-------------------------------|-------------------------------
- Instance name | **Required.** The master/satellite endpoint name where this client is a direct child of.
+ Instance name | **Required.** The master/satellite endpoint name where this agent is a direct child of.
Master/Satellite endpoint host | **Required.** The master or satellite's IP address or FQDN. This information is included in the `Endpoint` object configuration in the `zones.conf` file.
Master/Satellite endpoint port | **Optional.** The master or satellite's listening port. This information is included in the `Endpoint` object configuration.
@@ -772,7 +808,7 @@ Verify the certificate from the master/satellite instance where this node should
![Icinga 2 Windows Setup](images/distributed-monitoring/icinga2_windows_setup_wizard_04.png)
-#### Bundled NSClient++ Setup <a id="distributed-monitoring-setup-client-windows-nsclient"></a>
+#### Bundled NSClient++ Setup <a id="distributed-monitoring-setup-agent-windows-nsclient"></a>
If you have chosen to install/update the NSClient++ package, the Icinga 2 setup wizard asks
you to do so.
@@ -810,7 +846,7 @@ The NSClient++ REST API can be used to query metrics. [check_nscp_api](06-distri
uses this transport method.
-#### Finish Windows Client Setup <a id="distributed-monitoring-setup-client-windows-finish"></a>
+#### Finish Windows Agent Setup <a id="distributed-monitoring-setup-agent-windows-finish"></a>
Finish the Windows setup wizard.
@@ -831,21 +867,22 @@ Click `Examine Config` in the setup wizard to open a new Explorer window.
![Icinga 2 Windows Setup](images/distributed-monitoring/icinga2_windows_setup_wizard_examine_config.png)
-The configuration files can be modified with your favorite editor e.g. Notepad.
+The configuration files can be modified with your favorite editor e.g. Notepad++ or vim in Powershell (via chocolatey).
-In order to use the [top down](06-distributed-monitoring.md#distributed-monitoring-top-down) client
+In order to use the [top down](06-distributed-monitoring.md#distributed-monitoring-top-down) agent
configuration prepare the following steps.
-You don't need any local configuration on the client except for
+You don't need any local configuration on the agent except for
CheckCommand definitions which can be synced using the global zone
above. Therefore disable the inclusion of the `conf.d` directory
in the `icinga2.conf` file.
+
Navigate to `C:\ProgramData\icinga2\etc\icinga2` and open
the `icinga2.conf` file in your preferred editor. Remove or comment (`//`)
the following line:
```
-// Commented out, not required on a client with top down mode
+// Commented out, not required on an agent with top down mode
//include_recursive "conf.d"
```
@@ -869,25 +906,26 @@ and restart the `icinga2` service. Alternatively, you can use the `net {start,st
![Icinga 2 Windows Service Start/Stop](images/distributed-monitoring/icinga2_windows_cmd_admin_net_start_stop.png)
-Now that you've successfully installed a Windows client, please proceed to
+Now that you've successfully installed a Windows agent, please proceed to
the [detailed configuration modes](06-distributed-monitoring.md#distributed-monitoring-configuration-modes).
+
## Configuration Modes <a id="distributed-monitoring-configuration-modes"></a>
There are different ways to ensure that the Icinga 2 cluster nodes execute
checks, send notifications, etc.
The preferred method is to configure monitoring objects on the master
-and distribute the configuration to satellites and clients.
+and distribute the configuration to satellites and agents.
-The following chapters will explain this in detail with hands-on manual configuration
+The following chapters explain this in detail with hands-on manual configuration
examples. You should test and implement this once to fully understand how it works.
Once you are familiar with Icinga 2 and distributed monitoring, you
can start with additional integrations to manage and deploy your
configuration:
-* [Icinga Director](https://github.com/icinga/icingaweb2-module-director) provides a web interface to manage configuration and also allows to sync imported resources (CMDB, PuppetDB, etc.)
+* [Icinga Director](https://icinga.com/docs/director/latest/) provides a web interface to manage configuration and also allows to sync imported resources (CMDB, PuppetDB, etc.)
* [Ansible Roles](https://github.com/Icinga/icinga2-ansible)
* [Puppet Module](https://github.com/Icinga/puppet-icinga2)
* [Chef Cookbook](https://github.com/Icinga/chef-icinga2)
@@ -901,24 +939,24 @@ There are two different behaviors with check execution:
* Send a command execution event remotely: The scheduler still runs on the parent node.
* Sync the host/service objects directly to the child node: Checks are executed locally.
-Again, technically it does not matter whether this is a `client` or a `satellite`
+Again, technically it does not matter whether this is an `agent` or a `satellite`
which is receiving configuration or command execution events.
### Top Down Command Endpoint <a id="distributed-monitoring-top-down-command-endpoint"></a>
-This mode will force the Icinga 2 node to execute commands remotely on a specified endpoint.
-The host/service object configuration is located on the master/satellite and the client only
-needs the CheckCommand object definitions being used there.
+This mode forces the Icinga 2 node to execute commands remotely on a specified endpoint.
+The host/service object configuration is located on the master/satellite and the agent only
+needs the CheckCommand object definitions available.
Every endpoint has its own remote check queue. The amount of checks executed simultaneously
-can be limited on the endpoint with the `MaxConcurrentChecks` constant defined in [constants.conf](04-configuring-icinga-2.md#constants-conf). Icinga 2 may discard check requests,
+can be limited on the endpoint with the `MaxConcurrentChecks` constant defined in [constants.conf](04-configuration.md#constants-conf). Icinga 2 may discard check requests,
if the remote check queue is full.
-![Icinga 2 Distributed Top Down Command Endpoint](images/distributed-monitoring/icinga2_distributed_top_down_command_endpoint.png)
+![Icinga 2 Distributed Top Down Command Endpoint](images/distributed-monitoring/icinga2_distributed_monitoring_agent_checks_command_endpoint.png)
Advantages:
-* No local checks need to be defined on the child node (client).
+* No local checks need to be defined on the child node (agent).
* Light-weight remote check execution (asynchronous events).
* No [replay log](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-command-endpoint-log-duration) is necessary for the child node.
* Pin checks to specific endpoints (if the child zone consists of 2 endpoints).
@@ -934,54 +972,55 @@ commands, you need to configure the `Zone` and `Endpoint` hierarchy
on all nodes.
* `icinga2-master1.localdomain` is the configuration master in this scenario.
-* `icinga2-client1.localdomain` acts as client which receives command execution messages via command endpoint from the master. In addition, it receives the global check command configuration from the master.
+* `icinga2-agent1.localdomain` acts as agent which receives command execution messages via command endpoint from the master. In addition, it receives the global check command configuration from the master.
Include the endpoint and zone configuration on **both** nodes in the file `/etc/icinga2/zones.conf`.
The endpoint configuration could look like this, for example:
```
-[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
host = "192.168.56.101"
}
-object Endpoint "icinga2-client1.localdomain" {
+object Endpoint "icinga2-agent1.localdomain" {
host = "192.168.56.111"
+ log_duration = 0 // Disable the replay log for command endpoint agents
}
```
-Next, you need to define two zones. There is no naming convention, best practice is to either use `master`, `satellite`/`client-fqdn` or to choose region names for example `Europe`, `USA` and `Asia`, though.
+Next, you need to define two zones. There is no naming convention, best practice is to either use `master`, `satellite`/`agent-fqdn` or to choose region names for example `Europe`, `USA` and `Asia`, though.
-**Note**: Each client requires its own zone and endpoint configuration. Best practice
-is to use the client's FQDN for all object names.
+**Note**: Each agent requires its own zone and endpoint configuration. Best practice
+is to use the agent's FQDN for all object names.
-The `master` zone is a parent of the `icinga2-client1.localdomain` zone:
+The `master` zone is a parent of the `icinga2-agent1.localdomain` zone:
```
-[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent1.localdomain /]# vim /etc/icinga2/zones.conf
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain" ] //array with endpoint names
}
-object Zone "icinga2-client1.localdomain" {
- endpoints = [ "icinga2-client1.localdomain" ]
+object Zone "icinga2-agent1.localdomain" {
+ endpoints = [ "icinga2-agent1.localdomain" ]
parent = "master" //establish zone hierarchy
}
```
-You don't need any local configuration on the client except for
+You don't need any local configuration on the agent except for
CheckCommand definitions which can be synced using the global zone
above. Therefore disable the inclusion of the `conf.d` directory
in `/etc/icinga2/icinga2.conf`.
```
-[root@icinga2-client1.localdomain /]# vim /etc/icinga2/icinga2.conf
+[root@icinga2-agent1.localdomain /]# vim /etc/icinga2/icinga2.conf
-// Commented out, not required on a client as command endpoint
+// Commented out, not required on an agent as command endpoint
//include_recursive "conf.d"
```
@@ -996,15 +1035,15 @@ on both nodes.
Example on CentOS 7:
```
-[root@icinga2-client1.localdomain /]# icinga2 daemon -C
-[root@icinga2-client1.localdomain /]# systemctl restart icinga2
+[root@icinga2-agent1.localdomain /]# icinga2 daemon -C
+[root@icinga2-agent1.localdomain /]# systemctl restart icinga2
[root@icinga2-master1.localdomain /]# icinga2 daemon -C
[root@icinga2-master1.localdomain /]# systemctl restart icinga2
```
-Once the clients have successfully connected, you are ready for the next step: **execute
-a remote check on the client using the command endpoint**.
+Once the agents have successfully connected, you are ready for the next step: **execute
+a remote check on the agent using the command endpoint**.
Include the host and service object configuration in the `master` zone
-- this will help adding a secondary master for high-availability later.
@@ -1017,22 +1056,29 @@ Add the host and service objects you want to monitor. There is
no limitation for files and directories -- best practice is to
sort things by type.
-By convention a master/satellite/client host object should use the same name as the endpoint object.
-You can also add multiple hosts which execute checks against remote services/clients.
+By convention a master/satellite/agent host object should use the same name as the endpoint object.
+You can also add multiple hosts which execute checks against remote services/agents.
+
+The following example adds the `agent_endpoint` custom variable to the
+host and stores its name (FQDN). _Versions older than 2.11
+used the `client_endpoint` custom variable._
+
+This custom variable serves two purposes: 1) Service apply rules can match against it.
+2) Apply rules can retrieve its value and assign it to the `command_endpoint` attribute.
```
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf
-object Host "icinga2-client1.localdomain" {
+object Host "icinga2-agent1.localdomain" {
check_command = "hostalive" //check is executed on the master
address = "192.168.56.111"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
}
```
-Given that you are monitoring a Linux client, we'll add a remote [disk](10-icinga-template-library.md#plugin-check-command-disk)
+Given that you are monitoring a Linux agent, add a remote [disk](10-icinga-template-library.md#plugin-check-command-disk)
check.
```
@@ -1041,10 +1087,11 @@ check.
apply Service "disk" {
check_command = "disk"
- //specify where the check is executed
- command_endpoint = host.vars.client_endpoint
+ // Specify the remote agent as command execution endpoint, fetch the host custom variable
+ command_endpoint = host.vars.agent_endpoint
- assign where host.vars.client_endpoint
+ // Only assign where a host is marked as agent endpoint
+ assign where host.vars.agent_endpoint
}
```
@@ -1074,10 +1121,10 @@ The following steps will happen:
* Icinga 2 validates the configuration on `icinga2-master1.localdomain` and restarts.
* The `icinga2-master1.localdomain` node schedules and executes the checks.
-* The `icinga2-client1.localdomain` node receives the execute command event with additional command parameters.
-* The `icinga2-client1.localdomain` node maps the command parameters to the local check command, executes the check locally, and sends back the check result message.
+* The `icinga2-agent1.localdomain` node receives the execute command event with additional command parameters.
+* The `icinga2-agent1.localdomain` node maps the command parameters to the local check command, executes the check locally, and sends back the check result message.
-As you can see, no interaction from your side is required on the client itself, and it's not necessary to reload the Icinga 2 service on the client.
+As you can see, no interaction from your side is required on the agent itself, and it's not necessary to reload the Icinga 2 service on the agent.
You have learned the basics about command endpoint checks. Proceed with
the [scenarios](06-distributed-monitoring.md#distributed-monitoring-scenarios)
@@ -1091,7 +1138,7 @@ It comes in handy if you want to configure everything on the master node
and sync the satellite checks (disk, memory, etc.). The satellites run their
own local scheduler and will send the check result messages back to the master.
-![Icinga 2 Distributed Top Down Config Sync](images/distributed-monitoring/icinga2_distributed_top_down_config_sync.png)
+![Icinga 2 Distributed Top Down Config Sync](images/distributed-monitoring/icinga2_distributed_monitoring_satellite_config_sync.png)
Advantages:
@@ -1112,51 +1159,48 @@ commands, you need to configure the `Zone` and `Endpoint` hierarchy
on all nodes.
* `icinga2-master1.localdomain` is the configuration master in this scenario.
-* `icinga2-client2.localdomain` acts as client which receives configuration from the master. Checks are scheduled locally.
+* `icinga2-satellite1.localdomain` acts as satellite which receives configuration from the master. Checks are scheduled locally.
Include the endpoint and zone configuration on **both** nodes in the file `/etc/icinga2/zones.conf`.
The endpoint configuration could look like this:
```
-[root@icinga2-client2.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-satellite1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
host = "192.168.56.101"
}
-object Endpoint "icinga2-client2.localdomain" {
- host = "192.168.56.112"
+object Endpoint "icinga2-satellite1.localdomain" {
+ host = "192.168.56.105"
}
```
-Next, you need to define two zones. There is no naming convention, best practice is to either use `master`, `satellite`/`client-fqdn` or to choose region names for example `Europe`, `USA` and `Asia`, though.
+Next, you need to define two zones. There is no naming convention, best practice is to either use `master`, `satellite`/`agent-fqdn` or to choose region names for example `Europe`, `USA` and `Asia`, though.
-**Note**: Each client requires its own zone and endpoint configuration. Best practice
-is to use the client's FQDN for all object names.
-
-The `master` zone is a parent of the `icinga2-client2.localdomain` zone:
+The `master` zone is a parent of the `satellite` zone:
```
-[root@icinga2-client2.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent2.localdomain /]# vim /etc/icinga2/zones.conf
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain" ] //array with endpoint names
}
-object Zone "icinga2-client2.localdomain" {
- endpoints = [ "icinga2-client2.localdomain" ]
+object Zone "satellite" {
+ endpoints = [ "icinga2-satellite1.localdomain" ]
parent = "master" //establish zone hierarchy
}
```
-Edit the `api` feature on the client `icinga2-client2.localdomain` in
+Edit the `api` feature on the satellite `icinga2-satellite1.localdomain` in
the `/etc/icinga2/features-enabled/api.conf` file and set
`accept_config` to `true`.
```
-[root@icinga2-client2.localdomain /]# vim /etc/icinga2/features-enabled/api.conf
+[root@icinga2-satellite1.localdomain /]# vim /etc/icinga2/features-enabled/api.conf
object ApiListener "api" {
//...
@@ -1170,8 +1214,8 @@ on both nodes.
Example on CentOS 7:
```
-[root@icinga2-client2.localdomain /]# icinga2 daemon -C
-[root@icinga2-client2.localdomain /]# systemctl restart icinga2
+[root@icinga2-satellite1.localdomain /]# icinga2 daemon -C
+[root@icinga2-satellite1.localdomain /]# systemctl restart icinga2
[root@icinga2-master1.localdomain /]# icinga2 daemon -C
[root@icinga2-master1.localdomain /]# systemctl restart icinga2
@@ -1180,43 +1224,44 @@ Example on CentOS 7:
**Tip**: Best practice is to use a [global zone](06-distributed-monitoring.md#distributed-monitoring-global-zone-config-sync)
for common configuration items (check commands, templates, groups, etc.).
-Once the clients have connected successfully, it's time for the next step: **execute
-a local check on the client using the configuration sync**.
+Once the satellite(s) have connected successfully, it's time for the next step: **execute
+a local check on the satellite using the configuration sync**.
Navigate to `/etc/icinga2/zones.d` on your master node
`icinga2-master1.localdomain` and create a new directory with the same
-name as your satellite/client zone name:
+name as your satellite/agent zone name:
```
-[root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/icinga2-client2.localdomain
+[root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/satellite
```
Add the host and service objects you want to monitor. There is
no limitation for files and directories -- best practice is to
sort things by type.
-By convention a master/satellite/client host object should use the same name as the endpoint object.
-You can also add multiple hosts which execute checks against remote services/clients.
+By convention a master/satellite/agent host object should use the same name as the endpoint object.
+You can also add multiple hosts which execute checks against remote services/agents via [command endpoint](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)
+checks.
```
-[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/icinga2-client2.localdomain
-[root@icinga2-master1.localdomain /etc/icinga2/zones.d/icinga2-client2.localdomain]# vim hosts.conf
+[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/satellite
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim hosts.conf
-object Host "icinga2-client2.localdomain" {
+object Host "icinga2-satellite1.localdomain" {
check_command = "hostalive"
address = "192.168.56.112"
- zone = "master" //optional trick: sync the required host object to the client, but enforce the "master" zone to execute the check
+ zone = "master" //optional trick: sync the required host object to the satellite, but enforce the "master" zone to execute the check
}
```
-Given that you are monitoring a Linux client we'll just add a local [disk](10-icinga-template-library.md#plugin-check-command-disk)
+Given that you are monitoring a Linux satellite add a local [disk](10-icinga-template-library.md#plugin-check-command-disk)
check.
```
-[root@icinga2-master1.localdomain /etc/icinga2/zones.d/icinga2-client2.localdomain]# vim services.conf
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim services.conf
object Service "disk" {
- host_name = "icinga2-client2.localdomain"
+ host_name = "icinga2-satellite1.localdomain"
check_command = "disk"
}
@@ -1239,11 +1284,10 @@ The following steps will happen:
* Icinga 2 validates the configuration on `icinga2-master1.localdomain`.
* Icinga 2 copies the configuration into its zone config store in `/var/lib/icinga2/api/zones`.
* The `icinga2-master1.localdomain` node sends a config update event to all endpoints in the same or direct child zones.
-* The `icinga2-client2.localdomain` node accepts config and populates the local zone config store with the received config files.
-* The `icinga2-client2.localdomain` node validates the configuration and automatically restarts.
+* The `icinga2-satellite1.localdomain` node accepts config and populates the local zone config store with the received config files.
+* The `icinga2-satellite1.localdomain` node validates the configuration and automatically restarts.
-Again, there is no interaction required on the client
-itself.
+Again, there is no interaction required on the satellite itself.
You can also use the config sync inside a high-availability zone to
ensure that all config objects are synced among zone members.
@@ -1269,32 +1313,35 @@ distributed monitoring environment. We've seen them all in production
environments and received feedback from our [community](https://community.icinga.com/)
and [partner support](https://icinga.com/support/) channels:
-* [Single master with client](06-distributed-monitoring.md#distributed-monitoring-master-clients).
-* [HA master with clients as command endpoint](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-clients)
-* [Three level cluster](06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-client) with config HA masters, satellites receiving config sync, and clients checked using command endpoint.
+* [Single master with agents](06-distributed-monitoring.md#distributed-monitoring-master-agents).
+* [HA master with agents as command endpoint](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-agents)
+* [Three level cluster](06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-agents) with config HA masters, satellites receiving config sync, and agents checked using command endpoint.
You can also extend the cluster tree depth to four levels e.g. with 2 satellite levels.
Just keep in mind that multiple levels become harder to debug in case of errors.
You can also start with a single master setup, and later add a secondary
master endpoint. This requires an extra step with the [initial sync](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-initial-sync)
-for cloning the runtime state. This is described in detail [here](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-clients).
+for cloning the runtime state. This is described in detail [here](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-agents).
+
+<!-- Keep this for compatiblity -->
+<a id="distributed-monitoring-master-clients"></a>
-### Master with Clients <a id="distributed-monitoring-master-clients"></a>
+### Master with Agents <a id="distributed-monitoring-master-agents"></a>
In this scenario, a single master node runs the check scheduler, notifications
and IDO database backend and uses the [command endpoint mode](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)
-to execute checks on the remote clients.
+to execute checks on the remote agents.
-![Icinga 2 Distributed Master with Clients](images/distributed-monitoring/icinga2_distributed_scenarios_master_clients.png)
+![Icinga 2 Distributed Master with Agents](images/distributed-monitoring/icinga2_distributed_monitoring_scenarios_master_with_agents.png)
* `icinga2-master1.localdomain` is the primary master node.
-* `icinga2-client1.localdomain` and `icinga2-client2.localdomain` are two child nodes as clients.
+* `icinga2-agent1.localdomain` and `icinga2-agent2.localdomain` are two child nodes as agents.
Setup requirements:
* Set up `icinga2-master1.localdomain` as [master](06-distributed-monitoring.md#distributed-monitoring-setup-master).
-* Set up `icinga2-client1.localdomain` and `icinga2-client2.localdomain` as [client](06-distributed-monitoring.md#distributed-monitoring-setup-satellite-client).
+* Set up `icinga2-agent1.localdomain` and `icinga2-agent2.localdomain` as [agent](06-distributed-monitoring.md#distributed-monitoring-setup-agent-satellite).
Edit the `zones.conf` configuration file on the master:
@@ -1302,28 +1349,31 @@ Edit the `zones.conf` configuration file on the master:
[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
+ // That's us
}
-object Endpoint "icinga2-client1.localdomain" {
- host = "192.168.56.111" //the master actively tries to connect to the client
+object Endpoint "icinga2-agent1.localdomain" {
+ host = "192.168.56.111" // The master actively tries to connect to the agent
+ log_duration = 0 // Disable the replay log for command endpoint agents
}
-object Endpoint "icinga2-client2.localdomain" {
- host = "192.168.56.112" //the master actively tries to connect to the client
+object Endpoint "icinga2-agent2.localdomain" {
+ host = "192.168.56.112" // The master actively tries to connect to the agent
+ log_duration = 0 // Disable the replay log for command endpoint agents
}
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain" ]
}
-object Zone "icinga2-client1.localdomain" {
- endpoints = [ "icinga2-client1.localdomain" ]
+object Zone "icinga2-agent1.localdomain" {
+ endpoints = [ "icinga2-agent1.localdomain" ]
parent = "master"
}
-object Zone "icinga2-client2.localdomain" {
- endpoints = [ "icinga2-client2.localdomain" ]
+object Zone "icinga2-agent2.localdomain" {
+ endpoints = [ "icinga2-agent2.localdomain" ]
parent = "master"
}
@@ -1332,32 +1382,36 @@ object Zone "icinga2-client2.localdomain" {
object Zone "global-templates" {
global = true
}
+object Zone "director-global" {
+ global = true
+}
```
-The two client nodes do not necessarily need to know about each other. The only important thing
+The two agent nodes do not need to know about each other. The only important thing
is that they know about the parent zone and their endpoint members (and optionally the global zone).
If you specify the `host` attribute in the `icinga2-master1.localdomain` endpoint object,
-the client will actively try to connect to the master node. Since we've specified the client
-endpoint's attribute on the master node already, we don't want the clients to connect to the
+the agent will actively try to connect to the master node. Since you've specified the agent
+endpoint's attribute on the master node already, you don't want the agents to connect to the
master. **Choose one [connection direction](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-connection-direction).**
```
-[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
+ // Do not actively connect to the master by leaving out the 'host' attribute
}
-object Endpoint "icinga2-client1.localdomain" {
+object Endpoint "icinga2-agent1.localdomain" {
+ // That's us
}
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain" ]
}
-object Zone "icinga2-client1.localdomain" {
- endpoints = [ "icinga2-client1.localdomain" ]
+object Zone "icinga2-agent1.localdomain" {
+ endpoints = [ "icinga2-agent1.localdomain" ]
parent = "master"
}
@@ -1366,22 +1420,27 @@ object Zone "icinga2-client1.localdomain" {
object Zone "global-templates" {
global = true
}
-
-[root@icinga2-client2.localdomain /]# vim /etc/icinga2/zones.conf
+object Zone "director-global" {
+ global = true
+}
+```
+```
+[root@icinga2-agent2.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
+ // Do not actively connect to the master by leaving out the 'host' attribute
}
-object Endpoint "icinga2-client2.localdomain" {
+object Endpoint "icinga2-agent2.localdomain" {
+ // That's us
}
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain" ]
}
-object Zone "icinga2-client2.localdomain" {
- endpoints = [ "icinga2-client2.localdomain" ]
+object Zone "icinga2-agent2.localdomain" {
+ endpoints = [ "icinga2-agent2.localdomain" ]
parent = "master"
}
@@ -1390,9 +1449,12 @@ object Zone "icinga2-client2.localdomain" {
object Zone "global-templates" {
global = true
}
+object Zone "director-global" {
+ global = true
+}
```
-Now it is time to define the two client hosts and apply service checks using
+Now it is time to define the two agent hosts and apply service checks using
the command endpoint execution method on them. Note: You can also use the
config sync mode here.
@@ -1402,22 +1464,24 @@ Create a new configuration directory on the master node:
[root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/master
```
-Add the two client nodes as host objects:
+Add the two agent nodes as host objects:
```
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf
-object Host "icinga2-client1.localdomain" {
+object Host "icinga2-agent1.localdomain" {
check_command = "hostalive"
address = "192.168.56.111"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
}
-object Host "icinga2-client2.localdomain" {
+object Host "icinga2-agent2.localdomain" {
check_command = "hostalive"
address = "192.168.56.112"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
}
```
@@ -1428,6 +1492,7 @@ Add services using command endpoint checks:
apply Service "ping4" {
check_command = "ping4"
+
//check is executed on the master node
assign where host.address
}
@@ -1435,10 +1500,11 @@ apply Service "ping4" {
apply Service "disk" {
check_command = "disk"
- //specify where the check is executed
- command_endpoint = host.vars.client_endpoint
+ // Execute the check on the remote command endpoint
+ command_endpoint = host.vars.agent_endpoint
- assign where host.vars.client_endpoint
+ // Assign the service onto an agent
+ assign where host.vars.agent_endpoint
}
```
@@ -1449,19 +1515,39 @@ Validate the configuration and restart Icinga 2 on the master node `icinga2-mast
[root@icinga2-master1.localdomain /]# systemctl restart icinga2
```
-Open Icinga Web 2 and check the two newly created client hosts with two new services
+Open Icinga Web 2 and check the two newly created agent hosts with two new services
-- one executed locally (`ping4`) and one using command endpoint (`disk`).
+> **Note**
+>
+> You don't necessarily need to add the agent endpoint/zone configuration objects
+> into the master's zones.conf file. Instead, you can put them into `/etc/icinga2/zones.d/master`
+> either in `hosts.conf` shown above, or in a new file called `agents.conf`.
+
+> **Tip**:
+>
+> It's a good idea to add [health checks](06-distributed-monitoring.md#distributed-monitoring-health-checks)
+to make sure that your cluster notifies you in case of failure.
+
+In terms of health checks, consider adding the following for this scenario:
-### High-Availability Master with Clients <a id="distributed-monitoring-scenarios-ha-master-clients"></a>
+- Master node(s) check the connection to the agents
+- Optional: Add dependencies for the agent host to prevent unwanted notifications when agents are unreachable
-This scenario is similar to the one in the [previous section](06-distributed-monitoring.md#distributed-monitoring-master-clients). The only difference is that we will now set up two master nodes in a high-availability setup.
+Proceed in [this chapter](06-distributed-monitoring.md#distributed-monitoring-health-checks-master-agents).
+
+<!-- Keep this for compatibility -->
+<a id="distributed-monitoring-scenarios-ha-master-clients"></a>
+
+### High-Availability Master with Agents <a id="distributed-monitoring-scenarios-ha-master-agents"></a>
+
+This scenario is similar to the one in the [previous section](06-distributed-monitoring.md#distributed-monitoring-master-agents). The only difference is that we will now set up two master nodes in a high-availability setup.
These nodes must be configured as zone and endpoints objects.
-![Icinga 2 Distributed High Availability Master with Clients](images/distributed-monitoring/icinga2_distributed_scenarios_ha_master_clients.png)
+![Icinga 2 Distributed High Availability Master with Agents](images/distributed-monitoring/icinga2_distributed_monitoring_scenario_ha_masters_with_agents.png)
The setup uses the capabilities of the Icinga 2 cluster. All zone members
-replicate cluster events amongst each other. In addition to that, several Icinga 2
+replicate cluster events between each other. In addition to that, several Icinga 2
features can enable [HA functionality](06-distributed-monitoring.md#distributed-monitoring-high-availability-features).
Best practice is to run the database backend on a dedicated server/cluster and
@@ -1469,6 +1555,7 @@ only expose a virtual IP address to Icinga and the IDO feature. By default, only
endpoint will actively write to the backend then. Typical setups for MySQL clusters
involve Master-Master-Replication (Master-Slave-Replication in both directions) or Galera,
more tips can be found on our [community forums](https://community.icinga.com/).
+The IDO object must have the same `instance_name` on all master nodes.
**Note**: All nodes in the same zone require that you enable the same features for high-availability (HA).
@@ -1476,16 +1563,16 @@ Overview:
* `icinga2-master1.localdomain` is the config master master node.
* `icinga2-master2.localdomain` is the secondary master master node without config in `zones.d`.
-* `icinga2-client1.localdomain` and `icinga2-client2.localdomain` are two child nodes as clients.
+* `icinga2-agent1.localdomain` and `icinga2-agent2.localdomain` are two child nodes as agents.
Setup requirements:
* Set up `icinga2-master1.localdomain` as [master](06-distributed-monitoring.md#distributed-monitoring-setup-master).
-* Set up `icinga2-master2.localdomain` as [client](06-distributed-monitoring.md#distributed-monitoring-setup-satellite-client) (we will modify the generated configuration).
-* Set up `icinga2-client1.localdomain` and `icinga2-client2.localdomain` as [clients](06-distributed-monitoring.md#distributed-monitoring-setup-satellite-client) (when asked for adding multiple masters, set to `y` and add the secondary master `icinga2-master2.localdomain`).
+* Set up `icinga2-master2.localdomain` as [satellite](06-distributed-monitoring.md#distributed-monitoring-setup-agent-satellite) (**we will modify the generated configuration**).
+* Set up `icinga2-agent1.localdomain` and `icinga2-agent2.localdomain` as [agents](06-distributed-monitoring.md#distributed-monitoring-setup-agent-satellite) (when asked for adding multiple masters, set to `y` and add the secondary master `icinga2-master2.localdomain`).
In case you don't want to use the CLI commands, you can also manually create and sync the
-required SSL certificates. We will modify and discuss all the details of the automatically generated configuration here.
+required TLS certificates. We will modify and discuss all the details of the automatically generated configuration here.
Since there are now two nodes in the same zone, we must consider the
[high-availability features](06-distributed-monitoring.md#distributed-monitoring-high-availability-features).
@@ -1501,82 +1588,97 @@ backend, IDO database, used transports, etc.).
> **Note**
>
-> You can also start with a single master shown [here](06-distributed-monitoring.md#distributed-monitoring-master-clients) and later add
+> You can also start with a single master shown [here](06-distributed-monitoring.md#distributed-monitoring-master-agents) and later add
> the second master. This requires an extra step with the [initial sync](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-initial-sync)
> for cloning the runtime state after done. Once done, proceed here.
-The zone hierarchy could look like this. It involves putting the two master nodes
-`icinga2-master1.localdomain` and `icinga2-master2.localdomain` into the `master` zone.
+In this scenario, we are not adding the agent configuration immediately
+to the `zones.conf` file but will establish the hierarchy later.
+
+The first master looks like this:
```
[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
- host = "192.168.56.101"
+ // That's us
}
object Endpoint "icinga2-master2.localdomain" {
- host = "192.168.56.102"
+ host = "192.168.56.102" // Actively connect to the secondary master
}
-object Endpoint "icinga2-client1.localdomain" {
- host = "192.168.56.111" //the master actively tries to connect to the client
+object Zone "master" {
+ endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
}
-object Endpoint "icinga2-client2.localdomain" {
- host = "192.168.56.112" //the master actively tries to connect to the client
+/* sync global commands */
+object Zone "global-templates" {
+ global = true
}
-
-object Zone "master" {
- endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
+object Zone "director-global" {
+ global = true
}
+```
-object Zone "icinga2-client1.localdomain" {
- endpoints = [ "icinga2-client1.localdomain" ]
+The secondary master waits for connection attempts from the first master,
+and therefore does not try to connect to it again.
- parent = "master"
+```
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.conf
+
+object Endpoint "icinga2-master1.localdomain" {
+ // That's us
}
-object Zone "icinga2-client2.localdomain" {
- endpoints = [ "icinga2-client2.localdomain" ]
+object Endpoint "icinga2-master2.localdomain" {
+ // The first master already connects to us
+}
- parent = "master"
+object Zone "master" {
+ endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
}
/* sync global commands */
object Zone "global-templates" {
global = true
}
+object Zone "director-global" {
+ global = true
+}
```
-The two client nodes do not necessarily need to know about each other. The only important thing
+Restart both masters and ensure the initial connection and TLS handshake works.
+
+The two agent nodes do not need to know about each other. The only important thing
is that they know about the parent zone and their endpoint members (and optionally about the global zone).
If you specify the `host` attribute in the `icinga2-master1.localdomain` and `icinga2-master2.localdomain`
-endpoint objects, the client will actively try to connect to the master node. Since we've specified the client
-endpoint's attribute on the master node already, we don't want the clients to connect to the
+endpoint objects, the agent will actively try to connect to the master node. Since we've specified the agent
+endpoint's attribute on the master node already, we don't want the agent to connect to the
master nodes. **Choose one [connection direction](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-connection-direction).**
```
-[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
+ // Do not actively connect to the master by leaving out the 'host' attribute
}
object Endpoint "icinga2-master2.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
+ // Do not actively connect to the master by leaving out the 'host' attribute
}
-object Endpoint "icinga2-client1.localdomain" {
+object Endpoint "icinga2-agent1.localdomain" {
+ // That's us
}
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
}
-object Zone "icinga2-client1.localdomain" {
- endpoints = [ "icinga2-client1.localdomain" ]
+object Zone "icinga2-agent1.localdomain" {
+ endpoints = [ "icinga2-agent1.localdomain" ]
parent = "master"
}
@@ -1585,26 +1687,33 @@ object Zone "icinga2-client1.localdomain" {
object Zone "global-templates" {
global = true
}
+object Zone "director-global" {
+ global = true
+}
+
+```
-[root@icinga2-client2.localdomain /]# vim /etc/icinga2/zones.conf
+```
+[root@icinga2-agent2.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
+ // Do not actively connect to the master by leaving out the 'host' attribute
}
object Endpoint "icinga2-master2.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
+ // Do not actively connect to the master by leaving out the 'host' attribute
}
-object Endpoint "icinga2-client2.localdomain" {
+object Endpoint "icinga2-agent2.localdomain" {
+ //That's us
}
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
}
-object Zone "icinga2-client2.localdomain" {
- endpoints = [ "icinga2-client2.localdomain" ]
+object Zone "icinga2-agent2.localdomain" {
+ endpoints = [ "icinga2-agent2.localdomain" ]
parent = "master"
}
@@ -1613,11 +1722,13 @@ object Zone "icinga2-client2.localdomain" {
object Zone "global-templates" {
global = true
}
+object Zone "director-global" {
+ global = true
+}
```
-Now it is time to define the two client hosts and apply service checks using
-the command endpoint execution method. Note: You can also use the
-config sync mode here.
+Now it is time to define the two agent hosts and apply service checks using
+the command endpoint execution method.
Create a new configuration directory on the master node `icinga2-master1.localdomain`.
**Note**: The secondary master node `icinga2-master2.localdomain` receives the
@@ -1627,22 +1738,74 @@ configuration using the [config sync mode](06-distributed-monitoring.md#distribu
[root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/master
```
-Add the two client nodes as host objects:
+Add the two agent nodes with their zone/endpoint and host object configuration.
+
+> **Note**
+>
+> In order to keep things in sync between the two HA masters,
+> keep the `zones.conf` file as small as possible.
+>
+> You can create the agent zone and endpoint objects inside the
+> master zone and have them synced to the secondary master.
+> The cluster config sync enforces a reload allowing the secondary
+> master to connect to the agents as well.
+
+Edit the `zones.conf` file and ensure that the agent zone/endpoint objects
+are **not** specified in there.
+
+Then navigate into `/etc/icinga2/zones.d/master` and create a new file `agents.conf`.
```
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim agents.conf
+
+//-----------------------------------------------
+// Endpoints
+
+object Endpoint "icinga2-agent1.localdomain" {
+ host = "192.168.56.111" // The master actively tries to connect to the agent
+ log_duration = 0 // Disable the replay log for command endpoint agents
+}
+
+object Endpoint "icinga2-agent2.localdomain" {
+ host = "192.168.56.112" // The master actively tries to connect to the agent
+ log_duration = 0 // Disable the replay log for command endpoint agents
+}
+
+//-----------------------------------------------
+// Zones
+
+object Zone "icinga2-agent1.localdomain" {
+ endpoints = [ "icinga2-agent1.localdomain" ]
+
+ parent = "master"
+}
+
+object Zone "icinga2-agent2.localdomain" {
+ endpoints = [ "icinga2-agent2.localdomain" ]
+
+ parent = "master"
+}
+```
+
+Whenever you need to add an agent again, edit the mentioned files.
+
+Next, create the corresponding host objects for the agents. Use the same names
+for host and endpoint objects.
+
+```
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf
-object Host "icinga2-client1.localdomain" {
+object Host "icinga2-agent1.localdomain" {
check_command = "hostalive"
address = "192.168.56.111"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
}
-object Host "icinga2-client2.localdomain" {
+object Host "icinga2-agent2.localdomain" {
check_command = "hostalive"
address = "192.168.56.112"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
}
```
@@ -1653,17 +1816,18 @@ Add services using command endpoint checks:
apply Service "ping4" {
check_command = "ping4"
- //check is executed on the master node
+
+ // Check is executed on the master node
assign where host.address
}
apply Service "disk" {
check_command = "disk"
- //specify where the check is executed
- command_endpoint = host.vars.client_endpoint
+ // Check is executed on the remote command endpoint
+ command_endpoint = host.vars.agent_endpoint
- assign where host.vars.client_endpoint
+ assign where host.vars.agent_endpoint
}
```
@@ -1674,20 +1838,31 @@ Validate the configuration and restart Icinga 2 on the master node `icinga2-mast
[root@icinga2-master1.localdomain /]# systemctl restart icinga2
```
-Open Icinga Web 2 and check the two newly created client hosts with two new services
+Open Icinga Web 2 and check the two newly created agent hosts with two new services
-- one executed locally (`ping4`) and one using command endpoint (`disk`).
-**Tip**: It's a good idea to add [health checks](06-distributed-monitoring.md#distributed-monitoring-health-checks)
+> **Tip**:
+>
+> It's a good idea to add [health checks](06-distributed-monitoring.md#distributed-monitoring-health-checks)
to make sure that your cluster notifies you in case of failure.
+In terms of health checks, consider adding the following for this scenario:
-### Three Levels with Master, Satellites, and Clients <a id="distributed-monitoring-scenarios-master-satellite-client"></a>
+- Master node(s) check the connection to the agents
+- Optional: Add dependencies for the agent host to prevent unwanted notifications when agents are unreachable
+
+Proceed in [this chapter](06-distributed-monitoring.md#distributed-monitoring-health-checks-master-agents).
+
+<!-- Keep this for compatibility -->
+<a id="distributed-monitoring-scenarios-master-satellite-client"></a>
+
+### Three Levels with Masters, Satellites and Agents <a id="distributed-monitoring-scenarios-master-satellite-agents"></a>
This scenario combines everything you've learned so far: High-availability masters,
-satellites receiving their configuration from the master zone, and clients checked via command
+satellites receiving their configuration from the master zone, and agents checked via command
endpoint from the satellite zones.
-![Icinga 2 Distributed Master and Satellites with Clients](images/distributed-monitoring/icinga2_distributed_scenarios_master_satellite_client.png)
+![Icinga 2 Distributed Master and Satellites with Agents](images/distributed-monitoring/icinga2_distributed_monitoring_scenarios_master_satellites_agents.png)
> **Tip**:
>
@@ -1705,19 +1880,19 @@ Overview:
* `icinga2-master1.localdomain` is the configuration master master node.
* `icinga2-master2.localdomain` is the secondary master master node without configuration in `zones.d`.
* `icinga2-satellite1.localdomain` and `icinga2-satellite2.localdomain` are satellite nodes in a `master` child zone. They forward CSR signing requests to the master zone.
-* `icinga2-client1.localdomain` and `icinga2-client2.localdomain` are two child nodes as clients.
+* `icinga2-agent1.localdomain` and `icinga2-agent2.localdomain` are two child nodes as agents.
Setup requirements:
* Set up `icinga2-master1.localdomain` as [master](06-distributed-monitoring.md#distributed-monitoring-setup-master).
-* Set up `icinga2-master2.localdomain`, `icinga2-satellite1.localdomain` and `icinga2-satellite2.localdomain` as [clients](06-distributed-monitoring.md#distributed-monitoring-setup-satellite-client) (we will modify the generated configuration).
-* Set up `icinga2-client1.localdomain` and `icinga2-client2.localdomain` as [clients](06-distributed-monitoring.md#distributed-monitoring-setup-satellite-client).
+* Set up `icinga2-master2.localdomain`, `icinga2-satellite1.localdomain` and `icinga2-satellite2.localdomain` as [agents](06-distributed-monitoring.md#distributed-monitoring-setup-agent-satellite) (we will modify the generated configuration).
+* Set up `icinga2-agent1.localdomain` and `icinga2-agent2.localdomain` as [agents](06-distributed-monitoring.md#distributed-monitoring-setup-agent-satellite).
When being asked for the parent endpoint providing CSR auto-signing capabilities,
please add one of the satellite nodes. **Note**: This requires Icinga 2 v2.8+
-and the `CA Proxy` on all master, satellite and client nodes.
+and the `CA Proxy` on all master, satellite and agent nodes.
-Example for `icinga2-client1.localdomain`:
+Example for `icinga2-agent1.localdomain`:
```
Please specify the parent endpoint(s) (master or satellite) where this node should connect to:
@@ -1755,7 +1930,7 @@ Proceed with adding the optional client ticket for [CSR auto-signing](06-distrib
```
Please specify the request ticket generated on your Icinga 2 master (optional).
- (Hint: # icinga2 pki ticket --cn 'icinga2-client1.localdomain'):
+ (Hint: # icinga2 pki ticket --cn 'icinga2-agent1.localdomain'):
4f75d2ecd253575fe9180938ebff7cbca262f96e
```
@@ -1789,10 +1964,10 @@ Next you can optionally specify the local and parent zone names. This will be re
in the generated zone configuration file.
```
-Local zone name [icinga2-client1.localdomain]: icinga2-client1.localdomain
+Local zone name [icinga2-agent1.localdomain]: icinga2-agent1.localdomain
```
-Set the parent zone name to `satellite` for this client.
+Set the parent zone name to `satellite` for this agent.
```
Parent zone name [master]: satellite
@@ -1809,8 +1984,8 @@ Do you want to specify additional global zones? [y/N]: N
```
Last but not least the wizard asks you whether you want to disable the inclusion of the local configuration
-directory in `conf.d`, or not. Defaults to disabled, as clients either are checked via command endpoint, or
-they receive configuration synced from the parent zone.
+directory in `conf.d`, or not. Defaults to disabled, since agents are checked via command endpoint and the example
+configuration would collide with this mode.
```
Do you want to disable the inclusion of the conf.d directory [Y/n]: Y
@@ -1831,25 +2006,54 @@ must include the `host` attribute for the satellite endpoints:
[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
- //that's us
+ // That's us
}
object Endpoint "icinga2-master2.localdomain" {
- host = "192.168.56.102"
+ host = "192.168.56.102" // Actively connect to the second master.
}
object Endpoint "icinga2-satellite1.localdomain" {
- host = "192.168.56.105"
+ host = "192.168.56.105" // Actively connect to the satellites.
}
object Endpoint "icinga2-satellite2.localdomain" {
- host = "192.168.56.106"
+ host = "192.168.56.106" // Actively connect to the satellites.
}
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
}
+```
+
+The endpoint configuration on the secondary master looks similar,
+but changes the connection attributes - the first master already
+tries to connect, there is no need for a secondary attempt.
+
+```
+[root@icinga2-master2.localdomain /]# vim /etc/icinga2/zones.conf
+
+object Endpoint "icinga2-master1.localdomain" {
+ // First master already connects to us
+}
+
+object Endpoint "icinga2-master2.localdomain" {
+ // That's us
+}
+
+object Endpoint "icinga2-satellite1.localdomain" {
+ host = "192.168.56.105" // Actively connect to the satellites.
+}
+
+object Endpoint "icinga2-satellite2.localdomain" {
+ host = "192.168.56.106" // Actively connect to the satellites.
+}
+```
+The zone configuration on both masters looks the same. Add this
+to the corresponding `zones.conf` entries for the endpoints.
+
+```
object Zone "satellite" {
endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite2.localdomain" ]
@@ -1875,21 +2079,50 @@ instances.
[root@icinga2-satellite1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" {
- //this endpoint will connect to us
+ // This endpoint will connect to us
+}
+
+object Endpoint "icinga2-master2.localdomain" {
+ // This endpoint will connect to us
+}
+
+object Endpoint "icinga2-satellite1.localdomain" {
+ // That's us
+}
+
+object Endpoint "icinga2-satellite2.localdomain" {
+ host = "192.168.56.106" // Actively connect to the secondary satellite
+}
+```
+
+Again, only one side is required to establish the connection inside the HA zone.
+Since satellite1 already connects to satellite2, leave out the `host` attribute
+for `icinga2-satellite1.localdomain` on satellite2.
+
+```
+[root@icinga2-satellite2.localdomain /]# vim /etc/icinga2/zones.conf
+
+object Endpoint "icinga2-master1.localdomain" {
+ // This endpoint will connect to us
}
object Endpoint "icinga2-master2.localdomain" {
- //this endpoint will connect to us
+ // This endpoint will connect to us
}
object Endpoint "icinga2-satellite1.localdomain" {
- //that's us
+ // First satellite already connects to us
}
object Endpoint "icinga2-satellite2.localdomain" {
- host = "192.168.56.106"
+ // That's us
}
+```
+
+The zone configuration on both satellites looks the same. Add this
+to the corresponding `zones.conf` entries for the endpoints.
+```
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
}
@@ -1909,76 +2142,89 @@ object Zone "director-global" {
global = true
}
```
+
Keep in mind to control the endpoint [connection direction](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-connection-direction)
using the `host` attribute, also for other endpoints in the same zone.
-Adopt the configuration for `icinga2-master2.localdomain` and `icinga2-satellite2.localdomain`.
-
Since we want to use [top down command endpoint](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint) checks,
-we must configure the client endpoint and zone objects.
-In order to minimize the effort, we'll sync the client zone and endpoint configuration to the
-satellites where the connection information is needed as well.
+we must configure the agent endpoint and zone objects.
+
+In order to minimize the effort, we'll sync the agent zone and endpoint configuration to the
+satellites where the connection information is needed as well. Note: This only works with satellite
+and agents, since there already is a trust relationship between the master and the satellite zone.
+The cluster config sync to the satellite invokes an automated reload causing the agent connection attempts.
+
+`icinga2-master1.localdomain` is the configuration master where everything is stored:
```
[root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/{master,satellite,global-templates}
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/satellite
-[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-client1.localdomain.conf
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-agent1.localdomain.conf
-object Endpoint "icinga2-client1.localdomain" {
- host = "192.168.56.111" //the satellite actively tries to connect to the client
+object Endpoint "icinga2-agent1.localdomain" {
+ host = "192.168.56.111" // The satellite actively tries to connect to the agent
+ log_duration = 0 // Disable the replay log for command endpoint agents
}
-object Zone "icinga2-client1.localdomain" {
- endpoints = [ "icinga2-client1.localdomain" ]
+object Zone "icinga2-agent1.localdomain" {
+ endpoints = [ "icinga2-agent1.localdomain" ]
parent = "satellite"
}
-[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-client2.localdomain.conf
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-agent2.localdomain.conf
-object Endpoint "icinga2-client2.localdomain" {
- host = "192.168.56.112" //the satellite actively tries to connect to the client
+object Endpoint "icinga2-agent2.localdomain" {
+ host = "192.168.56.112" // The satellite actively tries to connect to the agent
+ log_duration = 0 // Disable the replay log for command endpoint agents
}
-object Zone "icinga2-client2.localdomain" {
- endpoints = [ "icinga2-client2.localdomain" ]
+object Zone "icinga2-agent2.localdomain" {
+ endpoints = [ "icinga2-agent2.localdomain" ]
parent = "satellite"
}
```
-The two client nodes do not necessarily need to know about each other, either. The only important thing
+The two agent nodes do not need to know about each other. The only important thing
is that they know about the parent zone (the satellite) and their endpoint members (and optionally the global zone).
-If you specify the `host` attribute in the `icinga2-satellite1.localdomain` and `icinga2-satellite2.localdomain`
-endpoint objects, the client node will actively try to connect to the satellite node. Since we've specified the client
-endpoint's attribute on the satellite node already, we don't want the client node to connect to the
-satellite nodes. **Choose one [connection direction](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-connection-direction).**
+> **Tipp**
+>
+> In the example above we've specified the `host` attribute in the agent endpoint configuration. In this mode,
+> the satellites actively connect to the agents. This costs some resources on the satellite -- if you prefer to
+> offload the connection attempts to the agent, or your DMZ requires this, you can also change the **[connection direction](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-connection-direction).**
+>
+> 1) Don't set the `host` attribute for the agent endpoints put into `zones.d/satellite`.
+> 2) Modify each agent's zones.conf file and add the `host` attribute to all parent satellites. You can automate this with using the `node wizard/setup` CLI commands.
-Example for `icinga2-client1.localdomain`:
+The agents are waiting for the satellites to connect, therefore they don't specify
+the `host` attribute in the endpoint objects locally.
+
+Example for `icinga2-agent1.localdomain`:
```
-[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent1.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-satellite1.localdomain" {
- //do not actively connect to the satellite by leaving out the 'host' attribute
+ // Do not actively connect to the satellite by leaving out the 'host' attribute
}
object Endpoint "icinga2-satellite2.localdomain" {
- //do not actively connect to the satellite by leaving out the 'host' attribute
+ // Do not actively connect to the satellite by leaving out the 'host' attribute
}
-object Endpoint "icinga2-client1.localdomain" {
- //that's us
+object Endpoint "icinga2-agent1.localdomain" {
+ // That's us
}
object Zone "satellite" {
endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite2.localdomain" ]
}
-object Zone "icinga2-client1.localdomain" {
- endpoints = [ "icinga2-client1.localdomain" ]
+object Zone "icinga2-agent1.localdomain" {
+ endpoints = [ "icinga2-agent1.localdomain" ]
parent = "satellite"
}
@@ -1993,29 +2239,29 @@ object Zone "director-global" {
}
```
-Example for `icinga2-client2.localdomain`:
+Example for `icinga2-agent2.localdomain`:
```
-[root@icinga2-client2.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent2.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-satellite1.localdomain" {
- //do not actively connect to the satellite by leaving out the 'host' attribute
+ // Do not actively connect to the satellite by leaving out the 'host' attribute
}
object Endpoint "icinga2-satellite2.localdomain" {
- //do not actively connect to the satellite by leaving out the 'host' attribute
+ // Do not actively connect to the satellite by leaving out the 'host' attribute
}
-object Endpoint "icinga2-client2.localdomain" {
- //that's us
+object Endpoint "icinga2-agent2.localdomain" {
+ // That's us
}
object Zone "satellite" {
endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite2.localdomain" ]
}
-object Zone "icinga2-client2.localdomain" {
- endpoints = [ "icinga2-client2.localdomain" ]
+object Zone "icinga2-agent2.localdomain" {
+ endpoints = [ "icinga2-agent2.localdomain" ]
parent = "satellite"
}
@@ -2030,40 +2276,42 @@ object Zone "director-global" {
}
```
-Now it is time to define the two client hosts on the master, sync them to the satellites
+Now it is time to define the two agents hosts on the master, sync them to the satellites
and apply service checks using the command endpoint execution method to them.
-Add the two client nodes as host objects to the `satellite` zone.
+Add the two agent nodes as host objects to the `satellite` zone.
We've already created the directories in `/etc/icinga2/zones.d` including the files for the
-zone and endpoint configuration for the clients.
+zone and endpoint configuration for the agents.
```
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/satellite
```
-Add the host object configuration for the `icinga2-client1.localdomain` client. You should
+Add the host object configuration for the `icinga2-agent1.localdomain` agent. You should
have created the configuration file in the previous steps and it should contain the endpoint
and zone object configuration already.
```
-[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-client1.localdomain.conf
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-agent1.localdomain.conf
-object Host "icinga2-client1.localdomain" {
+object Host "icinga2-agent1.localdomain" {
check_command = "hostalive"
address = "192.168.56.111"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+
+ vars.agent_endpoint = name // Follows the convention that host name == endpoint name
}
```
-Add the host object configuration for the `icinga2-client2.localdomain` client configuration file:
+Add the host object configuration for the `icinga2-agent2.localdomain` agent configuration file:
```
-[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-client2.localdomain.conf
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-agent2.localdomain.conf
-object Host "icinga2-client2.localdomain" {
+object Host "icinga2-agent2.localdomain" {
check_command = "hostalive"
address = "192.168.56.112"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+
+ vars.agent_endpoint = name // Follows the convention that host name == endpoint name
}
```
@@ -2074,7 +2322,8 @@ Add a service object which is executed on the satellite nodes (e.g. `ping4`). Pi
apply Service "ping4" {
check_command = "ping4"
- //check is executed on the satellite node
+
+ // Check is executed on the satellite node
assign where host.zone == "satellite" && host.address
}
```
@@ -2087,10 +2336,10 @@ Add services using command endpoint checks. Pin the apply rules to the `satellit
apply Service "disk" {
check_command = "disk"
- //specify where the check is executed
- command_endpoint = host.vars.client_endpoint
+ // Execute the check on the remote command endpoint
+ command_endpoint = host.vars.agent_endpoint
- assign where host.zone == "satellite" && host.vars.client_endpoint
+ assign where host.zone == "satellite" && host.vars.agent_endpoint
}
```
@@ -2101,7 +2350,7 @@ Validate the configuration and restart Icinga 2 on the master node `icinga2-mast
[root@icinga2-master1.localdomain /]# systemctl restart icinga2
```
-Open Icinga Web 2 and check the two newly created client hosts with two new services
+Open Icinga Web 2 and check the two newly created agent hosts with two new services
-- one executed locally (`ping4`) and one using command endpoint (`disk`).
> **Tip**:
@@ -2109,6 +2358,15 @@ Open Icinga Web 2 and check the two newly created client hosts with two new serv
> It's a good idea to add [health checks](06-distributed-monitoring.md#distributed-monitoring-health-checks)
to make sure that your cluster notifies you in case of failure.
+In terms of health checks, consider adding the following for this scenario:
+
+- Master nodes check whether the satellite zone is connected
+- Satellite nodes check the connection to the agents
+- Optional: Add dependencies for the agent host to prevent unwanted notifications when agents are unreachable
+
+Proceed in [this chapter](06-distributed-monitoring.md#distributed-monitoring-health-checks-master-satellite-agent).
+
+
## Best Practice <a id="distributed-monitoring-best-practice"></a>
We've put together a collection of configuration examples from community feedback.
@@ -2126,13 +2384,14 @@ to all nodes depending on them. Common examples are:
* Group objects.
* TimePeriod objects.
-Plugin scripts and binaries cannot be synced, this is for Icinga 2
+Plugin scripts and binaries must not be synced, this is for Icinga 2
configuration files only. Use your preferred package repository
and/or configuration management tool (Puppet, Ansible, Chef, etc.)
-for that.
+for keeping packages and scripts uptodate.
**Note**: Checkable objects (hosts and services) cannot be put into a global
-zone. The configuration validation will terminate with an error.
+zone. The configuration validation will terminate with an error. Apply rules
+work as they are evaluated locally on each endpoint.
The zone object configuration must be deployed on all nodes which should receive
the global configuration files:
@@ -2147,6 +2406,10 @@ object Zone "global-commands" {
The default global zones generated by the setup wizards are called `global-templates` and `director-global`.
+While you can should `global-templates` for your global configuration, `director-global` is reserved for use
+by [Icinga Director](https://icinga.com/docs/director/latest/). Please don't
+place any configuration in it manually.
+
Similar to the zone configuration sync you'll need to create a new directory in
`/etc/icinga2/zones.d`:
@@ -2164,7 +2427,7 @@ object CheckCommand "webinject" {
}
```
-Restart the client(s) which should receive the global zone before
+Restart the endpoints(s) which should receive the global zone before
before restarting the parent master/satellite nodes.
Then validate the configuration on the master node and restart Icinga 2.
@@ -2188,77 +2451,156 @@ checks.
In order to minimize the problems caused by this, you should configure
additional health checks.
-The `cluster` check, for example, will check if all endpoints in the current zone and the directly
-connected zones are working properly:
+#### cluster-zone with Masters and Agents <a id="distributed-monitoring-health-checks-master-agents"></a>
+
+The `cluster-zone` check will test whether the configured target zone is currently
+connected or not. This example adds a health check for the [ha master with agents scenario](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-agents).
```
-[root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/master
-[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-master1.localdomain.conf
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/services.conf
+
+apply Service "agent-health" {
+ check_command = "cluster-zone"
+
+ display_name = "cluster-health-" + host.name
+
+ /* This follows the convention that the agent zone name is the FQDN which is the same as the host object name. */
+ vars.cluster_zone = host.name
+
+ assign where host.vars.agent_endpoint
+}
+```
+
+In order to prevent unwanted notifications, add a service dependency which gets applied to
+all services using the command endpoint mode.
+
+```
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/dependencies.conf
+
+apply Dependency "agent-health-check" to Service {
+ parent_service_name = "agent-health"
+
+ states = [ OK ] // Fail if the parent service state switches to NOT-OK
+ disable_notifications = true
+
+ assign where host.vars.agent_endpoint // Automatically assigns all agent endpoint checks as child services on the matched host
+ ignore where service.name == "agent-health" // Avoid a self reference from child to parent
+}
+```
+
+#### cluster-zone with Masters, Satellites and Agents <a id="distributed-monitoring-health-checks-master-satellite-agent"></a>
+
+This example adds health checks for the [master, satellites and agents scenario](06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-agents).
+
+Whenever the connection between the master and satellite zone breaks,
+you may encounter late check results in Icinga Web. In order to view
+this failure and also send notifications, add the following configuration:
+
+First, add the two masters as host objects to the master zone, if not already
+existing.
+
+```
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/hosts.conf
object Host "icinga2-master1.localdomain" {
check_command = "hostalive"
+
address = "192.168.56.101"
}
-[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/cluster.conf
+object Host "icinga2-master2.localdomain" {
+ check_command = "hostalive"
-object Service "cluster" {
- check_command = "cluster"
- check_interval = 5s
- retry_interval = 1s
+ address = "192.168.56.102"
+}
+```
- host_name = "icinga2-master1.localdomain"
+Add service health checks against the satellite zone.
+
+```
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/health.conf
+
+apply Service "satellite-zone-health" {
+ check_command = "cluster-zone"
+ check_interval = 30s
+ retry_interval = 10s
+
+ vars.cluster_zone = "satellite"
+
+ assign where match("icinga2-master*.localdomain", host.name)
}
```
-The `cluster-zone` check will test whether the configured target zone is currently
-connected or not. This example adds a health check for the [ha master with clients scenario](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-clients).
+**Don't forget to create notification apply rules for these services.**
+
+Next are health checks for agents connected to the satellite zone.
+Navigate into the satellite directory in `zones.d`:
```
-[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/services.conf
+[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/satellite
+```
-apply Service "cluster-health" {
+You should already have configured agent host objects following [the master, satellite, agents scenario](06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-agents).
+Add a new configuration file where all the health checks are defined.
+
+```
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim health.conf
+
+apply Service "agent-health" {
check_command = "cluster-zone"
- display_name = "cluster-health-" + host.name
+ display_name = "agent-health-" + host.name
- /* This follows the convention that the client zone name is the FQDN which is the same as the host object name. */
+ // This follows the convention that the agent zone name is the FQDN which is the same as the host object name.
vars.cluster_zone = host.name
- assign where host.vars.client_endpoint
+ // Create this health check for agent hosts in the satellite zone
+ assign where host.zone == "satellite" && host.vars.agent_endpoint
}
```
-In case you cannot assign the `cluster_zone` attribute, add specific
-checks to your cluster:
+In order to prevent unwanted notifications, add a service dependency which gets applied to
+all services using the command endpoint mode.
```
-[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/cluster.conf
+[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim health.conf
-object Service "cluster-zone-satellite" {
- check_command = "cluster-zone"
- check_interval = 5s
- retry_interval = 1s
- vars.cluster_zone = "satellite"
+apply Dependency "agent-health-check" to Service {
+ parent_service_name = "agent-health"
- host_name = "icinga2-master1.localdomain"
+ states = [ OK ] // Fail if the parent service state switches to NOT-OK
+ disable_notifications = true
+
+ assign where host.zone == "satellite" && host.vars.agent_endpoint // Automatically assigns all agent endpoint checks as child services on the matched host
+ ignore where service.name == "agent-health" // Avoid a self reference from child to parent
}
```
-If you are using top down checks with command endpoint configuration, you can
-add a dependency which prevents notifications for all other failing services:
+This is all done on the configuration master, and requires the scenario to be fully up and running.
+
+#### Cluster Check
+
+The `cluster` check will check if all endpoints in the current zone and the directly
+connected zones are working properly. The disadvantage of using this check is that
+you cannot monitor 3 or more cluster levels with it.
```
-[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/dependencies.conf
+[root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/master
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-master1.localdomain.conf
-apply Dependency "health-check" to Service {
- parent_service_name = "child-health"
+object Host "icinga2-master1.localdomain" {
+ check_command = "hostalive"
+ address = "192.168.56.101"
+}
- states = [ OK ]
- disable_notifications = true
+[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/cluster.conf
- assign where host.vars.client_endpoint
- ignore where service.name == "child-health"
+object Service "cluster" {
+ check_command = "cluster"
+ check_interval = 5s
+ retry_interval = 1s
+
+ host_name = "icinga2-master1.localdomain"
}
```
@@ -2306,7 +2648,7 @@ C:\WINDOWS\system32>netsh advfirewall firewall add rule name="ICMP Allow incomin
#### Icinga 2 <a id="distributed-monitoring-windows-firewall-icinga2"></a>
-If your master/satellite nodes should actively connect to the Windows client
+If your master/satellite nodes should actively connect to the Windows agent
you'll also need to ensure that port `5665` is enabled.
```
@@ -2323,15 +2665,15 @@ C:\WINDOWS\system32>netsh advfirewall firewall add rule name="Open port 8443 (NS
```
For security reasons, it is advised to enable the NSClient++ HTTP API for local
-connection from the Icinga 2 client only. Remote connections to the HTTP API
+connection from the Icinga agent only. Remote connections to the HTTP API
are not recommended with using the legacy HTTP API.
-### Windows Client and Plugins <a id="distributed-monitoring-windows-plugins"></a>
+### Windows Agent and Plugins <a id="distributed-monitoring-windows-plugins"></a>
The Icinga 2 package on Windows already provides several plugins.
Detailed [documentation](10-icinga-template-library.md#windows-plugins) is available for all check command definitions.
-Add the following `include` statement on all your nodes (master, satellite, client):
+Add the following `include` statement on all your nodes (master, satellite, agent):
```
vim /etc/icinga2/icinga2.conf
@@ -2339,19 +2681,19 @@ vim /etc/icinga2/icinga2.conf
include <windows-plugins>
```
-Based on the [master with clients](06-distributed-monitoring.md#distributed-monitoring-master-clients)
+Based on the [master with agents](06-distributed-monitoring.md#distributed-monitoring-master-agents)
scenario we'll now add a local disk check.
-First, add the client node as host object:
+First, add the agent node as host object:
```
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf
-object Host "icinga2-client2.localdomain" {
+object Host "icinga2-agent2.localdomain" {
check_command = "hostalive"
address = "192.168.56.112"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
vars.os_type = "windows"
}
```
@@ -2368,9 +2710,9 @@ apply Service "disk C:" {
vars.disk_win_path = "C:"
//specify where the check is executed
- command_endpoint = host.vars.client_endpoint
+ command_endpoint = host.vars.agent_endpoint
- assign where host.vars.os_type == "windows" && host.vars.client_endpoint
+ assign where host.vars.os_type == "windows" && host.vars.agent_endpoint
}
```
@@ -2383,16 +2725,16 @@ Validate the configuration and restart Icinga 2.
Open Icinga Web 2 and check your newly added Windows disk check :)
-![Icinga 2 Client Windows](images/distributed-monitoring/icinga2_distributed_windows_client_disk_icingaweb2.png)
+![Icinga Windows Agent](images/distributed-monitoring/icinga2_distributed_windows_client_disk_icingaweb2.png)
If you want to add your own plugins please check [this chapter](05-service-monitoring.md#service-monitoring-requirements)
for the requirements.
-### Windows Client and NSClient++ <a id="distributed-monitoring-windows-nscp"></a>
+### Windows Agent and NSClient++ <a id="distributed-monitoring-windows-nscp"></a>
There are two methods available for querying NSClient++:
-* Query the [HTTP API](06-distributed-monitoring.md#distributed-monitoring-windows-nscp-check-api) locally from an Icinga 2 client (requires a running NSClient++ service)
+* Query the [HTTP API](06-distributed-monitoring.md#distributed-monitoring-windows-nscp-check-api) locally from an Icinga agent (requires a running NSClient++ service)
* Run a [local CLI check](06-distributed-monitoring.md#distributed-monitoring-windows-nscp-check-local) (does not require NSClient++ as a service)
Both methods have their advantages and disadvantages. One thing to
@@ -2401,30 +2743,31 @@ CPU utilization, please use the HTTP API instead of the CLI sample call.
#### NSCLient++ with check_nscp_api <a id="distributed-monitoring-windows-nscp-check-api"></a>
-The [Windows setup](06-distributed-monitoring.md#distributed-monitoring-setup-client-windows) already allows
+The [Windows setup](06-distributed-monitoring.md#distributed-monitoring-setup-agent-windows) already allows
you to install the NSClient++ package. In addition to the Windows plugins you can
use the [nscp_api command](10-icinga-template-library.md#nscp-check-api) provided by the Icinga Template Library (ITL).
The initial setup for the NSClient++ API and the required arguments
is the described in the ITL chapter for the [nscp_api](10-icinga-template-library.md#nscp-check-api) CheckCommand.
-Based on the [master with clients](06-distributed-monitoring.md#distributed-monitoring-master-clients)
+Based on the [master with agents](06-distributed-monitoring.md#distributed-monitoring-master-agents)
scenario we'll now add a local nscp check which queries the NSClient++ API to check the free disk space.
-Define a host object called `icinga2-client2.localdomain` on the master. Add the `nscp_api_password`
-custom attribute and specify the drives to check.
+Define a host object called `icinga2-agent2.localdomain` on the master. Add the `nscp_api_password`
+custom variable and specify the drives to check.
```
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf
-object Host "icinga2-client1.localdomain" {
-check_command = "hostalive"
-address = "192.168.56.111"
-vars.client_endpoint = name //follows the convention that host name == endpoint name
-vars.os_type = "Windows"
-vars.nscp_api_password = "icinga"
-vars.drives = [ "C:", "D:" ]
+object Host "icinga2-agent1.localdomain" {
+ check_command = "hostalive"
+ address = "192.168.56.111"
+
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
+ vars.os_type = "Windows"
+ vars.nscp_api_password = "icinga"
+ vars.drives = [ "C:", "D:" ]
}
```
@@ -2438,7 +2781,7 @@ apply Service "nscp-api-" for (drive in host.vars.drives) {
import "generic-service"
check_command = "nscp_api"
- command_endpoint = host.vars.client_endpoint
+ command_endpoint = host.vars.agent_endpoint
//display_name = "nscp-drive-" + drive
@@ -2460,14 +2803,14 @@ Validate the configuration and restart Icinga 2.
Two new services ("nscp-drive-D:" and "nscp-drive-C:") will be visible in Icinga Web 2.
-![Icinga 2 Distributed Monitoring Windows Client with NSClient++ nscp-api](images/distributed-monitoring/icinga2_distributed_windows_nscp_api_drivesize_icingaweb2.png)
+![Icinga 2 Distributed Monitoring Windows Agent with NSClient++ nscp-api](images/distributed-monitoring/icinga2_distributed_windows_nscp_api_drivesize_icingaweb2.png)
Note: You can also omit the `command_endpoint` configuration to execute
the command on the master. This also requires a different value for `nscp_api_host`
which defaults to `host.address`.
```
- //command_endpoint = host.vars.client_endpoint
+ //command_endpoint = host.vars.agent_endpoint
//vars.nscp_api_host = "localhost"
```
@@ -2481,13 +2824,14 @@ If you want to monitor specific Windows services, you could use the following ex
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf
-object Host "icinga2-client1.localdomain" {
-check_command = "hostalive"
-address = "192.168.56.111"
-vars.client_endpoint = name //follows the convention that host name == endpoint name
-vars.os_type = "Windows"
-vars.nscp_api_password = "icinga"
-vars.services = [ "Windows Update", "wscsvc" ]
+object Host "icinga2-agent1.localdomain" {
+ check_command = "hostalive"
+ address = "192.168.56.111"
+
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
+ vars.os_type = "Windows"
+ vars.nscp_api_password = "icinga"
+ vars.services = [ "Windows Update", "wscsvc" ]
}
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim services.conf
@@ -2496,7 +2840,7 @@ apply Service "nscp-api-" for (svc in host.vars.services) {
import "generic-service"
check_command = "nscp_api"
- command_endpoint = host.vars.client_endpoint
+ command_endpoint = host.vars.agent_endpoint
//display_name = "nscp-service-" + svc
@@ -2511,14 +2855,12 @@ apply Service "nscp-api-" for (svc in host.vars.services) {
#### NSCLient++ with nscp-local <a id="distributed-monitoring-windows-nscp-check-local"></a>
-The [Windows setup](06-distributed-monitoring.md#distributed-monitoring-setup-client-windows) already allows
-you to install the NSClient++ package. In addition to the Windows plugins you can
+The [Windows setup](06-distributed-monitoring.md#distributed-monitoring-setup-agent-windows) allows
+you to install the bundled NSClient++ package. In addition to the Windows plugins you can
use the [nscp-local commands](10-icinga-template-library.md#nscp-plugin-check-commands)
provided by the Icinga Template Library (ITL).
-![Icinga 2 Distributed Monitoring Windows Client with NSClient++](images/distributed-monitoring/icinga2_distributed_windows_nscp.png)
-
-Add the following `include` statement on all your nodes (master, satellite, client):
+Add the following `include` statement on all your nodes (master, satellite, agent):
```
vim /etc/icinga2/icinga2.conf
@@ -2529,19 +2871,20 @@ include <nscp>
The CheckCommand definitions will automatically determine the installed path
to the `nscp.exe` binary.
-Based on the [master with clients](06-distributed-monitoring.md#distributed-monitoring-master-clients)
+Based on the [master with agents](06-distributed-monitoring.md#distributed-monitoring-master-agents)
scenario we'll now add a local nscp check querying a given performance counter.
-First, add the client node as host object:
+First, add the agent node as host object:
```
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf
-object Host "icinga2-client1.localdomain" {
+object Host "icinga2-agent1.localdomain" {
check_command = "hostalive"
address = "192.168.56.111"
- vars.client_endpoint = name //follows the convention that host name == endpoint name
+
+ vars.agent_endpoint = name //follows the convention that host name == endpoint name
vars.os_type = "windows"
}
```
@@ -2554,7 +2897,7 @@ Next, add a performance counter check using command endpoint checks (details in
apply Service "nscp-local-counter-cpu" {
check_command = "nscp-local-counter"
- command_endpoint = host.vars.client_endpoint
+ command_endpoint = host.vars.agent_endpoint
vars.nscp_counter_name = "\\Processor(_total)\\% Processor Time"
vars.nscp_counter_perfsyntax = "Total Processor Time"
@@ -2563,7 +2906,7 @@ apply Service "nscp-local-counter-cpu" {
vars.nscp_counter_showall = true
- assign where host.vars.os_type == "windows" && host.vars.client_endpoint
+ assign where host.vars.os_type == "windows" && host.vars.agent_endpoint
}
```
@@ -2576,7 +2919,7 @@ Validate the configuration and restart Icinga 2.
Open Icinga Web 2 and check your newly added Windows NSClient++ check :)
-![Icinga 2 Distributed Monitoring Windows Client with NSClient++ nscp-local](images/distributed-monitoring/icinga2_distributed_windows_nscp_counter_icingaweb2.png)
+![Icinga 2 Distributed Monitoring Windows Agent with NSClient++ nscp-local](images/distributed-monitoring/icinga2_distributed_windows_nscp_counter_icingaweb2.png)
> **Tip**
>
@@ -2591,7 +2934,7 @@ with automating setups (setup, certificates, configuration).
### Certificate Auto-Renewal <a id="distributed-monitoring-certificate-auto-renewal"></a>
-Icinga 2 v2.8+ adds the possibility that nodes request certificate updates
+Icinga 2 v2.8+ added the possibility that nodes request certificate updates
on their own. If their expiration date is soon enough, they automatically
renew their already signed certificate by sending a signing request to the
parent node. You'll also see a message in the logs if certificate renewal
@@ -2606,6 +2949,12 @@ By default, the following features provide advanced HA functionality:
* [Checks](06-distributed-monitoring.md#distributed-monitoring-high-availability-checks) (load balanced, automated failover).
* [Notifications](06-distributed-monitoring.md#distributed-monitoring-high-availability-notifications) (load balanced, automated failover).
* [DB IDO](06-distributed-monitoring.md#distributed-monitoring-high-availability-db-ido) (Run-Once, automated failover).
+* [Elasticsearch](09-object-types.md#objecttype-elasticsearchwriter)
+* [Gelf](09-object-types.md#objecttype-gelfwriter)
+* [Graphite](09-object-types.md#objecttype-graphitewriter)
+* [InfluxDB](09-object-types.md#objecttype-influxdbwriter)
+* [OpenTsdb](09-object-types.md#objecttype-opentsdbwriter)
+* [Perfdata](09-object-types.md#objecttype-perfdatawriter) (for PNP)
#### High-Availability with Checks <a id="distributed-monitoring-high-availability-checks"></a>
@@ -2682,42 +3031,43 @@ data duplication in split-brain-scenarios. The failover timeout can be set for t
### Endpoint Connection Direction <a id="distributed-monitoring-advanced-hints-connection-direction"></a>
-Nodes will attempt to connect to another node when its local [Endpoint](09-object-types.md#objecttype-endpoint) object
+Endpoints attempt to connect to another endpoint when its local [Endpoint](09-object-types.md#objecttype-endpoint) object
configuration specifies a valid `host` attribute (FQDN or IP address).
Example for the master node `icinga2-master1.localdomain` actively connecting
-to the client node `icinga2-client1.localdomain`:
+to the agent node `icinga2-agent1.localdomain`:
```
[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.conf
//...
-object Endpoint "icinga2-client1.localdomain" {
- host = "192.168.56.111" //the master actively tries to connect to the client
- log_duration = 0
+object Endpoint "icinga2-agent1.localdomain" {
+ host = "192.168.56.111" // The master actively tries to connect to the agent
+ log_duration = 0 // Disable the replay log for command endpoint agents
}
```
-Example for the client node `icinga2-client1.localdomain` not actively
+Example for the agent node `icinga2-agent1.localdomain` not actively
connecting to the master node `icinga2-master1.localdomain`:
```
-[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent1.localdomain /]# vim /etc/icinga2/zones.conf
//...
object Endpoint "icinga2-master1.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
- log_duration = 0
+ // Do not actively connect to the master by leaving out the 'host' attribute
+ log_duration = 0 // Disable the replay log for command endpoint agents
}
```
-It is not necessary that both the master and the client node establish
+It is not necessary that both the master and the agent node establish
two connections to each other. Icinga 2 will only use one connection
-and close the second connection if established.
+and close the second connection if established. This generates useless
+CPU cycles and leads to blocking resources when the connection times out.
-**Tip**: Choose either to let master/satellite nodes connect to client nodes
+**Tip**: Choose either to let master/satellite nodes connect to agent nodes
or vice versa.
@@ -2728,12 +3078,12 @@ keep the same history (check results, notifications, etc.) when nodes are tempor
disconnected and then reconnect.
This functionality is not needed when a master/satellite node is sending check
-execution events to a client which is purely configured for [command endpoint](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)
-checks only.
+execution events to an agent which is configured as [command endpoint](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)
+for check execution.
The [Endpoint](09-object-types.md#objecttype-endpoint) object attribute `log_duration` can
be lower or set to 0 to fully disable any log replay updates when the
-client is not connected.
+agent is not connected.
Configuration on the master node `icinga2-master1.localdomain`:
@@ -2742,37 +3092,44 @@ Configuration on the master node `icinga2-master1.localdomain`:
//...
-object Endpoint "icinga2-client1.localdomain" {
- host = "192.168.56.111" //the master actively tries to connect to the client
+object Endpoint "icinga2-agent1.localdomain" {
+ host = "192.168.56.111" // The master actively tries to connect to the agent
log_duration = 0
}
-object Endpoint "icinga2-client2.localdomain" {
- host = "192.168.56.112" //the master actively tries to connect to the client
+object Endpoint "icinga2-agent2.localdomain" {
+ host = "192.168.56.112" // The master actively tries to connect to the agent
log_duration = 0
}
```
-Configuration on the client `icinga2-client1.localdomain`:
+Configuration on the agent `icinga2-agent1.localdomain`:
```
-[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
+[root@icinga2-agent1.localdomain /]# vim /etc/icinga2/zones.conf
//...
object Endpoint "icinga2-master1.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
+ // Do not actively connect to the master by leaving out the 'host' attribute
log_duration = 0
}
object Endpoint "icinga2-master2.localdomain" {
- //do not actively connect to the master by leaving out the 'host' attribute
+ // Do not actively connect to the master by leaving out the 'host' attribute
log_duration = 0
}
```
### Initial Sync for new Endpoints in a Zone <a id="distributed-monitoring-advanced-hints-initial-sync"></a>
+> **Note**
+>
+> This is required if you decide to change an already running single endpoint production
+> environment into a HA-enabled cluster zone with two endpoints.
+> The [initial setup](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-clients)
+> with 2 HA masters doesn't require this step.
+
In order to make sure that all of your zone endpoints have the same state you need
to pick the authoritative running one and copy the following content:
@@ -2780,8 +3137,11 @@ to pick the authoritative running one and copy the following content:
* Internal config package for runtime created objects (downtimes, comments, hosts, etc.) at `/var/lib/icinga2/api/packages/_api`
If you need already deployed config packages from the Director, or synced cluster zones,
-you can also sync the entire `/var/lib/icinga2` directory. This directory should also be
-included in your [backup strategy](02-getting-started.md#install-backup).
+you can also sync the entire `/var/lib/icinga2/api/packages` directory. This directory should also be
+included in your [backup strategy](02-installation.md#install-backup).
+
+Do **not** sync `/var/lib/icinga2/api/zones*` manually - this is an internal directory
+and handled by the Icinga cluster config sync itself.
> **Note**
>
@@ -2879,7 +3239,7 @@ This will tremendously help when someone is trying to help in the [community cha
### Silent Windows Setup <a id="distributed-monitoring-automation-windows-silent"></a>
-If you want to install the client silently/unattended, use the `/qn` modifier. The
+If you want to install the agent silently/unattended, use the `/qn` modifier. The
installation should not trigger a restart, but if you want to be completely sure, you can use the `/norestart` modifier.
```
@@ -2928,15 +3288,17 @@ In case you don't need anything in `conf.d`, use the following command line:
[root@icinga2-master1.localdomain /]# icinga2 node setup --master --disable-confd
```
+<!-- Keep this for compatibility -->
+<a id="distributed-monitoring-automation-cli-node-setup-satellite-client"></a>
-#### Node Setup with Satellites/Clients <a id="distributed-monitoring-automation-cli-node-setup-satellite-client"></a>
+#### Node Setup with Agents/Satellites <a id="distributed-monitoring-automation-cli-node-setup-agent-satellite"></a>
Make sure that the `/var/lib/icinga2/certs` directory exists and is owned by the `icinga`
user (or the user Icinga 2 is running as).
```
-[root@icinga2-client1.localdomain /]# mkdir -p /var/lib/icinga2/certs
-[root@icinga2-client1.localdomain /]# chown -R icinga:icinga /var/lib/icinga2/certs
+[root@icinga2-agent1.localdomain /]# mkdir -p /var/lib/icinga2/certs
+[root@icinga2-agent1.localdomain /]# chown -R icinga:icinga /var/lib/icinga2/certs
```
First you'll need to generate a new local self-signed certificate.
@@ -2950,9 +3312,9 @@ Pass the following details to the `pki new-cert` CLI command:
Example:
```
-[root@icinga2-client1.localdomain /]# icinga2 pki new-cert --cn icinga2-client1.localdomain \
---key /var/lib/icinga2/certs/icinga2-client1.localdomain.key \
---cert /var/lib/icinga2/certs/icinga2-client1.localdomain.crt
+[root@icinga2-agent1.localdomain /]# icinga2 pki new-cert --cn icinga2-agent1.localdomain \
+--key /var/lib/icinga2/certs/icinga2-agent1.localdomain.key \
+--cert /var/lib/icinga2/certs/icinga2-agent1.localdomain.crt
```
Request the master certificate from the master host (`icinga2-master1.localdomain`)
@@ -2969,13 +3331,13 @@ Pass the following details to the `pki save-cert` CLI command:
Example:
```
-[root@icinga2-client1.localdomain /]# icinga2 pki save-cert --key /var/lib/icinga2/certs/icinga2-client1.localdomain.key \
---cert /var/lib/icinga2/certs/icinga2-client1.localdomain.crt \
+[root@icinga2-agent1.localdomain /]# icinga2 pki save-cert --key /var/lib/icinga2/certs/icinga2-agent1.localdomain.key \
+--cert /var/lib/icinga2/certs/icinga2-agent1.localdomain.crt \
--trustedcert /var/lib/icinga2/certs/trusted-parent.crt \
--host icinga2-master1.localdomain
```
-Continue with the additional node setup step. Specify a local endpoint and zone name (`icinga2-client1.localdomain`)
+Continue with the additional node setup step. Specify a local endpoint and zone name (`icinga2-agent1.localdomain`)
and set the master host (`icinga2-master1.localdomain`) as parent zone configuration. Specify the path to
the previously stored trusted master certificate.
@@ -2988,7 +3350,7 @@ Pass the following details to the `node setup` CLI command:
Trusted master certificate | **Required.** Add the previously fetched trusted master certificate (this step means that you've verified its origin).
Parent host | **Optional.** FQDN or IP address of the parent host. This is where the command connects for CSR signing. If not specified, you need to manually copy the parent's public CA certificate file into `/var/lib/icinga2/certs/ca.crt` in order to start Icinga 2.
Parent endpoint | **Required.** Specify the parent's endpoint name.
- Client zone name | **Required.** Specify the client's zone name.
+ Local zone name | **Required.** Specify the agent/satellite zone name.
Parent zone name | **Optional.** Specify the parent's zone name.
Accept config | **Optional.** Whether this node accepts configuration sync from the master node (required for [config sync mode](06-distributed-monitoring.md#distributed-monitoring-top-down-config-sync)).
Accept commands | **Optional.** Whether this node accepts command execution messages from the master node (required for [command endpoint mode](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)).
@@ -2997,15 +3359,15 @@ Pass the following details to the `node setup` CLI command:
> **Note**
>
-> The `master_host` parameter is deprecated and will be removed in 2.10.0. Please use `--parent_host` instead.
+> The `master_host` parameter is deprecated and will be removed. Please use `--parent_host` instead.
-Example for Icinga 2 v2.9:
+Example:
```
-[root@icinga2-client1.localdomain /]# icinga2 node setup --ticket ead2d570e18c78abf285d6b85524970a0f69c22d \
---cn icinga2-client1.localdomain \
+[root@icinga2-agent1.localdomain /]# icinga2 node setup --ticket ead2d570e18c78abf285d6b85524970a0f69c22d \
+--cn icinga2-agent1.localdomain \
--endpoint icinga2-master1.localdomain \
---zone icinga2-client1.localdomain \
+--zone icinga2-agent1.localdomain \
--parent_zone master \
--parent_host icinga2-master1.localdomain \
--trustedcert /var/lib/icinga2/certs/trusted-parent.crt \
@@ -3013,7 +3375,7 @@ Example for Icinga 2 v2.9:
--disable-confd
```
-In case the client should connect to the master node, you'll
+In case the agent/satellite should connect to the master node, you'll
need to modify the `--endpoint` parameter using the format `cn,host,port`:
```
@@ -3021,13 +3383,13 @@ need to modify the `--endpoint` parameter using the format `cn,host,port`:
```
Specify the parent zone using the `--parent_zone` parameter. This is useful
-if the client connects to a satellite, not the master instance.
+if the agent connects to a satellite, not the master instance.
```
--parent_zone satellite
```
-In case the client should know the additional global zone `linux-templates`, you'll
+In case the agent should know the additional global zone `linux-templates`, you'll
need to set the `--global-zones` parameter.
```
@@ -3038,7 +3400,7 @@ The `--parent-host` parameter is optional since v2.9 and allows you to perform a
You cannot restart Icinga 2 yet, the CLI command asked to to manually copy the parent's public CA
certificate file in `/var/lib/icinga2/certs/ca.crt`. Once Icinga 2 is started, it sends
a ticket signing request to the parent node. If you have provided a ticket, the master node
-signs the request and sends it back to the client which performs a certificate update in-memory.
+signs the request and sends it back to the agent/satellite which performs a certificate update in-memory.
In case you did not provide a ticket, you need to manually sign the CSR on the master node
which holds the CA's key pair.
@@ -3046,18 +3408,18 @@ which holds the CA's key pair.
**You can find additional best practices below.**
-If this client node is configured as [remote command endpoint execution](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)
+If this agent node is configured as [remote command endpoint execution](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)
you can safely disable the `checker` feature. The `node setup` CLI command already disabled the `notification` feature.
```
-[root@icinga2-client1.localdomain /]# icinga2 feature disable checker
+[root@icinga2-agent1.localdomain /]# icinga2 feature disable checker
```
Disable "conf.d" inclusion if this is a [top down](06-distributed-monitoring.md#distributed-monitoring-top-down)
-configured client.
+configured agent.
```
-[root@icinga2-client1.localdomain /]# sed -i 's/include_recursive "conf.d"/\/\/include_recursive "conf.d"/g' /etc/icinga2/icinga2.conf
+[root@icinga2-agent1.localdomain /]# sed -i 's/include_recursive "conf.d"/\/\/include_recursive "conf.d"/g' /etc/icinga2/icinga2.conf
```
**Note**: This is the default since v2.9.
@@ -3065,9 +3427,9 @@ configured client.
**Optional**: Add an ApiUser object configuration for remote troubleshooting.
```
-[root@icinga2-client1.localdomain /]# cat <<EOF >/etc/icinga2/conf.d/api-users.conf
+[root@icinga2-agent1.localdomain /]# cat <<EOF >/etc/icinga2/conf.d/api-users.conf
object ApiUser "root" {
- password = "clientsupersecretpassword"
+ password = "agentsupersecretpassword"
permissions = ["*"]
}
EOF
@@ -3077,25 +3439,25 @@ In case you've previously disabled the "conf.d" directory only
add the file file `conf.d/api-users.conf`:
```
-[root@icinga2-client1.localdomain /]# echo 'include "conf.d/api-users.conf"' >> /etc/icinga2/icinga2.conf
+[root@icinga2-agent1.localdomain /]# echo 'include "conf.d/api-users.conf"' >> /etc/icinga2/icinga2.conf
```
Finally restart Icinga 2.
```
-[root@icinga2-client1.localdomain /]# systemctl restart icinga2
+[root@icinga2-agent1.localdomain /]# systemctl restart icinga2
```
Your automation tool must then configure master node in the meantime.
```
# cat <<EOF >>/etc/icinga2/zones.conf
-object Endpoint "icinga2-client1.localdomain" {
- //client connects itself
+object Endpoint "icinga2-agent1.localdomain" {
+ // Agent connects itself
}
-object Zone "icinga2-client1.localdomain" {
- endpoints = [ "icinga2-client1.localdomain" ]
+object Zone "icinga2-agent1.localdomain" {
+ endpoints = [ "icinga2-agent1.localdomain" ]
parent = "master"
}
@@ -3104,6 +3466,10 @@ EOF
## Using Multiple Environments <a id="distributed-monitoring-environments"></a>
+> **Note**
+>
+> This documentation only covers the basics. Full functionality requires a not yet released addon.
+
In some cases it can be desired to run multiple Icinga instances on the same host.
Two potential scenarios include:
@@ -3124,11 +3490,11 @@ When Icinga establishes a TLS connection to another cluster instance it automati
to signal which endpoint it is attempting to connect to. On its own this can already be used to position multiple
Icinga instances behind a load balancer.
-SNI example: `icinga2-client1.localdomain`
+SNI example: `icinga2-agent1.localdomain`
However, if the environment is configured to `production`, Icinga appends the environment name to the SNI hostname like this:
-SNI example with environment: `icinga2-client1.localdomain:production`
+SNI example with environment: `icinga2-agent1.localdomain:production`
Middleware like loadbalancers or TLS proxies can read the SNI header and route the connection to the appropriate target.
I.e., it uses a single externally-visible TCP port (usually 5665) and forwards connections to one or more Icinga
diff --git a/doc/07-agent-based-monitoring.md b/doc/07-agent-based-monitoring.md
index 99e4615..5355ac7 100644
--- a/doc/07-agent-based-monitoring.md
+++ b/doc/07-agent-based-monitoring.md
@@ -7,13 +7,13 @@ become handy.
## SNMP <a id="agent-based-checks-snmp"></a>
The SNMP daemon runs on the remote system and answers SNMP queries by plugin
-binaries. The [Monitoring Plugins package](02-getting-started.md#setting-up-check-plugins) ships
+binaries. The [Monitoring Plugins package](02-installation.md#setting-up-check-plugins) ships
the `check_snmp` plugin binary, but there are plenty of [existing plugins](05-service-monitoring.md#service-monitoring-plugins)
for specific use cases already around, for example monitoring Cisco routers.
The following example uses the [SNMP ITL](10-icinga-template-library.md#plugin-check-command-snmp) `CheckCommand` and just
-overrides the `snmp_oid` custom attribute. A service is created for all hosts which
-have the `snmp-community` custom attribute.
+overrides the `snmp_oid` custom variable. A service is created for all hosts which
+have the `snmp-community` custom variable.
```
apply Service "uptime" {
@@ -37,7 +37,7 @@ As such, it is recommended to always specify at least one `MIB`.
Calling a plugin using the SSH protocol to execute a plugin on the remote server fetching
its return code and output. The `by_ssh` command object is part of the built-in templates and
-requires the `check_by_ssh` check plugin which is available in the [Monitoring Plugins package](02-getting-started.md#setting-up-check-plugins).
+requires the `check_by_ssh` check plugin which is available in the [Monitoring Plugins package](02-installation.md#setting-up-check-plugins).
```
object CheckCommand "by_ssh_swap" {
diff --git a/doc/08-advanced-topics.md b/doc/08-advanced-topics.md
index a7acb95..d58558b 100644
--- a/doc/08-advanced-topics.md
+++ b/doc/08-advanced-topics.md
@@ -255,6 +255,8 @@ object TimePeriod "workhours" {
}
```
+### Across midnight <a id="timeperiods-across-midnight"></a>
+
If you want to specify a notification period across midnight,
you can define it the following way:
@@ -268,6 +270,21 @@ object Timeperiod "across-midnight" {
}
```
+Starting with v2.11 this can be shortened to using
+the first day as start with an overlapping range into
+the next day:
+
+```
+object Timeperiod "do-not-disturb" {
+ display_name = "Weekend DND"
+ ranges = {
+ "saturday" = "22:00-06:00"
+ }
+}
+```
+
+### Across several days, weeks or months <a id="timeperiods-across-days-weeks-months"></a>
+
Below you can see another example for configuring timeperiods across several
days, weeks or months. This can be useful when taking components offline
for a distinct period of time.
@@ -570,7 +587,7 @@ You might also want to add additional checks for SSL certificate expiration.
[Apply rules](03-monitoring-basics.md#using-apply) can be used to create a rule set which is
entirely based on host objects and their attributes.
-In addition to that [apply for and custom attribute override](03-monitoring-basics.md#using-apply-for)
+In addition to that [apply for and custom variable override](03-monitoring-basics.md#using-apply-for)
extend the possibilities.
The following example defines a dictionary on the host object which contains
@@ -647,7 +664,7 @@ apply Service "webserver_url" for (instance => config in host.vars.webserver.ins
}
```
-The variables defined in the host dictionary are not using the typical custom attribute
+The variables defined in the host dictionary are not using the typical custom variable
prefix recommended for CheckCommand parameters. Instead they are re-used for multiple
service checks in this example.
In addition to defining check parameters this way, you can also enrich the `display_name`
@@ -657,7 +674,7 @@ attribute with more details. This will be shown in in Icinga Web 2 for example.
There is a limited scope where functions can be used as object attributes such as:
-* As value for [Custom Attributes](03-monitoring-basics.md#custom-attributes-functions)
+* As value for [Custom Variables](03-monitoring-basics.md#custom-variables-functions)
* Returning boolean expressions for [set_if](08-advanced-topics.md#use-functions-command-arguments-setif) inside command arguments
* Returning a [command](08-advanced-topics.md#use-functions-command-attribute) array inside command objects
@@ -666,7 +683,7 @@ The other way around you can create objects dynamically using your own global fu
> **Note**
>
> Functions called inside command objects share the same global scope as runtime macros.
-> Therefore you can access host custom attributes like `host.vars.os`, or any other
+> Therefore you can access host custom variables like `host.vars.os`, or any other
> object attribute from inside the function definition used for [set_if](08-advanced-topics.md#use-functions-command-arguments-setif) or [command](08-advanced-topics.md#use-functions-command-attribute).
Tips when implementing functions:
@@ -682,7 +699,7 @@ inside the `icinga2.log` file depending in your log severity
in objects and other functions. Keep in mind that these functions are not marked
as side-effect-free and as such are not available via the REST API.
-Add a new configuration file `functions.conf` and include it into the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf)
+Add a new configuration file `functions.conf` and include it into the [icinga2.conf](04-configuration.md#icinga2-conf)
configuration file in the very beginning, e.g. after `constants.conf`. You can also manage global
functions inside `constants.conf` if you prefer.
@@ -722,7 +739,7 @@ to connect to the REST API.
```
$ ICINGA2_API_PASSWORD=icinga icinga2 console --connect 'https://root@localhost:5665/'
-Icinga 2 (version: v2.8.1-373-g4bea6d25c)
+Icinga 2 (version: v2.11.0)
<1> => globals.state_to_string(1)
"Warning"
<2> => state_to_string(2)
@@ -833,7 +850,7 @@ object HostGroup "printers-lexmark" {
```
Take a different more complex example: All hosts with the
-custom attribute `vars_app` as nested dictionary should be
+custom variable `vars_app` as nested dictionary should be
added to the host group `ABAP-app-server`. But only if the
`app_type` for all entries is set to `ABAP`.
@@ -858,7 +875,7 @@ object Host "appserver02" {
}
globals.check_app_type = function(host, type) {
- /* ensure that other hosts without the custom attribute do not match */
+ /* ensure that other hosts without the custom variable do not match */
if (typeof(host.vars.vars_app) != Dictionary) {
return false
}
@@ -907,7 +924,7 @@ The more significant problem was to only add the command parameter `--disk` to t
when the dictionary `compellent` contains the key `disks`, and omit it if not found.
By defining `set_if` as [abbreviated lambda function](17-language-reference.md#nullary-lambdas)
-and evaluating the host custom attribute `compellent` containing the `disks` this problem was
+and evaluating the host custom variable `compellent` containing the `disks` this problem was
solved like this:
```
@@ -955,11 +972,11 @@ The more programmatic approach for `set_if` could look like this:
if (typeof(srv_vars.compellent) == Dictionary) {
return srv_vars.compellent.contains("disks")
} else {
- log(LogInformationen, "checkcommand set_if", "custom attribute compellent_checks is not a dictionary, ignoring it.")
+ log(LogInformationen, "checkcommand set_if", "custom variable compellent_checks is not a dictionary, ignoring it.")
return false
}
} else {
- log(LogWarning, "checkcommand set_if", "empty custom attributes")
+ log(LogWarning, "checkcommand set_if", "empty custom variables")
return false
}
}}
@@ -973,7 +990,7 @@ or [EventCommands](09-object-types.md#objecttype-eventcommand) which does not re
a returned checkresult including state/output.
The following example was taken from the community support channels. The requirement was to
-specify a custom attribute inside the notification apply rule and decide which notification
+specify a custom variable inside the notification apply rule and decide which notification
script to call based on that.
```
@@ -996,7 +1013,7 @@ apply Notification "mail-admins-short" to Host {
The solution is fairly simple: The `command` attribute is implemented as function returning
an array required by the caller Icinga 2.
The local variable `mailscript` sets the default value for the notification scrip location.
-If the notification custom attribute `short` is set, it will override the local variable `mailscript`
+If the notification custom variable `short` is set, it will override the local variable `mailscript`
with a new value.
The `mailscript` variable is then used to compute the final notification command array being
returned.
@@ -1170,3 +1187,16 @@ Icinga 2 parses performance data strings returned by check plugins and makes the
warn | Value | Warning threshold value.
min | Value | Minimum value returned by the check.
max | Value | Maximum value returned by the check.
+
+### NotificationResult <a id="advanced-value-types-notificationresult"></a>
+
+ Name | Type | Description
+ --------------------------|-----------------------|----------------------------------
+ exit\_status | Number | The exit status returned by the check execution.
+ output | String | The notification command output.
+ execution\_endpoint | String | Name of the node executing the check.
+ command | Value | Array of command with shell-escaped arguments or command line string.
+ execution\_start | Timestamp | Check execution start time (as a UNIX timestamp).
+ execution\_end | Timestamp | Check execution end time (as a UNIX timestamp).
+ active | Boolean | Whether the result is from an active or passive check.
+
diff --git a/doc/09-object-types.md b/doc/09-object-types.md
index dc21013..27e475f 100644
--- a/doc/09-object-types.md
+++ b/doc/09-object-types.md
@@ -63,7 +63,7 @@ chapter.
### CheckCommand <a id="objecttype-checkcommand"></a>
-A check command definition. Additional default command custom attributes can be
+A check command definition. Additional default command custom variables can be
defined here.
Example:
@@ -108,7 +108,7 @@ Configuration Attributes:
--------------------------|-----------------------|----------------------------------
command | Array | **Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command. When using the "arguments" attribute this must be an array. Can be specified as function for advanced implementations.
env | Dictionary | **Optional.** A dictionary of macros which should be exported as environment variables prior to executing the command.
- vars | Dictionary | **Optional.** A dictionary containing custom attributes that are specific to this command.
+ vars | Dictionary | **Optional.** A dictionary containing custom variables that are specific to this command.
timeout | Duration | **Optional.** The command timeout in seconds. Defaults to `1m`.
arguments | Dictionary | **Optional.** A dictionary of command arguments.
@@ -116,79 +116,39 @@ Configuration Attributes:
#### CheckCommand Arguments <a id="objecttype-checkcommand-arguments"></a>
Command arguments can be defined as key-value-pairs in the `arguments`
-dictionary. If the argument requires additional configuration, for example
-a `description` attribute or an optional condition, the value can be defined
-as dictionary specifying additional options.
-
-Service:
-
-```
-vars.x_val = "My command argument value."
-vars.have_x = "true"
-```
-
-CheckCommand:
+dictionary. Best practice is to assign a dictionary as value which
+provides additional details such as the `description` next to the `value`.
```
-arguments = {
- "-X" = {
- value = "$x_val$"
- key = "-Xnew" /* optional, set a new key identifier */
- description = "My plugin requires this argument for doing X."
- required = false /* optional, no error if not set */
- skip_key = false /* always use "-X <value>" */
- set_if = "$have_x$" /* only set if variable defined and resolves to a numeric value. String values are not supported */
- order = -1 /* first position */
- repeat_key = true /* if `value` is an array, repeat the key as parameter: ... 'key' 'value[0]' 'key' 'value[1]' 'key' 'value[2]' ... */
- }
- "-Y" = {
- value = "$y_val$"
- description = "My plugin requires this argument for doing Y."
- required = false /* optional, no error if not set */
- skip_key = true /* don't prefix "-Y" only use "<value>" */
- set_if = "$have_y$" /* only set if variable defined and resolves to a numeric value. String values are not supported */
- order = 0 /* second position */
- repeat_key = false /* if `value` is an array, do not repeat the key as parameter: ... 'key' 'value[0]' 'value[1]' 'value[2]' ... */
+ arguments = {
+ "--parameter" = {
+ description = "..."
+ value = "..."
+ }
}
-}
```
+All available argument value entries are shown below:
+
Name | Type | Description
--------------------------|-----------------------|----------------------------------
- value | String/Function | Optional argument value set by a [runtime macro string](03-monitoring-basics.md#runtime-macros) or a [function call](17-language-reference.md#functions).
- key | String | Optional argument key overriding the key identifier.
- description | String | Optional argument description.
- required | Boolean | Required argument. Execution error if not set. Defaults to false (optional).
- skip\_key | Boolean | Use the value as argument and skip the key.
- set\_if | String/Function | Argument is added if the [runtime macro string](03-monitoring-basics.md#runtime-macros) resolves to a defined numeric or boolean value. String values are not supported. [Function calls](17-language-reference.md#functions) returning a value are supported too.
- order | Number | Set if multiple arguments require a defined argument order.
- repeat\_key | Boolean | If the argument value is an array, repeat the argument key, or not. Defaults to true (repeat).
+ value | String/Function | Optional argument value set by a [runtime macro string](03-monitoring-basics.md#runtime-macros) or a [function call](17-language-reference.md#functions). [More details](03-monitoring-basics.md#command-arguments-value).
+ description | String | Optional argument description. [More details](03-monitoring-basics.md#command-arguments-description).
+ required | Boolean | Required argument. Execution error if not set. Defaults to false (optional). [More details](03-monitoring-basics.md#command-arguments-required).
+ skip\_key | Boolean | Use the value as argument and skip the key. [More details](03-monitoring-basics.md#command-arguments-skip-key).
+ set\_if | String/Function | Argument is added if the [runtime macro string](03-monitoring-basics.md#runtime-macros) resolves to a defined numeric or boolean value. String values are not supported. [Function calls](17-language-reference.md#functions) returning a value are supported too. [More details](03-monitoring-basics.md#command-arguments-set-if).
+ order | Number | Set if multiple arguments require a defined argument order. The syntax is `..., -3, -2, -1, <un-ordered keys>, 1, 2, 3, ...`. [More details](03-monitoring-basics.md#command-arguments-order).
+ repeat\_key | Boolean | If the argument value is an array, repeat the argument key, or not. Defaults to true (repeat). [More details](03-monitoring-basics.md#command-arguments-repeat-key).
+ key | String | Optional argument key overriding the key identifier. [More details](03-monitoring-basics.md#command-arguments-key).
-Argument order:
+`value` and `description` are commonly used, the other entries allow
+to build more advanced CheckCommand objects and arguments.
-```
-..., -3, -2, -1, <un-ordered keys>, 1, 2, 3, ...
-```
-
-Define argument array:
+Please continue reading [here](03-monitoring-basics.md#command-arguments) for advanced usage and examples
+for command arguments.
-```
-value = "[ 'one', 'two', 'three' ]"
-```
-
-Argument array with `repeat_key = true`:
-
-```
-'key' 'value[0]' 'key' 'value[1]' 'key' 'value[2]'
-```
-Argument array with `repeat_key = false`:
-
-```
-'key' 'value[0]' 'value[1]' 'value[2]'
-```
-
-## Dependency <a id="objecttype-dependency"></a>
+### Dependency <a id="objecttype-dependency"></a>
Dependency objects are used to specify dependencies between hosts and services. Dependencies
can be defined as Host-to-Host, Service-to-Service, Service-to-Host, or Host-to-Service
@@ -294,7 +254,7 @@ Dependency objects have composite names, i.e. their names are based on the `chil
name you specified. This means you can define more than one object with the same (short) name as long as one of the `child_host_name` and
`child_service_name` attributes has a different value.
-## Endpoint <a id="objecttype-endpoint"></a>
+### Endpoint <a id="objecttype-endpoint"></a>
Endpoint objects are used to specify connection information for remote
Icinga 2 instances. More details can be found in the [distributed monitoring chapter](06-distributed-monitoring.md#distributed-monitoring).
@@ -302,7 +262,7 @@ Icinga 2 instances. More details can be found in the [distributed monitoring cha
Example:
```
-object Endpoint "icinga2-client1.localdomain" {
+object Endpoint "icinga2-agent1.localdomain" {
host = "192.168.56.111"
port = 5665
log_duration = 1d
@@ -312,7 +272,7 @@ object Endpoint "icinga2-client1.localdomain" {
Example (disable replay log):
```
-object Endpoint "icinga2-client1.localdomain" {
+object Endpoint "icinga2-agent1.localdomain" {
host = "192.168.5.111"
port = 5665
log_duration = 0
@@ -329,7 +289,7 @@ Configuration Attributes:
Endpoint objects cannot currently be created with the API.
-## EventCommand <a id="objecttype-eventcommand"></a>
+### EventCommand <a id="objecttype-eventcommand"></a>
An event command definition.
@@ -348,7 +308,7 @@ Configuration Attributes:
--------------------------|-----------------------|----------------------------------
command | Array | **Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command. When using the "arguments" attribute this must be an array. Can be specified as function for advanced implementations.
env | Dictionary | **Optional.** A dictionary of macros which should be exported as environment variables prior to executing the command.
- vars | Dictionary | **Optional.** A dictionary containing custom attributes that are specific to this command.
+ vars | Dictionary | **Optional.** A dictionary containing custom variables that are specific to this command.
timeout | Duration | **Optional.** The command timeout in seconds. Defaults to `1m`.
arguments | Dictionary | **Optional.** A dictionary of command arguments.
@@ -357,14 +317,14 @@ Command arguments can be used the same way as for [CheckCommand objects](09-obje
More advanced examples for event command usage can be found [here](03-monitoring-basics.md#event-commands).
-## Host <a id="objecttype-host"></a>
+### Host <a id="objecttype-host"></a>
A host.
Example:
```
-object Host "icinga2-client1.localdomain" {
+object Host "icinga2-agent1.localdomain" {
display_name = "Linux Client 1"
address = "192.168.56.111"
address6 = "2a00:1450:4001:815::2003"
@@ -383,10 +343,10 @@ Configuration Attributes:
address | String | **Optional.** The host's IPv4 address. Available as command runtime macro `$address$` if set.
address6 | String | **Optional.** The host's IPv6 address. Available as command runtime macro `$address6$` if set.
groups | Array of object names | **Optional.** A list of host groups this host belongs to.
- vars | Dictionary | **Optional.** A dictionary containing custom attributes that are specific to this host.
+ vars | Dictionary | **Optional.** A dictionary containing custom variables that are specific to this host.
check\_command | Object name | **Required.** The name of the check command.
max\_check\_attempts | Number | **Optional.** The number of times a host is re-checked before changing into a hard state. Defaults to 3.
- check\_period | Object name | **Optional.** The name of a time period which determines when this host should be checked. Not set by default.
+ check\_period | Object name | **Optional.** The name of a time period which determines when this host should be checked. Not set by default (effectively 24x7).
check\_timeout | Duration | **Optional.** Check command timeout in seconds. Overrides the CheckCommand's `timeout` attribute.
check\_interval | Duration | **Optional.** The check interval (in seconds). This interval is used for checks when the host is in a `HARD` state. Defaults to `5m`.
retry\_interval | Duration | **Optional.** The retry interval (in seconds). This interval is used for checks when the host is in a `SOFT` state. Defaults to `1m`. Note: This does not affect the scheduling [after a passive check result](08-advanced-topics.md#check-result-freshness).
@@ -441,10 +401,15 @@ Runtime Attributes:
last\_hard\_state | Number | The last hard state (0 = UP, 1 = DOWN).
last\_state\_up | Timestamp | When the last UP state occurred (as a UNIX timestamp).
last\_state\_down | Timestamp | When the last DOWN state occurred (as a UNIX timestamp).
+ last\_state\_unreachable | Timestamp | When the host was unreachable the last time (as a UNIX timestamp).
+ previous\_state\_change | Timestamp | Previous timestamp of `last_state_change` before processing a new check result.
+ severity | Number | [Severity](19-technical-concepts.md#technical-concepts-checks-severity) calculated value.
+ problem | Boolean | Whether the host is considered in a problem state type (NOT-UP).
+ handled | Boolean | Whether the host problem is handled (downtime or acknowledgement).
-## HostGroup <a id="objecttype-hostgroup"></a>
+### HostGroup <a id="objecttype-hostgroup"></a>
A group of hosts.
@@ -471,7 +436,7 @@ Configuration Attributes:
-## Notification <a id="objecttype-notification"></a>
+### Notification <a id="objecttype-notification"></a>
Notification objects are used to specify how users should be notified in case
of host and service state changes and other events.
@@ -506,13 +471,13 @@ Configuration Attributes:
--------------------------|-----------------------|----------------------------------
host\_name | Object name | **Required.** The name of the host this notification belongs to.
service\_name | Object name | **Optional.** The short name of the service this notification belongs to. If omitted, this notification object is treated as host notification.
- vars | Dictionary | **Optional.** A dictionary containing custom attributes that are specific to this notification object.
+ vars | Dictionary | **Optional.** A dictionary containing custom variables that are specific to this notification object.
users | Array of object names | **Required.** A list of user names who should be notified. **Optional.** if the `user_groups` attribute is set.
user\_groups | Array of object names | **Required.** A list of user group names who should be notified. **Optional.** if the `users` attribute is set.
times | Dictionary | **Optional.** A dictionary containing `begin` and `end` attributes for the notification.
command | Object name | **Required.** The name of the notification command which should be executed when the notification is triggered.
interval | Duration | **Optional.** The notification interval (in seconds). This interval is used for active notifications. Defaults to 30 minutes. If set to 0, [re-notifications](03-monitoring-basics.md#disable-renotification) are disabled.
- period | Object name | **Optional.** The name of a time period which determines when this notification should be triggered. Not set by default.
+ period | Object name | **Optional.** The name of a time period which determines when this notification should be triggered. Not set by default (effectively 24x7).
zone | Object name | **Optional.** The zone this object is a member of. Please read the [distributed monitoring](06-distributed-monitoring.md#distributed-monitoring) chapter for details.
types | Array | **Optional.** A list of type filters when this notification should be triggered. By default everything is matched.
states | Array | **Optional.** A list of state filters when this notification should be triggered. By default everything is matched. Note that the states filter is ignored for notifications of type Acknowledgement!
@@ -557,7 +522,7 @@ Runtime Attributes:
last\_problem\_notification | Timestamp | When the last notification was sent for a problem (as a UNIX timestamp).
-## NotificationCommand <a id="objecttype-notificationcommand"></a>
+### NotificationCommand <a id="objecttype-notificationcommand"></a>
A notification command definition.
@@ -643,7 +608,7 @@ Configuration Attributes:
--------------------------|-----------------------|----------------------------------
command | Array | **Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command. When using the "arguments" attribute this must be an array. Can be specified as function for advanced implementations.
env | Dictionary | **Optional.** A dictionary of macros which should be exported as environment variables prior to executing the command.
- vars | Dictionary | **Optional.** A dictionary containing custom attributes that are specific to this command.
+ vars | Dictionary | **Optional.** A dictionary containing custom variables that are specific to this command.
timeout | Duration | **Optional.** The command timeout in seconds. Defaults to `1m`.
arguments | Dictionary | **Optional.** A dictionary of command arguments.
@@ -651,7 +616,7 @@ Command arguments can be used the same way as for [CheckCommand objects](09-obje
More details on specific attributes can be found in [this chapter](03-monitoring-basics.md#notification-commands).
-## ScheduledDowntime <a id="objecttype-scheduleddowntime"></a>
+### ScheduledDowntime <a id="objecttype-scheduleddowntime"></a>
ScheduledDowntime objects can be used to set up recurring downtimes for hosts/services.
@@ -702,7 +667,7 @@ with the same (short) name as long as one of the `host_name` and
`service_name` attributes has a different value.
-## Service <a id="objecttype-service"></a>
+### Service <a id="objecttype-service"></a>
Service objects describe network services and how they should be checked
by Icinga 2.
@@ -741,10 +706,10 @@ Configuration Attributes:
display\_name | String | **Optional.** A short description of the service.
host\_name | Object name | **Required.** The host this service belongs to. There must be a `Host` object with that name.
groups | Array of object names | **Optional.** The service groups this service belongs to.
- vars | Dictionary | **Optional.** A dictionary containing custom attributes that are specific to this service.
+ vars | Dictionary | **Optional.** A dictionary containing custom variables that are specific to this service.
check\_command | Object name | **Required.** The name of the check command.
max\_check\_attempts | Number | **Optional.** The number of times a service is re-checked before changing into a hard state. Defaults to 3.
- check\_period | Object name | **Optional.** The name of a time period which determines when this service should be checked. Not set by default.
+ check\_period | Object name | **Optional.** The name of a time period which determines when this service should be checked. Not set by default (effectively 24x7).
check\_timeout | Duration | **Optional.** Check command timeout in seconds. Overrides the CheckCommand's `timeout` attribute.
check\_interval | Duration | **Optional.** The check interval (in seconds). This interval is used for checks when the service is in a `HARD` state. Defaults to `5m`.
retry\_interval | Duration | **Optional.** The retry interval (in seconds). This interval is used for checks when the service is in a `SOFT` state. Defaults to `1m`. Note: This does not affect the scheduling [after a passive check result](08-advanced-topics.md#check-result-freshness).
@@ -792,7 +757,7 @@ Runtime Attributes:
downtime\_depth | Number | Whether the service has one or more active downtimes.
flapping\_last\_change | Timestamp | When the last flapping change occurred (as a UNIX timestamp).
flapping\_current | Number | Current flapping value in percent (see flapping\_thresholds)
- flapping | Boolean | Whether the host is flapping between states.
+ flapping | Boolean | Whether the service is flapping between states.
state | Number | The current state (0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN).
last\_state | Number | The previous state (0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN).
last\_hard\_state | Number | The last hard state (0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN).
@@ -800,9 +765,14 @@ Runtime Attributes:
last\_state\_warning | Timestamp | When the last WARNING state occurred (as a UNIX timestamp).
last\_state\_critical | Timestamp | When the last CRITICAL state occurred (as a UNIX timestamp).
last\_state\_unknown | Timestamp | When the last UNKNOWN state occurred (as a UNIX timestamp).
+ last\_state\_unreachable | Timestamp | When the service was unreachable the last time (as a UNIX timestamp).
+ previous\_state\_change | Timestamp | Previous timestamp of `last_state_change` before processing a new check result.
+ severity | Number | [Severity](19-technical-concepts.md#technical-concepts-checks-severity) calculated value.
+ problem | Boolean | Whether the service is considered in a problem state type (NOT-OK).
+ handled | Boolean | Whether the service problem is handled (downtime or acknowledgement).
-## ServiceGroup <a id="objecttype-servicegroup"></a>
+### ServiceGroup <a id="objecttype-servicegroup"></a>
A group of services.
@@ -827,7 +797,7 @@ Configuration Attributes:
-## TimePeriod <a id="objecttype-timeperiod"></a>
+### TimePeriod <a id="objecttype-timeperiod"></a>
Time periods can be used to specify when hosts/services should be checked or to limit
when notifications should be sent out.
@@ -888,7 +858,7 @@ Runtime Attributes:
is\_inside | Boolean | Whether we're currently inside this timeperiod.
-## User <a id="objecttype-user"></a>
+### User <a id="objecttype-user"></a>
A user.
@@ -942,10 +912,10 @@ Configuration Attributes:
display\_name | String | **Optional.** A short description of the user.
email | String | **Optional.** An email string for this user. Useful for notification commands.
pager | String | **Optional.** A pager string for this user. Useful for notification commands.
- vars | Dictionary | **Optional.** A dictionary containing custom attributes that are specific to this user.
+ vars | Dictionary | **Optional.** A dictionary containing custom variables that are specific to this user.
groups | Array of object names | **Optional.** An array of group names.
enable\_notifications | Boolean | **Optional.** Whether notifications are enabled for this user. Defaults to true.
- period | Object name | **Optional.** The name of a time period which determines when a notification for this user should be triggered. Not set by default.
+ period | Object name | **Optional.** The name of a time period which determines when a notification for this user should be triggered. Not set by default (effectively 24x7).
types | Array | **Optional.** A set of type filters when a notification for this user should be triggered. By default everything is matched.
states | Array | **Optional.** A set of state filters when a notification for this should be triggered. By default everything is matched.
@@ -955,7 +925,7 @@ Runtime Attributes:
--------------------------|-----------------------|----------------------------------
last\_notification | Timestamp | When the last notification was sent for this user (as a UNIX timestamp).
-## UserGroup <a id="objecttype-usergroup"></a>
+### UserGroup <a id="objecttype-usergroup"></a>
A user group.
@@ -979,7 +949,7 @@ Configuration Attributes:
groups | Array of object names | **Optional.** An array of nested group names.
-## Zone <a id="objecttype-zone"></a>
+### Zone <a id="objecttype-zone"></a>
Zone objects are used to specify which Icinga 2 instances are located in a zone.
Please read the [distributed monitoring chapter](06-distributed-monitoring.md#distributed-monitoring) for additional details.
@@ -1094,7 +1064,7 @@ and API usage specifying the certificate files used for ssl
authorization and additional restrictions.
This configuration object is available as [api feature](11-cli-commands.md#cli-command-feature).
-The `TicketSalt` constant must be defined in [constants.conf](04-configuring-icinga-2.md#constants-conf).
+The `TicketSalt` constant must be defined in [constants.conf](04-configuration.md#constants-conf).
Example:
@@ -1121,8 +1091,8 @@ Configuration Attributes:
accept\_config | Boolean | **Optional.** Accept zone configuration. Defaults to `false`.
accept\_commands | Boolean | **Optional.** Accept remote commands. Defaults to `false`.
max\_anonymous\_clients | Number | **Optional.** Limit the number of anonymous client connections (not configured endpoints and signing requests).
- cipher\_list | String | **Optional.** Cipher list that is allowed. For a list of available ciphers run `openssl ciphers`. Defaults to `ALL:!LOW:!WEAK:!MEDIUM:!EXP:!NULL`.
- tls\_protocolmin | String | **Optional.** Minimum TLS protocol version. Must be one of `TLSv1`, `TLSv1.1` or `TLSv1.2`. Defaults to `TLSv1`.
+ cipher\_list | String | **Optional.** Cipher list that is allowed. For a list of available ciphers run `openssl ciphers`. Defaults to `ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256`.
+ tls\_protocolmin | String | **Optional.** Minimum TLS protocol version. Since v2.11, only `TLSv1.2` is supported. Defaults to `TLSv1.2`.
tls\_handshake\_timeout | Number | **Optional.** TLS Handshake timeout. Defaults to `10s`.
access\_control\_allow\_origin | Array | **Optional.** Specifies an array of origin URLs that may access the API. [(MDN docs)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Access-Control-Allow-Origin)
access\_control\_allow\_credentials | Boolean | **Deprecated.** Indicates whether or not the actual request can be made using credentials. Defaults to `true`. [(MDN docs)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Access-Control-Allow-Credentials)
@@ -1156,7 +1126,7 @@ requires to use `cipher_list` compatible with the endpoint using the oldest vers
other tools to connect to the API ensure also compatibility with them as this setting affects not only inter-cluster
communcation but also the REST API.
-### CheckerComponent <a id="objecttype-checkcomponent"></a>
+### CheckerComponent <a id="objecttype-checkercomponent"></a>
The checker component is responsible for scheduling active checks.
This configuration object is available as [checker feature](11-cli-commands.md#cli-command-feature).
@@ -1167,11 +1137,10 @@ Example:
object CheckerComponent "checker" { }
```
-Configuration Attributes:
-
- Name | Type | Description
- --------------------------|-----------------------|----------------------------------
- concurrent\_checks | Number | **Optional and deprecated.** The maximum number of concurrent checks. Was replaced by global constant `MaxConcurrentChecks` which will be set if you still use `concurrent_checks`.
+In order to limit the concurrent checks on a master/satellite endpoint,
+use [MaxConcurrentChecks](17-language-reference.md#icinga-constants-global-config) constant.
+This also applies to an agent as command endpoint where the checker
+feature is disabled.
### CheckResultReader <a id="objecttype-checkresultreader"></a>
@@ -1345,7 +1314,10 @@ Configuration Attributes:
source | String | **Optional.** Source name for this instance. Defaults to `icinga2`.
enable\_send\_perfdata | Boolean | **Optional.** Enable performance data for 'CHECK RESULT' events.
enable\_ha | Boolean | **Optional.** Enable the high availability functionality. Only valid in a [cluster setup](06-distributed-monitoring.md#distributed-monitoring-high-availability-features). Defaults to `false`.
-
+ enable\_tls | Boolean | **Optional.** Whether to use a TLS stream. Defaults to `false`.
+ ca\_path | String | **Optional.** Path to CA certificate to validate the remote host. Requires `enable_tls` set to `true`.
+ cert\_path | String | **Optional.** Path to host certificate to present to the remote host for mutual verification. Requires `enable_tls` set to `true`.
+ key\_path | String | **Optional.** Path to host key to accompany the cert\_path. Requires `enable_tls` set to `true`.
### GraphiteWriter <a id="objecttype-graphitewriter"></a>
@@ -1402,7 +1374,7 @@ Configuration Attributes:
enable\_host\_checks | Boolean | **Optional.** Whether active host checks are globally enabled. Defaults to true.
enable\_service\_checks | Boolean | **Optional.** Whether active service checks are globally enabled. Defaults to true.
enable\_perfdata | Boolean | **Optional.** Whether performance data processing is globally enabled. Defaults to true.
- vars | Dictionary | **Optional.** A dictionary containing custom attributes that are available globally.
+ vars | Dictionary | **Optional.** A dictionary containing custom variables that are available globally.
environment | String | **Optional.** Specify the Icinga environment. This overrides the `Environment` constant specified in the configuration or on the CLI with `--define`. Defaults to empty.
### IdoMySqlConnection <a id="objecttype-idomysqlconnection"></a>
@@ -1444,7 +1416,7 @@ Configuration Attributes:
ssl\_capath | String | **Optional.** MySQL SSL trusted SSL CA certificates in PEM format directory path.
ssl\_cipher | String | **Optional.** MySQL SSL list of allowed ciphers.
table\_prefix | String | **Optional.** MySQL database table prefix. Defaults to `icinga_`.
- instance\_name | String | **Optional.** Unique identifier for the local Icinga 2 instance. Defaults to `default`.
+ instance\_name | String | **Optional.** Unique identifier for the local Icinga 2 instance, used for multiple Icinga 2 clusters writing to the same database. Defaults to `default`.
instance\_description | String | **Optional.** Description for the Icinga 2 instance.
enable\_ha | Boolean | **Optional.** Enable the high availability functionality. Only valid in a [cluster setup](06-distributed-monitoring.md#distributed-monitoring-high-availability-db-ido). Defaults to `true`.
failover\_timeout | Duration | **Optional.** Set the failover timeout in a [HA cluster](06-distributed-monitoring.md#distributed-monitoring-high-availability-db-ido). Must not be lower than 30s. Defaults to `30s`.
@@ -1538,7 +1510,7 @@ Configuration Attributes:
ssl\_cert | String | **Optional.** PostgreSQL SSL certificate file path.
ssl\_ca | String | **Optional.** PostgreSQL SSL certificate authority certificate file path.
table\_prefix | String | **Optional.** PostgreSQL database table prefix. Defaults to `icinga_`.
- instance\_name | String | **Optional.** Unique identifier for the local Icinga 2 instance. Defaults to `default`.
+ instance\_name | String | **Optional.** Unique identifier for the local Icinga 2 instance, used for multiple Icinga 2 clusters writing to the same database. Defaults to `default`.
instance\_description | String | **Optional.** Description for the Icinga 2 instance.
enable\_ha | Boolean | **Optional.** Enable the high availability functionality. Only valid in a [cluster setup](06-distributed-monitoring.md#distributed-monitoring-high-availability-db-ido). Defaults to `true`.
failover\_timeout | Duration | **Optional.** Set the failover timeout in a [HA cluster](06-distributed-monitoring.md#distributed-monitoring-high-availability-db-ido). Must not be lower than 30s. Defaults to `30s`.
@@ -1734,7 +1706,7 @@ Configuration Attributes:
### PerfdataWriter <a id="objecttype-perfdatawriter"></a>
Writes check result performance data to a defined path using macro
-pattern consisting of custom attributes and runtime macros.
+pattern consisting of custom variables and runtime macros.
This configuration object is available as [perfdata feature](14-features.md#writing-performance-data-files).
Example:
@@ -1774,6 +1746,11 @@ in `host_perfdata_path` and `service_perfdata_path` to generate a unique filenam
Periodically writes status and configuration data files which are used by third-party tools.
This configuration object is available as [statusdata feature](14-features.md#status-data).
+> **Note**
+>
+> This feature is DEPRECATED and will be removed in future releases.
+> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
+
Example:
```
diff --git a/doc/10-icinga-template-library.md b/doc/10-icinga-template-library.md
index fb7283f..200ce7e 100644
--- a/doc/10-icinga-template-library.md
+++ b/doc/10-icinga-template-library.md
@@ -23,7 +23,7 @@ You are advised to create your own CheckCommand definitions in
## Generic Templates <a id="itl-generic-templates"></a>
-By default the generic templates are included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file:
+By default the generic templates are included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file:
```
include <itl>
@@ -78,7 +78,7 @@ plugin scripts.
Check command for the built-in `icinga` check. This check returns performance
data for the current Icinga instance and optionally allows for minimum version checks.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-----------------------|---------------
@@ -95,7 +95,7 @@ The `cluster` check command does not support any vars.
Check command for the built-in `cluster-zone` check.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-----------------------|---------------
@@ -107,7 +107,7 @@ cluster\_lag\_critical | **Optional.** Critical threshold for log lag in seconds
Check command for the built-in `ido` check.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
--------------------------------|-----------------------------
@@ -127,7 +127,7 @@ or [runtime object checks](08-advanced-topics.md#access-object-attributes-at-run
In contrast to the [check_dummy](https://www.monitoring-plugins.org/doc/man/check_dummy.html)
plugin, Icinga 2 implements a light-weight in memory check with 2.9+.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -138,7 +138,7 @@ dummy\_text | **Optional.** Plugin output. Defaults to "Check was successfu
Specialised check command object for passive checks which uses the functionality of the "dummy" check command with appropriate default values.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -160,6 +160,15 @@ Check command for the built-in `exception` check. This check throws an exception
For test and demo purposes only. The `exception` check command does not support
any vars.
+### sleep <a id="itl-sleep"></a>
+
+Check command for the built-in `sleep` check. This allows to use sleep for testing
+and debugging only.
+
+Name | Description
+----------------|--------------
+sleep\_time | **Optional.** The duration of the sleep in seconds. Defaults to 1s.
+
<!-- keep this anchor for URL link history only -->
<a id="plugin-check-commands"></a>
@@ -168,7 +177,7 @@ any vars.
The Plugin Check Commands provides example configuration for plugin check commands
provided by the [Monitoring Plugins](https://www.monitoring-plugins.org) project.
-By default the Plugin Check Commands are included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration
+By default the Plugin Check Commands are included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration
file:
include <plugins>
@@ -187,7 +196,7 @@ which contains the path of the plugins from the Monitoring Plugins project.
The plugin [apt](https://www.monitoring-plugins.org/doc/man/check_apt.html) checks for software updates on systems that use
package management systems based on the apt-get(8) command found in Debian based systems.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -199,6 +208,7 @@ apt_exclude | **Optional.** Exclude packages matching REGEXP from th
apt_critical | **Optional.** If the full package information of any of the upgradable packages match this REGEXP, the plugin will return CRITICAL status. Can be specified multiple times.
apt_timeout | **Optional.** Seconds before plugin times out (default: 10).
apt_only_critical | **Optional.** Only warn about critical upgrades.
+apt_list | **Optional.** List packages available for upgrade.
### breeze <a id="plugin-check-command-breeze"></a>
@@ -206,7 +216,7 @@ apt_only_critical | **Optional.** Only warn about critical upgrades.
The [check_breeze](https://www.monitoring-plugins.org/doc/man/check_breeze.html) plugin reports the signal
strength of a Breezecom wireless equipment.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-----------------|---------------------------------
@@ -221,7 +231,7 @@ breeze_critical | **Required.** Percentage strength below which a WARNING statu
The [check_by_ssh](https://www.monitoring-plugins.org/doc/man/check_by_ssh.html) plugin uses SSH to execute
commands on a remote host.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
---------------- | --------------
@@ -246,7 +256,7 @@ by_ssh_skip_stderr | **Optional.** Ignore all or (if specified) first n lines on
The [check_clamd](https://www.monitoring-plugins.org/doc/man/check_clamd.html) plugin tests CLAMD
connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-------------------|--------------
@@ -277,7 +287,7 @@ clamd_ipv6 | **Optional.** Use IPv6 connection. Defaults to false.
The [check_dhcp](https://www.monitoring-plugins.org/doc/man/check_dhcp.html) plugin
tests the availability of DHCP servers on a network.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -294,7 +304,7 @@ dhcp_unicast | **Optional.** Whether to use unicast requests. Defaults to fal
The [check_dig](https://www.monitoring-plugins.org/doc/man/check_dig.html) plugin
test the DNS service on the specified host using dig.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
---------------------|--------------
@@ -318,7 +328,7 @@ The [check_disk](https://www.monitoring-plugins.org/doc/man/check_disk.html) plu
checks the amount of used disk space on a mounted file system and generates an alert
if free space is less than one of the threshold values.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
--------------------|------------------------
@@ -348,13 +358,14 @@ disk\_ignore\_ereg\_path | **Optional.** Regular expression to ignore selected
disk\_timeout | **Optional.** Seconds before connection times out (default: 10).
disk\_units | **Optional.** Choose bytes, kB, MB, GB, TB (default: MB).
disk\_exclude\_type | **Optional.** Ignore all filesystems of indicated type. Multiple regular expression strings must be defined as array. Defaults to "none", "tmpfs", "sysfs", "proc", "configfs", "devtmpfs", "devfs", "mtmfs", "tracefs", "cgroup", "fuse.gvfsd-fuse", "fuse.gvfs-fuse-daemon", "fdescfs", "overlay", "nsfs", "squashfs".
+disk\_include\_type | **Optional.** Check only filesystems of indicated type. Multiple regular expression strings must be defined as array.
### disk_smb <a id="plugin-check-command-disk-smb"></a>
The [check_disk_smb](https://www.monitoring-plugins.org/doc/man/check_disk_smb.html) plugin
uses the `smbclient` binary to check SMB shares.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
------------------------|------------------------
@@ -375,7 +386,7 @@ uses the nslookup program to obtain the IP address for the given host/domain que
An optional DNS server to use may be specified. If no DNS server is specified, the
default server(s) specified in `/etc/resolv.conf` will be used.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
---------------------|--------------
@@ -396,7 +407,7 @@ dns_timeout | **Optional.** Seconds before connection times out. Defaul
The [check_file_age](https://www.monitoring-plugins.org/doc/man/check_file_age.html) plugin
checks a file's size and modification time to make sure it's not empty and that it's sufficiently recent.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-----------------------|--------------------------------------------------------------------------------------------------------
@@ -413,7 +424,7 @@ file_age_ignoremissing | **Optional.** Return OK if the file does not exist. Def
The [check_flexlm](https://www.monitoring-plugins.org/doc/man/check_flexlm.html) plugin
checks available flexlm license managers. Requires the `lmstat` command.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-------------------|----------------------------------------------------------
@@ -429,7 +440,7 @@ necessary to set the `suid` flag on `fping`.
This CheckCommand expects an IPv4 address.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -454,7 +465,7 @@ necessary to set the `suid` flag on `fping`.
This CheckCommand expects an IPv6 address.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -476,7 +487,7 @@ fping_source_interface | **Optional.** The source interface name.
The [check_ftp](https://www.monitoring-plugins.org/doc/man/check_ftp.html) plugin
tests FTP connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-------------------|--------------
@@ -510,7 +521,7 @@ This plugin uses the 'qstat' command, the popular game server status query tool.
If you don't have the package installed, you will need to [download](http://www.activesw.com/people/steve/qstat.html)
or install the package `quakestat` before you can use this plugin.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-------------------|-------------------
@@ -531,7 +542,7 @@ Check command object for the [check_ping](https://www.monitoring-plugins.org/doc
plugin with host check default values. This variant uses the host's `address` attribute
if available and falls back to using the `address6` attribute if the `address` attribute is not set.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -549,7 +560,7 @@ ping_timeout | **Optional.** The plugin timeout in seconds. Defaults to 0 (no
Check command object for the [check_ping](https://www.monitoring-plugins.org/doc/man/check_ping.html)
plugin with host check default values. This variant uses the host's `address` attribute.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -567,7 +578,7 @@ ping_timeout | **Optional.** The plugin timeout in seconds. Defaults to 0 (no
Check command object for the [check_ping](https://www.monitoring-plugins.org/doc/man/check_ping.html)
plugin with host check default values. This variant uses the host's `address6` attribute.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -586,7 +597,7 @@ The [check_hpjd](https://www.monitoring-plugins.org/doc/man/check_hpjd.html) plu
tests the state of an HP printer with a JetDirect card. Net-snmp must be installed
on the computer running the plugin.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -604,7 +615,7 @@ check connection times, and report on certificate expiration times.
The plugin can either test the HTTP response of a server, or if `http_certificate` is set to a non-empty value, the TLS certificate age for a HTTPS host.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
---------------------------------|---------------------------------
@@ -663,7 +674,7 @@ The main difference is that check_ping executes the system's ping(1) command and
parses its output while `check_icmp` talks ICMP itself. `check_icmp` must be installed with
`setuid` root.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -687,7 +698,7 @@ icmp_ttl | **Optional.** The TTL on outgoing packets.
The [check_imap](https://www.monitoring-plugins.org/doc/man/check_imap.html) plugin
tests IMAP connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------------|--------------
@@ -720,7 +731,7 @@ can be used to check LDAP servers.
The plugin can also be used for monitoring ldaps connections instead of the deprecated `check_ldaps`.
This can be ensured by enabling `ldap_starttls` or `ldap_ssl`.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
------------------------|--------------
@@ -746,7 +757,7 @@ ldap_verbose | **Optional.** Show details for command-line debugging (disabled
The [check_load](https://www.monitoring-plugins.org/doc/man/check_load.html) plugin
tests the current system load average.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -763,7 +774,7 @@ load_percpu | **Optional.** Divide the load averages by the number of CPUs (
The [check_mailq](https://www.monitoring-plugins.org/doc/man/check_mailq.html) plugin
checks the number of messages in the mail queue (supports multiple sendmail queues, qmail).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
------------------------|--------------
@@ -780,7 +791,7 @@ mailq_sudo | **Optional.** Use sudo to execute the mailq command.
The [check_mysql](https://www.monitoring-plugins.org/doc/man/check_mysql.html) plugin
tests connections to a MySQL server.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
------------------------|---------------------------------------------------------------
@@ -813,7 +824,7 @@ The result from the query should be numeric. For extra security, create a user w
**Note**: You must specify `mysql_query_password` with an empty string to force an empty password,
overriding any my.cnf settings.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
------------------------|---------------------------------------------------------------
@@ -835,7 +846,7 @@ The [negate](https://www.monitoring-plugins.org/doc/man/negate.html) plugin
negates the status of a plugin (returns OK for CRITICAL and vice-versa).
Additional switches can be used to control which state becomes what.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------------|---------------------------------------------------------------
@@ -855,7 +866,7 @@ The `check_nrpe` plugin can be used to query an [NRPE](https://icinga.com/docs/i
server or [NSClient++](https://www.nsclient.org). **Note**: This plugin
is considered insecure/deprecated.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -876,7 +887,7 @@ nrpe_version_2 | **Optional.** Use this if you want to connect using NRPE v2 pro
The [check_nt](https://www.monitoring-plugins.org/doc/man/check_nt.html) plugin
collects data from the [NSClient++](https://www.nsclient.org) service.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -898,7 +909,7 @@ checks the clock offset between the local host and a remote NTP server.
**Note**: If you want to monitor an NTP server, please use `ntp_peer`.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -920,7 +931,7 @@ checks the health of an NTP server. It supports checking the offset with the syn
jitter and stratum. This plugin will not check the clock offset between the local host and NTP
server; please use `ntp_time` for that purpose.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -948,7 +959,7 @@ If a query is specified using the `pgsql_query` attribute, it will be executed a
connecting to the server. The result from the query has to be numeric in order
to compare it against the query thresholds if set.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
------------------------|---------------------------------------------------------------
@@ -974,7 +985,7 @@ round trip average (milliseconds).
This command uses the host's `address` attribute if available and falls back to using
the `address6` attribute if the `address` attribute is not set.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -996,7 +1007,7 @@ round trip average (milliseconds).
This command uses the host's `address` attribute if not explicitly specified using
the `ping_address` attribute.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1017,7 +1028,7 @@ round trip average (milliseconds).
This command uses the host's `address6` attribute if not explicitly specified using
the `ping_address` attribute.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1035,7 +1046,7 @@ ping_timeout | **Optional.** The plugin timeout in seconds. Defaults to 0 (no
The [check_pop](https://www.monitoring-plugins.org/doc/man/check_pop.html) plugin
tests POP connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
---------------------|--------------
@@ -1067,7 +1078,7 @@ checks all processes and generates WARNING or CRITICAL states if the specified
metric is outside the required threshold ranges. The metric defaults to number
of processes. Search filters can be applied to limit the processes to check.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
---------------------|--------------
@@ -1101,7 +1112,7 @@ typically be executed at regular predictable intervals. Please be sure that the
password used does not allow access to sensitive system resources.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-------------------|--------------
@@ -1121,7 +1132,7 @@ radius_timeout | **Optional.** The number of seconds before connection times
The [check_rpc](https://www.monitoring-plugins.org/doc/man/check_rpc.html)
plugin tests if a service is registered and running using `rpcinfo -H host -C rpc_command`.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
--- | ---
@@ -1138,7 +1149,7 @@ rpc_verbose | **Optional.** Show verbose output. Defaults to false.
The [check_simap](https://www.monitoring-plugins.org/doc/man/check_simap.html) plugin
tests SIMAP connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-----------------------|--------------
@@ -1167,7 +1178,7 @@ simap_ipv6 | **Optional.** Use IPv6 connection. Defaults to false.
The [check_ide_smart](https://www.monitoring-plugins.org/doc/man/check_ide_smart.html) plugin
checks a local hard drive with the (Linux specific) SMART interface. Requires installation of `smartctl`.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1179,7 +1190,7 @@ smart_device | **Required.** The name of a local hard drive to monitor.
The [check_smtp](https://www.monitoring-plugins.org/doc/man/check_smtp.html) plugin
will attempt to open an SMTP connection with the host.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------------|--------------
@@ -1210,7 +1221,7 @@ checks the status of remote machines and obtains system information via SNMP.
**Note**: This plugin uses the `snmpget` command included with the NET-SNMP package.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
--------------------|--------------
@@ -1242,7 +1253,7 @@ snmp_perf_oids | **Optional.** Label performance data with OIDs instead of
Check command object for the [check_snmp](https://www.monitoring-plugins.org/doc/man/check_snmp.html)
plugin, using SNMPv3 authentication and encryption options.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
---------------------|--------------
@@ -1251,6 +1262,7 @@ snmpv3_getnext | **Optional.** Use SNMP GETNEXT instead of SNMP GET.
snmpv3_seclevel | **Optional.** The security level. Defaults to authPriv.
snmpv3_auth_alg | **Optional.** The authentication algorithm. Defaults to SHA.
snmpv3_user | **Required.** The username to log in with.
+snmpv3_context | **Optional.** The SNMPv3 context.
snmpv3_auth_key | **Required,** The authentication key. Required if `snmpv3_seclevel` is set to `authPriv` otherwise optional.
snmpv3_priv_key | **Required.** The encryption key.
snmpv3_oid | **Required.** The SNMP OID.
@@ -1272,7 +1284,7 @@ snmpv3_timeout | **Optional.** The command timeout in seconds. Defaults to
Check command object for the [check_snmp](https://www.monitoring-plugins.org/doc/man/check_snmp.html)
plugin, using the uptime OID by default.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1286,7 +1298,7 @@ snmp_community | **Optional.** The SNMP community. Defaults to "public".
The [check_spop](https://www.monitoring-plugins.org/doc/man/check_spop.html) plugin
tests SPOP connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------------|--------------
@@ -1316,7 +1328,7 @@ spop_ipv6 | **Optional.** Use IPv6 connection. Defaults to false.
The [check_ssh](https://www.monitoring-plugins.org/doc/man/check_ssh.html) plugin
connects to an SSH server at a specified host and port.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1332,7 +1344,7 @@ ssh_ipv6 | **Optional.** Use IPv6 connection. Defaults to false.
Check command object for the [check_tcp](https://www.monitoring-plugins.org/doc/man/check_tcp.html) plugin,
using ssl-related options.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
------------------------------|--------------
@@ -1349,7 +1361,7 @@ ssl_sni | **Optional.** The `server_name` that is send to
The [check_ssmtp](https://www.monitoring-plugins.org/doc/man/check_ssmtp.html) plugin
tests SSMTP connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
-----------------------|--------------
@@ -1379,7 +1391,7 @@ ssmtp_ipv6 | **Optional.** Use IPv6 connection. Defaults to false.
The [check_swap](https://www.monitoring-plugins.org/doc/man/check_swap.html) plugin
checks the swap space on a local machine.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1395,7 +1407,7 @@ swap_noswap | **Optional.** Resulting state when there is no swap regardless
The [check_tcp](https://www.monitoring-plugins.org/doc/man/check_tcp.html) plugin
tests TCP connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1426,7 +1438,7 @@ tcp_ipv6 | **Optional.** Use IPv6 connection. Defaults to false.
The [check_udp](https://www.monitoring-plugins.org/doc/man/check_udp.html) plugin
tests UDP connections with the specified host (or unix socket).
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1445,7 +1457,7 @@ The [check_ups](https://www.monitoring-plugins.org/doc/man/check_ups.html) plugi
tests the UPS service on the specified host. [Network UPS Tools](http://www.networkupstools.org)
must be running for this plugin to work.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1465,7 +1477,7 @@ The [check_users](https://www.monitoring-plugins.org/doc/man/check_users.html) p
checks the number of users currently logged in on the local system and generates an
error if the number exceeds the thresholds specified.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1508,7 +1520,7 @@ The data collection is instant and free disk space (default, see `disk_win_show_
> Percentage based thresholds can be used by adding a '%' to the threshold
> value.
-Custom attributes:
+Custom variables:
Name | Description
:---------------------|:------------
@@ -1524,7 +1536,7 @@ disk\_win\_show\_used | **Optional**. Use used instead of free space.
Check command object for the `check_load.exe` plugin.
This plugin collects the inverse of the performance counter `\Processor(_Total)\% Idle Time` two times, with a wait time of one second between the collection. To change this wait time use [`perfmon-windows`](10-icinga-template-library.md#windows-plugins-load-windows).
-Custom attributes:
+Custom variables:
Name | Description
:---------------|:------------
@@ -1543,7 +1555,7 @@ The memory collection is instant and free memory is used for threshold computati
> value. Keep in mind that memory\_win\_unit is applied before the
> value is calculated.
-Custom attributes:
+Custom variables:
Name | Description
:-----------------|:------------
@@ -1558,7 +1570,7 @@ memory\_win\_show\_used | **Optional**. Show used memory instead of the free mem
Check command object for the `check_network.exe` plugin.
Collects the total Bytes inbound and outbound for all interfaces in one second, to itemise interfaces or use a different collection interval use [`perfmon-windows`](10-icinga-template-library.md#windows-plugins-load-windows).
-Custom attributes:
+Custom variables:
Name | Description
:-------------------|:------------
@@ -1574,7 +1586,7 @@ This plugins allows to collect data from a Performance Counter. After the first
To receive a list of possible Performance Counter Objects run `check_perfmon.exe --print-objects` and to view an objects instances and counters run `check_perfmon.exe --print-object-info -P "name of object"`
-Custom attributes:
+Custom variables:
Name | Description
:---------------------|:------------
@@ -1591,7 +1603,7 @@ perfmon\_win\_syntax | **Optional**. Use this in the performance output instead
Check command object for the `check_ping.exe` plugin.
ping-windows should automatically detect whether `ping_win_address` is an IPv4 or IPv6 address. If not, use ping4-windows and ping6-windows. Also note that check\_ping.exe waits at least `ping_win_timeout` milliseconds between the pings.
-Custom attributes:
+Custom variables:
Name | Description
:------------------|:------------
@@ -1607,7 +1619,7 @@ ping\_win\_timeout | **Optional**. The timeout in milliseconds. Default: 1000
Check command object for `check_procs.exe` plugin.
When using `procs_win_user` this plugins needs administrative privileges to access the processes of other users, to just enumerate them no additional privileges are required.
-Custom attributes:
+Custom variables:
Name | Description
:----------------|:------------
@@ -1621,7 +1633,7 @@ procs\_win\_user | **Optional**. Count this users processes.
Check command object for `check_service.exe` plugin.
This checks thresholds work different since the binary decision whether a service is running or not does not allow for three states. As a default `check_service.exe` will return CRITICAL when `service_win_service` is not running, the `service_win_warn` flag changes this to WARNING.
-Custom attributes:
+Custom variables:
Name | Description
:-------------------------|:------------
@@ -1635,7 +1647,7 @@ service\_win\_service | **Required**. Name of the service to check.
Check command object for `check_swap.exe` plugin.
The data collection is instant.
-Custom attributes:
+Custom variables:
Name | Description
:--------------- | :------------
@@ -1654,18 +1666,18 @@ Querying Microsoft for Windows updates can take multiple seconds to minutes. An
> The Network Services Account which runs Icinga 2 by default does not have the required
> permissions to run this check.
-Custom attributes:
+Custom variables:
Name | Description
:-------------------|:------------
-update\_win\_warn | **Optional**. If set, returns warning when important updates are available.
-update\_win\_crit | **Optional**. If set, return critical when important updates that require a reboot are available.
+update\_win\_warn | **Optional**. The warning threshold.
+update\_win\_crit | **Optional**. The critical threshold.
update\_win\_reboot | **Optional**. Set to treat 'may need update' as 'definitely needs update'. Please Note that this is true for almost every update and is therefore not recommended.
+ignore\_reboot | **Optional**. Set to disable behavior of returning critical if any updates require a reboot.
-In contrast to most other plugins, the values of check_update's custom attributes do not set thresholds, but just enable/disable the behavior described in the table above.
-It can be enabled/disabled for example by setting them to "true" or "false", "1" or "0" would also work.
-Thresholds will always be "1".
+If a warning threshold is set but not a critical threshold, the critical threshold will be set to one greater than the set warning threshold.
+Unless the `ignore_reboot` flag is set, if any updates require a reboot the plugin will return critical.
> **Note**
>
@@ -1678,7 +1690,7 @@ Thresholds will always be "1".
Check command object for `check_uptime.exe` plugin.
Uses GetTickCount64 to get the uptime, so boot time is not included.
-Custom attributes:
+Custom variables:
Name | Description
:-----------------|:------------
@@ -1691,7 +1703,7 @@ uptime\_win\_unit | **Optional**. The unit to display the received value in, thr
Check command object for `check_users.exe` plugin.
-Custom attributes:
+Custom variables:
Name | Description
:----------------|:------------
@@ -1719,7 +1731,7 @@ are not recommended with using the legacy HTTP API.
`check_nscp_api` is part of the Icinga 2 plugins. This plugin is available for
both, Windows and Linux/Unix.
-Verify that the ITL CheckCommand is included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file:
+Verify that the ITL CheckCommand is included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file:
vim /etc/icinga2/icinga2.conf
@@ -1738,7 +1750,7 @@ and integrate them into Icinga 2.
The check plugin `check_nscp_api` can be integrated with the `nscp_api` CheckCommand object:
-Custom attributes:
+Custom variables:
Name | Description
:----------------------|:----------------------
@@ -1762,12 +1774,12 @@ check_cpu CRITICAL: critical(5m: 48%, 1m: 36%), 5s: 0% | 'total 5m'=48%;40;30 't
Icinga 2 can use the `nscp client` command to run arbitrary NSClient++ checks locally on the client.
You can enable these check commands by adding the following the include directive in your
-[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file:
+[icinga2.conf](04-configuration.md#icinga2-conf) configuration file:
include <nscp>
You can also optionally specify an alternative installation directory for NSClient++ by adding
-the NscpPath constant in your [constants.conf](04-configuring-icinga-2.md#constants-conf) configuration
+the NscpPath constant in your [constants.conf](04-configuration.md#constants-conf) configuration
file:
const NscpPath = "C:\\Program Files (x86)\\NSClient++"
@@ -1779,7 +1791,7 @@ Note that it is not necessary to run NSClient++ as a Windows service for these c
The check command object for NSClient++ is available as `nscp-local`.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
----------------|--------------
@@ -1827,19 +1839,19 @@ nscp_memory_showall | **Optional.** Shows more details in plugin output, defau
Check command object for the `check_os_version` NSClient++ plugin.
-This command has the same custom attributes like the `nscp-local` check command.
+This command has the same custom variables like the `nscp-local` check command.
### nscp-local-pagefile <a id="nscp-check-local-pagefile"></a>
Check command object for the `check_pagefile` NSClient++ plugin.
-This command has the same custom attributes like the `nscp-local` check command.
+This command has the same custom variables like the `nscp-local` check command.
### nscp-local-process <a id="nscp-check-local-process"></a>
Check command object for the `check_process` NSClient++ plugin.
-This command has the same custom attributes like the `nscp-local` check command.
+This command has the same custom variables like the `nscp-local` check command.
### nscp-local-service <a id="nscp-check-local-service"></a>
@@ -1862,13 +1874,13 @@ nscp_service_showall | **Optional.** Shows more details in plugin output, defa
Check command object for the `check_uptime` NSClient++ plugin.
-This command has the same custom attributes like the `nscp-local` check command.
+This command has the same custom variables like the `nscp-local` check command.
### nscp-local-version <a id="nscp-check-local-version"></a>
Check command object for the `check_version` NSClient++ plugin.
-This command has the same custom attributes like the `nscp-local` check command.
+This command has the same custom variables like the `nscp-local` check command.
In addition to that the default value for `nscp_modules` is set to `[ "CheckHelpers" ]`.
### nscp-local-disk <a id="nscp-check-local-disk"></a>
@@ -1877,7 +1889,8 @@ Check command object for the `check_drivesize` NSClient++ plugin.
Name | Description
-----------------------|------------------
-nscp_disk_drive | **Optional.** Drive character, default to all drives.
+nscp_disk_drive | **Optional.** Drive character, default to all drives. Can be an array if multiple drives should be monitored.
+nscp_disk_exclude | **Optional.** Drive character, default to none. Can be an array of drive characters if multiple drives should be excluded.
nscp_disk_free | **Optional.** Switch between checking free space (free=true) or used space (free=false), default to false.
nscp_disk_warning | **Optional.** Threshold for WARNING in percent or absolute (use MB, GB, ...), default to 80 (used) or 20 percent (free).
nscp_disk_critical | **Optional.** Threshold for CRITICAL in percent or absolute (use MB, GB, ...), default to 90 (used) or 10 percent (free).
@@ -1931,7 +1944,7 @@ The SNMP manubulon plugin check commands assume that the global constant named `
is set to the path where the Manubublon SNMP plugins are installed.
You can enable these plugin check commands by adding the following the include directive in your
-[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file:
+[icinga2.conf](04-configuration.md#icinga2-conf) configuration file:
include <manubulon>
@@ -1967,7 +1980,7 @@ You can enable these plugin check commands by adding the following the include d
Check command object for the [check_snmp_env.pl](http://nagios.manubulon.com/snmp_env.html) plugin.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
@@ -1994,7 +2007,7 @@ snmp_timeout | **Optional.** The command timeout in seconds. Defaults
Check command object for the [check_snmp_load.pl](http://nagios.manubulon.com/snmp_load.html) plugin.
-Custom attributes passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
+Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
Name | Description
@@ -2021,7 +2034,7 @@ snmp_timeout | **Optional.** The command timeout in seconds. Defaults
Check command object for the [check_snmp_mem.pl](http://nagios.manubulon.com/snmp_mem.html) plugin.
-Custom attributes passed as [command parameters](03-monitoring-basics.m