In this article, we’ll highlight the biggest changes and provide links to resources so you can start exploring the new functionality right away.

New Simple Search Homepage

At the heart of Log Server 2026 is the completely brand-new Simple Search homepage.
This streamlined interface is built for quick, everyday investigation, making it easier for users of all experience levels to search for common log events and gain powerful insights without the clutter.

OpenSearch 2 → 3 Upgrade

Under the hood, Nagios Log Server 2026 upgrades its core components from OpenSearch 2.x to 3.1.0 and Logstash 9.1.1, increasing performance, stability, and scalability.

Quality of Life & UX Enhancements

The 2026 release introduces a number of subtle but meaningful refinements that improve everyday usability:

• “Add Log Source” (+) button consolidates source setup actions into one central place.
• Timestamp localization adapts automatically to your region and time zone.
• Improved LDAP/AD editing page for simpler authentication configuration.
• Role assignment per cluster instance for better administrative control of the jobs each instance executes.

All of these updates contribute to a more cohesive, accessible, and responsive Log Server experience.

Changelog

For a detailed list of fixes and developer notes, visit the full changelog below:

Getting Started

If you’re new to Nagios Log Server or ready to upgrade to the 2026 release, download the trial version here:

Analyzing Logs in Nagios Log Server

For a complete walkthrough on using queries, filters, dashboards, and how to manage your home page mode to analyze logs effectively, check out this guide:

Step 1: Add a Log Source in Nagios Log Server

1. Log in to Nagios Log Server.
2. Click + Add Log Source.
3. Select Linux as the source type.

Step 2: Run the Auto-Configuration Script on openSUSE

1. Copy the script command from the Linux Source Setup page.
2. On the openSUSE server, run:

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 the Log Server.

Step 3: Verify Logs are Received

• Return to the setup page in Nagios Log Server.
• Enter the openSUSE server’s IP in the Verify Incoming Logs section.
• Or run a host query from Dashboards > Search:

host.ip:<openSUSE-IP>

• To test manually, run:

logger "This is a test log entry"

Step 4: (Optional) Manual Configuration

1.Check the rsyslog work directory:

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

2.Manually create or edit the forwarding config:

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

Add the following line:

*.* @<NagiosLogServerIP>:5544;RSYSLOG_SyslogProtocol23Format

3.Restart rsyslog:

sudo systemctl restart rsyslog.service

Step 5: Link to Nagios XI

• Utilize queries and alert conditions in Nagios Log Server to trigger alerts in Nagios XI via API or event handlers.
• Integrate log monitoring with service checks for a comprehensive system overview.

Final Notes

• Logs are forwarded over port 5544; ensure openSUSE’s firewall allows outbound traffic on this port.
• The + Add Log Source feature in Nagios Log Server allows you to add additional log sources as needed.
• Regularly review logs in Nagios Log Server to detect system anomalies and security threats.

Conclusion

By following this guide, you can successfully monitor and analyze openSUSE 15 logs with Nagios Log Server 2024R2 in Nagios XI. This setup ensures proactive issue detection and enhances overall system observability. For best results, maintain regular log audits and optimize alert configurations to capture critical events.

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

This guide explains how to configure an Apple Silicon-based macOS system (e.g., M1, M2, or later) to forward logs to Nagios Log Server for centralized log management and real-time monitoring. We’ll use rsyslog to forward logs, as macOS’s native syslogd has limited remote forwarding capabilities.

Prerequisites

Before starting, ensure you have:

• Nagios Log Server installed and running (latest version, e.g., 2024R2 recommended).
• An Apple Silicon-based macOS device (macOS 11 Big Sur or later) with administrator privileges.
• Network access between the Mac and the Nagios Log Server instance.
• The IP address and port (default: 514) of your Nagios Log Server.

Why Use Nagios Log Server?

Nagios Log Server provides:

• Centralized log collection and management.
• Real-time analysis with dashboards and alerts.
• Scalability with clustering and failover.
• Compatibility with macOS logs via syslog.

Key Logs to Monitor

Nagios Log Server can collect:

• System Logs: System.log, Kernel.log.
• Application Logs: App-specific logs.
• Security Logs: Auth.log, firewall logs.
• Performance Logs: CPU, memory, and disk activity.

Installation and Setup

Step 1: Enable macOS Logging

macOS uses the unified logging system (log command) and syslogd.

