# Icinga 2: the monitoring core that needs a web interface bolted on top > A C++ monitoring server with a configuration language rather than a config format, a REST API, a distributed zone model and a licence that changed in 2024, documented almost entirely off the README. **Icinga/icinga2** — The core of our monitoring platform with a powerful configuration language and REST API. - Repository: https://github.com/Icinga/icinga2 - Website: https://icinga.com/docs/icinga2/latest - Stars: 2,239 · Forks: 616 - Language: C++ - License: GPL-3.0 - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/icinga-icinga2 ## What the server does, in the project's own framing The About section is four sentences and they define the scope precisely. Icinga is described as a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. Scalability is the claim attached to it: Icinga can monitor large, complex environments across multiple locations. Three verbs, three different outputs. Availability checks are the familiar ping-and-HTTP half. Notifications are a separate concern with its own plugins. Performance data for reporting is the one that shapes architecture, because a system that keeps performance data for graphs and reports needs somewhere to put it, and the topic list on the repository shows the range of backends in play: Graphite, InfluxDB, OpenTSDB and Graylog all appear as topics alongside cluster, elastic, tls and rest-api. That combination of topics is a decent map of the system without reading a line of code. Monitoring and notification are the core, cluster and distributed-monitoring are about running many nodes, and the remaining topics are integrations. The language is C++, and the tree confirms a substantial server rather than a script collection. ## The stack has two halves and you need both The single most useful sentence in the README is the one that says Icinga 2 is the monitoring server and requires Icinga Web 2 on top in your Icinga Stack. That is a correction to a common misconception, because the name Icinga is often used for the whole product while this repository is only the engine. The engine checks hosts and services, tracks their state, handles the check scheduling and the cluster communication, and exposes results. The web interface is what renders any of it. Neither half is optional if your goal is a monitoring system rather than an API to build one on. The repository tree supports that reading. Under lib/ sits the implementation, itl/ is an interval and timing library used throughout Icinga codebases, icinga-app/ is the command line application, icinga-installer/ handles setup, plugins/ holds the check plugin integrations, and third-party/ records vendored dependencies. There is a Containerfile at the root, so container deployment is a supported path rather than a community workaround. ## Three ways to manage configuration, and that choice is the real decision The README states that configuration can be easily managed with either Icinga Director, config management tools, or plain text within the Icinga DSL. Three options, presented as equals, and they are not equal in practice. Plain text with the DSL means writing a real programming language for your monitoring setup. The Icinga DSL reference is linked from the README as a language reference rather than a format specification, which tells you what you are signing up for: you get apply blocks, functions, variables and inheritance instead of a list of stanzas, and in exchange you get logic. That is the right answer when your checks follow rules and the wrong one when you want to add a host in under a minute. Icinga Director is the middle path, a web interface for generating that configuration without writing the DSL by hand. Configuration management tools sit at the other end, where templates in Ansible or similar systems render files that Icinga reads. Teams already running configuration management usually pick that route, and it means the monitoring configuration lives in the same review process as the rest of the infrastructure. This choice propagates. Whichever path you take determines how you onboard a host, how you scale to a thousand of them, and who can approve a change. It is worth deciding before installing anything. ## Distributed monitoring through zones and the REST API The README links a whole chapter to distributed monitoring, which tells you the architecture is a first-class concern rather than an add-on. The topic list names cluster and distributed-monitoring, and the security advisories in recent releases describe child-zone connections, which is where the topology shows up in practice. Those advisories are worth reading as design documentation. The v2.16.5 and v2.15.6 notes both describe a limit on message size between nodes lower in the hierarchy, applied because a node could otherwise use a message limit of roughly one gigabyte to exhaust another node's memory. A fix that constrains messages specifically on child-zone connections is a fix aimed at the trust boundary between a parent and the nodes reporting to it, which tells you the hierarchy is a real privilege boundary and not just an organisational convenience. The REST API is the other integration point. Filter expressions on endpoints are permission-controlled, and the v2.16.5 release tightened that, applying user permissions to filter expressions on the events endpoint the same way they already applied to the objects endpoint. The practical lesson for anyone automating against Icinga 2 is that API users are scoped by permission, and the boundaries between endpoints have changed as vulnerabilities were found. ## The licence changed under everyone who already had a copy The licence section is the longest part of the README and it exists because of a real complication. Icinga 2 and its documentation are licensed under the GNU General Public License Version 3 or later, with the copy in LICENSE.md in the source package. The note underneath is the part worth reading twice. Historically Icinga 2 was licensed under GPL version 2 or later, but newly introduced dependencies licensed under the Apache License 2.0 are not compatible with GPLv2, so the project upgraded its licence to GPLv3 or later effective from version v2.16.0 onwards. All versions prior to v2.16.0, and all existing source code files, remain under GPLv2 or later, with the licence information recorded in those files. So the licence is version-dependent rather than uniform, and a vendored copy of an old release is not on the same terms as a current one. There is also a special exception permitting linkage with the OpenSSL library under conditions described in each source file, with a clause about extending or deleting the exception. The README adds that the exception is only relevant for OpenSSL 1.x, since OpenSSL 3.0 and later are Apache 2.0 licensed and compatible with GPLv3 without one. Recent releases reflect that: v2.16.4 added support for OpenSSL 4.0 and ensured compatibility with newer OpenSSL versions. ## A README that is mostly a table of contents There is no quick start in this repository. The Installation section under that heading is a list of seven links and nothing else: Installation, Monitoring Basics, Configuration, Distributed Monitoring, Addons Integrations and Features, Troubleshooting, and Upgrading. The Documentation section adds one more link to the same site. Support points at the project website, the community channels and a partner programme for professional support. For a project with this much operational surface, that is a defensible choice. Installation differs by packaging, configuration is a language, and distributed deployment has topology questions that a README cannot usefully answer. The chapter list is in fact a decent reading order for an evaluation. What is missing is any statement about the current release line. The repository itself does carry the information: the default branch is master, there is a Containerfile and a publiccode.yml for public code metadata, and the release history shows v2.16.5 published on 2026-08-18 alongside a parallel v2.15.6 the same day, which is the usual pattern of maintaining a stable branch alongside a current one. The last push was 2026-09-28. The security reporting process has its own page rather than an issue tracker, which is what you would want from a project of this size. ## Conclusion Icinga 2 is not a product you evaluate from its README, because the README is a table of contents with a licence section attached. The decisions that matter live in the linked chapters: installation, monitoring basics, distributed monitoring and the addons page. What the README does establish is the shape of the stack, which is the part people get wrong. This is a server that checks things and emits performance data, and it needs Icinga Web 2 on top before a human sees any of it. If you are choosing between monitoring projects, that split between core engine and interface, and the choice between the Icinga DSL, the Director and a config management tool for generating configuration, will tell you more than any feature comparison. ## FAQ ### What is Icinga used for? It checks the availability of network resources, notifies users of outages and generates performance data for reporting. The repository is the monitoring server itself, and it requires Icinga Web 2 on top before anything is visible in a browser, so the engine and the interface are separate pieces of the stack. ### Where does Icinga 2 send its performance data? The README does not name a default backend, which is worth knowing before you go looking for one there. It points at a chapter on addons and integrations, and the repository topics name the systems Icinga 2 feeds: Graphite, InfluxDB, OpenTSDB and Graylog. Those are data backends rather than competitor monitors. ### Do I need Icinga Web 2 to use Icinga 2? For anything a human reads, yes. The README describes Icinga 2 as the monitoring server and says it requires Icinga Web 2 on top in your stack. Without the web layer you have a server that checks things and exposes results through its REST API, which is only useful if you are building something on top of it. ### How do I write monitoring configuration for Icinga 2? The README lists three options: plain text in the Icinga DSL, the Icinga Director web interface, or configuration management tools that generate the files. The DSL is a language with its own reference rather than a simple format, which is the main thing to know before choosing it. ### Under what licence is Icinga 2 released? GPL version 3 or later from version v2.16.0 onwards, because newly added Apache 2.0 licensed dependencies are not compatible with GPLv2. Everything before v2.16.0 remains under GPLv2 or later, so the terms depend on which version you are running. A special exception covers linking with OpenSSL, and it is only relevant for OpenSSL 1.x. ## Sources - [Icinga/icinga2 on GitHub](https://github.com/Icinga/icinga2) - [License: GPL-3.0](https://github.com/Icinga/icinga2/blob/master/LICENSE) - [Project website](https://icinga.com/docs/icinga2/latest) - [README](https://github.com/Icinga/icinga2/blob/master/README.md) - [Releases](https://github.com/Icinga/icinga2/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/icinga-icinga2