Before we begin, here’s a list of key terms and acronyms that will be used throughout this article for your reference:

• IDS (Intrusion Detection System): Monitors traffic and alerts on suspicious activity.
• IPS (Intrusion Prevention System): Inline enforcement that can block/drop/modify packets per policy.
• NSM (Network Security Monitoring): Collection of rich network telemetry (flows, DNS/HTTP/TLS/etc.) for detection, hunting, and IR (Incident Response).
• EVE JSON (Extensible Event Format): Suricata’s structured JSON log output (alerts, flows, DNS/HTTP/TLS/SMB, stats).
• SIEM (Security Information and Event Management): Category of platforms that ingest, correlate, and analyze security events (Splunk, Graylog, Elastic SIEM).
• LMP (Log Management Platform): Centralized logging and analytics solutions such as Nagios Log Server (OpenSearch), ELK (Elasticsearch/Logstash/Kibana), and Graylog.
• AF_PACKET / NFQUEUE: Linux mechanisms; AF_PACKET for high-speed capture, NFQUEUE to punt packets to user space for verdicts (accept/drop/modify) in inline setups.
• DPDK / PF_RING / Netmap: A high-speed path that uses shared memory rings between the NIC and user space to move packets with minimal overhead, enabling low-latency, high-throughput processing.
• Hyperscan: High-speed multi-pattern matching engine that accelerates Suricata’s rule matching.
• JA3 / JA3S: TLS fingerprinting methods (client/server) used as metadata signals on encrypted traffic.
• RSS (Receive Side Scaling) / Fanout: NIC/OS features that distribute traffic across cores/queues to enable parallel processing.

What Is Suricata?

Suricata is a high-performance, open-source network threat detection engine that can run as IDS, IPS (inline), and NSM (network security monitoring). It inspects traffic at line rate, parses application protocols, matches rules (Snort-compatible syntax), and emits rich JSON logs for downstream analysis.

Why Suricata Is Useful

Teams use Suricata to:

• Detect and block threats with signature and protocol-aware detection.
• Monitor security posture via detailed logs.
• Hunt and investigate using structured EVE JSON in SIEM/LMP pipelines.
• Enforce policy inline (IPS) to stop known bad traffic at the perimeter of east-west.

How Suricata Works: Core Components

Suricata splits work into capture, decode, stream reassembly, app-layer parsing, detection, and output pipelines that scale across CPU cores.

Operating Modes

Packet Acquisition & Modes

Multithreaded Engine

• Scales across CPU cores; separates capture, decode, stream reassembly, app-layer parsing, detection, and output into pipelines.
• Hyperscan (optional) accelerates multi-pattern matching.

App-Layer Protocol Parsing

Suricata understands common protocols and exposes fields to rules and logs, including URIs, headers, HTTP methods and status, TLS SNI, ALPN, JA3 and JA3S, certificate subjects and issuers, and DNS query names and response codes, enabling precise detection and faster investigations.

Detection

• Rules: Snort-style with Suricata extensions.
• Files & extraction: Identify file types, log hashes, and optionally extract (policy-controlled).
• Flow & anomaly logic: Stateful tracking, TCP normalization, and protocol violations.

Output & Integration

• EVE JSON: Unified, structured logs (alerts, flows, DNS/HTTP/TLS/SMB, stats).
• Ships cleanly into Elastic/Logstash/Kibana, Splunk, Graylog, or any JSON-capable pipeline.
• Optional pcap logging per event or full stream (size/rotation policies).
• Fast.log: Single-line alert file (timestamp, action, sig, src to dst, proto). Fast to read; lacks rich context vs. EVE JSON.

Use Cases & Example Workflows

• Edge IPS: Block malware C2, exploit kits, and known bad domains/IPs inline; alert on policy violations.
• Internal east-west monitoring: Spot lateral movement (SMB admin shares, RDP exposure, suspicious DNS).
• Threat hunting: Query EVE for rare TLS fingerprints, odd user agents, and beacon-like flows.
• IR support: Pivot from an alert to related flows, HTTP requests, and DNS lookups; extract files for sandboxing.
• Compliance & auditing: Prove that disallowed services are blocked and sensitive protocols are encrypted.

Best Practices & Tips

