Due to architectural changes introduced in Nagios Log Server 2024R2, an in-place upgrade from 2024R1.x is not supported. Instead, deploy a new Nagios Log Server 2026R2 Cluster and migrate data using the included migration utility.

During this migration, you may run into issues you can resolve on your own before contacting Nagios Support. This article covers how to review migration logs, run the migration manually, and identify common errors.

For migration instructions, see the Migrating to Nagios Log Server 2026 document.

Verify Versions

Before troubleshooting, confirm that you have used supported versions for the source and destination clusters:

• Source Cluster: Nagios Log Server 2024R1.3.8
• Destination Cluster: At least Nagios Log Server 2026R2

Common Migration Issues

Many issues can be resolved based on the log output, without the need to contact Nagios Support. For example, if you see that the logs show connectivity issues, it could be related to network connectivity problems.

Here is a list of common migration issues:

• Network connectivity problems
• Authentication failures
• OpenSearch indexing errors
• Data mapping conflicts
• Permission issues
• Dashboard or settings migration failures

Review Migration Logs

On the target instance, you can grep the logs to find all the messages generated by the migration, to isolate issues:

RHEL-Based Systems

cat /var/log/messages | grep "Nagios Log Server Migration"

cat /var/log/messages | grep "Nagios Log Server Migration"

Debian-Based Systems

cat /var/log/syslog | grep "Nagios Log Server Migration"

cat /var/log/syslog | grep "Nagios Log Server Migration"

Run the Migration From the Command Line

Another option is to run the migration from the command line which gives you more flexibility and control, and shows actual errors on the console. You can isolate a specific index, migrate only the log data, or restart the previous migration. Run the following migration script from the command line on the target instance:

php /usr/local/nagioslogserver/scripts/migrate_data.php -s <source_ip>

php /usr/local/nagioslogserver/scripts/migrate_data.php -s <source_ip>

Example:

php /usr/local/nagioslogserver/scripts/migrate_data.php -s 192.168.55.101 -i logstash-2026.07.30 -r

php /usr/local/nagioslogserver/scripts/migrate_data.php -s 192.168.55.101 -i logstash-2026.07.30 -r

This command will migrate the index named logstash-2026.07.30 and restart the previous migration using 192.168.55.101 as the source instance.

Common Parameters:

• -s <source_ip> The IP address of the source cluster. This is required.
• -i <index_name> Migrates the specified index.
• -l Migrates log data.
• -r Restarts previous migration.

Reading Migration Outputs

The following examples show what to look for in the log files or on the console, if performed manually.

Failed Migration Example

{
  "failures": [
    {
      "cause": {
        "type": "mapper_parsing_exception",
        "reason": "object mapping conflict"
      },
      "status": 400
    }
  ]
}

{
  "failures": [
    {
      "cause": {
        "type": "mapper_parsing_exception",
        "reason": "object mapping conflict"
      },
      "status": 400
    }
  ]
}

A mapper_parsing_exception indicates a data mapping conflict during migration. If you see this, please open a Support Case.

Successful Migration Example

{
  "created": 1,
  "version_conflicts": 0,
  "failures": []
}

{
  "created": 1,
  "version_conflicts": 0,
  "failures": []
}

An empty failures array indicates the migration completed without errors.

Before Opening a Support Case

If you still need help, collect the following and upload them to your Support Case:

• Source and destination Log Server versions
• Migration log output
• Any output from the migration script
• Screenshots of reported errors
• Full diagnostic profiles of both instances

Conclusion

Migrating to the latest Nagios Log Server version is a significant step. If you worked through these troubleshooting steps and still see errors, open a Support Case and include the items listed above so our team can review your migration as quickly as possible.

Additional Resources

• Migrating from 2024R1 to 2026
• Backing Up and Restoring Nagios Log Server
• Nagios Log Server Admin Guide
• Nagios Log Server Documentation
• Nagios Support Forum

As a result, many organizations are planning a PHP upgrade. This article describes what you need to consider before a PHP upgrade, so your Nagios software keeps working properly.

What This Means for Nagios Monitoring Solutions 

Nagios XI and our other web-based products (including Nagios Fusion) run on the PHP version installed on your server, so applying your Linux vendor’s PHP security updates is important.

When Nagios software is initially installed, it relies on the base version of PHP that the OS vendor installs. The following is mostly geared towards Nagios XI, but it is applicable to our other software as well. 

For example, RHEL 8 installs PHP 7.2, RHEL 9 installs PHP 8.0, and Ubuntu 24.04 LTS installs PHP 8.3. 

As of October 1, 2026, the current versions of our software require a minimum of PHP 7.4 and have been developed and tested to run on PHP 8.4.

How to Check Your System

Check whether your PHP packages include the PHP2Shell fixes.

RHEL-Based Systems

rpm -q --changelog php-common | grep -i CVE-2026-1096

rpm -q --changelog php-common | grep -i CVE-2026-1096

If the command returns CVE-2026-109618 and CVE-2026-109619, your PHP packages include the fixes. If it returns nothing, apply your Linux vendor’s latest PHP updates, then check again.

