As a best practice, you should regularly monitor your Logmanager appliance’s health metrics to identify potential hardware or software issues before they affect operations. This guide covers the most common causes of system health problems that we have encountered while resolving customer support cases.

In this guide, you’ll learn how to:

Keep your Logmanager appliance hardware healthy and up to date
Monitor event queues and EPS trends
Identify DNS-related performance issues
Manage disk space and data retention
Check databse health and resource usage
Optimize database field counts
Monitor parsing engine capacity
Troubleshoot slow or inefficient parsers
Identify noisy log sources that consume excessive resources

Following these recommendations will help you detect issues before they affect performance, data retention, or log processing capacity.

Hardware

Serious hardware issues are relatively rare, but they can have a disproportionate impact on Logmanager operations compared to the effort required to prevent them.

To get started, log in to iDRAC, the server’s management platform, which is accessible through a dedicated management interface. The login credentials can be found on the pull-out tag located on the front of the server.

Update the Firmware

As a first step, we recommend checking the currently installed firmware versions and comparing them with the latest versions available from the hardware manufacturer.

You can do this in Maintenance → System Update → Manual Update. By selecting the Use Default Address option, iDRAC will connect directly to Dell’s firmware repository, check for applicable updates, and determine the optimal update sequence for the individual components.

Keeping firmware up to date helps minimize the risk of issues caused by known bugs and improves overall system stability.

Enabling Dell firmware updates at Logmanager — *Fig. 1: Enabling Dell firmware updates in Logmanager*

Check for Hardware Errors

Next, check the system for hardware errors.

Logmanager automatically generates alerts for the most critical hardware issues. However, important notifications can occasionally be overlooked or lost in crowded inboxes. For this reason, it is good practice to periodically review the built-in health reports available in iDRAC and verify that no hardware errors or warnings are present.

Hardware errors check in Logmanager — *Fig. 2: Fig. 2: Hardware error alerts in Logmanager*

Software

The Logmanager application stack provides several ways to monitor system health through the Web GUI. The primary indicators are System Status, Database Status, and Parsing Engine Metrics.

System Status

Check the Event Queue

The incoming event queue contains logs that are waiting to be indexed into Elasticsearch. If the queue size is increasing, it indicates that there is a bottleneck somewhere in the processing pipeline.

In an ideal scenario, the queue remains empty most of the time, growing only during temporary peaks in incoming data and quickly returning to normal once those peaks subside.

If the queue continues to grow for an extended period without showing signs of decreasing, it may eventually reach the 50 GB threshold, at which point the queued data will be purged.

event queue check in Logmanager — *Fig. 3: Event queue check in Logmanager*

Check the EPS Trend

The database indexing rate, measured in EPS (Events Per Second), is a useful metric that indicates the load placed on the database.

Different Logmanager appliance sizes can handle different EPS rates before performance begins to degrade. The recommended EPS limits for each appliance size can be found in the product datasheet.

Short-term spikes are generally not a problem. However, if your Logmanager instance is consistently processing more events than it is designed to handle, the incoming event queue will continue to grow and may eventually begin discarding data.

If this occurs, consider reducing the volume of incoming logs at the source. In many environments, firewalls are among the largest contributors to log volume and are often a good starting point for optimization.

Check the DNS response times

The DNS latency is surprisingly significant when it comes to Logmanager health. When DNS resolving is turned on, each log can be slowed down by waiting for a response from the DNS server and in turn blocking other logs from using the thread. An otherwise healthy Logmanager could be easily working through half the expected EPS in this situation. To prevent this kind of mishaps, make sure your response times are in the green.

If response times are consistently high, consider temporarily disabling DNS resolution by navigating to Network → DNS → Resolve Hostnames until the underlying DNS issue is resolved.

*Fig. 5: DNS response times check in Logmanager*

Check Available Disk Space

Even though there are built-in mechanisms that take care of disk space, it’s good to know where you stand. When you start running out of disk space, the system starts removing the oldest indices until it has enough space for Elasticsearch operations. If you started out with tiny 50 GB indices and ended up with 1 TB of daily events, it’s possible to have multiple indices erased daily. Checking the available disk space will enable you to make informed decisions regarding your backup policy.