• Curate rulesets: Start with Emerging Threats (ET Open/Pro) plus org-specific rules; disable noisy signs; use thresholds/suppress for chatty networks.
• Log with purpose: Enable just the EVE records you’ll actually use (flows, DNS, HTTP, TLS, alerts).
• Stage changes: Test new rules and IPS actions in IDS mode first; promote to inline after validating FP/FN rates.
• Context matters: Tag sensors, VLANs, and subnets; enrich EVE downstream with asset/owner/criticality.
• Document scope & approvals: Especially for IPS and track who approved what traffic to block and where.
• Mind encrypted traffic: Use metadata (SNI, JA3/JA3S, cert fields, and flow patterns) and policy controls when payloads are opaque.

Strengths and Trade-Offs

Useful links

Suricata • User Guide

Suricata • Eve JSON Output

Suricata • Hyperscan

Wireshark Deep Dive

Ethics, Safety, and Policy

• Obtain explicit authorization for monitoring/inline blocking on sensitive networks.
• Use change windows with defined rollback plans for IPS deployments.
• Maintain auditable records of ruleset changes and block decisions.
• Follow least-privilege and data minimization for captured context and extracted files.
• Ensure HA/fail-open/closed behavior is documented, tested, and approved by stakeholders.

Summary

Suricata turns raw traffic into actionable security telemetry and, when run inline, into enforcement. With disciplined deployment that includes sensible capture choices, tuned rule sets, purposeful logging, and staged IPS, it provides a reliable foundation for threat detection, exposure management, incident response, and compliance.

What Nagios Mod-Gearman Does

Nagios Mod-Gearman (NMG) provides a way of offloading active check execution from the Nagios monitoring engine (in Nagios Core, Nagios XI, and Nagios CSP) to separate worker Linux servers. This capability provides a variety of benefits:

• Load Reduction: Having another system execute check plugins can significantly reduce the load on your Nagios server, increasing the number of total checks possible.
• Load Balancing: Multiple workers can be employed to more evenly distribute the check load.
• Distributed Monitoring: Remote workers can be employed to check assets on remote network segments and forward the results upstream to your Nagios server.

By offloading the checks, you’ll be able to maximize the number of checks a single Nagios server can run and to check even remote networks and secured subnets that you don’t have inbound access to from your Nagios server.

How it Works

The two components of Nagios Mod-Gearman are NMG Server and NMG Worker:

NMG Server

The Server broker module lives on your Nagios server. It is configured either using the module.conf file in Nagios Core 4.5+ and Nagios XI versions between 2024R1.2 and 2024R2.0 or using the new Configuration Editor UI option, a brand-new Premium feature in Nagios XI 2024R2.1. The server module is used to define whether host, service, and specific hostgroup and servicegroup checks should be added to the queue for workers to fetch and execute. You can also define local hostgroups and servicegroups that will be ignored by NMG and handled by the Core engine.

NMG Worker

Although the Worker module can also run on your Nagios server itself, it is mainly designed to run on separate Linux servers. In Core 4.5+, XI versions between 2024R1.2 and 2024R2.0, and in situations where inbound access to the worker server from your Nagios XI server on Port 22 is not available, it is configured using the worker.conf file. In XI 2024R2.1+ workers can be configured using the Manage Workers UI option.

Each worker can be assigned to handle the general host and service queues, or specific hostgroups and servicegroups. By assigning only certain groups to your worker, you can achieve distributed monitoring even in complex networks.

Plugins and Data Paths

An important note is that any plugins you wish a worker to execute need to be installed on the worker system. The Deploy function of Remote Workers will handle installation of the default plugins in Nagios XI, but custom plugins and their requirements will need to be manually added to any workers you want to handle checks that require them.

Worker communication with the NMG Server module is all inbound to your Nagios server from the workers on port 4730, so inbound access from Nagios to the workers is not necessary for Gearman itself to function. Workers reach out to Nagios both to check the queue to determine if there are checks they need to run and to forward back the results.

The Manage Worker function in the XI, which enables you to configure, deploy, and sync workers and settings right from the UI, requires inbound network access to the worker via SSH on Port 22.

This diagram outlines the direction of data flow in an NMG setup that includes both an inbound-accessible worker on the same network as Nagios and a worker running on a remote network:

Initial Setup

