Modern security platforms generate an enormous volume of logs every day. Authentication events, endpoint telemetry, file integrity monitoring (FIM), vulnerability scans, cloud activity, audit records, and network alerts all need to be collected, indexed, and searched quickly. Without a high-performance indexing engine, even the most advanced security monitoring solution becomes difficult to use as datasets grow. This is where the Wazuh Indexer becomes one of the most important components of the entire Wazuh ecosystem.
It serves as the centralized storage and search engine for security events, allowing analysts to retrieve millions of records within seconds while supporting dashboards, alerts, visualizations, threat hunting, and compliance reporting.
Unlike traditional databases that struggle with large-scale log analytics, Wazuh Indexer is built on OpenSearch, a distributed search and analytics engine designed specifically for high-volume, near real-time data processing.
By distributing indexes across multiple nodes, balancing workloads, and replicating data for high availability, the Indexer enables organizations to scale their Security Operations Center (SOC) without sacrificing performance.
Many administrators understand how to deploy Wazuh agents and managers but spend far less time learning how the Indexer actually works.
As environments grow beyond a few hundred endpoints, however, understanding index management, shard allocation, storage planning, retention policies, and cluster health becomes essential for maintaining a reliable deployment.
Throughout this guide, you’ll learn:
- What Wazuh Indexer is and how it fits into the Wazuh architecture
- How indexing, shards, replicas, and cluster coordination work
- Best practices for deploying, scaling, securing, and monitoring Indexer clusters
- Common performance bottlenecks and troubleshooting techniques
- Storage optimization, Index State Management (ISM), and data retention strategies
- How to build highly available Indexer clusters for enterprise environments
By the end of this guide, you’ll understand not only how to use Wazuh Indexer, but also how to optimize it for scalability, resilience, and long-term operational efficiency.
What Is Wazuh Indexer?
The Wazuh Indexer is the distributed search and storage engine responsible for indexing, storing, and retrieving all security events generated throughout a Wazuh deployment.
Beginning with Wazuh 4.x, the project transitioned from Elasticsearch to OpenSearch, giving organizations an open-source search platform optimized for log analytics, distributed storage, and real-time querying.
Rather than acting as a traditional relational database, Wazuh Indexer stores security events inside specialized indexes that are optimized for fast searching, aggregation, and analytics.
This architecture enables analysts to search across billions of security events in seconds while supporting dashboards, detections, compliance reporting, and forensic investigations.
Overview of the OpenSearch-Based Indexing Engine
At its core, Wazuh Indexer is an OpenSearch cluster configured specifically for security monitoring workloads.
OpenSearch organizes data into indexes, which are divided into shards and distributed across multiple nodes.
This architecture allows storage capacity and search performance to grow horizontally simply by adding more Indexer nodes.
Because OpenSearch performs indexing in near real time, new security events become searchable almost immediately after they arrive.
This capability is critical for incident response, where analysts often need to investigate active attacks within minutes.
According to the OpenSearch documentation, distributed indexing and parallel query execution significantly improve scalability compared to centralized search architectures.
Feature Insight: The OpenSearch project emphasizes that distributed indexing, automatic shard allocation, and replication are core mechanisms that enable clusters to scale while maintaining resilience during node failures.
Role Within the Wazuh Architecture
Within a standard Wazuh deployment, each major component has a distinct responsibility:
- Wazuh Agents collect endpoint telemetry.
- Wazuh Manager analyzes events, applies decoders and detection rules, and generates alerts.
- Wazuh Indexer stores alerts, logs, vulnerability data, inventory information, and security metadata.
- Wazuh Dashboard provides visualization, searching, dashboards, and management interfaces.
The Indexer does not analyze events itself.
Instead, it specializes in making analyzed security data searchable and highly available.
This separation of responsibilities allows each component to scale independently.
Organizations collecting large volumes of logs can expand the Indexer cluster without necessarily increasing Manager capacity.
Related Guides:
Types of Security Data It Stores
Depending on your enabled modules, Wazuh Indexer stores a wide variety of information, including:
- Security alerts
- File Integrity Monitoring (FIM) events
- Vulnerability detection results
- Security Configuration Assessment (SCA) findings
- Endpoint inventory information
- Windows Event Logs
- Linux audit logs
- Authentication logs
- Cloud service logs
- Network security events
- Threat intelligence matches
- Agent metadata
- Compliance reports
- Archived historical events
As deployments mature, organizations commonly accumulate billions of indexed documents spanning months or years of operational history.
How Indexing Improves Search Performance
Traditional databases often require scanning large tables before returning search results.
Indexing works differently.
When data enters Wazuh Indexer, OpenSearch builds optimized inverted indexes that allow searches to locate matching documents almost instantly instead of scanning every record.
For example, searching for:
- Failed SSH logins
- Critical vulnerability detections
- Ransomware indicators
- Specific IP addresses
- Particular usernames
can return results from millions of events within seconds because the Indexer already maintains optimized searchable structures.
This dramatically reduces investigation time during security incidents.
Benefits of Wazuh Indexer
Organizations benefit from Wazuh Indexer in several ways:
- Near real-time indexing of security events
- Extremely fast full-text searching
- Horizontal scalability through clustering
- High availability using replica shards
- Distributed storage across multiple nodes
- Powerful aggregations for dashboards and reports
- Efficient long-term log retention
- Integration with OpenSearch APIs
- Advanced filtering and analytics capabilities
- Built-in support for Index State Management (ISM)
These capabilities make the Indexer the foundation for threat hunting, compliance reporting, and enterprise-scale security analytics.
Related Guides:
How Wazuh Indexer Works
Understanding how data flows through Wazuh Indexer makes it much easier to troubleshoot performance issues, design scalable clusters, and optimize storage.
Although indexing appears seamless from the Dashboard, several coordinated processes occur behind the scenes whenever new security events arrive.
Data Ingestion Workflow
A typical event follows this sequence:
- A Wazuh Agent collects security telemetry from an endpoint.
- The event is forwarded to the Wazuh Manager.
- The Manager processes decoders and detection rules.
- Alerts are generated when rules match.
- Filebeat forwards processed alerts to the Wazuh Indexer.
- OpenSearch indexes the documents.
- Indexed data becomes searchable through the Dashboard and REST APIs.
This pipeline separates event collection, analysis, storage, and visualization into independent services, making the platform easier to scale.
Related Guide: Wazuh Filebeat: A Step-by-Step Setup Guide
Index Creation and Management
Rather than storing every document in a single massive database, Wazuh Indexer organizes information into multiple indexes.
Indexes are typically created based on:
- Alert data
- Monitoring data
- Inventory information
- Vulnerability results
- Archive logs
As indexes grow, administrators can:
- Rotate indexes
- Delete expired data
- Apply retention policies
- Move older indexes to slower storage
- Automate lifecycle management using ISM
Proper index management prevents oversized indexes that can negatively impact indexing speed and search performance.
Related Guides:
Shards and Replicas Explained
Every OpenSearch index is divided into smaller pieces called primary shards.
Instead of placing an entire index on one server, shards distribute the data across multiple Indexer nodes.
For example:
- Index size: 500 GB
- Primary shards: 5
- Approximate shard size: 100 GB each
Because searches execute across all shards simultaneously, query performance improves significantly.
Replica shards provide additional copies of each primary shard.
Their benefits include:
- High availability
- Automatic failover
- Increased search throughput
- Protection against hardware failures
Choosing the correct number of shards and replicas is one of the most important design decisions in a Wazuh deployment.
Oversharding can waste memory and CPU, while undersharding can limit scalability.
Related Guide: How to Design a Wazuh OpenSearch Shard Allocation Strategy
Search and Query Processing
When a user searches within the Wazuh Dashboard:
- The query is sent to the Indexer cluster.
- The coordinating node distributes the request to relevant shards.
- Each shard performs its portion of the search independently.
- Results are aggregated.
- The final response is returned to the Dashboard.
This parallel processing model is one reason OpenSearch can search billions of indexed documents with low latency.
Cluster Coordination
A Wazuh Indexer deployment typically consists of multiple nodes working together as a single logical cluster.
Cluster coordination is responsible for:
- Tracking cluster membership
- Managing node communication
- Monitoring cluster health
- Assigning shards
- Detecting failed nodes
- Promoting replicas when failures occur
- Rebalancing data after node recovery
This distributed architecture minimizes single points of failure and allows maintenance or hardware failures to occur with minimal disruption when the cluster is properly configured.
Feature Insight: OpenSearch uses a cluster coordination subsystem to maintain a consistent cluster state, elect a cluster manager node, and safely manage shard allocation and recovery across distributed nodes.
Related Guide:
Wazuh Indexer Architecture
A well-designed Wazuh Indexer architecture ensures security events remain searchable, resilient, and highly available as your environment grows.
Whether you’re protecting a small business with a few hundred endpoints or an enterprise with tens of thousands of devices, understanding how the Indexer is structured helps you design a deployment that balances performance, scalability, and fault tolerance.
The architecture can range from a single server used for testing to distributed multi-node clusters spanning multiple availability zones or data centers.
Single-Node Deployments
A single-node deployment runs all indexing services on one server.
This architecture is commonly used for:
- Lab environments
- Proof-of-concept deployments
- Small businesses
- Training environments
- Development and testing
A typical single-node deployment includes:
- One Wazuh Manager
- One Wazuh Indexer
- One Wazuh Dashboard
Advantages include:
- Simple installation
- Minimal hardware requirements
- Easy administration
- Lower infrastructure costs
However, there are several limitations:
- No redundancy
- No automatic failover
- Limited scalability
- Maintenance causes downtime
- Hardware failure results in service interruption
While suitable for smaller environments, production deployments that require high availability should use multiple Indexer nodes.
Multi-Node Clusters
As organizations onboard more endpoints and retain data for longer periods, a single Indexer often becomes a bottleneck.
A multi-node cluster distributes data across several servers, allowing the workload to scale horizontally.
Benefits include:
- Higher indexing throughput
- Improved search performance
- Automatic shard distribution
- Better fault tolerance
- Increased storage capacity
- Rolling maintenance with minimal downtime
- Replica-based recovery after node failures
For example, a three-node cluster may distribute indexes evenly across all servers while maintaining replica copies on different nodes.
If one server fails, replica shards continue serving requests until the failed node returns.
Large enterprises often expand to five or more nodes as indexed data volumes reach multiple terabytes.
Related Guides:
Cluster Manager and Data Nodes
Every OpenSearch-based Wazuh Indexer cluster contains nodes with specific responsibilities.
The cluster manager node (formerly called the master node in OpenSearch terminology) is responsible for coordinating cluster operations, including:
- Maintaining cluster state
- Managing node membership
- Assigning shards
- Coordinating index creation
- Detecting failed nodes
- Initiating shard recovery
Data nodes perform the heavy lifting by:
- Storing indexes
- Processing indexing requests
- Executing search queries
- Handling aggregations
- Serving search results
In smaller deployments, a single node often performs both roles.
In larger enterprise clusters, dedicated cluster manager nodes improve stability because they are isolated from resource-intensive indexing workloads.
Feature Insight: OpenSearch recommends using dedicated cluster manager nodes in larger production environments to reduce the likelihood of cluster instability caused by heavy indexing or search traffic.
Communication with Wazuh Manager
The Wazuh Manager and Indexer perform separate functions but communicate continuously.
The general workflow is:
- Wazuh Agents collect endpoint data.
- The Manager analyzes events using decoders and detection rules.
- Alerts are generated.
- Filebeat forwards alerts securely to the Indexer.
- The Indexer stores searchable documents.
This separation allows administrators to scale managers and indexers independently.
For example:
- Increased endpoint count may require additional Managers.
- Increased data volume may require additional Indexer nodes.
- Increased analyst activity may require additional Dashboard resources.
Related Guide: Wazuh Filebeat: A Step-by-Step Setup Guide
Communication with the Dashboard
The Wazuh Dashboard does not store security events.
Instead, it acts as the visualization layer that communicates directly with the Indexer.
When a user:
- Searches logs
- Opens dashboards
- Investigates alerts
- Builds visualizations
- Generates reports
the Dashboard sends search requests to the Indexer, which returns matching documents for display.
Because all searches originate from the Indexer, Dashboard responsiveness is heavily influenced by Indexer performance, storage health, shard distribution, and cluster resource utilization.
If communication between the Dashboard and Indexer is interrupted, dashboards may fail to load, searches can return errors, and monitoring statistics may become unavailable.
Related Guide: How to Fix Missing Statistics in Wazuh Dashboard
Installing Wazuh Indexer
Installing Wazuh Indexer is straightforward, but careful planning helps ensure the deployment performs reliably from the start.
Hardware sizing, operating system compatibility, storage performance, and initial configuration all influence indexing speed and cluster stability.
While the official installation process is well documented, understanding the prerequisites and validation steps can help prevent common deployment issues.
System Requirements
The required resources depend on the number of monitored endpoints and the expected event volume.
Typical production recommendations include:
| Component | Recommended Minimum |
|---|---|
| CPU | 4–8 dedicated cores |
| Memory | 8–16 GB RAM (or more for larger deployments) |
| Storage | Fast SSD or NVMe storage |
| Network | Low-latency, high-bandwidth connectivity |
| Operating System | Supported Linux distribution (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, etc.) |
Large deployments often require significantly more memory because OpenSearch uses heap space for indexing, caching, and query execution.
Storage performance is equally important.
SSDs and NVMe drives generally provide much better indexing performance than traditional spinning disks, especially under sustained write-heavy workloads.
Installation Prerequisites
Before installing Wazuh Indexer, verify that:
- The operating system is supported.
- System time is synchronized using NTP.
- Hostnames resolve correctly between cluster nodes.
- Firewall rules permit required communication ports.
- Sufficient disk capacity is available.
- Java requirements are satisfied (if applicable to your deployment version).
- TLS certificates are prepared for secure node communication.
- Swap configuration follows OpenSearch recommendations.
For production environments, it is also advisable to plan shard allocation, storage capacity, and future cluster expansion before ingesting large amounts of data.
Installation Methods
Wazuh supports several deployment approaches depending on the environment.
Common installation methods include:
- Package-based installation using the official repositories
- All-in-one deployments
- Multi-node production installations
- Automated deployments using Ansible
- Containerized deployments using Docker
- Kubernetes deployments for cloud-native environments
Each approach ultimately produces the same core Indexer functionality but differs in deployment complexity and scalability.
Organizations managing large infrastructures often automate deployments to ensure configuration consistency across every node.
Initial Configuration
After installation, administrators typically configure:
- Cluster name
- Node name
- Node roles
- Discovery settings
- Seed hosts
- Initial cluster manager nodes
- TLS certificates
- Memory allocation
- Storage locations
- Network bindings
Additional tuning may include:
- Heap size optimization
- Disk watermark thresholds
- Thread pool settings
- Snapshot repositories
- Index templates
- Security plugin configuration
Planning these settings early reduces the need for disruptive configuration changes as the environment grows.
Related Guide: How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes
Verifying the Installation
Before ingesting production data, verify that the Indexer is operating correctly.
Recommended validation steps include:
- Confirm the Indexer service is running.
- Check cluster health.
- Verify all expected nodes have joined the cluster.
- Confirm no unassigned shards exist.
- Ensure TLS communication succeeds.
- Test Dashboard connectivity.
- Verify alerts are being indexed.
- Review startup logs for warnings or errors.
Completing these checks helps identify configuration issues before they affect production workloads.
Related Guides:
Understanding Wazuh Indexes
Indexes are the fundamental building blocks of Wazuh Indexer.
Every alert, vulnerability result, inventory update, and monitoring record is stored inside one or more indexes, allowing OpenSearch to organize data efficiently and execute searches in parallel.
Rather than storing all information together, Wazuh separates different types of data into dedicated indexes.
This improves query performance, simplifies lifecycle management, and allows administrators to apply different retention policies to different datasets.
Alert Indexes
Alert indexes store the security events generated by the Wazuh Manager after rules are evaluated.
These indexes typically contain:
- Security alerts
- Authentication events
- Malware detections
- File Integrity Monitoring alerts
- Compliance events
- Cloud monitoring events
- Threat intelligence matches
- Custom rule matches
Alert indexes are generally the most active indexes because they receive continuous updates from monitored endpoints.
As organizations scale, these indexes often consume the largest share of storage capacity.
Archive Indexes
Archive indexes contain historical security data retained for long-term analysis, auditing, or regulatory compliance.
Organizations commonly use archive indexes for:
- Incident investigations
- Compliance audits
- Historical trend analysis
- Long-term forensic searches
- Regulatory retention requirements
Older archive indexes are frequently moved to lower-cost storage using Index State Management policies while remaining searchable when needed.
Related Guide: Wazuh Data Retention Guide
Monitoring Indexes
Monitoring indexes store operational information about the Wazuh environment itself rather than endpoint security events.
Examples include:
- Cluster health metrics
- Node statistics
- Performance counters
- Resource utilization
- Indexing performance
- Search latency
- JVM statistics
Administrators use this information to identify bottlenecks, monitor resource consumption, and troubleshoot cluster issues before they impact production.
Naming Conventions
Wazuh uses consistent naming conventions so related data can be easily identified and managed.
Well-designed naming conventions make it easier to:
- Apply retention policies
- Create index templates
- Automate snapshots
- Manage lifecycle policies
- Simplify troubleshooting
- Organize dashboards
- Filter searches efficiently
Administrators should avoid changing naming conventions without understanding how dashboards, templates, and automation workflows reference existing indexes.
Index Lifecycle Overview
Indexes move through several stages during their lifetime.
A typical lifecycle includes:
- An index is created.
- Security events are continuously written.
- Searches and aggregations query the indexed data.
- Older indexes become read-only.
- ISM policies transition indexes to warm or lower-cost storage (if configured).
- Snapshots may be created for backup purposes.
- Expired indexes are automatically deleted based on retention policies.
Automating this lifecycle helps maintain predictable storage usage, consistent search performance, and compliance with organizational data retention requirements.
Feature Insight: The OpenSearch project recommends lifecycle automation through Index State Management (ISM) to reduce manual administration, optimize storage tiers, and automatically delete expired indexes according to defined policies.
Related Guides:
- How to Configure Wazuh Index State Management (ISM)
- How to Manage Wazuh Storage
- How to Migrate Wazuh Indexer Data to New Storage Volumes
Managing Data in Wazuh Indexer
As a Wazuh deployment grows, effective data management becomes just as important as collecting security events.
Poorly managed indexes can lead to slow searches, excessive disk usage, mapping conflicts, and cluster instability.
Fortunately, Wazuh Indexer provides several mechanisms to organize, optimize, and automate how data is stored throughout its lifecycle.
By understanding index templates, mappings, aliases, rollover strategies, and safe deletion practices, administrators can keep their clusters performing efficiently while minimizing operational overhead.
Index Templates
An index template defines the settings and mappings that should be automatically applied whenever a new index is created.
Rather than configuring every index manually, templates ensure consistency across your environment by specifying properties such as:
- Number of primary shards
- Number of replica shards
- Field mappings
- Index settings
- Refresh intervals
- Compression options
- Lifecycle policies
For example, if your environment creates a new daily alert index, an index template ensures that each new index uses the same shard configuration and field definitions.
Benefits of using index templates include:
- Consistent index configurations
- Simplified administration
- Reduced configuration errors
- Easier automation
- Improved scalability
Without templates, manually configuring indexes increases the risk of inconsistent settings that can negatively impact search performance and storage efficiency.
If template conflicts occur, new indexes may inherit incorrect mappings or settings, potentially causing indexing failures.
Related Guide: Fixing Rejected Index Templates and Invalid Mapping Types in Wazuh
Mappings
Mappings define how OpenSearch stores and indexes individual fields within documents.
Each field has a specific data type, such as:
keywordtextintegerlongbooleandateipgeo_point
Choosing appropriate field types improves both indexing efficiency and search performance.
For example:
- IP addresses should use the
iptype. - Timestamps should use the
datetype. - Hostnames often use
keyword. - Long log messages typically use
text.
Incorrect mappings can lead to:
- Indexing failures
- Query errors
- Increased storage usage
- Reduced aggregation performance
- Mapping conflicts across indexes
A well-designed mapping strategy ensures that security data remains searchable while minimizing unnecessary storage consumption.
Aliases
An index alias is a logical name that points to one or more indexes.
Instead of applications referencing individual indexes directly, they can reference an alias that remains constant even as underlying indexes change.
For example:
wazuh-alertsmay point to today’s active alert index, while tomorrow the alias automatically switches to the newly created index after rollover.
Aliases provide several advantages:
- Simplified application configuration
- Easier index migrations
- Zero-downtime index transitions
- Flexible search across multiple indexes
- Support for rolling index updates
Aliases are particularly useful when implementing automated rollover and retention policies because dashboards and applications continue using the same logical name.
Index Rollover
As indexes grow, search performance and recovery times may begin to degrade.
Instead of allowing a single index to become excessively large, administrators can implement index rollover.
Rollover automatically creates a new index when predefined thresholds are reached, such as:
- Maximum size
- Maximum age
- Maximum document count
For example:
- Create a new index every day.
- Create a new index after 50 GB.
- Create a new index after 50 million documents.
Smaller indexes provide several operational benefits:
- Faster recovery
- Improved search efficiency
- Easier snapshot management
- Better shard balancing
- Simplified retention policies
Most production Wazuh environments combine rollover with Index State Management (ISM) to automate the entire index lifecycle.
Related Guide: How to Configure Wazuh Index State Management (ISM)
Deleting Old Indexes Safely
Eventually, old security data must be removed to reclaim storage.
Deleting indexes manually without proper planning can permanently remove valuable forensic evidence or violate regulatory retention requirements.
Before deleting indexes, administrators should:
- Verify retention requirements.
- Confirm backups or snapshots exist if needed.
- Ensure indexes are no longer actively queried.
- Review compliance policies.
- Validate deletion targets carefully.
- Delete entire indexes rather than individual documents whenever possible.
Deleting complete indexes is significantly more efficient than deleting millions of individual records because OpenSearch simply removes the index metadata instead of updating every document.
Many organizations automate index deletion through ISM policies, ensuring expired indexes are removed consistently without manual intervention.
Feature Insight: The OpenSearch documentation recommends automating rollover and deletion through Index State Management policies to reduce administrative effort and maintain predictable storage consumption.
Related Guide: Wazuh Data Retention Guide
Storage Planning and Capacity Management
Storage is often the first resource that becomes constrained as a Wazuh deployment grows.
Every security alert, vulnerability scan, inventory update, and audit log consumes disk space, and organizations collecting data from thousands of endpoints can generate hundreds of gigabytes of indexed data each day.
Proactive capacity planning helps prevent indexing slowdowns, shard allocation failures, and service interruptions caused by insufficient disk space.
Estimating Storage Requirements
Storage requirements depend on several variables, including:
- Number of monitored endpoints
- Daily event volume
- Average event size
- Retention period
- Replica count
- Compression ratio
- Index overhead
For example, consider an environment with:
- 5,000 endpoints
- 40 GB of indexed data per day
- 90-day retention
- One replica
The raw storage calculation would be:
40 GB × 90 days = 3.6 TBWith one replica, storage consumption approximately doubles:
3.6 TB × 2 = 7.2 TBAdditional overhead should also be reserved for shard metadata, index management, snapshots, and future growth.
A common best practice is to maintain extra free capacity rather than sizing storage to operate continuously near its limits.
Disk Utilization
Maintaining healthy disk utilization is essential for cluster stability.
As disks fill, indexing performance may decline because OpenSearch has less available space for merging segments, writing new data, and relocating shards.
General recommendations include:
- Monitor disk usage continuously.
- Leave sufficient free space for shard movement.
- Avoid operating near full capacity.
- Expand storage before utilization becomes critical.
- Review growth trends regularly.
Capacity planning should account for expected growth over the coming months rather than reacting only when storage is nearly exhausted.
High and Low Disk Watermarks
OpenSearch uses disk watermarks to protect clusters from running out of storage.
These thresholds trigger different behaviors as disk usage increases.
Common watermark levels include:
- Low watermark – OpenSearch begins avoiding allocation of new shards to nodes with reduced free space.
- High watermark – Existing shards may be relocated away from heavily utilized nodes to balance disk usage.
- Flood-stage watermark – Indexes may be placed into read-only mode to prevent disks from becoming completely full.
Although exact threshold values can be customized, administrators should monitor utilization trends well before these limits are reached.
Ignoring watermark warnings can eventually lead to:
- Failed indexing operations
- Unassigned shards
- Read-only indexes
- Cluster instability
- Search performance degradation
Feature Insight: OpenSearch automatically enforces disk-based shard allocation rules using configurable watermark thresholds to help protect clusters from storage exhaustion and maintain operational stability.
Storage Optimization Techniques
Several best practices can significantly reduce storage consumption while maintaining search performance.
These include:
- Implementing index rollover
- Applying retention policies
- Deleting expired indexes automatically
- Using appropriate shard sizes
- Reducing unnecessary indexed fields
- Moving older indexes to lower-cost storage tiers
- Optimizing mappings
- Regularly reviewing storage growth
Organizations should periodically evaluate whether all collected data provides operational value.
Eliminating unnecessary log sources can reduce both storage costs and indexing workload.
Related Guide: How to Manage Wazuh Storage
Compression Considerations
OpenSearch supports compression to reduce disk usage without sacrificing data integrity.
Compression helps organizations:
- Lower storage costs
- Improve cache efficiency
- Reduce disk I/O
- Increase storage density
However, compression introduces additional CPU overhead because documents must be compressed during indexing and decompressed when retrieved.
For most production environments, the storage savings substantially outweigh the modest increase in CPU utilization, particularly when indexing large volumes of historical security data.
The ideal compression strategy depends on available hardware, indexing rates, and query workloads.
Related Guide: Wazuh Data Retention Guide
Shards, Replicas, and Performance
Shard configuration is one of the most important factors affecting Wazuh Indexer performance.
Proper shard planning influences indexing throughput, search latency, cluster recovery times, storage efficiency, and overall scalability.
Poor shard design can create long-term operational challenges that become increasingly difficult to correct as indexed data grows.
Choosing the Right Shard Count
Every OpenSearch index is divided into one or more primary shards, allowing data to be distributed across multiple nodes.
The ideal number of shards depends on factors such as:
- Expected index size
- Number of cluster nodes
- Available CPU resources
- Search workload
- Indexing rate
- Future growth
Too few shards may:
- Limit parallel processing
- Reduce scalability
- Concentrate workloads on fewer nodes
Too many shards may:
- Increase memory usage
- Consume additional CPU
- Slow cluster recovery
- Increase cluster management overhead
Instead of maximizing the shard count, administrators should size shards according to anticipated index growth and cluster capacity.
Replica Planning
Replica shards are complete copies of primary shards stored on different nodes.
Replicas provide several benefits:
- High availability
- Automatic failover
- Improved search throughput
- Faster disaster recovery
- Maintenance flexibility
If a primary shard becomes unavailable because of hardware failure or maintenance, a replica can immediately assume responsibility for serving requests.
The number of replicas should reflect both availability requirements and available storage.
Increasing replicas improves resilience but also increases storage consumption and indexing overhead.
Balancing Shard Allocation
An evenly balanced cluster distributes shards across available nodes to prevent resource bottlenecks.
Balanced allocation helps achieve:
- Consistent CPU utilization
- Even disk consumption
- Improved search performance
- Better indexing throughput
- Faster shard recovery
Cluster balancing becomes especially important after adding or removing nodes, restoring snapshots, or recovering from failures.
Administrators should periodically review shard distribution to ensure that no single node becomes overloaded while others remain underutilized.
Avoiding Oversharding
Oversharding occurs when indexes contain far more shards than necessary.
Although each shard stores only part of the data, every shard also consumes cluster resources, including:
- Heap memory
- CPU time
- Metadata
- File handles
- Cluster coordination overhead
Common causes of oversharding include:
- Creating too many small indexes
- Using excessive primary shards
- Failing to consolidate low-volume data
- Retaining unnecessary historical indexes
Symptoms of oversharding may include:
- Increased heap usage
- Slower searches
- Higher cluster state update times
- Longer recovery operations
- Reduced indexing performance
Designing indexes around expected data volume rather than arbitrary shard counts helps avoid these issues.
Monitoring Shard Health
Healthy shards are essential for maintaining reliable indexing and search operations.
Administrators should regularly monitor:
- Unassigned shards
- Initializing shards
- Relocating shards
- Replica synchronization
- Cluster health status
- Disk allocation
- Shard recovery progress
Routine monitoring allows teams to identify developing problems before they affect production workloads.
Feature Insight: Both the OpenSearch documentation and guidance from experienced search engineers emphasize routine monitoring of shard allocation and cluster health as a key practice for maintaining predictable search performance and minimizing recovery times after failures.
Related Guides:
- How to Design a Wazuh OpenSearch Shard Allocation Strategy
- How to Fix Wazuh All Shards Failed Error
- How to Fix a Yellow Cluster Status in Wazuh Indexer
Scaling Wazuh Indexer
As organizations collect more security telemetry, the demands placed on Wazuh Indexer increase significantly.
Higher event volumes, longer retention periods, and more frequent analyst queries all require additional compute, storage, and memory resources.
Fortunately, Wazuh Indexer is built on OpenSearch’s distributed architecture, making it possible to scale both vertically and horizontally.
Choosing the right scaling strategy depends on your current infrastructure, performance bottlenecks, budget, and future growth plans.
Vertical Scaling
Vertical scaling involves increasing the resources available to an existing Indexer node.
Common upgrades include:
- Adding more CPU cores
- Increasing RAM
- Expanding storage capacity
- Migrating from HDDs to SSDs or NVMe drives
- Increasing network bandwidth
Vertical scaling is often the quickest way to improve performance because it doesn’t require changes to the cluster topology.
Benefits include:
- Simpler deployment
- No additional cluster nodes
- Faster indexing performance
- Lower administrative complexity
However, vertical scaling has practical limitations.
Every server eventually reaches its maximum hardware capacity, and a single node still represents a potential point of failure.
Vertical scaling works best for:
- Small deployments
- Moderate growth
- Temporary performance improvements
- Resource-constrained environments
Horizontal Scaling
Horizontal scaling adds additional Indexer nodes to the cluster instead of increasing the size of existing servers.
This approach distributes workloads across multiple machines, allowing the cluster to handle:
- Higher indexing rates
- Larger data volumes
- More concurrent searches
- Increased storage capacity
- Greater fault tolerance
For example, instead of upgrading one server from 8 CPU cores to 32 cores, an organization may deploy three or five Indexer nodes that share the workload.
Advantages include:
- Nearly linear scalability for many workloads
- Improved high availability
- Better resilience during hardware failures
- Easier long-term capacity planning
- Reduced performance bottlenecks
Horizontal scaling is the preferred approach for most enterprise Wazuh deployments.
Feature Insight: OpenSearch is designed as a distributed search engine, allowing indexing and query workloads to be shared across multiple nodes rather than relying on a single high-powered server.
Adding New Nodes
Expanding a Wazuh Indexer cluster involves more than simply installing another server.
A typical expansion process includes:
- Provision the new server.
- Install Wazuh Indexer.
- Configure TLS certificates.
- Join the server to the existing cluster.
- Verify cluster health.
- Confirm node discovery.
- Allow shard reallocation.
- Monitor indexing performance after expansion.
Once the node joins successfully, OpenSearch begins redistributing shards to take advantage of the additional resources.
Administrators should avoid adding multiple heavily loaded nodes simultaneously unless expansion has been carefully planned and tested.
Related Guide: How to Set Up a Multi-Node Wazuh Cluster
Rebalancing Data
After adding or removing nodes, the cluster automatically rebalances shard placement.
During rebalancing, OpenSearch attempts to distribute:
- Primary shards
- Replica shards
- Disk utilization
- Search workloads
Proper rebalancing helps ensure:
- Even storage consumption
- Consistent CPU utilization
- Improved query performance
- Reduced node hotspots
Because shard movement consumes network bandwidth and disk I/O, administrators should monitor cluster health during large rebalancing operations to ensure production workloads remain unaffected.
Scaling Best Practices
Successfully scaling Wazuh Indexer requires ongoing planning rather than reactive upgrades.
Recommended best practices include:
- Monitor storage growth continuously.
- Track indexing and search latency.
- Maintain balanced shard sizes.
- Use SSD or NVMe storage for production workloads.
- Scale before reaching hardware limits.
- Reserve capacity for future growth.
- Test scaling procedures in non-production environments.
- Monitor heap utilization and garbage collection.
- Automate cluster health monitoring.
Organizations should also periodically review whether their shard allocation, retention policies, and storage architecture remain appropriate as data volumes evolve.
Related Guides:
Managing Data Lifecycle
Managing the lifecycle of indexed data is essential for maintaining a healthy Wazuh deployment.
Without automated lifecycle policies, indexes continue growing indefinitely, increasing storage costs, reducing search performance, and making cluster administration more difficult.
A well-designed lifecycle strategy ensures that data is automatically rolled over, retained for the required period, archived when appropriate, and deleted once it is no longer needed.
Index State Management (ISM)
Index State Management (ISM) is OpenSearch’s lifecycle automation framework used by Wazuh Indexer to manage indexes throughout their lifespan.
Instead of manually performing routine maintenance tasks, administrators can define policies that automatically:
- Roll over indexes
- Transition indexes between storage tiers
- Make indexes read-only
- Create snapshots
- Delete expired indexes
Each policy consists of one or more states and transitions based on conditions such as:
- Index age
- Index size
- Document count
Automating these operations reduces administrative effort while ensuring consistent lifecycle management across the entire cluster.
Feature Insight: The OpenSearch ISM plugin enables administrators to automate index lifecycle actions based on configurable conditions, helping reduce manual intervention and improve storage efficiency.
Related Guide: How to Configure Wazuh Index State Management (ISM)
Data Retention Policies
Every organization should define retention policies that balance operational needs, compliance obligations, and available storage.
Retention periods often vary by data type.
For example:
| Data Type | Example Retention |
|---|---|
| Critical security alerts | 1 year |
| Authentication logs | 180 days |
| Operational monitoring data | 90 days |
| Development or testing logs | 30 days |
Retention decisions should consider:
- Regulatory requirements
- Incident response needs
- Compliance frameworks
- Storage costs
- Business policies
Keeping unnecessary data indefinitely increases storage requirements without providing additional operational value.
Related Guide: Wazuh Data Retention Guide
Automatic Rollover
Automatic rollover prevents indexes from becoming excessively large.
Instead of continuously writing to one growing index, rollover creates a new index after predefined thresholds are reached.
Typical rollover triggers include:
- Maximum index size
- Maximum age
- Maximum document count
Benefits include:
- Improved indexing performance
- Faster search operations
- Smaller recovery windows
- Easier snapshot management
- More predictable shard sizes
Most production deployments combine rollover with ISM so that new indexes are created and managed automatically.
Snapshot Planning
Snapshots provide point-in-time backups of indexes and cluster metadata.
Rather than creating snapshots only after configuration changes, organizations should establish a regular snapshot schedule.
Planning considerations include:
- Snapshot frequency
- Storage location
- Retention period
- Available bandwidth
- Recovery objectives
- Compliance requirements
Common strategies include:
- Daily incremental snapshots
- Weekly full snapshots
- Monthly long-term archive snapshots
Snapshots should be tested periodically to verify they can be restored successfully when needed.
Archiving Older Data
Not all indexed data requires high-performance storage.
Older indexes that are accessed infrequently can often be archived to lower-cost storage while remaining available for compliance reviews or forensic investigations.
Archiving offers several benefits:
- Reduced storage costs
- Improved cluster performance
- Faster indexing of active data
- Better capacity utilization
Organizations should establish clear policies defining:
- Which data is archived
- When data is archived
- How archived data is retrieved
- When archived data is permanently deleted
Automating archival as part of the lifecycle strategy helps ensure consistent storage management over time.
Related Guides:
Backing Up and Restoring Wazuh Indexer
Even highly available clusters require reliable backups.
Hardware failures, accidental deletions, configuration errors, ransomware incidents, and software bugs can all result in data loss if no recovery strategy is in place.
OpenSearch uses snapshots as its primary backup mechanism.
Unlike traditional file-level backups, snapshots capture indexes and cluster metadata in a format designed for efficient recovery.
Snapshot Repositories
Before snapshots can be created, administrators must configure a snapshot repository.
Supported repository types include:
- Local file systems
- Network-attached storage (NAS)
- Shared file systems
- Cloud object storage (depending on deployment and plugins)
The repository should be:
- Reliable
- Secure
- Accessible to cluster nodes
- Sized appropriately for expected backup growth
Repositories should also be monitored to ensure adequate free space and successful backup completion.
Creating Snapshots
Snapshots capture the state of selected indexes at a specific point in time.
Administrators may choose to back up:
- Individual indexes
- Multiple indexes
- Entire clusters
- Cluster metadata
- Templates and policies
Snapshot frequency depends on:
- Data change rate
- Recovery objectives
- Compliance requirements
- Available storage
Automating snapshot creation helps ensure backups remain current without relying on manual processes.
Feature Insight: According to the OpenSearch documentation, snapshots are incremental after the initial backup, meaning only newly created or changed data segments are copied, reducing storage usage and backup duration.
Restoring Indexes
When data loss occurs, snapshots can be used to restore affected indexes.
Common recovery scenarios include:
- Accidental index deletion
- Corrupted indexes
- Failed upgrades
- Hardware replacement
- Disaster recovery testing
Before restoring data, administrators should:
- Verify snapshot integrity.
- Identify the correct recovery point.
- Confirm sufficient storage capacity.
- Evaluate the impact on production workloads.
- Test restoration procedures whenever possible.
Routine recovery testing helps ensure backup procedures work as expected during real incidents.
Disaster Recovery Planning
Backups alone do not constitute a disaster recovery strategy.
A comprehensive recovery plan should define:
- Recovery Point Objective (RPO)
- Recovery Time Objective (RTO)
- Backup schedules
- Restoration procedures
- Roles and responsibilities
- Secondary infrastructure
- Communication procedures
- Validation steps after recovery
Documented disaster recovery plans reduce downtime and improve organizational readiness during major incidents.
Backup Best Practices
To maximize reliability, organizations should follow several backup best practices:
- Schedule automated snapshots.
- Store backups separately from production systems.
- Encrypt backup repositories.
- Monitor snapshot success and failures.
- Test restores on a regular basis.
- Retain multiple recovery points.
- Document recovery procedures.
- Review backup policies as data volumes grow.
A disciplined backup strategy, combined with lifecycle management and proactive capacity planning, significantly reduces the operational risk of large-scale Wazuh deployments.
Related Guides:
Migrating Wazuh Indexer Storage
Storage requirements often change as Wazuh environments grow.
Organizations may need to replace older disks, move from HDDs to SSDs, expand capacity, or migrate workloads to new infrastructure.
Migrating Wazuh Indexer storage requires careful planning because indexes contain active security data that must remain consistent throughout the migration process.
A poorly planned migration can result in:
- Missing indexes
- Corrupted data
- Extended downtime
- Unassigned shards
- Cluster instability
A controlled migration process minimizes risk while preserving indexed security information.
Related Guide: How to Migrate Wazuh Indexer Data to New Storage Volumes
When Migration Is Necessary
Common reasons to migrate Wazuh Indexer storage include:
- Running out of available disk space
- Replacing aging hardware
- Moving to faster SSD or NVMe storage
- Increasing storage capacity
- Moving workloads to new servers
- Improving indexing performance
- Changing infrastructure providers
Storage migration is especially common when organizations experience increased endpoint coverage and higher event ingestion rates.
For example, a deployment that originally supported hundreds of endpoints may eventually require significantly faster storage after expanding to thousands of systems.
Preparing for Migration
Before migrating storage, administrators should complete several preparation steps.
Recommended preparation includes:
- Review current disk utilization.
- Verify cluster health.
- Confirm all indexes are healthy.
- Create recent snapshots.
- Document current configuration.
- Identify available migration methods.
- Schedule maintenance windows if required.
- Validate new storage performance.
Important checks include:
- Cluster status is green.
- No shards are unassigned.
- Indexing is functioning normally.
- Backup snapshots are available.
Migration should never begin while the cluster is already experiencing stability issues.
Related Guide: How to Fix Wazuh All Shards Failed Error
Moving Data Safely
There are several approaches for migrating Wazuh Indexer data.
Common strategies include:
1. Snapshot and Restore
This approach creates a backup snapshot, moves it to the new environment, and restores the indexes.
Advantages:
- Safest approach
- Built-in recovery mechanism
- Good for major infrastructure changes
2. Rolling Storage Migration
In multi-node clusters, administrators can migrate nodes individually while maintaining cluster availability.
Typical steps include:
- Disable shard allocation.
- Remove or migrate one node.
- Move storage.
- Rejoin the node.
- Allow shard recovery.
- Repeat for remaining nodes.
3. Data Copy Migration
Administrators may copy data directories directly in certain controlled scenarios, but this requires careful handling because OpenSearch maintains internal metadata and shard states.
For production environments, snapshot-based migration is generally preferred because it reduces the risk of inconsistent data.
Validating Migrated Indexes
After migration, administrators should verify:
- All nodes joined successfully.
- Cluster health is normal.
- Index counts match expectations.
- Document counts are consistent.
- Searches return expected results.
- Dashboard connectivity works.
- No shard allocation errors exist.
Validation should include testing:
- Recent alerts
- Historical searches
- Dashboards
- Reports
- API queries
A migration should not be considered complete until normal security operations have been confirmed.
Common Migration Issues
Several problems commonly occur during Wazuh Indexer storage migrations.
Insufficient Disk Space
The destination storage may not have enough capacity for:
- Existing indexes
- Replica shards
- Future growth
- Temporary migration overhead
Solution:
- Calculate requirements before migration.
- Include replica storage.
- Maintain growth capacity.
Unassigned Shards
After migration, shards may remain unavailable because of allocation issues.
Possible causes include:
- Incorrect node configuration
- Disk watermarks
- Missing data paths
- Cluster discovery problems
Solution:
- Review cluster health.
- Check allocation explanations.
- Verify node configuration.
Slow Recovery Times
Large datasets may take hours or days to recover depending on:
- Data volume
- Network speed
- Disk performance
- Number of shards
Solution:
- Use faster storage.
- Monitor recovery progress.
- Schedule migrations during low activity periods.
Permission Problems
Incorrect ownership or permissions can prevent Indexer from reading migrated data.
Solution:
- Verify directory ownership.
- Confirm service permissions.
- Review Indexer logs.
Related Guide: How to Migrate Wazuh Indexer Data to New Storage Volumes
Monitoring Wazuh Indexer Health
Continuous monitoring is essential for maintaining a reliable Wazuh Indexer cluster.
Performance issues often develop gradually, beginning with increasing disk usage, rising memory pressure, slower queries, or delayed indexing.
By monitoring cluster health and resource utilization, administrators can identify problems before they affect security visibility.
Cluster Health Status
Cluster health is one of the most important indicators of Wazuh Indexer availability.
OpenSearch reports cluster health using three primary states:
Green
- All primary shards are assigned.
- All replica shards are available.
- Cluster is operating normally.
Yellow
- Primary shards are available.
- One or more replica shards are missing.
Yellow status usually indicates reduced redundancy but does not necessarily prevent searches.
Red
- One or more primary shards are unavailable.
- Data may be missing or inaccessible.
- Immediate investigation is required.
Administrators should regularly monitor cluster health because prolonged unhealthy states can lead to data availability problems.
Related Guide: How to Fix a Yellow Cluster Status in Wazuh Indexer
Node Statistics
Node statistics provide visibility into individual Indexer performance.
Important metrics include:
- CPU utilization
- Memory consumption
- Disk usage
- Indexing rate
- Search latency
- Active connections
- Thread pool activity
Node-level monitoring helps identify:
- Overloaded servers
- Uneven shard distribution
- Resource bottlenecks
- Failing hardware
In multi-node clusters, comparing statistics between nodes helps identify whether workloads are properly balanced.
JVM Memory Usage
Because Wazuh Indexer runs on Java, JVM memory management directly impacts performance.
Important JVM metrics include:
- Heap utilization
- Garbage collection activity
- Memory pressure
- Heap allocation failures
Common symptoms of JVM memory problems include:
- Slow searches
- Failed indexing operations
- Long garbage collection pauses
- Node instability
Administrators should maintain appropriate heap sizing and avoid assigning excessive memory because OpenSearch also requires system memory outside the JVM heap.
Related Guide: How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes
Disk Usage Monitoring
Disk monitoring is critical because OpenSearch depends heavily on available storage capacity.
Important disk metrics include:
- Used capacity percentage
- Available space
- Growth rate
- Disk latency
- I/O utilization
Administrators should configure alerts before reaching disk watermarks to allow time for corrective action.
Preventative actions include:
- Expanding storage
- Removing expired indexes
- Adjusting retention policies
- Migrating older data
Related Guide: How to Manage Wazuh Storage
Performance Metrics
Performance monitoring provides insight into whether the Indexer can keep up with security workloads.
Key metrics include:
Indexing Performance
Measures how quickly new security events are stored.
Important indicators:
- Documents indexed per second
- Indexing latency
- Rejected indexing requests
Search Performance
Measures how efficiently analysts can retrieve information.
Indicators include:
- Query response time
- Search queue length
- Slow queries
Cluster Performance
Measures overall reliability.
Indicators include:
- Shard recovery times
- Cluster state updates
- Node availability
- Replica synchronization
Regular performance monitoring allows administrators to optimize resources, identify bottlenecks, and maintain reliable security visibility.
Related Guides:
- How to Design a Wazuh OpenSearch Shard Allocation Strategy
- How to Fix circuit_breaking_exception Data Overloads in Wazuh Indexer
Securing Wazuh Indexer
Security is a critical consideration when deploying Wazuh Indexer because it stores sensitive security telemetry, including authentication events, vulnerability findings, endpoint activity, and threat detection data.
A compromised Indexer could expose valuable information about an organization’s infrastructure, security posture, and operational activity.
Therefore, production deployments should implement encryption, strong authentication, access controls, and network protections.
Wazuh Indexer includes OpenSearch Security features that provide mechanisms for protecting stored data and controlling access to cluster resources.
TLS Encryption
Transport Layer Security (TLS) protects communication between Wazuh components by encrypting data as it moves between systems.
In a typical Wazuh deployment, TLS protects communication between:
- Wazuh Manager and Wazuh Indexer
- Wazuh Dashboard and Wazuh Indexer
- Indexer nodes within a cluster
- Administrative clients and OpenSearch APIs
TLS encryption prevents attackers from intercepting sensitive information such as:
- Security alerts
- Authentication records
- Vulnerability information
- Endpoint metadata
- Administrative requests
Production environments should use properly configured certificates issued by a trusted certificate authority or an internally managed PKI system.
Best practices include:
- Use valid certificates for all nodes.
- Rotate certificates before expiration.
- Protect private keys.
- Disable insecure protocols.
- Verify certificate trust chains.
- Monitor certificate expiration dates.
Certificate problems are one of the most common causes of communication failures in Wazuh deployments.
Related Guide: How to Fix Wazuh Certificate Errors
Authentication
Authentication ensures that only authorized users and services can connect to Wazuh Indexer.
Wazuh Indexer supports authentication mechanisms that verify user identities before allowing access to cluster resources.
Common authentication approaches include:
- Internal user databases
- Certificate-based authentication
- LDAP integration
- Active Directory integration
- Single sign-on solutions
Strong authentication practices include:
- Enforcing strong passwords.
- Removing default credentials.
- Using unique accounts.
- Limiting administrative access.
- Enabling centralized identity management where possible.
Administrative accounts should be carefully controlled because they can modify indexes, security policies, and cluster configurations.
Role-Based Access Control
Role-Based Access Control (RBAC) allows administrators to control what users can access and what actions they can perform.
Instead of giving every user full cluster permissions, RBAC assigns permissions based on responsibilities.
Examples include:
Security Analysts
May need access to:
- Security alerts
- Dashboards
- Investigation queries
Security Administrators
May require:
- Rule management
- Index management
- Configuration access
Platform Administrators
May require:
- Cluster monitoring
- Node management
- Infrastructure operations
RBAC reduces security risk by following the principle of least privilege.
A user investigating malware alerts should not automatically have permission to delete indexes or modify cluster settings.
Multi-Tenancy Considerations
Multi-tenancy allows multiple users or teams to share the same Wazuh Indexer environment while maintaining separate access boundaries.
Common use cases include:
- Managed Security Service Providers (MSSPs)
- Large enterprises with multiple security teams
- Organizations separating business units
- Development and production environments
Multi-tenancy controls:
- Which dashboards users can access
- Which indexes users can search
- Which saved objects are visible
- Which administrative actions are permitted
Incorrect multi-tenancy configuration can result in:
- Missing dashboards
- Permission errors
- Authentication failures
- Users seeing incorrect data
- Dashboard loading problems
Administrators should carefully align:
- Security roles
- Index permissions
- Tenant configuration
- Dashboard access rules
Related Guide: Resolving OpenSearch Multi-Tenancy Mismatches in Wazuh Deployments
Network Security Best Practices
Network security provides an additional layer of protection around Wazuh Indexer infrastructure.
Recommended practices include:
- Restrict Indexer access using firewalls.
- Expose only required ports.
- Place Indexer nodes on protected networks.
- Restrict administrative API access.
- Use network segmentation.
- Monitor unusual connection attempts.
- Disable unnecessary services.
Common ports in Wazuh deployments include:
- 9200 — Indexer REST API communication
- 9300 — Internal cluster communication
- 443 — Dashboard HTTPS communication
Only trusted systems should communicate directly with Indexer nodes.
Additional protections include:
- VPN access for remote administration
- Network intrusion detection
- Security monitoring
- Regular vulnerability assessments
A properly secured Indexer reduces the risk of unauthorized access while maintaining availability for security operations.
Cross Cluster Search
As organizations expand, they may operate multiple Wazuh Indexer clusters across different locations, business units, or environments.
Cross Cluster Search (CCS) allows administrators to search data across multiple OpenSearch clusters from a single Wazuh Indexer environment without manually moving or copying data.
This capability is especially useful for distributed security operations where analysts need visibility across multiple environments.
Related Guide: How to Configure Wazuh Cross Cluster Search
What Cross Cluster Search Is
Cross Cluster Search allows one OpenSearch cluster to send search requests to remote clusters.
Instead of consolidating all security data into one massive cluster, organizations can maintain separate clusters while providing centralized search capabilities.
For example:
- Region A operates one Wazuh cluster.
- Region B operates another Wazuh cluster.
- A central SOC searches both environments from one location.
The query is distributed across connected clusters, and results are combined into a single response.
Unlike data replication, Cross Cluster Search does not copy indexes between clusters.
Each cluster maintains ownership of its own data.
Benefits
Cross Cluster Search provides several advantages:
- Centralized threat hunting
- Reduced need for data duplication
- Independent cluster management
- Regional data sovereignty
- Improved scalability
- Easier multi-site deployments
Organizations can maintain separate environments while still allowing analysts to investigate events across the entire infrastructure.
Common scenarios include:
- Global enterprises with regional SOC teams
- Hybrid cloud environments
- Separate production and development clusters
- MSSP deployments managing multiple customers
Remote Cluster Configuration
To use Cross Cluster Search, administrators must configure trusted communication between clusters.
Typical configuration steps include:
- Enable remote cluster connectivity.
- Configure remote cluster addresses.
- Verify network connectivity.
- Configure security permissions.
- Test cross-cluster queries.
Requirements usually include:
- Compatible OpenSearch versions
- Network connectivity between clusters
- Valid TLS configuration
- Appropriate authentication permissions
Incorrect configuration may result in:
- Connection failures
- Authentication errors
- Timeout issues
- Missing search results
Common Use Cases
Common Cross Cluster Search implementations include:
Centralized Security Operations
A SOC team searches alerts from multiple Wazuh deployments without logging into each environment separately.
Regional Deployments
Organizations maintain local clusters for performance while providing global visibility.
Compliance Investigations
Security teams search historical records across multiple environments during audits.
Large Enterprise Scaling
Organizations split workloads across multiple clusters instead of operating one extremely large cluster.
Performance Considerations
Cross Cluster Search introduces additional network and processing requirements.
Performance depends on:
- Network latency
- Query complexity
- Number of remote clusters
- Amount of returned data
- Remote cluster resources
Best practices include:
- Limit searches to required indexes.
- Avoid broad wildcard queries.
- Monitor network latency.
- Use appropriate time ranges.
- Maintain compatible cluster versions.
- Monitor remote cluster health.
Poorly optimized queries can create unnecessary load on both local and remote clusters.
Related Guide: How to Configure Wazuh Cross Cluster Search
Common Wazuh Indexer Problems
Wazuh Indexer provides powerful search and analytics capabilities, but administrators may encounter issues related to memory, storage, indexing, cluster health, and configuration.
Understanding common failure scenarios helps reduce troubleshooting time and prevent recurring problems.
Circuit Breaking Exceptions
A circuit breaking exception occurs when OpenSearch prevents an operation because it estimates that the request would consume too much memory.
This protection prevents the JVM from running out of memory and crashing the Indexer node.
Common causes include:
- Large search queries
- Excessive aggregations
- High indexing volume
- Insufficient heap allocation
- Too many concurrent requests
Symptoms include:
- Failed searches
- Dashboard errors
- Slow queries
- Indexing failures
Solutions may include:
- Optimizing queries
- Increasing available memory
- Adjusting heap settings
- Reducing unnecessary aggregations
- Scaling the Indexer cluster
Related Guide: How to Fix circuit_breaking_exception Data Overloads in Wazuh Indexer
Rejected Index Templates
Index template errors occur when OpenSearch cannot apply the expected template during index creation.
Common causes include:
- Invalid template definitions
- Conflicting templates
- Incorrect settings
- Version compatibility problems
Symptoms include:
- New indexes failing to create
- Indexing failures
- Missing data
- Dashboard errors
Administrators should review:
- Existing templates
- Template priority
- Field mappings
- Index patterns
Related Guide: Fixing Rejected Index Templates and Invalid Mapping Types in Wazuh
Invalid Mapping Types
Mapping conflicts happen when the same field is assigned different data types across indexes.
For example:
- One index stores a field as a string.
- Another index stores the same field as an integer.
OpenSearch cannot reliably search fields with conflicting definitions.
Common causes include:
- Custom log sources
- Incorrect decoder configurations
- Manual index modifications
- Application changes
Solutions include:
- Reviewing mappings
- Creating correct templates
- Reindexing affected data
- Standardizing field definitions
Missing Dashboard Statistics
Missing statistics in Wazuh Dashboard often indicate communication or indexing problems between Dashboard and Indexer.
Possible causes include:
- Authentication failures
- Missing permissions
- Index availability problems
- Incorrect tenant configuration
- Failed indexing operations
Troubleshooting steps include:
- Checking Indexer health.
- Reviewing Dashboard logs.
- Verifying user permissions.
- Confirming required indexes exist.
Related Guide: How to Fix Missing Statistics in Wazuh Dashboard
All Shards Failed
The “all shards failed” error occurs when OpenSearch cannot successfully execute a query because every shard involved in the operation has failed.
Common causes include:
- Corrupted indexes
- Mapping conflicts
- Unassigned shards
- Disk problems
- Cluster instability
Symptoms include:
- Failed searches
- Dashboard errors
- Missing data
- Query failures
Resolution typically involves:
- Checking cluster health.
- Identifying failed shards.
- Reviewing Indexer logs.
- Repairing allocation problems.
- Restoring from snapshots if necessary.
Related Guide: How to Fix Wazuh All Shards Failed Error
High Disk Usage
High disk usage is one of the most common causes of Wazuh Indexer instability.
When disks approach configured watermarks, OpenSearch may:
- Stop allocating shards
- Move shards between nodes
- Set indexes to read-only mode
Common causes include:
- Excessive retention periods
- Rapid log growth
- Missing rollover policies
- Large indexes
- Insufficient storage capacity
Solutions include:
- Deleting expired indexes.
- Expanding storage.
- Adjusting retention policies.
- Implementing ISM automation.
- Migrating data to larger volumes.
Related Guide: How to Manage Wazuh Storage
Cluster Health Turns Yellow or Red
Cluster health problems indicate that the Indexer cluster is not operating normally.
Yellow Status
Usually means:
- Primary shards are available.
- Replica shards are missing.
Common causes:
- Failed nodes
- Insufficient resources
- Allocation restrictions
Red Status
Means:
- Primary shards are unavailable.
- Data may be inaccessible.
Common causes:
- Corrupted indexes
- Disk failures
- Node outages
- Allocation failures
Troubleshooting should include:
- Checking cluster health.
- Reviewing shard allocation.
- Examining node availability.
- Checking disk capacity.
- Reviewing Indexer logs.
Maintaining healthy cluster status is essential because degraded clusters can eventually affect security monitoring visibility.
Related Guides:
A properly secured, scalable, and monitored Wazuh Indexer provides the foundation required for reliable enterprise security analytics.
By combining strong access controls, lifecycle automation, cross-cluster capabilities, and proactive troubleshooting, organizations can maintain a resilient search platform capable of supporting large-scale threat detection operations.
Be First to Comment