Debian Systems

Debian 12

apt list | grep php8.2-common

apt list | grep php8.2-common

If they have this version, they have the patch: 8.2.35-1~deb12u1

Debian 13

apt list | grep php8.4-common

apt list | grep php8.4-common

If they have this version, they have the patch: 8.4.27-1~deb13u1

Ubuntu Systems

Ubuntu 22

apt list | grep php8.1-common

apt list | grep php8.1-common

If they have this version, they have the patch: 8.1.2-1ubuntu2.28

Ubuntu 24.04

apt list | grep php8.3-common

apt list | grep php8.3-common

If they have this version, they have the patch: 8.3.6-0ubuntu0.24.04.13

Example Output (RHEL 9)

[root@nagios-xi ~]# php --version
 PHP 8.0.30 (cli) (built: Oct 21 2026 15:47:44) ( NTS gcc x86_64 )
 Copyright (c) The PHP Group
 Zend Engine v4.0.30, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.30, Copyright (c), by Zend Technologies
[root@nagios-xi ~]# rpm -q --changelog php-common | grep -i CVE-2026-10961
  CVE-2026-109618, CVE-2026-109619

Options to Safeguard Your Installations 

Choose the option that fits your situation. For most PHP2Shell concerns, applying your Linux vendor’s security updates is the fastest and safest path.

If You Need a PHP Upgrade for Security or Vulnerability Concerns

Keep in mind that Linux vendors backport security fixes into the PHP versions they ship, so an older version number does not always mean your system is vulnerable. Use the check above, or check with your Linux distribution vendor, to see if you need to upgrade your version of PHP. 

Contact your Linux distribution vendor for the proper method to update your version of PHP and stay inside the parameters listed in this article. 

If You Need a PHP Upgrade Within the Same Major Version

Nagios strongly recommends that you do not upgrade from one major version of PHP to another (for example, from PHP 7.x to PHP 8.x).

For example, if you are running Nagios XI on RHEL 8, with PHP 7.2, you can upgrade to anything from version 7.4 through the highest, available version of PHP 7.x, but do not upgrade to PHP 8.0 or above.

When Nagios performs the initial software installation, it depends on the major version of all the components that ship with that distribution. A PHP upgrade to a different major version can cause issues with the software, as well as with the OS itself.

If You Need a PHP Upgrade to a Higher Major Version

To maintain the integrity of your installed version of Nagios software, migrate your XI instance to a newer release of your Linux distribution that installs the major PHP version you need.

For example, if you are on RHEL 8, running PHP 7.4 and wish to upgrade to PHP 8.3, back up your XI instance and restore it to a new RHEL 9 or RHEL 10 system. Then perform the PHP upgrade on the new instance to PHP 8.3. 

Related Reading: Backing Up And Restoring XI

Before Any PHP Upgrade 

It is important to perform all PHP upgrades in your test environment before your production environment and take a snapshot or clone of your virtual machine so you can roll back if you encounter any problems. 

After making a PHP upgrade, make sure to install the latest SourceGuardian loaders for the new version. See: Nagios XI – Installing Latest SourceGuardian Loaders. 

We are monitoring this situation and will provide updates as more information becomes available.

Additional Resources

• Nagios XI Best Practices
• Nagios Documentation Hub
• Nagios Support Forum

Performance Comparison

Below are screenshots of the top output of a lab machine configured with approximately 13,000 checks running check_ncpa.py:

And the same machine running the compiled version of check_ncpa:

Before You Begin

The new binary version is being configured by default on new installations of XI 2026R1.7. Upgraded systems keep the Python version by default so that customers can decide to opt in if they have not made any customizations to the Python version of the plugin.

If you want to test the new version of check_ncpa on your upgraded system or switch back to using the Python version, please use the steps below.

As always, we recommend testing the script in your test environment prior to using it in production.

Please note that if you are running Nagios Mod-Gearman (NMG) checks, we recommend waiting for a future version as the current version does not work properly with NMG.

Switching to the Compiled check_ncpa Plugin

1. Before making changes, back up your current configuration. Navigate to Core Configuration Manager (CCM) > Quick Tools > Configuration Snapshots and confirm a recent snapshot is listed. If the switch causes problems, you can restore this snapshot to return to your previous configuration.
2. Navigate to Configure > Core Config Manager > Commands > Commands in the Nagios XI web interface.
3. Search for check_xi_ncpa and click the Edit icon.

4. Change the Command Line from $USER1$/check_ncpa.py to $USER1$/check_ncpa, leaving the remainder of the command intact.

This will force the checks to use the new version of check_ncpa.

5. Click Save, then click Apply Configuration.

Switching Back to the Python Version

To switch back to the Python version, repeat steps 2-5 and change $USER1$/check_ncpa back to $USER1$/check_ncpa.py.

Conclusion

The compiled check_ncpa plugin lets your Nagios XI server run the same NCPA checks with significantly less overhead, freeing capacity to monitor more of your environment on existing hardware. Because the change applies to every service using the check_xi_ncpa command, validate it in a test environment and take a configuration snapshot before switching production systems. If you need to return to the original plugin, switching back takes only a single command edit.