If you’re using Nagios XI 2024R2.1+, NMG is pre-loaded and can be configured entirely in the web interface. Simply navigate to the Configure > Remote Workers menu. This guide covers all aspects of managing NMG from the XI UI, including an explanation of each Server and Worker setting:

Managing Nagios Mod-Gearman in the Nagios XI UI

If you’re using a Nagios XI version between 2024R1.2 and 2024R2.0, you can install and manage NMG from the command line.

In situations where inbound access to a worker is not possible, although you won’t be able to leverage the Manage Workers option in the XI interface, you can still manually install and leverage NMG workers. You’ll also still be able to centrally manage your NMG Server settings with the Configuration Editor. This document covers Server installation (p2) and Worker installation (p5) :

Integrating NMG with Nagios XI

Details on managing the Server module queue and Worker module settings from the command line via their text-based configuration files in various use cases can be found here:

Managing NMG Queues and Workers

If you’re using an older version of Nagios XI along with Mod Gearman, there is a path to using Nagios Mod Gearman. You’ll need to upgrade your XI install to at least 2024R1.2, then you can load Nagios Mod Gearman and migrate your configurations:

Migrating from Mod-Gearman to Nagios Mod-Gearman

Additional Resources

Compiling Nagios Mod-Gearman

Nagios Mod-Gearman Github

Project Page on nagios.org

Great Directions: Understand Architecture and Data Paths in Nagios Tools

In this article, we’ll take a quick look at how it works and what it does, as well as provide links to detailed documentation and additional resources to help you make the most of your Apache webserver geoip data.

Using the Map Panel

Since the Logstash Geoip plugin and a GeoIP Filter are now loaded in Log Server by default, setup is as simple as creating a new Map panel in any custom Dashboards you’d like to visualize geoip data in. Full setup details to help you get it up and running in minutes can be found in this document:

Using the Map Panel in Nagios Log Server

Here’s a look at a custom Apache dashboard that incorporates the panel, along with several other useful panels to help you dig into your webserver data:

This article provides an overview of other valuable options you can incorporate to create an ultimate Apache Dashboard like the one above:

Create a Great Apache Dashboard in Nagios Log Server R2

Customizing the Look of Your Maps

The default MapLibre demotiles style is a great starting point, but many other options are available online. As long as the styles you wish to use meet the MapLibre style specifications, they should work. Here’s an example of four custom styles from maptiler.com:

Simply enter the style’s URL in the Tile API URL field, and (if it’s not part of the URL, which in the case of the above examples it is), then enter the API key in the Tile API Key field to leverage other options.

Getting Started

If you’re not already using Nagios Log Server, a great starting point would be to use the free 30-day, fully functional trial version:

Free Trial Download

We’d also be happy to offer you a custom Demo session to provide you with a guided tour of Log Server, or a Quickstart remote session with one of our support techs if you’d like some hands-on help with your trial setup.

If there’s any way we can be of help, please feel free to email us at sales@nagios.com so we can assist you further!

Benefits of Using the Wizard

• Rapid Deployment: Automated setup saves configuration time.
• Customizable Metrics: Monitor only what matters.
• Flexible Alerting: Set warning and critical thresholds per metric.
• Intuitive Interface: Fully integrated into Nagios XI’s Monitoring Wizard.
• Metrics Monitored: CPU usage & load, memory availability, disk usage, system uptime, network traffic, running processes, and hostname information.

Prerequisites

Before proceeding, ensure:

• Nagios XI 2024R2.0+ installed (the Zabbix Agent Wizard is included by default).
• Zabbix agent running on the target host (port 10050/tcp open).
• Administrator credentials for XI and the host.

Security Note: Always use trusted sources for downloads. Ensure secure communication (e.g., TLS encryption) is configured for the agent.

Step 1: Launch the Wizard

• In the XI web UI, go to Configure > Configuration Wizards.
• Select Zabbix Agent Wizard, then click Next.
• Enter the host’s IP address or FQDN when prompted.

Step 2: Configure Host Monitoring

• Enter Host Name: Provide a unique display name for the host.
• Select Metrics: Tick the metrics you want to monitor (CPU, memory, disk, network, uptime, processes).
• Define Thresholds: Set warning and critical values for each metric.