• Verify Logging is Active:
  1. Open Terminal.
  2. Check the live log stream:

log stream --level info

log stream --level info

1. Press Ctrl+C to exit.

Check Syslogd: Verify syslogd is running:

sudo launchctl list | grep syslogd

sudo launchctl list | grep syslogd

If not running, load it:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.syslogd.plist

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.syslogd.plist

Step 2: Install and Configure rsyslog

Since macOS’s syslogd doesn’t natively support robust remote forwarding, install rsyslog via Homebrew.

• Install Homebrew: On Apple Silicon, Homebrew installs to /opt/homebrew/:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Add Homebrew to your PATH:

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zshrc
source ~/.zshrc

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zshrc
source ~/.zshrc

Install rsyslog:

brew install rsyslog

brew install rsyslog

Configure rsyslog: Edit the configuration file:

sudo nano /opt/homebrew/etc/rsyslog.conf

sudo nano /opt/homebrew/etc/rsyslog.conf

Add the following to forward logs to Nagios Log Server:

*.* @<logserver_ip>:514    # UDP
# OR
*.* @@<logserver_ip>:514   # TCP (preferred if supported)

*.* @<logserver_ip>:514    # UDP
# OR
*.* @@<logserver_ip>:514   # TCP (preferred if supported)

Replace <logserver_ip> with your Nagios Log Server’s IP (e.g., 192.168.1.100).

Enable modules (uncomment or add at the top):

module(load="imuxsock")    # Local system logs
module(load="imklog")      # Kernel logs

module(load="imuxsock")    # Local system logs
module(load="imklog")      # Kernel logs

Save and exit (Ctrl+X, Y, Enter).

Start rsyslog:

sudo brew services start rsyslog

sudo brew services start rsyslog

Verify it’s running:

ps aux | grep rsyslogd

ps aux | grep rsyslogd

Firewall Check: If macOS’s firewall is enabled (System Settings > Network > Firewall), allow outbound traffic on port 514 (UDP or TCP).

Step 3: Configure Nagios Log Server

Set up Nagios Log Server to receive logs:

1. Log into the Nagios Log Server web interface (e.g., http://<logserver_ip>:80).
2. Go to Configure > Configuration Editor.
3. Under Log Sources, add a new source:

• Type: Syslog (UDP or TCP, matching your rsyslog config).
• IP Address: Your Mac’s IP (find with ifconfig | grep inet).
• Port: 514 (default).
• Save and apply the configuration.

Step 4: Verify Log Collection

• Test Log Forwarding: On the Mac, generate a test log:

logger "Test log from macOS (Apple Silicon) to Nagios Log Server"

logger "Test log from macOS (Apple Silicon) to Nagios Log Server"

Check Nagios Log Server:

1. Go to Home > Dashboards or Reports.
2. Look for the test message from your Mac’s IP.

• If it doesn’t appear:
  • Verify the server is listening on port 514 (netstat -an | grep 514 on the server).
  • Test connectivity (ping <logserver_ip> from the Mac).
  • Check macOS firewall settings.

Best Practices

• Alerts: In Nagios Log Server, set up alerts (e.g., for failed logins) via Configure > Alerts.
• Dashboards: Customize dashboards to visualize macOS log trends.
• Secure Forwarding: For production, use TCP with TLS:

Add to rsyslog.conf:

$ActionForwardDefaultTemplate RSYSLOG_SyslogProtocol23Format

$ActionForwardDefaultTemplate RSYSLOG_SyslogProtocol23Format

• Configure TLS in Nagios Log Server (see official docs).

Log Rotation: macOS handles local rotation via newsyslog; configure retention in Nagios Log Server.

Conclusion

Your Apple Silicon macOS system is now forwarding logs to Nagios Log Server using rsyslog. This setup leverages Nagios Log Server’s powerful log analysis, alerting, and visualization features. For advanced monitoring, explore Nagios Log Server’s documentation or integrate with Nagios XI for broader system oversight.

For more details, check:

• Nagios Log Server Documentation
• Nagios Support Forum

Getting Started

After setup, logs that would typically appear in /var/log/messages will be forwarded to the Nagios Log Server R2, allowing centralized monitoring and alerting.

Automatic Setup Using a Script

The easiest way to configure log forwarding is by using the provided script. This method requires rsyslog to be installed on your CentOS 7 machine.

Steps to Run the Script:

1. Ensure Rsyslog is Installed:

sudo yum install rsyslog -y
sudo systemctl enable --now rsyslog

sudo yum install rsyslog -y
sudo systemctl enable --now rsyslog

2. Download the Script from the Nagios Log Server R2:

curl -sS -O http://192.168.1.49/nagioslogserver/scripts/setup-linux.sh

curl -sS -O http://192.168.1.49/nagioslogserver/scripts/setup-linux.sh

3. Execute the Script to Configure Rsyslog:

sudo bash setup-linux.sh -s 192.168.1.49 -p 5544

sudo bash setup-linux.sh -s 192.168.1.49 -p 5544

• Replace 192.168.1.49 with your Nagios Log Server R2’s IP address.
• The -p 5544 option specifies the port for log transmission.

Manual Setup Using Rsyslog Configuration

If you prefer manual setup or need more control over configurations, follow these steps:

1. Edit Rsyslog Configuration:

<code>sudo nano /etc/rsyslog.d/99-nagios.conf

<code>sudo nano /etc/rsyslog.d/99-nagios.conf

2. Add the following configuration:

*.* @@192.168.1.49:5544

*.* @@192.168.1.49:5544

• Replace 192.168.1.49 with the IP address of your Nagios Log Server R2.
• The @@ symbol indicates TCP transmission; use @ for UDP if needed.

3. Restart Rsyslog to Apply Changes:

sudo systemctl restart rsyslog<br>

sudo systemctl restart rsyslog<br>

4. Check Status to Ensure it’s Running:

sudo systemctl status rsyslog<br>

sudo systemctl status rsyslog<br>

Receiving Logs in Log Server

On your Log Server’s GUI, click Add Log Source.

Click Linux.

Type in your machine’s IP address to see if you are receiving logs. If it’s working, the interface will confirm that logs are being received.

Conclusion

Whether using the automatic script or manual setup, forwarding logs from CentOS 7 to Nagios Log Server R2 ensures centralized log management for better monitoring and alerting. Use the method that best fits your deployment needs.

Monitoring macOS using a Log Server enables centralized logging and real-time event tracking. This guide explains how to configure an Intel-based macOS system to forward logs to a Log Server for analysis. We’ll cover enabling logging, setting up log forwarding, and applying best practices for effective monitoring.

Prerequisites

Before starting, ensure you have:

• A running instance of a Log Server (e.g., Splunk, Graylog, or ELK; latest version recommended).
• An Intel-based macOS device (macOS 10.15 Catalina or later) with administrator privileges.
• Internet connectivity or network access between the Mac and the Log Server.

Why Monitor macOS with a Log Server?

Monitoring macOS logs helps you:

• Identify Security Threats – Detect unauthorized access attempts and suspicious activity.
• Analyze System Performance – Track system logs to find performance bottlenecks.
• Ensure Compliance – Maintain logs for audits and compliance requirements.
• Troubleshoot Issues – Gain insights into system errors and failures.

Key Logs to Monitor

A Log Server can collect various logs from macOS, including:

System Logs

• System.log – General system activity and errors.
• Kernel.log – Kernel-related messages and errors.
• Application Logs – Logs from installed applications.

Security Logs

• Auth.log – Authentication attempts and failures.
• Firewall Logs – Records of blocked and allowed connections.

Performance Logs

• CPU & Memory Usage Logs – Insights into system resource consumption.
• Disk Activity Logs – Read/write operations on the file system.

Installation and Setup

Step 1: Enable and Configure macOS Logging

macOS uses the unified logging system (log command) and syslogd for log management.

1. Verify Logging is Active:
   • Open Terminal.
   • Check the live log stream:

log stream --level info

log stream --level info

This displays real-time logs. Press Ctrl+C to exit.

Enable Syslog Compatibility:

• macOS’s syslogd is enabled by default but needs configuration for remote forwarding. No need to manually load it unless modified:

sudo launchctl list | grep syslogd

sudo launchctl list | grep syslogd

If not running, load it:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.syslogd.plist

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.syslogd.plist

Step 2: Install and Configure Log Forwarding

To forward logs to a Log Server, we’ll use rsyslog, as macOS’s built-in syslogd has limited remote forwarding capabilities.

1. Install Homebrew (if not installed):
   • On Intel Macs, Homebrew installs to /usr/local/:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Follow the prompts and add Homebrew to your PATH if prompted:

echo 'eval "$(/usr/local/bin/brew shellenv)"' >> ~/.zshrc
source ~/.zshrc

echo 'eval "$(/usr/local/bin/brew shellenv)"' >> ~/.zshrc
source ~/.zshrc

Install rsyslog:

• Run:

brew install rsyslog

brew install rsyslog

Configure rsyslog for Remote Forwarding:

• Edit the configuration file:

sudo nano /usr/local/etc/rsyslog.conf

sudo nano /usr/local/etc/rsyslog.conf

Add these lines at the bottom to forward all logs to your Log Server:

*.* @<logserver_ip>:514    # Single @ for UDP
# OR
*.* @@<logserver_ip>:514   # Double @@ for TCP (if supported by your Log Server)

*.* @<logserver_ip>:514    # Single @ for UDP
# OR
*.* @@<logserver_ip>:514   # Double @@ for TCP (if supported by your Log Server)

• Replace <logserver_ip> with your Log Server’s IP address (e.g., 192.168.1.100).

Enable necessary modules (uncomment or add at the top if missing):

module(load="imuxsock")    # For local system logs
module(load="imklog")      # For kernel logs

module(load="imuxsock")    # For local system logs
module(load="imklog")      # For kernel logs

Save and exit (Ctrl+X, Y, Enter)

Start rsyslog:

• Run as a service:

sudo brew services start rsyslog

sudo brew services start rsyslog

Verify it’s running:

ps aux | grep rsyslogd

ps aux | grep rsyslogd

You should see an rsyslogd process.

Firewall Note: If macOS’s firewall is enabled (System Preferences > Security & Privacy > Firewall), allow outbound UDP/TCP port 514.

Step 3: Configure the Log Server

Set up your Log Server to receive logs from the Mac:

1. Log into your Log Server’s web interface.
2. Navigate to Configuration > Log Sources (or equivalent, depending on your Log Server).
3. Add a new log source:

1. Type: Syslog (UDP or TCP, matching Step 2).
   • IP Address: Your Mac’s IP (find it with ifconfig | grep inet).
     • Port: 514 (default for syslog).
2. Save and apply the configuration.

Step 4: Verify Log Collection

Test that logs are being forwarded:

1. Generate a test log on the Mac:

logger "Test log message from macOS"

logger "Test log message from macOS"

Check the Log Server interface for the message (e.g., under “Logs” or “Events”).

• If it doesn’t appear:
  • Ensure the Log Server is listening on port 514 (run netstat -an | grep 514 on the server).
  • Verify network connectivity (ping <logserver_ip> from the Mac).
  • Check macOS firewall settings.

Best Practices for macOS Log Monitoring

• Set Proactive Alerts: Configure the Log Server to notify you of security events (e.g., failed logins) or system errors.
• Monitor Authentication Logs: Watch for patterns in authentication-related logs (e.g., subsystem:com.apple.securityd in unified logs).
• Optimize Log Storage: Implement log rotation on the Log Server (macOS handles local rotation via newsyslog).
• Analyze System Performance: Use log data to track trends (pair with tools like sysdiagnose for deeper insights).
• Secure Forwarding: Use TCP with TLS if supported (add $ActionForwardDefaultTemplate RSYSLOG_SyslogProtocol23Format to rsyslog.conf and configure TLS).

Conclusion

You’ve configured your Intel-based macOS system to forward logs to a Log Server using rsyslog. This setup enables centralized monitoring of system, security, and application events. For comprehensive unified log coverage, consider the advanced setup or a dedicated agent.

For further customization, adjust rsyslog.conf filters or Log Server settings to focus on specific log types. Regularly review logs to maintain system health and security.

For additional support, refer to:

• Nagios XI Documentation
• Nagios Mac Exchange
• Nagios Support Forum
• Nagios Knowledge Base

For the last 10 years, Nagios Log Server has provided users with a powerful log collection, analysis, archiving, and alerting solution. We’re excited to announce the release of Log Server 2024R2, and in this article we’ll discuss the major frontend and backend updates and improvements you’ll discover in the new major release.

User Interface: The Next Generation

When you download the new Log Server 2024R2 release, the first thing you’ll notice is the beautiful new user interface, coded from scratch by the Nagios development team. Check out how easy it is to manage Dashboard panels now!

The new UI is crisp, clean, and fast. This change will provide greater flexibility and agility to our developers, enabling them to quickly incorporate new ideas, respond to customer feedback, and cultivate Log Server’s look and feel in the future. For example, creating the new Dark Theme and Light Theme:

One change that might take a moment to get used to is that the menu bar is now on the left, and icon-based, just like the Nagios XI Neptune theme you may already use. Aside from that, longtime Log Server users will still feel right at home, as we’ve kept the menu structure and location of key functions the same.

Another major enhancement comes in how panels are managed in your Dashboards.

Major Backend Updates

The improvements in Log Server 2024R2 go far beyond the stunning new UI, extending to the core components of the tool. First off, the datastore has been shifted from Elasticsearch to Opensearch 2.14.0. Secondly, Logstash has been updated to v8.13.4. These updates will provide you with improved security and functionality in your Log Server deployment.

The upgrade to Opensearch means that Log Server users will now benefit from the uniform field labeling and hierarchical tree structure of the Elastic Common Schema (ECS). For example, information such as the host name of different types of log sources will be uniformly placed into a common field, in this case host.hostname.

In previous versions of Log Server, this would have been Hostname for Windows sources, and hostname for Linux sources, causing no results to show in the case of simple capitalization mistakes when composing queries. Setting up queries and alerts to find the important log entries you’re after will be quicker and easier going forward, since the fields for common attributes will have the same name and capitalization regardless of the source type.

You’ll also notice that in R2, significantly more fields are parsed in your syslog data, including data such as process.name, service.type, log.syslog.severity.code, and log.syslog.severity.name, further enabling you to quickly narrow down datasets in your queries.

Migration Made Easy

Due to the upgrade from Elasticsearch to OpenSearch an inline upgrade from R1 to R2 isn’t possible, but we have created a GUI-based migration tool to help existing users migrate their data and to a new R2 deployment. The tool makes migrating the following to your new R2 deployment a snap:

• The log data contained in the Elasticsearch engine.
• User accounts
• Configuration
• Queries
• History
• Alerts

More Resources

A great way to dive in and learn all about the changes is this recent webinar:

Nagios Log Server 2024R2 Showcase

Fully-updated documentation for Log Server 2024R2 can be found in the Admin Guide:

Nagios Log Server Administrator Guide

Learn how to monitor your Log Server cluster intelligently with Business Process Intelligence here:

Nagios XI BPI: Actionable Insights for IT Monitoring and Optimization

Learn how Log Server can help empower you with a holistic perspective your your infrastructure’s health here:

Get Holistic with 4 Nagios Solutions

Take Nagios Log Server 2024R2 for a Spin

Discover our powerful log collection, analysis, archiving, and alerting solution with a stunning new UI and major backend improvements.

Beautiful new user interface

Upgraded to OpenSearch 2.14.0

Enhanced log analysis capabilities

Easy migration tool

Explore Log Server 2024R2

One great answer to these questions is built right into Nagios Log Server. You’re probably already using a variety of custom queries in Nagios Log Server to help you narrow down your collected data into important subsets for your Dashboards and Alerts, but may not be aware that Log Server includes the option to generate queries with AI. In this article, we’ll discuss the capabilities and how-to’s of this awesome experimental feature.

Setting up the AI

You have multiple options to choose from when selecting the best AI model to generate your queries. Log Server includes built-in support for Anthropic, Mistral, and Open AI if you wish to use a 3rd party provider. To set this up, navigate to the Admin > Global Settings menu, and scroll down to the Experimental Features section:

We’ve also documented a self-hosted option for those who would like to run the Nagios Enterprises’ Large Language Models on their own with vLLM. Once you’ve accepted the Disclaimer and chosen your method, you’re ready to go.

Generating Queries

Once you have things set up, it’s time to start making queries. Navigate to Dashboards, and you’ll now notice a new look:

Now, you can enter a description of what type of log events you’d like to see. You’ll notice a few examples alternating in the box to give you some ideas. After you punch in what you’re looking for, hit enter and enjoy the sparkling stars animation during the second or two it will take for the query to be generated, then review the results.

You’ll see the filtered results in the various panels of your Dashboard as usual and can click the Advanced Search arrow on the right of the prompt section to review, edit, and manage your AI-generated queries. You can also use this section to add your own handmade queries.

For example, the prompt “show me Linux security events” generated the following query for us:

This can serve as both a quick way to easily generate simple and complex queries for users of all experience levels and a valuable learning resource for those trying to learn how to compose Lucene queries. When useful queries that you may want to use again are generated, be sure to save them.

To combine multiple queries, simply enter another request in the prompt box, and it will be applied to your Dashboard alongside other queries already present. The queries combine with an OR statement, so combined results will be shown, and will be color-coded in Panels such as Events Over Time. You can modify the color representing each query by clicking the small colored circle to the left of their text input boxes, which will open a color wheel popup.

It’s easy to set up and use this powerful feature, making it valuable for users of all skill levels—even for creating the most complex queries.

Texas A&M Forest Service (TAMFS) has a longstanding commitment to protecting and managing the state’s forest resources while responding to wildfires and other natural disasters. Managing vast amounts of data across its statewide operations requires a robust and efficient log management solution. With the adoption of Nagios Log Server, TAMFS has transformed its IT operations, ensuring greater reliability, security, and performance.

Challenges Faced by Texas A&M Forest Service

Before implementing Nagios Log Server, TAMFS encountered several challenges:

Scattered Log Data

TAMFS operates across multiple locations, creating a decentralized log management issue. IT teams struggled with fragmented log data, making it difficult to analyze system performance and security threats.

Limited Visibility

The existing log management approach lacked real-time monitoring, making it difficult to detect system anomalies or cyber threats.

Compliance and Reporting Issues

As a government agency, TAMFS must comply with stringent security and data retention policies. Generating reports from disparate logs was time-consuming and prone to errors.

Manual Troubleshooting

Without a centralized logging solution, identifying and resolving IT issues took longer, impacting operational efficiency.

Why Nagios Log Server?

After assessing multiple solutions, TAMFS chose Nagios Log Server due to its:

Scalability

Capable of handling large amounts of log data from multiple sources.

Real-time Monitoring & Alerting

Provides near-instant notifications for system anomalies.

User-friendly Interface

Simplifies log analysis, allowing IT staff to pinpoint issues quickly.

Compliance Support

Enables automated reporting and data retention compliance.

Cost-Effectiveness

Offers a powerful solution without exceeding budget constraints.

Implementation & Transformation

The deployment of Nagios Log Server across TAMFS operations was a seamless process, thanks to its easy integration with existing IT infrastructure. Here’s how it revolutionized operations:

1. Centralized Log Management

With Nagios Log Server, TAMFS successfully unified logs from servers, applications, and network devices into a single repository. This eliminated the inefficiencies of scattered data, enabling IT teams to access and analyze logs from anywhere within the organization.

2. Enhanced Security and Threat Detection

Cybersecurity is a top priority for TAMFS. Nagios Log Server’s real-time monitoring and alerting system allowed IT teams to detect and respond to potential security breaches proactively. By setting up customized alerts, TAMFS could identify failed login attempts, unauthorized access, and unusual network activity before they escalated into critical issues.

3. Improved System Performance & Issue Resolution

Before Nagios Log Server, diagnosing IT issues required manual log inspections, causing delays in resolution. Now, with centralized log data and powerful search capabilities, TAMFS IT personnel can quickly identify system errors, performance bottlenecks, and failing hardware, reducing downtime and enhancing productivity.

4. Compliance & Reporting Made Easy

As a state agency, TAMFS must comply with federal and state regulations concerning data security, log retention, and reporting. Nagios Log Server streamlined compliance efforts by automatically generating reports, securely storing log data, and ensuring adherence to audit requirements without added complexity.

5. Cost Savings & Operational Efficiency

Nagios Log Server provided TAMFS with a budget-friendly yet powerful log management solution. By reducing manual troubleshooting efforts, optimizing IT resource allocation, and preventing costly downtime, the agency saved both time and money. Additionally, the solution’s pricing didn’t change based on the amount of log data ingested.

Conclusion

The implementation of Nagios Log Server at Texas A&M Forest Service has been a game-changer, ensuring that the agency remains resilient, efficient, and secure in its mission to protect Texas’s forests and natural resources. By embracing a centralized log management solution, TAMFS has achieved operational excellence, setting a benchmark for other state agencies. With Nagios Log Server, the future of IT management at TAMFS looks stronger than ever.

To learn about more ways Nagios can solve real life problems, check out our other Nagios Success Stories.

Effective IT infrastructure monitoring requires robust tools to ensure system health and performance. Nagios XI provides comprehensive monitoring capabilities, and SNMP (Simple Network Management Protocol) is a widely used method for monitoring Windows servers. Configuring SNMP in Windows and integrating it with Nagios XI allows organizations to monitor system metrics efficiently.

Why Use SNMP for Windows Monitoring?

1. Centralized Monitoring

SNMP enables centralized monitoring of multiple Windows servers, providing real-time insights into system performance and health.

2. Lightweight and Efficient

SNMP is a lightweight protocol that requires minimal resources while offering detailed system information.

3. Standardized Protocol

SNMP is a widely accepted protocol, making it compatible with various monitoring tools, including Nagios XI.

4. Custom Monitoring

With SNMP, organizations can customize monitoring by configuring additional performance metrics based on their requirements.

Prerequisites

Before configuring SNMP for Windows monitoring in Nagios XI, ensure the following:

• Nagios XI is installed and running.
• SNMP service is installed on the Windows server.
• Firewall rules allow SNMP traffic.
• SNMP community string is properly configured.

Installing and Configuring SNMP on Windows

To enable SNMP monitoring, install and configure the SNMP service on Windows.

Steps to Install SNMP on Windows Server:

1. Open PowerShell as an administrator.
2. Run the following command to install SNMP:

Install-WindowsFeature -Name SNMP-Service -IncludeManagementTools

Install-WindowsFeature -Name SNMP-Service -IncludeManagementTools

3. Verify SNMP installation:

Get-Service -Name SNMP

Get-Service -Name SNMP

Configuring SNMP on Windows Server:

1. Open Services (services.msc).
2. Locate and open SNMP Service properties.
3. Navigate to the Security tab.
4. Add a community string (e.g., public) and set permissions.
5. Allow SNMP packets from Nagios XI’s IP address.
6. Restart the SNMP service:

Restart-Service SNMP

Restart-Service SNMP

Configuring Nagios XI for SNMP Monitoring

To integrate SNMP monitoring in Nagios XI, configure SNMP checks for the Windows server.

Adding an SNMP Windows Host in Nagios XI

1. Log in to Nagios XI.
2. Navigate to Configure > Run the Monitoring Wizard.
3. Select Windows SNMP.
4. Enter the Windows server’s IP address.
5. Specify the SNMP community string (e.g., public).
6. Configure the desired monitoring checks (CPU, disk, memory, etc.).
7. Click Finish to apply the configuration.

Manually Adding SNMP Host Configuration

Alternatively, add an SNMP host manually in Nagios XI.

Example Nagios XI Configuration for SNMP Host:

define host {
    use             windows-server
    host_name       Windows_Server_01
    address         192.168.1.100
    max_check_attempts 5
    check_period    24x7
    check_command   check-host-alive
    notification_period 24x7
}

define host {
    use             windows-server
    host_name       Windows_Server_01
    address         192.168.1.100
    max_check_attempts 5
    check_period    24x7
    check_command   check-host-alive
    notification_period 24x7
}

Example Nagios XI Service Configuration for SNMP:

define service {
    use                 generic-service
    host_name           Windows_Server_01
    service_description CPU Load
    check_command       check_snmp! -H 192.168.1.100 -C public -o .1.3.6.1.2.1.25.3.3.1.2.1
}

define service {
    use                 generic-service
    host_name           Windows_Server_01
    service_description CPU Load
    check_command       check_snmp! -H 192.168.1.100 -C public -o .1.3.6.1.2.1.25.3.3.1.2.1
}

Testing and Troubleshooting

Verification Steps:

• Confirm SNMP service status on Windows:

Get-Service -Name SNMP

Get-Service -Name SNMP

• Test SNMP response from Nagios XI:

snmpwalk -v2c -c public 192.168.1.100

snmpwalk -v2c -c public 192.168.1.100

• Check Nagios XI configuration syntax:

nagios -v /usr/local/nagios/etc/nagios.cfg

nagios -v /usr/local/nagios/etc/nagios.cfg

• Restart Nagios XI service if needed:

systemctl restart nagios

systemctl restart nagios

Conclusion

Integrating Windows SNMP monitoring with Nagios XI enhances system visibility and ensures proactive issue resolution. By configuring SNMP properly, organizations can monitor CPU usage, disk space, memory utilization, and other key performance metrics efficiently. This setup minimizes downtime, optimizes resource management, and provides centralized monitoring for IT infrastructure. For additional support, visit the Nagios Support Forum or the Nagios Knowledgebase.