*Fig. 6: Available disk space check in Logmanager*

Database Status

Check the DB State

The search engine state is a single data point that indicates whether the database is operating normally. Its values range from green to yellow to red. If the state is green or yellow, there is usually nothing to worry about. However, a red state should only appear for short periods of time. If the red state persists, please contact support.

*Fig. 7: Database status check in Logmanager*

Look for Open Indices

Running Elasticsearch is relatively resource-intensive, and Logmanager should ideally have only the necessary indices open, as each open index consumes a significant amount of RAM. When available memory approaches zero, performance starts to degrade and may eventually lead to system instability.

You can prevent such situations by checking the index list and closing any indices that are not currently needed to free up resources. Restored backups are a special case, as they cannot be deleted automatically and may continue consuming resources unless they are removed manually.

*Fig. 8: Open indices check in Logmanager*

Check the DB Field Count

The field count can be compared to the column count in a standard relational database. The more fields, or columns, you have, the slower searches are going to be. In our case, having too many fields could cause the database to start misbehaving entirely. We recommend a maximum of 1,000 fields, as this number is high enough for most use cases while still being low enough to avoid performance issues.

You can check your field count by opening the Log Overview dashboard and scrolling all the way down to All Events. If the number in parentheses next to All is approaching 1,000, please review your parsers, as they may be creating too many fields in the database.

There is also a selection of lite parsers available, which can be enabled under Parser > Lookup Tables > Lite-Parsing Settings. Each of these reduces the number of fields parsed from its respective log source.

*Fig. 9: Database field count check in Logmanager*

Parsing Engine

Parsing Engine Metrics are the secret sauce of Logmanager troubleshooting. The dashboard can be accessed by opening System Status, clicking General / System Status in the upper-left corner, and then selecting Parsing Engine Metrics from the list of dashboards.

Check the Parsing Capacity Threshold

The first thing to look at is the parsing engine capacity. There is a limited amount of resources available to classify, parse, and generate alerts from your logs. If the available capacity is fully exhausted while more logs continue to arrive, the EPS will drop and the event queue may soon start to fill up.

Check the Total Parser Usage chart to see whether you have enough spare capacity for your needs. It is generally safe to assume that the green portion of the chart represents a safe zone, corresponding to roughly 75% of the total capacity.

If your system consistently operates above this threshold, in the yellow or red zones, you may be able to identify the cause by scrolling further down and investigating the other charts available in the dashboard.

*Fig. 10: Total parser usage check in Logmanager*

Measure the Time Spent Processing Your Parsers

While the built-in classifiers, parsers, and alerts are benchmarked and tested before release, custom parsers often evolve organically without a firm understanding of the ideal architecture. It is entirely possible that one of your custom parsers contains a problematic loop hidden somewhere in the code. Issues like these can be difficult to spot without the right data.

Fortunately, the Time Spent Processing X charts can help point you in the right direction. If you find any custom parsers that take significantly longer to execute than others, take a quick look at the code to determine whether there are any redundant or suboptimal constructs.

See the Top Logging Hosts

As the number of logging sources in Logmanager grows, a noisy source can easily slip through and place unexpected strain on system resources.

You can identify such sources using the Top Logging Hosts chart. This chart allows you to pinpoint specific timestamps and trace issues back to problematic configuration changes or other causes of increased log volume.

*Fig. 11: Top logging hosts chart in Logmanager*

Conclusion

Regular health checks are one of the simplest ways to keep your Logmanager deployment running smoothly and avoid unexpected performance issues.

By periodically reviewing hardware health, event queues, database status, parsing engine metrics, and storage utilization, you can identify potential bottlenecks before they affect log collection, search performance, or data retention.

Most issues discussed in this guide can be detected early and resolved with minimal effort. Making these checks part of your routine maintenance process will help ensure that your Logmanager instance remains stable, performant, and ready to handle future growth.

How to Monitor and Maintain Logmanager Health