• Make selections for your other monitoring settings in Steps 3-5, defining key aspects such as the check interval, notification settings, host and service groups, and parent-child relationships.
• Click Finish and Apply to apply your settings and finish the wizard.

The wizard automatically creates and applies the necessary configurations.

Step 3: Verify Monitoring and View Results

3.1 Manual Testing (Optional)

You can run the following command from the command line of your Nagios XI server to verify things are working:

/usr/local/nagios/libexec/check_zabbix_agent.py \ -H 192.168.1.50 --check cpu -w 80 -c 90

/usr/local/nagios/libexec/check_zabbix_agent.py \ -H 192.168.1.50 --check cpu -w 80 -c 90

Example output:

OK: CPU usage 22.3% | cpu_usage=22.3;80;90
CRITICAL: Available memory 72MB | available_memory=72MB;200;100

OK: CPU usage 22.3% | cpu_usage=22.3;80;90
CRITICAL: Available memory 72MB | available_memory=72MB;200;100

3.2 Service Status

Go to Home > Details > Service Status, then search for and locate your new host to view the status of it’s services.

Performance Graphs

Troubleshooting Common Issues

Conclusion

By following these three steps, you’ll have Zabbix-agent metrics in Nagios XI in under 10 minutes, eliminating manual setup and boosting monitoring efficiency.

Additional Resources

• Nagios Support Forum
• Nagios XI Documentation
• Nagios XI Admin Guide

Prerequisites

• You have Internet or Ethernet access
• Your host is running Linux or Windows

Installing the Windows Exporter from Prometheus Community GitHub onto a Windows Host

1. Download the latest version from GitHub

• Go to https://github.com/prometheus-community/windows_exporter
• Look for the latest release and download the amd64.msi file

2. Run the installer

• In the initial Custom Setup section, choose Entire feature will be installed on local hard drive under Firewall Exception. This will add an inbound permission for the Exporter listening port.

• Click all the options that say Next or Proceed in the installer
  • You do not need to change or add any other information to use the Prometheus Wizard in Nagios XI, you can simply keep the defaults.

• It will say it is installed
• (Optional): Confirm it is up and running by entering http://<HOST_IP>:9182/metrics

With all the above steps completed, your Windows system is now properly configured for Prometheus monitoring, and you’re ready to move on to integrating it with Nagios XI.

Installing and Running the Prometheus Node Exporter on a Linux Host

1. Download the latest version using command line

• Go to https://prometheus.io/docs/guides/node-exporter/
• Right click the Linux download link and select Copy Link to get exactly what you need to enter in the below wget command.
• On your Linux host, open the terminal
• Run the following command:
  

# wget https://github.com/prometheus/node_exporter/releases/download/v<VERSION>/node_exporter-<VERSION>.<OS>-<ARCH>.tar.gz

This will download the Node Exporter to your Linux host.

2. Run Node Explorer

• Run the following commands:
  • tar xvfz node_exporter-*.*-amd64.tar.gz
  • cd node_exporter-*.*-amd64
  • ./node_exporter

With these above steps completed, your Linux host is ready for Prometheus monitoring, and we are ready to move on to integrating with Nagios XI.

Conclusion

With this, we’ve set it up the data exporters and are ready to configure monitoring in Nagios XI, enabling us to gather all of the same data the same way that Prometheus does, giving us access to the detailed information it provides while showing the data in XI in a clear way.

Prerequisites

• Know the IP address of your host
• Your Host is Linux or Windows
• You have the Linux Exporter or Windows Exporter installed on your host
  • If you need help with this, you can refer to this article and come back

Configuring Hosts using the Prometheus Wizard

As long as you are using the premium version of Nagios XI, you will automatically have the Prometheus wizard. If you are not using premium, you will need to upgrade to access the wizard.

• Go to Configure (gear icon) > Configuration Wizards
• Find and select Prometheus

• Enter the host IP Address
• Select the Operating System (Windows or Linux)
• Do not change the host port, it will select the default for both Windows and Linux

By default, the wizard will be set up to perform services for the CPU usage, memory usage and the disk usage.

You can add more services that the exporter grabs by scrolling a little lower, should you wish to also monitor any of these services simply click them or hit select all.

Verify Monitoring