Looking for more ways to get the most out of Nagios XI? Browse the Nagios Library for documentation and how-to guides, or visit Nagios Support if you have questions about switching to the compiled plugin.

Weekly, Monthly, and Yearly Best Practices

A healthy Nagios XI environment requires ongoing maintenance to ensure accurate monitoring, optimal performance, and reliable alerting. This guide outlines key weekly, monthly, and yearly tasks to keep your system in top shape.

Weekly Tasks

Review Unhandled Alerts

Open the Service and Host Problems views to identify alerts that have not been acknowledged or resolved. Investigate recurring or long-standing issues.

Monitor System Resource Usage

Check the Nagios XI server’s CPU, memory, and disk usage using the Performance Info section. High resource consumption could impact monitoring performance.

Check System Logs

Review important log files such as:

• /var/log/messages
• /usr/local/nagiosxi/var
  Look for unusual entries, frequent plugin failures, or warnings that require attention.

Backup Nagios XI Configuration

Verify that scheduled backups are completing successfully. Perform a manual backup before making any configuration changes.

Monthly Tasks

Clean Up Old or Unused Configurations

Remove obsolete hosts, services, and checks using the Core Config Manager. Apply configuration changes after cleanup.

Prune Event Logs and Performance Data

Archive or delete older logs and performance data to save disk space. Configure retention policies under Performance Settings or use scheduled cleanup scripts.

Check for Plugin and Component Updates

Visit the Nagios Exchange and XI update manager to download and apply updates to plugins, components, and configuration wizards.

Test Notification Deliverability

Trigger test alerts to ensure all notification methods (email, SMS, chat integrations) are functional and reaching the correct recipients.

Yearly Tasks

Review Alert Thresholds and Escalation Policies

Ensure thresholds reflect current usage patterns. Update contact groups and escalation rules to match current team structures and responsibilities.

Audit User Accounts and Permissions

Remove inactive user accounts and review permission levels to comply with internal security policies and access control best practices.

Upgrade to the Latest Stable Version

Review release notes, back up your system, and upgrade to the latest stable version of Nagios XI to benefit from new features and security patches.

Test Disaster Recovery Plan

Restore a backup in a test environment to ensure recovery procedures are reliable. Document any updates to the process based on test results.

Document the Current Monitoring Environment

Maintain a detailed record of:

• Monitored hosts and services.
• Custom plugins and event handlers.
• Alert routing and contact methods.
  This is useful for audits, onboarding, and incident response.

Additional Best Practices

• Schedule maintenance tasks using a shared team calendar or task management tool.
• Use configuration snapshots before making bulk changes for quick rollback if needed.
• Regularly communicate monitoring changes or updates to relevant stakeholders.

Helpful Tools Within Nagios XI

Conclusion

Consistent maintenance is essential for a stable and effective Nagios XI deployment. Following this weekly, monthly, and yearly checklist ensures your monitoring system is accurate, secure, and always ready to detect problems before they become critical.

Step 1: Add a New Log Source in Nagios Log Server

1. Log in to Nagios Log Server.
2. Click + Add Log Source or navigate to the Add a Log Source section.
3. Select Linux from the available source types.

Step 2: Run the Auto-Configuration Script on Ubuntu

1. On the Linux Source Setup page, copy the provided curl command.
2. SSH into your Ubuntu 20 machine as a root user.
3. Paste and execute the script:

curl -sS -O http://<NagiosLogServerIP>/nagioslogserver/scripts/setup-linux.sh sudo bash setup-linux.sh -s <NagiosLogServerIP> -p 5544

curl -sS -O http://<NagiosLogServerIP>/nagioslogserver/scripts/setup-linux.sh sudo bash setup-linux.sh -s <NagiosLogServerIP> -p 5544

This sets up rsyslog to forward logs to your Nagios Log Server.

Step 3: Verify Incoming Logs

• Use the Verify Incoming Logs field by entering the Ubuntu machine’s IP.
• Or navigate to Dashboards > Nagios Log Server Search and run:

host.ip:<Ubuntu-IP>

host.ip:<Ubuntu-IP>

• Test log submission with:

logger "This is a test log entry"

logger "This is a test log entry"

• Check if the test log appears in Nagios Log Server.

Step 4: Manually Configure rsyslog (Advanced Users)

If you prefer a manual setup:

1. Verify your rsyslog working directory:

ls -d /var/lib/rsyslog || ls -d /var/spool/rsyslog

ls -d /var/lib/rsyslog || ls -d /var/spool/rsyslog

2. Edit the config file:

sudo nano /etc/rsyslog.d/99-nagioslogserver.conf

sudo nano /etc/rsyslog.d/99-nagioslogserver.conf

Add the following line:

*.* @<NagiosLogServerIP>:5544;RSYSLOG_SyslogProtocol23Format

*.* @<NagiosLogServerIP>:5544;RSYSLOG_SyslogProtocol23Format

3. Restart rsyslog:

sudo systemctl restart rsyslog.service

