Great Directions: Understand Architecture and Data Paths in Nagios Tools

Nagios solutions can monitor just about anything, and in a variety of ways and directions. There are also various methods available to combine results from multiple Nagios solutions and to architect your monitoring to suit large, geographically separated, and cloud infrastructures. Let’s explore architecture and the path data travels across the Nagios ecosystem.

Nagios XI Check Architecture

Nagios XI can monitor both actively and passively, using agent-based and agentless methods. The best approach will depend on the specifics of your environment and requirements.

Agent-based vs. Agentless Checks

With agent-based methods, a lightweight agent is installed on the monitored host, which enables Nagios to connect to it and run checks. Agents provide the flexibility to monitor a wider array of metrics than agentless methods, since they are not limited strictly to data made available by a native protocol and can incorporate custom plugins. However, agents slightly increase administrative overhead, since they need to be installed and updated. A smart agent like NCPA provides even more utility by enabling Nagios XI to scan your hosts for things like drives and running services/processes, and by providing powerful additional tools like a web UI and check API.

With agentless methods, a native protocol like SNMP is leveraged to run checks. Although, as stated above, an agentless method will be limited to the specific metrics the native protocol can produce, agentless methods don’t require direct updates outside of regular software and firmware updates. Native protocols may also enable you to scan your hosts for elements that can be monitored. For example, the Network Switch and Router wizard will scan your network device for interfaces.

Active Checks

Active checks in Nagios XI are scheduled and executed by the Nagios server, so communication is outbound from Nagios to the monitored host. Examples of active checks include:

• NCPA and NRPE agent checks.
• SNMP polling (for example, checks configured using the Network Switch and Router wizard).
• Checks created with the Network Analyzer or Log Server wizards.
• Website checks (using the Website monitoring wizard).

Active checks tend to be easier to configure since they can often be set up using Nagios XI’s comprehensive suite of monitoring wizards but do require a direct inbound network path to your host.

Passive Checks

In a passive model, checks are initiated by the remote host and sent upstream to Nagios XI.

Examples of passive checks include:

• NCPA (which has both an active and passive capability) and NRDP agent checks.
• SNMP Traps.
• Nagios Network Analyzer and Nagios Log Server alerts configured in those tools (which use NRDP to send results upstream to Nagios XI).

Passive checks can be more challenging to initially configure but are useful in situations where inbound access to the monitored host network isn’t possible or desirable. Passive checks also reduce load on your Nagios XI server, enabling you to get more checks out of a single monitoring server.

Event Handlers and Actions

Event handlers are automated, scripted actions that Nagios XI can be configured to execute in response to detected state changes. Actions are manually executed using clickable icons in the UI. In both cases, Nagios executes the handler, and communication is outbound from Nagios to the target host. If the handler or action is designed to execute a script (for example, to restart a stopped service), this is often carried out by a local agent such as NCPA running on the remote host.

Network Analyzer

Flow data from network devices and servers running flow clients travels upstream from the devices to Network Analyzer, which acts as a collector and aggregator.

Nagios Log Server

Log data is sent upstream to Log Server by the sources you are collecting from. Data is also passed back and forth between the cluster instances by Opensearch for clustered redundancy of your collected logs. One option is to send the data directly to individual Log Server instances.

This approach works well unless the instance breaks, in which case incoming log data will have nowhere to go and will queue on the sending source until the instance recovers. As long as you’re running a multi-instance cluster, previously collected logs will still be protected, but new results won’t be collected.

A more resilient approach is to incorporate a load balancer or round robin DNS setup, so that incoming log events from the sources will always be routed to an available instance.

Nagios Fusion

Nagios Fusion polls remote Nagios XI, Nagios Core, Nagios Log Server, and Nagios Network Analyzer servers via HTTP/HTTPS. Communication is initiated by an outbound connection from Fusion to your fused Nagios servers, but since standard web ports are used it’s often easier to get approval for this architecture from network security teams.

Federated Monitoring

In a federated architecture, data is sent upstream from remote Nagios XI and Core servers to a centralized XI server. The transmission is handled by NRDP, so it is sent via HTTP/HTTPS just like regular NRDP passive checks.

The pro of this model is that it provides centralized reporting and notification management capabilities, and since the incoming results are passive, enables the centralized XI server to handle more total checks than if it were running the checks itself. However, Fusion is better suited to handle massive scale.

You can find more details about the above distributed architecture options in this document:

Nagios Monitoring Architecture Solutions For Large Organizations

Hopefully, the above overview has provided you with great directions to help you navigate the planning, execution, and cultivation of your Nagios deployment. Here are a few additional resources to help you succeed with Nagios:

How to Maximize Your Free Trial of Nagios XI

Nagios XI Enterprise Edition: 10 Great Features

Please feel free to email us at sales@nagios.com if there’s anything we can assist with!