On the homepage find your new host and check its services. You’ll be able to see all the services and depending on how long they have been running you can see a graph showing the changes over time.

As you can see with our new host, it has started to monitor all services that we had selected.

Conclusion

Integrating the Prometheus Wizard with Nagios XI streamlines performance monitoring, greatly improving the efficiency and responsiveness of your infrastructure oversight. With this intuitive tool, administrators can easily tap into key metrics, quickly detect issues, and maintain the health and stability of their systems.

To learn more about using monitoring wizards in Nagios XI, you can take a look at this document:

Understanding and Using Configuration Wizards in Nagios XI

Setting up Your Apache Dashboard

Start Collecting Data

First off, you’ll need to set up your Apache webserver to send its logs upstream to your Log Server cluster. Simply click the green + Add Log Source button at the top of the interface and follow the instructions in the Apache Server section.

Build a Foundation and Save It

Once you have data coming in, navigate to Dashboards and select the built-in Nagios Log Server Search dashboard. Before making any changes, select Save as from the top menu and save the dashboard under a new name like Apache Dashboard, choosing either to save it as a personal dashboard (only visible to your login) or Global (visible to all Users).

Another approach would be to start with the built-in Empty Dashboard, but since Log Server Search already has an Events Over Time histogram panel and an All Events table, both of which we’ll want in our Apache dashboard, it saves time to start with it instead.

It’s also worth saving your Dashboard regularly as you build it, so you don’t lose any of your work if you bounce to another section of the interface accidentally.

Narrow the Field

Before we add panels, let’s narrow our results a bit to just focus on Apache logs. To do so, we’ll add two queries:

type: apache_access

type: apache_error

If there are other things you might like to see reflected in your Events Over Time histogram, you can add them as well. Things like the following simple queries might be worth paying attention to:

http.response.status_code:403

http.response.status_code:404

You can also simply click the 404 and 500 default query templates to load detailed queries focusing on those response codes and to use as a reference for creating your own more complex queries.

One advantage of combining multiple smaller queries is that the color you select for each query will appear in the Events Over Time panel, giving you quick visual insight into the volume of results reflecting each query:

Add Your Custom Panels

Now that we’ve created a basic dashboard and narrowed down the data set to relevant logs, it’s time to add a few key panels to our Apache Dashboard.

To add a panel, click the + sign on the upper right, at the top of the Row.

Note that when your new Panel populates to the dashboard, it will appear at the bottom of the Row, below the All Events table. Simply click the top of any Panel you wish to move and drag it to where you want to place it, and resize Panels as needed by clicking and dragging from the bottom-right or bottom-left corner.

The following three options are a great start for Apache data analysis:

http Response Codes

This panel will show you the http response codes generated by your webserver, helping you quickly identify things like broken pages (404 codes), visitors attempting to access unauthorized resources (403 codes), and webserver-side issues with completing requests (500 codes).

Field: http.response.status_code

Apache Hits

This panel will provide insight into the top IP addresses of visitors to your site. You can adjust the ‘Count’ field in the Edit Panel form to show more or less IPs.

Field: source.address

Top URLs

This panel will enable you to see the top URLs visited on your site, providing insight into everything from user behavior to code injection attempts.

Field: url.original

Add a Map

Another awesome panel for Apache data is the Map panel, which enables you to leverage geoip data in your Apache logs to visualize where hits are coming from geographically.

Field: source.geo.location

The Final Dashboard

With those panels added and customized, you now have a great Apache Dashboard to reference anytime you want to dig into the details.

You may also wish to get proactive alerts when certain events are collected, such as 404 response codes. You can learn more about turning queries into alerts in the following guide:

Alerting on Log Events with Nagios Log Server

You can learn more about creating and managing Dashboards and Queries here:

Analyzing Logs with Nagios Log Server R2

Finally, this article highlights all of the updates and enhancements in Nagios Log Server R2 in case you’re new to Log Server or are still running version 2024R1:

In this article we’ll discuss Custom Includes, a way to fine-tune and personalize your experience in the XI user interface (UI).

How to Use Custom Includes

To access the component, navigate to Admin > System Extensions > Custom Includes.

Here you can upload CSS, Javascript, and image files, and once uploaded, select which you want to activate to modify the user interface.