sudo systemctl restart rsyslog.service

4. Confirm logs are reaching the server:

tail -f /var/log/syslog | grep rsyslog

tail -f /var/log/syslog | grep rsyslog

Step 5: Integrate Log Server with Nagios XI (Optional Alerting)

• Configure Nagios XI to receive alerts for specific log patterns from Nagios Log Server.
• Set up alert queries within Nagios Log Server to trigger notifications in XI.
• Use Event Handlers or the Nagios XI API for automated responses based on log events.

Troubleshooting Tips

• Ensure the Ubuntu system allows outbound traffic to Nagios Log Server on port 5544.
• Check /var/log/syslog for local log activity.
• Review /var/log/rsyslog.log for configuration errors.
• Run the following to confirm rsyslog is active:

sudo systemctl status rsyslog

sudo systemctl status rsyslog

• Use tcpdump to check if logs are sent to Nagios Log Server:

sudo tcpdump -i any port 5544

sudo tcpdump -i any port 5544

Final Notes

• Logs are forwarded over port 5544 by default.
• Use secure log transmission if required by enabling TLS in rsyslog.
• Regularly review log retention and indexing settings in Nagios Log Server.

References

• Nagios Forum
• Nagios XI Documentation

SSL certificates play a crucial role in securing websites and applications by encrypting communication. Expired SSL certificates can lead to security warnings, service disruptions, and loss of trust from users. Nagios XI provides a reliable way to monitor SSL certificates and ensure they are renewed before expiration. This guide will walk you through setting up SSL certificate expiration monitoring in Nagios XI.

Why Monitor SSL Certificate Expiration?

• Avoid Service Interruptions – Prevent downtime due to expired certificates.
• Enhance Security – Ensure continued encryption and protection.
• Maintain Compliance – Meet security standards and best practices.
• Automate Monitoring – Receive alerts before certificates expire.

Option 1: Using the Website Wizard

The built-in Website Wizard in Nagios XI (which uses the check_http plugin), provides the easiest approach to setting up SSL Certificate monitoring. Simply use an https URL in Step 1, and you will see an SSL Certificate check option in Step 2. The Days to Expiration threshold sets the check to alert you if the certificate will expire within the set number of days.

The output of the check will provide you with details on the number of days left before expiration:

You can learn more about the Website Wizard in this guide:

How To Monitor Websites with Nagios XI

Option 2: Using a Custom Plugin

Nagios XI also enables you to use custom plugins, and the check_ssl_cert plugin is commonly used.

Step 1: Install the Required Plugin

Installing check_ssl_cert

cd /usr/local/nagios/libexec
wget https://raw.githubusercontent.com/matteocorti/check_ssl_cert/master/check_ssl_cert
chmod +x check_ssl_cert

cd /usr/local/nagios/libexec
wget https://raw.githubusercontent.com/matteocorti/check_ssl_cert/master/check_ssl_cert
chmod +x check_ssl_cert

Step 2: Create a New Command in Nagios XI

• Log in to Nagios XI and navigate to Configure > Core Config Manager.
• Go to Commands and click Add New Command.
• Configure the command as follows:
  • Command Name:

check_ssl_certificate

check_ssl_certificate

• Command Line:

$USER1$/check_ssl_cert -H $ARG1$ -w $ARG2$ -c $ARG3$

$USER1$/check_ssl_cert -H $ARG1$ -w $ARG2$ -c $ARG3$

• Description: Monitors SSL certificate expiration.
• Click Save and Apply Configuration.

Step 3: Add a New Service to Monitor SSL Expiration

1. Go to Configure > Core Config Manager > Services.
2. Click Add New Service.
3. Configure the service:
   • Host: Select the target website or server.
   • Check Command: check_ssl_certificate.
   • Arguments:
     • $ARG1$ – The domain name (e.g., example.com).
     • $ARG2$ – Warning threshold in days (e.g., 30 for 30 days before expiration).
     • $ARG3$ – Critical threshold in days (e.g., 15 for critical alerts within 15 days).
   • Check Interval: Set the frequency of checks.
   • Click Save and Apply Configuration.

Step 4: Test the SSL Monitoring Setup

After configuration, force a check in Nagios XI:

/usr/local/nagios/libexec/check_ssl_cert -H example.com -w 30 -c 15

/usr/local/nagios/libexec/check_ssl_cert -H example.com -w 30 -c 15

If the certificate is valid, the output should indicate the number of days remaining before expiration.

Step 5: Configure Notifications and Alerts

1. Go to Configure > Notification Preferences.
2. Enable email or SMS notifications.
3. Set up escalation rules to alert different teams as the expiration date nears.

Conclusion

Monitoring SSL certificates with Nagios XI ensures your website and applications remain secure and accessible. By setting up automated checks and alerts, you can avoid expired SSL issues and maintain continuous encryption. Regularly review your SSL monitoring setup to ensure effectiveness and compliance with security best practices.

Nagios XI is a powerful monitoring solution that provides extensive reporting capabilities. With the right reports, businesses can gain valuable insights into their IT infrastructure’s performance, availability, and trends. This article explores how to generate and share performance reports using Nagios XI.

Understanding Nagios XI Reporting Features

Nagios XI offers a variety of reporting tools that allow users to track and analyze system performance. These include:

• Availability Reports – Track system uptime and downtime.
• Capacity Planning Reports – Identify future resource needs.
• Executive Summary Reports – Provide high-level overviews of system health.
• Service Level Agreement (SLA) Reports – Ensure compliance with business agreements.
• Alert Reports – Analyze historical alert trends.

How to Generate Performance Reports in Nagios XI

Generating reports in Nagios XI is a straightforward process. Simply follow these steps to create a performance report:

Step 1: Access the Reporting Module

1. Log in to your Nagios XI dashboard.
2. Navigate to the Reports tab.
3. Select the type of report you wish to generate.

Step 2: Configure Report Parameters

1. Choose the hosts or services you want to include.
2. Set the time period (e.g., last 24 hours, last 7 days, custom range).
3. Apply filters to refine the data.

Step 3: Generate the Report

1. Click the Run Report button.
2. Review the generated report to ensure it contains the necessary data.

How to Share Performance Reports

Once the report is generated, it can be shared with relevant stakeholders in multiple ways.

Exporting Reports

Nagios XI allows users to export reports in various formats:

• PDF – Ideal for sharing in formal reports or presentations.
• CSV – Useful for further data analysis in spreadsheet applications.
• PNG/JPG – Suitable for embedding in documents or emails.

Automating Report Delivery

Nagios XI enables automated report scheduling and delivery:

1. Navigate to the Scheduled Reports section.
2. Select the report to automate.
3. Configure the delivery frequency (e.g., daily, weekly, monthly).
4. Enter recipient email addresses.
5. Click Save Schedule to activate automated delivery.

Best Practices for Effective Reporting

To maximize the impact of Nagios XI reports, consider the following best practices:

• Use visual elements – Charts and graphs make data more digestible.
• Schedule reports strategically – Ensure reports are sent at optimal times for decision-making.
• Customize reports for different audiences – Technical teams may require more granular data, while executives may prefer high-level summaries.
• Regularly review reports – Stay proactive by analyzing trends and addressing potential issues before they escalate.

Additional Resources

To enhance your use of Nagios XI, here are some helpful resources:

Nagios XI Resourcess Page — The ultimate hub for Nagios XI product-specific resources, guides, and best practices.

Nagios XI Admin Guide – Explore full guides on how to use Nagios XI.

Nagios Support Forum – Ask questions to the Nagios community for help and advice.

Nagios YouTube Channel – Learn through step-by-step video tutorials how to use Nagios Monitoring Solutions.

Nagios Webinars – Discover live webinar demonstrations and Q&A sessions led by experts.

Conclusion

Nagios XI’s robust reporting capabilities empower businesses to monitor IT performance effectively and make data-driven decisions. By generating, customizing, and sharing reports efficiently, organizations can enhance operational efficiency and maintain system reliability. Start leveraging Nagios XI reporting today to gain deeper insights into your IT environment.

Happy monitoring!

Nagios Log Server 2024R2 is a powerful tool for centralized log management, analysis, and monitoring. It enables IT teams to track system health, identify security threats, and streamline compliance reporting. By aggregating logs from various sources into a single dashboard, organizations can proactively detect issues, improve efficiency, and meet regulatory requirements. This article explores real-world use cases where organizations benefit from deploying Nagios Log Server 2024R2.

1. Centralized Log Management

Why It Matters

Managing logs across multiple systems manually is inefficient and prone to errors. Without a centralized log management solution, IT teams must sift through logs on individual devices, leading to delays in detecting and resolving issues. Nagios Log Server 2024R2 centralizes logs from servers, applications, and network devices, providing a single source of truth for log data.

Use Case

A large enterprise with multiple data centers uses Nagios Log Server 2024R2 to collect and analyze logs from thousands of devices, reducing troubleshooting time and improving operational efficiency. With automated log aggregation, IT teams can quickly search logs, correlate events, and generate insights that enhance system reliability.

Related Reading

Texas A&M Forest Service: Achieving Operational Excellence with Nagios Log Server

2. Security Event Monitoring

Why It Matters

Cybersecurity threats are becoming increasingly sophisticated, requiring organizations to actively monitor logs for signs of intrusion. Nagios Log Server 2024R2 helps businesses detect security anomalies, unauthorized access attempts, and potential breaches before they escalate.

Use Case

A financial institution leverages Nagios Log Server 2024R2 to detect unusual login patterns and access attempts. By setting up real-time alerts, the IT security team can take immediate action when a suspicious event is detected. For instance, if an administrator account experience repeated failed login attempts, an alert is triggered, allowing the security team to investigate and mitigate potential threats.

Related Reading

Streamlining Logistics and Security with Nagios XI

3. Compliance Reporting

Why It Matters

Regulatory frameworks such as HIPAA, PCI-DSS, and GDPR require businesses to retain and monitor logs for a specified period. Manual log collection and analysis can be labor-intensive and error-prone, making compliance challenging.