As a simple example, let’s change the header and footer to a new gradient. First, we’ll verify the name of the objects we want to modify by right-clicking them and choosing Inspect in our browser:

Now that we’ve determined the object names, we’ll take the easy route and generate some custom CSS gradient code using a free web generator like https://cssgradient.io/. Finally, we’ll create two files in a text editor and save them as .css.

Header-Gradient-Blue.css

#header {
    background: #020024;
    background: linear-gradient(90deg,rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 35%, rgba(0, 212, 255, 1) 100%);
}

Footer-Gradient-Blue.css

#footer {
    background: #020024;
    background: linear-gradient(90deg,rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 35%, rgba(0, 212, 255, 1) 100%);
}

Now we’ll upload the files in the Custom Includes menu, click their checkboxes, and click Save Changes. Once you refresh your browser or bounce to a new menu, you’ll see the style change:

We could take the customization further by customizing objects like leftnav, and the mid-menu section titles. Regarding section titles, they do take a bit more work since each is an individual object. For example, to customize the section titles in the Home menu, we’d load a .css file with the following:

#mid-menu-home-section-favorites {   
	background: #020024;
	background: linear-gradient(90deg, rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 91%, rgba(0, 212, 255, 1) 100%);
}

#mid-menu-home-section-quickview {   
	background: #020024;
	background: linear-gradient(90deg, rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 91%, rgba(0, 212, 255, 1) 100%);
}

#mid-menu-home-section-details {   
	background: #020024;
	background: linear-gradient(90deg, rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 91%, rgba(0, 212, 255, 1) 100%);
}

#mid-menu-home-section-graphs {   
	background: #020024;
	background: linear-gradient(90deg, rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 91%, rgba(0, 212, 255, 1) 100%);
}

#mid-menu-home-section-maps {   
	background: #020024;
	background: linear-gradient(90deg, rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 91%, rgba(0, 212, 255, 1) 100%);
}

#mid-menu-home-section-incident-management {   
	background: #020024;
	background: linear-gradient(90deg, rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 91%, rgba(0, 212, 255, 1) 100%);
}

#mid-menu-home-section-monitoringprocess {   
	background: #020024;
	background: linear-gradient(90deg, rgba(2, 0, 36, 1) 0%, rgba(9, 9, 121, 1) 91%, rgba(0, 212, 255, 1) 100%);
}

Here’s a look at the Home menu with the above CSS loaded, as well as a new file to modify leftnav to match the gradient we chose for our header and footer:

Note that the Neptune theme won’t be impacted by CSS changes made to Custom Includes. For best results, customize the Modern Dark and Modern Light themes.

You can also incorporate images into your customization, as detailed toward the end of this guide:

Using Custom Includes in Nagios XI

To return the UI to its default look, simply uncheck your custom files in the Custom Includes settings and save your changes.

How to Use the Custom Logo Component

You may also wish to add your own company logo to the upper left of the Nagios XI UI, which can be done easily with the Custom Logo Component found in Admin > System Extensions > Components > Custom Logo.

You’ll need to copy whichever file you wish to use as your new logo to /usr/local/nagiosxi/html/images on your Nagios XI server and make sure it’s 100px X 42px. Also make sure that you click the Enable Custom Logo checkbox once your settings are updated to activate the change.

In this example we’re having a little fun with the feature, but for practical uses it’s a great way to brand the UI and make your users feel at home by using your company or department’s official logo.

Note that in the Custom Logo menu you can also change the Target URL for the logo to any URL you’d like.

If you aren’t already using Nagios XI and would like to try out these features, we offer a free trial version you can take for a spin:

Nagios XI Free Trial Download

We’d also be happy to offer you a custom Demo session if you want a guided tour of our solutions or a free Quickstart remote session with a sales engineer to help you get a few things set up. You can email sales@nagios.com for details on setting up either option.

1. Using the Report

To access the report, navigate to the Reports menu, then select Capacity Planning. Next, select the Period (how far into the future you want to project), and select the specific Host, Hostgroup, or Servicegroup to graph the results for.

Once you make all of your customization selections, you can then save, email, export, and even (another great Enterprise Edition feature) schedule the report for automatic delivery at set times.

Alternately, you can navigate to the Status Detail page for a service and go to the Capacity Planning tab to view projections.