Use Case

A healthcare provider uses Nagios Log Server 2024R2 to generate audit-ready reports for compliance with HIPAA regulations. By automating log retention and generating compliance reports on demand, the organization ensures that it meets regulatory requirements without excessive manual effort. Additionally, role-based access control (RBAC) ensures that only authorized personnel can view sensitive log data.

Related Reading

Achieve Regulatory Standards Compliance with Nagios Monitoring Solutions

4. Troubleshooting and Root Cause Analysis

Why It Matters

IT teams need to quickly identify the root cause of system failures to minimize downtime and prevent recurring issues. Manually searching logs across different platforms can be time-consuming, delaying resolutions and negatively impacting business operations.

Use Case

An e-commerce company relies on Nagios Log Server 2024R2 to correlate application, server, and network logs, helping IT teams diagnose and resolve checkout system failures in real time. When customers report checkout failures, IT engineers can quickly query the logs to determine whether the issue stems from a database error, network latency, or application crash. Faster troubleshooting leads to improved customer experience and higher revenue retention.

Related Reading

Calculating the True Cost of Downtime

5. Performance Monitoring and Optimization

Why It Matters

Monitoring system performance trends enables organizations to proactively address performance issues before they impact end users. Historical log data can help identify slowdowns, inefficiencies, and capacity constraints.

Use Case

A cloud services provider uses Nagios Log Server 2024R2 to analyze historical log data and identify performance bottlenecks. By visualizing trends in CPU, memory, and network usage, the IT team can optimize server resources and prevent service disruptions. Additionally, predictive analytics help forecast capacity needs, ensuring that infrastructure scales efficiently with demand.

Related Reading

DeepSeek AI: Ensuring Uptime and Availability for Optimal Performance

6. Incident Response and Forensics

Why It Matters

When security incidents occur, organizations must respond quickly to contain threats and conduct forensic investigations. Detailed logs are crucial for understanding the attack vector and identifying affected systems.

Use Case

A government agency uses Nagios Log Server 2024R2 to conduct forensic investigations after detecting potential cyber threats. When an intrusion is detected, security analysts review logs to trace the attack’s origin, determine how the attacker gained access, and assess the extent of the damage. By preserving historical log data, organizations can build a timeline of events and improve their security posture for future threats.

Related Reading

Ransomware Attacks – Nagios Can Improve Your Response to Reduce the Impact

Conclusion

Nagios Log Server 2024R2 is a versatile solution that enhances IT operations across various industries. Whether for security, compliance, troubleshooting, or performance monitoring, organizations can leverage its capabilities to improve efficiency and reliability. With centralized log management, automated alerts, and robust analytics, businesses can proactively detect issues, respond to incidents, and ensure compliance with regulatory requirements. Migrating to Nagios Log Server 2024R2 helps organizations stay ahead of IT challenges while maintaining security and operational excellence.

This article will guide you through installing the Nagios Cross-Platform Agent (NCPA) on Arch Linux (version 2025.03.01) and configuring it in Nagios XI for centralized monitoring.

Prerequisites

Before we begin, ensure that you have the following:

1. A working Arch Linux system: Ensure your Arch Linux installation is up-to-date, and you have sudo privileges.
2. Nagios XI installed: Nagios XI should be installed on a separate server, as this will be used to manage and monitor the system where NCPA is deployed.
3. Network connectivity: Your Arch Linux system should be able to communicate with the Nagios XI server over the network.

Step 1: Installing Nagios Cross-Platform Agent (NCPA) on Arch Linux

As of March 2025, the NCPA package is not directly available in the Arch Linux repositories, so you will need to manually download and install the agent.

1.1. Download the NCPA Agent

To get the NCPA agent on Arch Linux, follow these steps:

1. Install necessary dependencies: First, ensure your system is fully updated, and install the required packages to build NCPA:

sudo pacman -Syu
sudo pacman -S git base-devel python3

sudo pacman -Syu
sudo pacman -S git base-devel python3

2. Clone the NCPA repository: Clone the official Nagios NCPA repository from GitHub:

git clone https://github.com/NagiosEnterprises/ncpa.git
cd ncpa

git clone https://github.com/NagiosEnterprises/ncpa.git
cd ncpa

3. Install NCPA: NCPA can be installed using the following commands. Since Arch Linux uses makepkg for building packages, you need to create the package manually:

makepkg -si

makepkg -si

This command will build and install NCPA, including any required dependencies.

4. Start the NCPA service: Once installed, you can start the NCPA service:

sudo systemctl start ncpa

sudo systemctl start ncpa

To enable NCPA to start automatically on boot, use:

sudo systemctl enable ncpa

sudo systemctl enable ncpa

You can check the status of the NCPA service by running:

sudo systemctl status ncpa

sudo systemctl status ncpa

5. Configure the firewall (if applicable): If you are using a firewall, make sure to allow the necessary ports (default is port 5693 for NCPA) to pass through:

sudo ufw allow 5693

sudo ufw allow 5693

1.2. Verify the NCPA Installation

After installing and starting the NCPA service, verify that it’s running properly by accessing the web interface. Open your browser and visit the following URL (replace <arch-linux-ip> with your actual IP address):

http://<arch-linux-ip>:5693

http://<arch-linux-ip>:5693

You should be prompted with a login screen. The default username is nagiosadmin and the default password is nagios.

Step 2: Configure NCPA in Nagios XI

Once you have installed and verified that NCPA is running on your Arch Linux system, the next step is to configure it within Nagios XI for centralized monitoring.

2.1. Add Host to Nagios XI

1. Log in to Nagios XI: Open your web browser and log in to your Nagios XI server (e.g., http://<nagios-xi-ip>/nagiosxi).
2. Navigate to the “Configure” menu: From the main dashboard of Nagios XI, go to the Configure tab and select Core Configuration Manager.
3. Add a new host: In the Core Configuration Manager, click on Hosts in the left-hand menu and then click the Add New button.
4. Host Settings:
   • Host Name: Enter a meaningful name for the Arch Linux host (e.g., arch-linux).
   • Alias: Optionally, provide an alias (e.g., Arch Linux System).
   • Address: Enter the IP address of your Arch Linux machine (e.g., 192.168.1.100).
   • Host Template: You can either use a predefined template or create a custom template for monitoring NCPA. If using a predefined template, select Generic Host.
5. Save the host configuration.

2.2. Add Service for NCPA Monitoring

Now that you’ve added the host, it’s time to add services to monitor specific metrics via NCPA.

1. Add Services: After saving the host, navigate to the Services section under the host configuration and click Add New.
2. Service Configuration:
   • Service Name: Enter a descriptive name for the service (e.g., CPU Usage or Memory Usage).
   • Service Description: Optionally, provide more details.
   • Service Type: Select NCPA.
   • Check Command: From the list of check commands, select check_ncpa.py or check_ncpa.py!<metric> (replace <metric> with the desired metric like cpu, memory, disk, etc.).
   • Additional Arguments: You can customize the command arguments to match your needs, such as the one below and save the service configuration:

-H <arch-linux-ip> -t <token> -P 5693 -M 'system/uptime'

-H <arch-linux-ip> -t <token> -P 5693 -M 'system/uptime'

3. Configure NCPA Token: To make sure the Nagios XI server communicates securely with NCPA, you will need to use the token set during NCPA setup (the default token is nagios). If you set a custom token, use it in the configuration.

Update the check command in Nagios XI to include this token, like this:

-H <arch-linux-ip> -t nagios -P 5693 -M 'system/uptime'

-H <arch-linux-ip> -t nagios -P 5693 -M 'system/uptime'

Below are screenshots of where you’ll go inside Nagios XI when setting up the wizard. Once you have selected the wizard make sure to follow the prompts. You can also select “finish with defaults” after entering in initial information.

2.3. Verify Monitoring

Once you’ve configured the host and services, go back to the Nagios XI dashboard and check the status of the new host and services. If everything is set up correctly, you should begin seeing the system metrics of the Arch Linux machine being reported in real-time. You can also test individual metrics by manually running the NCPA check command from the Nagios XI server:

/usr/local/nagios/libexec/check_ncpa.py -H <arch-linux-ip> -t nagios -P 5693 -M 'system/uptime'

/usr/local/nagios/libexec/check_ncpa.py -H <arch-linux-ip> -t nagios -P 5693 -M 'system/uptime'

If the configuration is correct, you will receive a status message with the requested metric data.

2.4. Automate Service Checks

To ensure that Nagios XI continuously monitors the Arch Linux system, make sure the services you created are set up to check regularly by setting the appropriate intervals in the service settings (e.g., every 5 minutes).

Step 3: Troubleshooting

If you encounter any issues, here are a few troubleshooting steps:

• Firewall: Ensure that port 5693 is open on both the Arch Linux server and the Nagios XI server.
• Token Mismatch: Double-check the token configuration in both Nagios XI and NCPA.
• NCPA Logs: Check the NCPA logs on your Arch Linux system for any error messages. Logs are usually found in /var/log/ncpa/.

Conclusion

By following these steps, you should have successfully installed the Nagios Cross-Platform Agent (NCPA) on your Arch Linux system and configured it for monitoring in Nagios XI. NCPA is a powerful and flexible tool for monitoring various system metrics, and when combined with Nagios XI, it provides a comprehensive solution for centralized network monitoring. Keep your system up-to-date and periodically review your Nagios XI configuration to ensure optimal performance.

For further assistance, refer to the Nagios Support Forum or the Nagios Documentation Hub.

For additional customization and advanced features, refer to the official NCPA documentation.

Introduction

Nagios Log Server R2 is a powerful tool for centralized log management and analysis, but like any logging system, it may encounter indexing issues that cause slow searches, missing logs, or delayed data processing. Proper log indexing ensures logs are efficiently stored and quickly retrievable when needed for monitoring, security analysis, or compliance reporting.

In this guide, we’ll walk through the common causes of log indexing issues in Nagios Log Server R2 and how to troubleshoot them effectively.

1. Identifying the Root Cause of Indexing Issues

Before applying a fix, determine whether the issue is related to:

• Slow searches – Log queries take too long to return results.
• Missing logs – Some logs are not appearing in searches.
• Delayed log indexing – Logs arrive but are indexed late.

To check indexing status and shard health, run:

curl -X GET "http://localhost:9200/_cluster/health?pretty"

curl -X GET "http://localhost:9200/_cluster/health?pretty"

A green status means the cluster is healthy, while yellow or red indicates indexing problems.

2. Fixing Slow Log Searches in Nagios Log Server 2024R2

A. Check System Resources

Run the following command to check CPU, memory, and disk usage:

top
df -h

top
df -h

If CPU or memory usage is consistently high, consider:

• Adding more system resources (RAM, CPU)
• Restarting the Nagios Log Server service to free up memory: systemctl restart nagioslogserver

B. Optimize Shard Allocation

Too many small shards slow down queries. Check the number of shards:

curl -X GET "http://localhost:9200/_cat/shards?v"

curl -X GET "http://localhost:9200/_cat/shards?v"

If you have too many shards, consider merging indices or increasing shard size.

To adjust shard count for a new index:

curl -X PUT "http://localhost:9200/_settings" -H "Content-Type: application/json" -d '
{
  "index": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}'

curl -X PUT "http://localhost:9200/_settings" -H "Content-Type: application/json" -d '
{
  "index": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}'

For existing indices, use the force merge command:

curl -X POST "http://localhost:9200/_forcemerge?max_num_segments=1"

curl -X POST "http://localhost:9200/_forcemerge?max_num_segments=1"

This reduces overhead and speeds up searches.

C. Limit Search Query Scope

Narrow down search queries to specific time ranges or log sources:

• Use shorter time frames instead of searching all logs
• Filter by specific log sources (firewall, Linux, Windows logs)

3. Fixing Missing Logs in Nagios Log Server R2

A. Verify Log Input Sources

Check if log sources (servers, firewalls, applications) are sending data.

1. List active log inputs: curl -X GET "http://localhost:9200/_cat/indices?v"
2. If an expected index is missing, restart log collection: systemctl restart rsyslog

B. Check Log Collection Services

If Nagios Log Server isn’t receiving logs, restart the Logstash service:

systemctl restart logstash

systemctl restart logstash

Check the Logstash logs for errors:

tail -f /var/log/logstash/logstash.log

tail -f /var/log/logstash/logstash.log

If Logstash is down, re-enable it:

systemctl enable --now logstash

systemctl enable --now logstash

C. Verify Firewall and Network Connectivity

If logs are not arriving, check firewall rules on the source system:

sudo firewall-cmd --list-all

sudo firewall-cmd --list-all

Make sure the firewall allows traffic on port 514 (Syslog) or 9200 (Opensearch).

To open ports:

sudo firewall-cmd --add-port=514/udp --permanent
sudo firewall-cmd --reload

sudo firewall-cmd --add-port=514/udp --permanent
sudo firewall-cmd --reload

4. Fixing Delayed Log Indexing

A. Check Indexing Queue Size

If logs are delayed, check the queue size:

curl -X GET "http://localhost:9200/_cluster/pending_tasks"

curl -X GET "http://localhost:9200/_cluster/pending_tasks"

If there are too many pending tasks, restart the OpenSearch to clear the backlog:

systemctl restart opensearch

systemctl restart opensearch

B. Increase Java Heap Size for OpenSearch

If Elasticsearch is running out of memory, increase heap size:

1. Edit the jvm.options file: nano /etc/opensearch/jvm.options
2. Increase memory allocation (e.g., from 8gb to 16gb): -Xms4g -Xmx4g
3. Restart opensearch: systemctl restart opensearch

C. Reduce Log Retention Period

If old logs consume too much storage, delete outdated logs:

curl -X DELETE "http://localhost:9200/logs-2023.01*"

curl -X DELETE "http://localhost:9200/logs-2023.01*"

Or set an automatic log retention policy:

curl -X PUT "http://localhost:9200/_ilm/policy/log_cleanup" -H "Content-Type: application/json" -d '
{
  "policy": {
    "phases": {
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}'

curl -X PUT "http://localhost:9200/_ilm/policy/log_cleanup" -H "Content-Type: application/json" -d '
{
  "policy": {
    "phases": {
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}'

This automatically deletes logs older than 90 days, freeing up space.

5. Verifying Cluster Health and Performance

To ensure Nagios Log Server R2 is functioning correctly, regularly check:

• Cluster health: curl -X GET "http://localhost:9200/_cluster/health?pretty"
• Disk space usage: df -h
• Logstash service status: systemctl status logstash

Conclusion

Properly managing log indexing in Nagios Log Server R2 ensures faster searches, real-time log analysis, and efficient storage utilization. Regular monitoring and maintenance will keep Nagios Log Server 2024R2 running efficiently. If issues persist, check back on Nagios documentation, consider maintenance and support, or ask the Nagios Support Forum.

Happy monitoring!