The options tabs to the right of the initial graph provide access to a data Summary, all of the individual data points, and the option to customize your Time Period and Extrapolation Method.

2. Adding Graphs to Dashboards

You’ll notice the Dashify icon on the upper left of each Capacity Planning graph, which you can click to easily add them to your Dashboards. This provides an easy way to quickly access at-a-glance projections for key services in your environment and to roll them into other Dashboards you’ve created.

3. Using the Wizard

It’s even possible to set up alerts on projections using the Capacity Planning Wizard, found in the Configure > Configuration Wizards menu. In Step 1 you’ll choose which service to monitor. Then in Step 2 you’ll choose how far ahead the check should look, what algorithm it should use, the projected value at which you want to be alerted, and how many days in advance of the resource hitting the custom value you wish to be alerted.

You can choose to either add the newly created services to the host under which the services producing the performance data reside or check the “Put all new services on a specific host” checkbox to assign them elsewhere (for example, to a dummy host reserved just for capacity planning checks).

You can click the Render Graph link at the bottom of the wizard to see a graph of current and projected data and to see where your Custom Value selection falls within it.

Once the checks are created, you can monitor them like any other service or even roll them into your Business Process Intelligence groups:

Resources

For a more detailed overview of using Capacity Planning, take a look at this guide:

How to Use Capacity Planning in Nagios XI

If you’d like a tour of all of the Enterprise Edition features, this article provides a comprehensive overview:

10 Great Features of the Nagios XI Enterprise Edition

If you’d like to try Capacity Planning out for yourself, we offer a free trial version you can take for a spin:

Nagios XI Free Trial Download

We’d also be happy to offer you a custom Demo session if want a guided tour of our solutions, or a free Quickstart remote session with a sales engineer to help you get a few things set up. You can email sales@nagios.com for details on setting up either option.

In this guide, we’ll walk you through the process of creating alerts in Log Server 2024R2 so you can monitor your systems more effectively.

1. Log into Nagios Log Server

Start by logging into Nagios Log Server using the credentials you created during the installation process.

2. Create New Alert

Once logged in, navigate to the left-hand menu and click the bell icon to access the Alerting section. Here, you can view any previously created alerts. To create a new alert, click on “New Alert.” A configuration window will appear.

3. Fill in the following to define your alert

Alert Name

• Choose a name that accurately describes the purpose of your alert (e.g., “Failed SSH Login.”)

Type

• Query: Ideal for checking historical log data within a specified time period.
• Real-Time: Monitors logs as they are ingested, providing immediate detection.
• Host Freshness: Tracks if a host is actively sending logs, useful for detecting system outages.

In this example, we’ll use the Query type and leave the next option as undefined.

Check Interval

• This determines how often the system checks the query. You can specify intervals in seconds (s), minutes (m), hours (h), or days (d).

Example: 1m to check every minute.

Lookback Period

• Defines how far back the system will look when executing the query.

Example: 15m to examine the last 15 minutes of logs.

Warning Threshold

• The number of matching events that trigger a warning notification.

Critical Threshold

• The number of events that escalate the alert to critical status.

In this scenario, we’ll set the warning threshold to 2 and the critical threshold to 3. This is especially useful for identifying brute-force login attempts before they escalate into larger issues.

Nagios Log Server offers several notification options:

• Nagios (send using NRDP.)
• Execute Script.
• Send an SNMP Trap.
• Email Users.
  

You can configure multiple alerts and customize how notifications are delivered—or even trigger automated scripts in response to alerts. For example, you could automatically shut down a machine if a certain condition is met.

4. Select the Take Ownership Option

You’ll also see an option to “Take Ownership”. Selecting this checkbox ensures that only users with admin rights can modify or delete the alert.

5. Create Alert

Once all settings are configured, click “Create Alert”. If you choose the Query type, you can find your alert under the Query section.

6. Final Steps

Click the three-dot menu next to your alert to access the following options:

• Show alert in Dashboard.
• Run this alert now.
• Deactivate this alert.
• Edit this alert.
• Remove.

That’s it! You’ve successfully created an alert in Log Server 2024R2. Alerts are a powerful feature that can significantly improve your ability to respond to system issues in real time. If you prefer a visual guide, we recommend checking out our YouTube tutorial, which walks through this entire setup step-by-step.