How to Build a Wazuh Indexer Cluster

The Wazuh indexer is a highly scalable, full-text search and analytics engine used to store and index security alerts generated by the Wazuh manager.

Built on top of OpenSearch, it acts as the central data repository of the Wazuh architecture.

It organizes incoming security data into JSON documents, making massive volumes of security event logs rapidly searchable and quantifiable.

Why Deploy a Wazuh Indexer Cluster?

Benefits of Clustering

• • High Availability: Keeps the search engine accessible and operational even if individual physical servers experience hardware crashes.
  • Improved Scalability: Allows horizontal scaling by adding new instances to handle increased EPS without reconfiguring existing hardware.
  • Data Redundancy: Ensures multiple copies of security logs exist across separate physical nodes to eliminate data loss risks.
  • Better Fault Tolerance: Automatically detects dead nodes, reorganizes the remaining infrastructure, and shifts tasks without system downtime.

Overview of the Deployment Process

1. 1. Prepare Nodes: Configure network settings, firewall rules, and certificate authorities across all intended server hosts.
   2. Install Packages: Deploy the Wazuh indexer binaries onto every node participating in the cluster architecture.
   3. Configure Cluster Settings: Define node roles, cluster names, and network bindings in the configuration files.
   4. Generate Certificates: Secure inter-node and client-to-node communications using TLS certificates.
   5. Initialize the Cluster: Boot the instances and run the initialization script to elect leaders and form the cluster state. 

Understanding Wazuh Indexer Cluster Architecture

Component Relationships

• • Wazuh Manager: Collects logs from agents, analyzes events against security rules, generates alerts, and forwards those alerts to the Wazuh indexer via Filebeat.
  • Wazuh Indexer: Receives raw alerts from the manager, stores them in partitioned data structures, and runs search queries when requested.
  • Wazuh Dashboard: Connects directly to the Wazuh indexer cluster to query stored alerts and render real-time visualizations for security analysts. 

Core Cluster Components

Cluster Nodes

Any single running instance of the Wazuh indexer process is considered a node. Multiple nodes share the responsibilities of indexing data and serving user queries.

Master-Eligible Nodes

These instances control the cluster’s configuration state. They manage global tasks like creating or deleting indices, tracking which nodes are active, and deciding where to distribute data shards. Only one master-eligible node is elected as the active cluster leader at any given time.

Data Nodes

Data nodes hold the actual security logs and alerts indexed by the system. They perform data-heavy operations including document indexing, data modification, and local search execution.

Cluster Coordination

The cluster maintains consensus using an internal voting system among master-eligible nodes. This process prevents data synchronization conflicts and ensures that configuration changes are safely replicated across the entire cluster layout.

Recommended Cluster Topologies

• • Single-Node Deployment: Installs all components on a single server. It is ideal for testing, staging, and small lab environments, but lacks any redundancy or high availability.
  • Three-Node Production Cluster: Contains three nodes that act as both master-eligible and data nodes. This setup is the minimum requirement for a resilient production environment, ensuring voting majorities remain intact if one node drops offline.
  • Multi-Node Enterprise Cluster: Separates node responsibilities into dedicated master nodes and dedicated data nodes across four or more servers. It is optimized for high-EPS enterprise environments to prevent heavy search queries from affecting cluster management tasks.

How Data Replication Works

Primary Shards

When an index is created, it is split into one or more primary shards. Each primary shard is a self-contained Lucene index instance that holds a subset of the total documents and handles initial write operations.

Replica Shards

Every primary shard can have one or more replica shards, which are exact duplicates of the primary data. Replica shards provide backup copies for data safety and handle read operations to speed up visualization queries on the dashboard.

Data Availability During Node Failures

The cluster prevents primary and replica shards of the same dataset from living on the same physical host. If a node holding a primary shard fails, the master node instantly promotes a corresponding replica shard on a surviving node to “primary” status. This automatic failover happens in seconds, keeping security dashboards operational and preventing data loss.

Building a reliable Wazuh Indexer cluster starts with properly sizing your infrastructure.

Since the Wazuh Indexer is based on the OpenSearch engine, insufficient CPU, memory, or storage resources can lead to indexing delays, slow searches, cluster instability, and increased recovery times during node failures.

While small test environments can operate with minimal resources, production deployments should be designed to accommodate log growth, retention requirements, and future scaling.

CPU Recommendations

The CPU requirements depend largely on log ingestion volume, search frequency, and the number of endpoints sending data.

Minimum Lab Environment

• 2 vCPUs per node
• Suitable for testing and small proof-of-concept deployments
• Not recommended for production workloads

Small Production Environment

• 4 vCPUs per node
• Up to several hundred monitored endpoints
• Moderate search activity

Medium to Large Production Environment

• 8+ vCPUs per node
• Thousands of monitored endpoints
• High query volumes and frequent dashboard usage

The OpenSearch team recommends allocating sufficient CPU resources because indexing, shard allocation, replication, and query execution all compete for processing power.

Expert Insight: OpenSearch engineers frequently emphasize that CPU bottlenecks often appear before storage bottlenecks in log analytics environments because every incoming event must be parsed, indexed, and replicated across the cluster.

Memory Recommendations

Memory is one of the most important resources in any Wazuh Indexer deployment.

The indexer relies heavily on memory for:

• Index caching
• Query performance
• Shard management
• Cluster state maintenance
• Java Virtual Machine (JVM) operations

A common recommendation is to allocate approximately 50% of available system memory to the JVM heap while leaving the remaining memory available to the operating system.

Recommended RAM Per Node

For production environments, Wazuh generally recommends at least 8 GB of RAM for Indexer nodes.

If you’re planning long-term storage of security events, review your retention strategy in How to Configure Wazuh Log Retention.

 Storage Considerations

Storage planning should account for:

• Daily log volume
• Retention period
• Replica count
• Future growth

Because every replica shard duplicates data, clustering increases total storage requirements.

For example:

SSD storage is strongly recommended.

Benefits include:

• Faster indexing
• Reduced shard recovery times
• Better search performance
• Lower cluster latency

Avoid traditional spinning disks whenever possible in production environments.

Network Bandwidth Requirements

Cluster nodes constantly communicate with one another.

This communication includes:

• Cluster state updates
• Shard synchronization
• Replica transfers
• Recovery operations
• Health checks

Recommended network connectivity:

Latency between nodes should remain as low as possible.

High latency can cause:

• Delayed shard allocation
• Split-brain scenarios
• Cluster instability
• Slower recovery operations

Whenever possible, place Indexer nodes within the same data center or low-latency network segment.

Software Requirements

Before creating the cluster, verify that all nodes meet Wazuh’s software compatibility requirements.

Supported Linux Distributions

Wazuh supports several enterprise Linux distributions for Indexer deployments, including:

• Ubuntu Server
• Debian
• Red Hat Enterprise Linux (RHEL)
• Rocky Linux
• AlmaLinux
• Oracle Linux

For production deployments, use the latest supported long-term support (LTS) release whenever possible.

Official Wazuh installation guide: https://documentation.wazuh.com/current/installation-guide/

Wazuh Version Compatibility

Every cluster node should run:

• The same Wazuh Indexer version
• The same OpenSearch version bundled with Wazuh
• The same security configuration

Mixing versions within the cluster can result in:

• Cluster formation failures
• Replication issues
• Incompatible shard allocation
• Upgrade complications

Before deployment, verify compatibility across:

• Wazuh Manager
• Wazuh Dashboard
• Wazuh Indexer

If you are planning an upgrade before clustering, see How to Upgrade a Wazuh Agent for general upgrade planning considerations.

Required Packages

Typical packages required on Linux systems include:

curl
tar
wget
unzip
gnupg
ca-certificates

Depending on your distribution, additional networking or security packages may also be required.

Ensure the following services are available:

• systemd
• NTP/chrony
• Network Manager (optional)
• OpenSSL

Security Certificates

Every Wazuh Indexer node requires valid TLS certificates.

Certificates are used to secure:

• Node-to-node communication
• Dashboard communication
• API access

Without properly configured certificates, cluster formation may fail.

For certificate troubleshooting, see How to Fix Wazuh Certificate Errors.

Network and Firewall Requirements

Network configuration is a common source of cluster deployment failures.

Every node must be able to communicate with every other node reliably.

 Required Ports

Common Wazuh Indexer ports include:

The most critical port for cluster creation is:

9300/TCP

This port handles cluster coordination and shard replication.

Inter-Node Communication

Verify that all nodes can:

• Resolve each other’s hostnames
• Reach each other through firewalls
• Exchange traffic on cluster ports
• Maintain stable connectivity

A simple connectivity test can be performed with:

ping node2.example.com

and

nc -zv node2.example.com 9300

DNS and Hostname Resolution

Every cluster node should have:

• A unique hostname
• Consistent forward DNS resolution
• Consistent reverse DNS resolution

Many administrators choose to define static entries in /etc/hosts to eliminate DNS dependency during initial cluster formation.

Example:

10.0.1.10 indexer01
10.0.1.11 indexer02
10.0.1.12 indexer03

This helps prevent node discovery failures during deployment.

Time Synchronization

Time synchronization is often overlooked but is essential for cluster stability.

Importance of NTP

All nodes should maintain synchronized system clocks.

Use one of the following:

• NTP
• Chrony
• Enterprise time servers

Benefits include:

• Accurate event timestamps
• Reliable authentication
• Consistent certificate validation
• Predictable cluster operations

NTP Best Practices from NIST: https://www.nist.gov/pml/time-and-frequency-division/time-services

Preventing Cluster Inconsistencies

Clock drift between nodes can create several problems:

• Authentication failures
• Certificate validation errors
• Replication delays
• Misleading log timelines
• Troubleshooting difficulties

Before building the cluster, verify synchronization:

timedatectl status

Expected output should show:

System clock synchronized: yes
NTP service: active

A properly synchronized environment reduces operational risk and helps ensure consistent cluster behavior as nodes join, leave, or recover from failures.

Planning Your Cluster Deployment

Proper planning is one of the most important steps when building a Wazuh Indexer cluster.

A well-designed cluster provides the scalability and fault tolerance required for long-term security monitoring, while poor planning can result in performance bottlenecks, excessive storage costs, and difficult future migrations.

Before deploying any nodes, determine your expected log volume, retention requirements, endpoint count, and anticipated growth over the next several years.

Determining the Number of Nodes

The number of Indexer nodes directly impacts cluster availability, storage capacity, and overall performance.

Small Environments

Small organizations and lab environments can often operate with a three-node cluster.

Typical characteristics include:

• Fewer than 500 monitored endpoints
• Less than 20 GB of logs per day
• Moderate dashboard usage
• Standard compliance requirements

A three-node deployment provides:

• High availability
• Data replication
• Quorum-based cluster management
• Protection against a single node failure

Although a single-node deployment is possible, it should only be used for testing environments because it lacks redundancy.

Medium-Sized Deployments

Medium environments typically include:

• 500–5,000 monitored endpoints
• 20–100 GB of daily log ingestion
• Multiple security analysts
• Increased search workloads

Recommended architecture:

• 3 dedicated cluster manager nodes
• 3–6 data nodes

Separating management and data responsibilities improves cluster stability and minimizes the risk of cluster elections impacting indexing performance.

Large-Scale Deployments

Enterprise environments often monitor:

• Thousands of servers and workstations
• Cloud workloads
• Network devices
• Security appliances
• Kubernetes clusters

If you are monitoring containerized environments, you may also find our guide on How to Monitor Kubernetes Using Wazuh helpful.

Large deployments often require:

• Dedicated cluster manager nodes
• Multiple data nodes
• Dedicated ingest nodes
• Multi-tier storage architectures

Large clusters are designed to continue operating even during hardware failures, maintenance windows, or unexpected traffic spikes.

Choosing Node Roles

One of the most important architectural decisions is determining how cluster responsibilities are distributed.

Dedicated Master Nodes

Modern OpenSearch clusters use cluster manager nodes (formerly known as master nodes).

These nodes manage:

• Cluster state
• Shard allocation
• Node discovery
• Election processes

Best practice is to deploy three dedicated cluster manager nodes.

Benefits include:

• Improved cluster stability
• Faster elections
• Reduced risk of split-brain conditions
• Better scalability

Data Nodes

Data nodes store and process indexed security events.

Responsibilities include:

• Indexing logs
• Running searches
• Managing shards
• Storing replicas

Most cluster resources are typically allocated to data nodes because they handle the majority of workload processing.

Hybrid Nodes

Hybrid nodes combine both cluster management and data responsibilities.

Advantages:

• Simpler deployment
• Lower infrastructure costs
• Suitable for small environments

Disadvantages:

• Reduced scalability
• Resource contention
• Greater impact during node failures

For most organizations, hybrid nodes work well in a three-node cluster.

Capacity Planning Considerations

Capacity planning ensures your cluster can support both current and future requirements.

Daily Log Volume

Estimate the average amount of security data generated each day.

Common log sources include:

• Wazuh agents
• Windows event logs
• Syslog devices
• Firewalls
• Cloud platforms
• Endpoint security tools

If you plan to ingest network security data, review How to Collect Firewall Logs in Wazuh for additional sizing considerations.

Example:

Actual values vary significantly depending on logging verbosity.

Retention Requirements

Many organizations retain logs for:

• 30 days
• 90 days
• 1 year
• Multiple years

Compliance frameworks often influence retention policies.

Longer retention periods increase:

• Storage requirements
• Backup costs
• Replication overhead

For retention planning strategies, see How to Configure Wazuh Log Retention.

Future Growth Estimates

Many organizations underestimate future log growth.

When sizing a cluster, consider:

• Endpoint growth
• Cloud adoption
• Additional integrations
• Regulatory requirements
• Security monitoring expansion

A common recommendation is to plan for at least 30–50% annual growth.

Expert Insight: OpenSearch architects frequently recommend sizing clusters for future growth rather than current usage because adding nodes later often requires shard rebalancing and significant operational effort.

Example Production Architecture

The following architecture is commonly used for small-to-medium production deployments.

Three-Node Wazuh Indexer Cluster

Benefits include:

• High availability
• Replica support
• Automatic failover
• Simplified management

If one node fails, the cluster remains operational.

Wazuh Manager Integration

The Wazuh Manager forwards security events to the Indexer cluster.

Typical flow:

Wazuh Agents
      ↓
Wazuh Manager
      ↓
Wazuh Indexer Cluster
      ↓
Wazuh Dashboard

The manager does not store long-term event data. Instead, the Indexer cluster becomes the central repository for security events.

Dashboard Connectivity

The Wazuh Dashboard communicates with the Indexer cluster through the OpenSearch API.

For resiliency, many organizations place a load balancer in front of the cluster.

Benefits include:

• Simplified configuration
• Automatic failover
• Better user experience
• Improved availability

Installing Wazuh Indexer on Each Node

After planning the architecture, the next step is installing the Wazuh Indexer software on every cluster node.

Each node should be prepared identically before cluster configuration begins.

Preparing the Servers

Consistency across nodes is critical.

Every node should have:

• Identical operating system versions
• Consistent hostnames
• Proper DNS records
• Synchronized clocks
• Matching security configurations

Update Operating System

Before installing any packages, update the operating system.

Ubuntu/Debian:

sudo apt update
sudo apt upgrade -y

RHEL/Rocky Linux/AlmaLinux:

sudo dnf update -y

Applying updates before deployment reduces compatibility and security issues.

Configure Hostnames

Assign a unique hostname to each node.

Example:

indexer01
indexer02
indexer03

Verify hostname resolution:

hostnamectl

And test connectivity:

ping indexer02

Verify Network Connectivity

All nodes must communicate with one another before cluster formation begins.

Verify:

• ICMP connectivity
• DNS resolution
• Port accessibility
• Firewall rules

A simple connectivity test:

nc -zv indexer02 9300

Successful communication now prevents difficult troubleshooting later.

Installing Required Dependencies

Certain operating system settings should be configured before installing the Indexer.

Java Requirements (If Applicable)

Modern Wazuh Indexer releases include bundled Java runtimes.

However, verify compatibility with your deployment documentation before installation.

Wazuh Indexer installation requirements: https://documentation.wazuh.com/current/installation-guide/wazuh-indexer/

System Configuration Settings

OpenSearch-based deployments commonly require kernel tuning.

Example:

sudo sysctl -w vm.max_map_count=262144

Verify:

sysctl vm.max_map_count

Expected output:

vm.max_map_count = 262144

This setting is required for proper memory mapping operations.

Installing the Wazuh Indexer Package

Repository Configuration

Add the official Wazuh repository.

Example (Ubuntu):

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key add -

Then configure the repository according to your operating system.

Package Installation Steps

Install the package:

sudo apt install wazuh-indexer -y

or

sudo dnf install wazuh-indexer -y

Installation may take several minutes depending on system resources.

Verifying Successful Installation

Verify that the package is installed:

rpm -qa | grep wazuh-indexer

or

dpkg -l | grep wazuh-indexer

Confirm the service exists:

systemctl status wazuh-indexer

At this stage, the service may not yet be configured to join a cluster, which is expected.

Configuring Cluster Settings

Once the software is installed, the next step is configuring cluster discovery and node communication settings.

Understanding the Main Configuration File

Most cluster settings are configured in:

/etc/wazuh-indexer/opensearch.yml

This file controls:

• Cluster formation
• Node discovery
• Network bindings
• Security settings
• Replication behavior

Important Configuration Parameters

Some of the most important parameters include:

• cluster.name
• node.name
• network.host
• discovery.seed_hosts
• cluster.initial_cluster_manager_nodes

Proper configuration of these settings determines whether nodes can successfully discover one another.

Configure Cluster Name

The cluster name identifies all participating nodes.

Example:

cluster.name: wazuh-prod-cluster

All nodes must use the exact same cluster name.

Using unique names prevents accidental connections between separate clusters.

Configure Node Names

Each node requires a unique identifier.

Example:

node.name: indexer01

Naming Conventions

Common approaches include:

indexer01
indexer02
indexer03

or

wazuh-indexer-prod-01
wazuh-indexer-prod-02
wazuh-indexer-prod-03

Best Practices

Use names that clearly indicate:

• Environment
• Function
• Location (if applicable)

Consistent naming simplifies troubleshooting and monitoring.

Configure Discovery Settings

Discovery settings allow nodes to find one another during cluster formation.

Seed Hosts

Specify the cluster nodes:

discovery.seed_hosts:
  - indexer01
  - indexer02
  - indexer03

These hosts serve as the initial discovery points for cluster communication.

Initial Cluster Manager Nodes

During initial cluster creation:

cluster.initial_cluster_manager_nodes:
  - indexer01
  - indexer02
  - indexer03

These nodes participate in the first cluster election.

This setting is only required when creating the cluster initially.

Configure Network Settings

Network settings determine how nodes communicate.

Bind Addresses

Example:

network.host: 10.0.1.10

or

network.host: 0.0.0.0

Production deployments should use explicit IP addresses whenever possible.

Transport Settings

Example:

transport.port: 9300

This port handles:

• Node discovery
• Cluster state updates
• Replication traffic

Cluster Communication

Ensure:

• Firewalls allow traffic
• DNS resolves correctly
• Hostnames match configuration

Cluster communication issues are among the most common causes of deployment failures.

Example Cluster Configuration

The following example demonstrates a basic three-node cluster.

cluster.name: wazuh-prod-cluster

node.name: indexer01

network.host: 10.0.1.10

discovery.seed_hosts:
  - indexer01
  - indexer02
  - indexer03

cluster.initial_cluster_manager_nodes:
  - indexer01
  - indexer02
  - indexer03

Explanation of Each Parameter

Once these settings are configured consistently across all nodes, the cluster is ready for certificate deployment and initial startup.

Configuring Security Certificates

Security certificates are a critical component of every Wazuh Indexer cluster deployment.

Because the Wazuh Indexer is based on OpenSearch, certificate-based authentication and encryption protect communications between cluster nodes and connected components.

Improper certificate configuration is one of the most common reasons for cluster formation failures.

Why Certificates Are Required

Wazuh secures cluster communications using Transport Layer Security (TLS).

Certificates provide:

• Encryption
• Authentication
• Integrity validation
• Protection against man-in-the-middle attacks

Without valid certificates, cluster nodes cannot securely trust one another.

Secure Node-to-Node Communication

Every Indexer node exchanges:

• Cluster state information
• Replication traffic
• Shard allocation data
• Health status information

TLS ensures this traffic remains encrypted while verifying that each participating node belongs to the cluster.

Without node certificates, malicious systems could potentially attempt to join the cluster.

Secure Client Communication

Certificates also secure communications between:

• Wazuh Dashboard
• Wazuh Manager
• Administrative tools
• API clients

This protects:

• User credentials
• Search requests
• Security alerts
• Administrative operations

OpenSearch security documentation: https://opensearch.org/docs/latest/security-plugin/

Certificate Types Used by Wazuh

Several certificate types work together to establish trust across the deployment.

Root CA

The Root Certificate Authority (CA) serves as the trust anchor.

Responsibilities include:

• Signing node certificates
• Signing administrative certificates
• Establishing cluster-wide trust

Every system within the deployment must trust the same Root CA.

Example:

root-ca.pem

Protect the Root CA carefully and store backups securely.

Node Certificates

Each Indexer node requires its own certificate.

Example:

indexer01.pem
indexer02.pem
indexer03.pem

These certificates:

• Authenticate individual nodes
• Secure replication traffic
• Enable cluster formation

Node certificates should include:

• Hostnames
• Fully qualified domain names (FQDNs)
• IP addresses (when applicable)

Administrative Certificates

Administrative certificates are used for privileged cluster management tasks.

Examples include:

• Security administration
• Configuration updates
• API management

Example files:

admin.pem
admin-key.pem

Administrative certificates should be restricted to authorized administrators only.

Deploying Certificates to Cluster Nodes

After generating certificates, deploy them consistently across every Indexer node.

Certificate Placement

Common certificate locations include:

/etc/wazuh-indexer/certs/

Example structure:

/etc/wazuh-indexer/certs/
├── root-ca.pem
├── indexer01.pem
├── indexer01-key.pem
├── admin.pem
└── admin-key.pem

All referenced paths must match the configuration in opensearch.yml.

File Permissions

Certificates should only be accessible by the Wazuh Indexer service account.

Example:

sudo chown wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs/*

Restrict private keys:

sudo chmod 600 /etc/wazuh-indexer/certs/*-key.pem

This reduces the risk of credential exposure.

Security Best Practices

Follow these certificate management recommendations:

• Use unique certificates per node
• Protect private keys
• Rotate certificates periodically
• Maintain secure backups
• Restrict administrative certificate access

If certificate-related issues occur during deployment, see How to Fix Wazuh Certificate Errors for detailed troubleshooting guidance.

Verifying Certificate Configuration

Before starting the cluster, verify that all certificates are correctly installed.

Common Validation Checks

Confirm:

• Certificate files exist
• File paths are correct
• Ownership is properly configured
• Hostnames match certificate subjects
• Certificate chains are valid

Example verification:

openssl x509 -in indexer01.pem -text -noout

Review:

• Subject names
• Subject Alternative Names (SANs)
• Expiration dates

Certificate Troubleshooting

Common certificate problems include:

Useful troubleshooting logs:

journalctl -u wazuh-indexer

and

tail -f /var/log/wazuh-indexer/wazuh-cluster.log

Proper certificate validation before startup can prevent hours of troubleshooting later.

Starting the Wazuh Indexer Cluster

Once all configuration and certificate files are in place, you can start the cluster.

At this stage, the nodes should be able to discover one another and form a healthy cluster.

Starting Services on Each Node

Start the Wazuh Indexer service on each server.

Service Startup Procedures

Enable automatic startup:

sudo systemctl enable wazuh-indexer

Start the service:

sudo systemctl start wazuh-indexer

Verify status:

sudo systemctl status wazuh-indexer

A healthy service should display:

active (running)

Startup Order Recommendations

For most three-node clusters:

1. Start the first node
2. Start the second node
3. Start the third node

Allow each node time to initialize before proceeding.

In larger environments with dedicated cluster manager nodes:

1. Start cluster manager nodes first
2. Verify election completion
3. Start data nodes

This reduces cluster discovery issues.

Verifying Cluster Formation

After all nodes are running, confirm successful cluster formation.

Checking Cluster Health

Query the cluster health API:

curl -k -u admin:password \
https://localhost:9200/_cluster/health?pretty

Example output:

{
  "cluster_name": "wazuh-prod-cluster",
  "status": "green",
  "number_of_nodes": 3
}

Cluster health states:

A healthy production cluster should eventually reach Green status.

Confirming Node Membership

Verify participating nodes:

curl -k -u admin:password \
https://localhost:9200/_cat/nodes?v

Expected output should show all configured nodes.

Example:

indexer01
indexer02
indexer03

If a node is missing, investigate:

• Firewall rules
• Hostname resolution
• Certificate configuration
• Discovery settings

Viewing Cluster Status

Monitoring cluster status provides visibility into overall health and performance.

Health APIs

Useful API endpoints include:

/_cluster/health

/_cluster/stats

/_nodes/stats

These APIs provide information about:

• Cluster health
• Storage usage
• Memory consumption
• Index statistics

Node Information APIs

Retrieve detailed node information:

curl -k -u admin:password \
https://localhost:9200/_nodes?pretty

This displays:

• Node roles
• Transport addresses
• Plugin information
• Resource allocation

Shard Allocation Checks

Check shard distribution:

curl -k -u admin:password \
https://localhost:9200/_cat/shards?v

Review shard placement to ensure:

• Balanced allocation
• Replica availability
• Healthy replication

Expert Insight: OpenSearch maintainers recommend routinely monitoring shard allocation because uneven shard distribution is one of the most common causes of performance issues in growing clusters.

Connecting Wazuh Components to the Cluster

After the Indexer cluster is operational, connect the remaining Wazuh components.

This allows security events to flow through the entire platform.

Configure Wazuh Manager

The Wazuh Manager forwards alerts and indexed events to the cluster.

Updating Indexer Connection Settings

Locate the Indexer connection settings in the Manager configuration.

Update the configuration to reference the clustered Indexer nodes rather than a standalone Indexer.

Example:

hosts:
  - https://indexer01:9200
  - https://indexer02:9200
  - https://indexer03:9200

This enables communication with multiple cluster members.

Testing Connectivity

Verify connectivity from the Manager:

curl -k https://indexer01:9200

Successful responses confirm:

• DNS resolution
• TLS configuration
• Network connectivity

If connectivity fails, review certificates and firewall settings.

Configure Wazuh Dashboard

The Wazuh Dashboard must also connect to the cluster.

Connecting Dashboard to Clustered Indexers

Update the Dashboard configuration to include Indexer endpoints.

Example:

opensearch.hosts:
  - https://indexer01:9200
  - https://indexer02:9200
  - https://indexer03:9200

This allows dashboard queries to be distributed across available nodes.

High Availability Considerations

Many production deployments place a load balancer in front of the cluster.

Benefits include:

• Simplified configuration
• Automatic failover
• Reduced administrative overhead
• Improved user experience

Common load balancing options include:

• HAProxy
• NGINX
• Cloud load balancers

HAProxy documentation: https://www.haproxy.org/

Verifying End-to-End Communication

The final step is validating data flow through the entire Wazuh deployment.

Confirming Alert Indexing

Generate a test alert from a monitored endpoint.

Then verify indexing:

curl -k -u admin:password \
https://localhost:9200/wazuh-alerts-*/_search?pretty

Recent alerts should appear in search results.

You can also generate test alerts using the techniques described in How to Test Wazuh Rules.

Dashboard Validation Tests

Verify the Dashboard can:

• Display agent information
• Display alerts
• Execute searches
• Load visualizations
• Display cluster health

Additional validation checks include:

• Agent status visibility
• Recent event ingestion
• Dashboard login functionality
• Search performance

If alerts fail to appear, review Manager-to-Indexer communication and compare against guidance in Wazuh Agent Not Connecting to Manager? 12 Proven Fixes.

At this point, your Wazuh Indexer cluster should be fully operational, providing high availability, scalability, and resilient storage for your security monitoring environment.

Validating Cluster Health

After building and connecting your Wazuh Indexer cluster, it is important to verify that the environment is functioning correctly.

Ongoing health validation helps identify potential issues before they impact indexing, searches, or dashboard availability.

A healthy cluster should maintain node availability, shard replication, and consistent performance even during component failures.

Check Cluster Health Status

The cluster health API provides a high-level overview of cluster status.

Use the following command:

curl -k -u admin:password \
https://localhost:9200/_cluster/health?pretty

Key values to monitor include:

• Status
• Number of nodes
• Active shards
• Unassigned shards
• Pending tasks

Green Status

A Green status indicates the cluster is fully operational.

Characteristics include:

• All primary shards are available
• All replica shards are available
• No unassigned shards
• Full redundancy maintained

Example:

{
  "status": "green"
}

Green is the desired state for production environments.

Yellow Status

Yellow indicates that primary shards are available but one or more replica shards are unavailable.

Common causes include:

• A node is offline
• Replica allocation is incomplete
• Cluster maintenance activities

Example:

{
  "status": "yellow"
}

The cluster remains operational, but redundancy may be reduced.

Red Status

Red status indicates that one or more primary shards are unavailable.

Potential consequences include:

• Missing security events
• Failed searches
• Dashboard errors
• Data loss risks

Example:

{
  "status": "red"
}

Immediate investigation is required when a cluster enters a Red state.

Verify Node Membership

Node verification ensures all expected cluster members are participating.

Listing Active Nodes

Use:

curl -k -u admin:password \
https://localhost:9200/_cat/nodes?v

Example output:

indexer01
indexer02
indexer03

The output should match the number of deployed nodes.

Confirming Expected Cluster Size

Check cluster size:

curl -k -u admin:password \
https://localhost:9200/_cluster/health?pretty

Review:

{
  "number_of_nodes": 3
}

If fewer nodes appear than expected, investigate:

• Firewall rules
• Certificate issues
• Discovery settings
• DNS resolution
• Service failures

If node communication problems occur, review Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work, as many network troubleshooting concepts apply to cluster communications as well.

Test Failover Scenarios

Failover testing validates cluster resilience.

Simulating Node Outages

Stop one Indexer node:

sudo systemctl stop wazuh-indexer

Then verify:

• Cluster remains accessible
• Dashboard continues functioning
• Searches remain operational
• Alerts continue indexing

A properly configured three-node cluster should remain available after a single node failure.

Verifying Continued Operation

After taking a node offline:

curl -k -u admin:password \
https://localhost:9200/_cluster/health?pretty

Expected results:

• Cluster remains operational
• Node count decreases
• Status may temporarily become Yellow
• Existing data remains accessible

Restart the node afterward:

sudo systemctl start wazuh-indexer

Verify the node rejoins the cluster successfully.

Monitor Index Replication

Replica health is essential for fault tolerance.

Replica Synchronization

Check shard allocation:

curl -k -u admin:password \
https://localhost:9200/_cat/shards?v

Review:

• Primary shards
• Replica shards
• Allocation status

Healthy clusters should distribute replicas across multiple nodes.

Recovery Processes

When nodes rejoin the cluster, OpenSearch automatically begins shard recovery.

Monitor recovery progress:

curl -k -u admin:password \
https://localhost:9200/_cat/recovery?v

Recovery speed depends on:

• Data volume
• Network bandwidth
• Storage performance
• Cluster load

Expert Insight: OpenSearch engineers consistently recommend validating recovery procedures before production deployment because many organizations discover replication issues only after their first hardware failure.

Performance Tuning Best Practices

As your environment grows, performance tuning becomes increasingly important.

Proper tuning can significantly improve indexing throughput, search responsiveness, and cluster stability.

Optimize JVM Memory Settings

Because the Wazuh Indexer runs on Java, JVM configuration directly impacts performance.

Heap Sizing Recommendations

A common OpenSearch recommendation is:

• Allocate approximately 50% of available RAM to JVM heap
• Leave the remaining memory for the operating system cache

Examples:

Avoid allocating more than 31–32 GB to JVM heap because larger heaps can reduce Java performance due to compressed object pointer limitations.

OpenSearch performance tuning documentation: https://opensearch.org/docs/latest/tuning-your-cluster/

Avoiding Memory Pressure

Monitor JVM memory utilization closely.

Warning signs include:

• Frequent garbage collection
• Slow searches
• Indexing delays
• Node instability

Check memory usage:

curl -k -u admin:password \
https://localhost:9200/_nodes/stats/jvm?pretty

Configure Shards Properly

Shard configuration has a major impact on scalability and resource utilization.

Choosing Shard Counts

Each shard consumes:

• CPU
• Memory
• Storage
• Cluster state resources

General guidance:

• Small indexes: 1–3 shards
• Medium indexes: 3–5 shards
• Large indexes: 5+ shards

Avoid excessive shard counts unless justified by workload requirements.

Avoiding Over-Sharding

Over-sharding is one of the most common OpenSearch performance issues.

Symptoms include:

• Excessive memory usage
• Long cluster state updates
• Slow searches
• Increased recovery times

Many organizations create far more shards than necessary during initial deployments.

Expert Insight: Elastic and OpenSearch architects frequently identify over-sharding as one of the most common root causes of cluster performance degradation.

Storage Optimization

Storage performance directly affects indexing and search operations.

SSD Recommendations

Solid-state drives are strongly recommended.

Benefits include:

• Faster indexing
• Reduced recovery times
• Improved search responsiveness
• Lower latency

Avoid spinning disks whenever possible for production clusters.

Disk Allocation Planning

Monitor disk usage carefully.

Recommended thresholds:

OpenSearch may stop allocating shards when disks approach critical utilization levels.

Monitor Cluster Metrics

Regular monitoring helps identify performance issues early.

CPU Utilization

Monitor:

• Average CPU load
• Indexing workload
• Search workload
• Background processes

Persistent utilization above 80% may indicate a need for additional resources.

Memory Usage

Track:

• JVM heap usage
• System memory
• Cache utilization

Memory shortages often manifest as slower searches and increased garbage collection activity.

Disk Consumption

Monitor:

• Free space
• Growth rate
• Replica overhead

For retention planning, review How to Configure Wazuh Log Retention to ensure storage usage remains predictable.

Query Performance

Measure:

• Search latency
• Dashboard responsiveness
• Aggregation performance

Useful API:

curl -k -u admin:password \
https://localhost:9200/_nodes/stats/indices/search?pretty

Consistent monitoring provides early warning of emerging bottlenecks.

High Availability and Disaster Recovery

Building a cluster improves availability, but organizations should also plan for major outages, hardware failures, and disaster recovery scenarios.

Designing for High Availability

High availability ensures security monitoring continues even when components fail.

Redundant Nodes

At least three Indexer nodes are recommended.

Benefits include:

• Quorum-based elections
• Replica availability
• Fault tolerance
• Reduced downtime

A three-node cluster can typically withstand a single node failure without losing access to indexed data.

Load Balancing Strategies

Many organizations deploy load balancers in front of Indexer clusters.

Common solutions include:

• HAProxy
• NGINX
• Cloud-native load balancers

Benefits:

• Automatic failover
• Simplified client configuration
• Improved availability
• Better traffic distribution

The Wazuh Dashboard can also benefit from load-balanced Indexer access.

Backup and Snapshot Strategies

Cluster replication protects against node failures but does not replace backups.

Snapshot Repositories

Snapshots provide point-in-time backups of cluster data.

Supported repositories include:

• Shared filesystems
• NFS storage
• Cloud object storage
• S3-compatible storage

Snapshots allow rapid restoration after accidental deletion or catastrophic failures.

Scheduled Backups

Best practices include:

• Daily snapshots
• Weekly retention validation
• Automated backup schedules
• Offsite storage copies

Common backup frequencies:

OpenSearch snapshot documentation: https://opensearch.org/docs/latest/tuning-your-cluster/availability-and-recovery/snapshots/

Recovery Procedures

Every production deployment should have documented recovery procedures.

Node Replacement

When replacing a failed node:

1. Provision a new server
2. Install Wazuh Indexer
3. Deploy certificates
4. Apply cluster configuration
5. Start the service
6. Verify shard recovery

OpenSearch automatically reallocates shards when the replacement node joins the cluster.

Cluster Restoration

In a catastrophic outage:

1. Deploy new Indexer infrastructure
2. Restore configuration files
3. Restore certificates
4. Recover snapshots
5. Validate cluster health

Recovery testing should be performed periodically rather than waiting for an actual disaster.

Data Recovery Workflows

A complete recovery workflow should document:

• Backup locations
• Recovery procedures
• Required credentials
• Validation steps
• Expected recovery times

Organizations that routinely test recovery processes typically recover significantly faster than those relying solely on documented procedures.

For organizations collecting critical security telemetry from firewalls, endpoints, and cloud services, disaster recovery planning is just as important as detection engineering.

Consider pairing your cluster strategy with guidance from How to Collect Firewall Logs in Wazuh, How to Monitor AWS CloudTrail Logs Using Wazuh, and How to Configure Wazuh Log Retention to create a comprehensive long-term monitoring architecture.

Troubleshooting Common Wazuh Indexer Cluster Issues

Even a properly configured Wazuh Indexer cluster can experience issues related to networking, certificates, resource limitations, or shard allocation.

Understanding the most common problems can significantly reduce troubleshooting time and help maintain cluster availability.

Nodes Not Joining the Cluster

One of the most common deployment problems occurs when Indexer nodes fail to discover or join the cluster.

Discovery Configuration Issues

Incorrect discovery settings frequently prevent cluster formation.

Verify the following parameters:

cluster.name
node.name
discovery.seed_hosts
cluster.initial_cluster_manager_nodes

Common mistakes include:

• Incorrect hostnames
• Missing seed hosts
• Typographical errors
• Inconsistent cluster names

Review the opensearch.yml file on every node and ensure configurations are consistent.

Network Connectivity Problems

Nodes must communicate over the transport port:

9300/TCP

Verify connectivity:

nc -zv indexer02 9300

Potential network-related causes include:

• Firewall restrictions
• Incorrect routing
• DNS resolution failures
• Security group misconfigurations

Testing connectivity between every node pair helps identify communication failures quickly.

Certificate Mismatches

TLS certificate problems frequently prevent nodes from authenticating with one another.

Common certificate issues include:

• Incorrect Subject Alternative Names (SANs)
• Expired certificates
• Wrong certificate paths
• Missing Root CA files

Review service logs:

journalctl -u wazuh-indexer

For additional certificate troubleshooting guidance, see How to Fix Wazuh Certificate Errors.

Cluster Health Remains Yellow

A Yellow cluster status indicates that primary shards are healthy but replica shards are not fully allocated.

Unassigned Replica Shards

View shard status:

curl -k -u admin:password \
https://localhost:9200/_cat/shards?v

Common causes include:

• Insufficient nodes
• Offline nodes
• Storage limitations
• Allocation restrictions

Single-node environments often remain Yellow because replicas cannot be allocated to the same node as their primary shard.

Replica Allocation Problems

Review allocation explanations:

curl -k -u admin:password \
https://localhost:9200/_cluster/allocation/explain?pretty

This API often reveals:

• Disk threshold violations
• Allocation filtering rules
• Resource shortages
• Node eligibility issues

Cluster Health Turns Red

A Red cluster status requires immediate attention because one or more primary shards are unavailable.

Missing Primary Shards

When primary shards become unavailable:

• Searches may fail
• Alerts may be inaccessible
• Data loss may occur

Investigate:

curl -k -u admin:password \
https://localhost:9200/_cat/indices?v

Review shard health and affected indexes.

Node Failures

Unexpected node failures are a common cause of Red status.

Check:

systemctl status wazuh-indexer

Potential causes include:

• Hardware failures
• Storage corruption
• Memory exhaustion
• Operating system crashes

Monitoring node health proactively can help prevent major outages.

Certificate Validation Errors

Certificate-related issues often appear after upgrades, renewals, or hostname changes.

Expired Certificates

Check expiration dates:

openssl x509 -in node.pem -noout -dates

Expired certificates commonly cause:

• Authentication failures
• Node join failures
• Dashboard connection problems

Organizations should implement certificate renewal schedules before expiration occurs.

Incorrect Permissions

Improper file permissions can prevent the service from accessing certificates.

Recommended permissions:

chmod 600 *-key.pem

Verify ownership:

chown wazuh-indexer:wazuh-indexer *

Hostname Mismatches

Certificate hostnames must match:

• Node hostnames
• DNS records
• Configuration files

Mismatch errors often appear as TLS handshake failures.

High Resource Utilization

Resource bottlenecks can significantly impact cluster performance.

Memory Bottlenecks

Monitor JVM memory:

curl -k -u admin:password \
https://localhost:9200/_nodes/stats/jvm?pretty

Warning signs include:

• Frequent garbage collection
• Slow searches
• Indexing delays
• Cluster instability

Review JVM sizing recommendations discussed earlier in this guide.

Disk Pressure

Monitor disk usage:

curl -k -u admin:password \
https://localhost:9200/_cat/allocation?v

Disk pressure can cause:

• Unassigned shards
• Yellow cluster health
• Failed indexing operations

For environments with long-term retention requirements, review How to Configure Wazuh Log Retention to ensure storage growth remains manageable.

Excessive Shard Counts

Over-sharding is a frequent performance issue.

Symptoms include:

• High memory consumption
• Slow cluster state updates
• Increased recovery times

Expert Insight: OpenSearch performance engineers consistently identify excessive shard counts as one of the most common root causes of cluster performance degradation in large deployments.

Reducing unnecessary shards often yields immediate performance improvements.

Security Best Practices

Because the Wazuh Indexer stores security telemetry and potentially sensitive organizational data, implementing strong security controls is essential.

Secure Inter-Node Communication

Cluster communication should always be encrypted.

TLS Encryption

TLS protects:

• Cluster state updates
• Replication traffic
• Administrative operations
• Search requests

Never disable TLS in production environments.

OpenSearch Security Plugin Documentation: https://opensearch.org/docs/latest/security-plugin/

Certificate Rotation

Certificates should be rotated periodically.

Benefits include:

• Reduced credential exposure
• Improved compliance
• Stronger operational security

Organizations should maintain documented certificate lifecycle procedures.

Restrict Administrative Access

Administrative privileges should be tightly controlled.

Role-Based Access Control

Use RBAC to separate responsibilities.

Examples:

RBAC reduces the risk of accidental or malicious changes.

Least Privilege Principles

Grant only the permissions required for each role.

Avoid:

• Shared administrative accounts
• Excessive privileges
• Unrestricted API access

Following least-privilege principles significantly reduces attack surface.

Protect Sensitive Data

Security monitoring environments often contain confidential information.

Encryption Strategies

Consider encrypting:

• Data in transit
• Backup repositories
• Snapshot storage
• Administrative credentials

Encryption helps protect data from unauthorized access.

Secure Backups

Backup repositories should be:

• Access-controlled
• Encrypted
• Monitored
• Regularly tested

Backup security is often overlooked despite containing the same sensitive data as production systems.

Regular Security Audits

Security reviews help identify misconfigurations before they become incidents.

Configuration Reviews

Review:

• Node configurations
• Discovery settings
• Access controls
• Network restrictions

Periodic audits help maintain consistency across the cluster.

Certificate Audits

Validate:

• Expiration dates
• Trusted certificate authorities
• SAN entries
• Private key protection

Certificate audits help prevent unexpected outages.

Access Monitoring

Monitor:

• Administrative logins
• API usage
• Privilege changes
• Authentication failures

If suspicious activity is detected, custom detections can be implemented using techniques covered in How to Create Custom Detection Rules in Wazuh (With Examples).

Frequently Asked Questions

How many nodes should a Wazuh Indexer cluster have?

For production environments, three nodes is generally considered the minimum recommended cluster size.

A three-node cluster provides:

• High availability
• Quorum-based elections
• Replica support
• Fault tolerance

Single-node deployments should be reserved for testing and development environments.

Can I run a Wazuh Indexer cluster with only two nodes?

Technically yes, but it is not recommended.

Two-node clusters can experience quorum and availability challenges during node failures.

A three-node deployment provides significantly better resilience and is considered the standard production architecture.

What happens if a cluster node fails?

If replica shards are configured properly, the cluster should continue operating.

Typical behavior includes:

• Automatic failover
• Continued search functionality
• Ongoing alert ingestion
• Temporary Yellow cluster status

The cluster automatically rebalances data when the failed node returns.

How do I check cluster health?

Use the cluster health API:

curl -k -u admin:password \
https://localhost:9200/_cluster/health?pretty

Monitor:

• Health status
• Node count
• Shard allocation
• Unassigned shards

Green status indicates a fully healthy cluster.

Can I add new nodes to an existing cluster?

Yes.

Adding nodes is a common way to:

• Increase storage capacity
• Improve performance
• Support growth

After a new node joins, the cluster automatically redistributes shards and replicas.

Does Wazuh Indexer support automatic failover?

Yes.

When deployed as a properly configured cluster, Wazuh Indexer automatically handles:

• Node failures
• Replica promotion
• Cluster elections
• Data redistribution

This is one of the primary reasons organizations choose clustered deployments.

How much storage should I allocate for a cluster?

Storage requirements depend on:

• Daily log volume
• Retention period
• Replica count
• Growth expectations

A useful planning formula is:

Daily Log Volume × Retention Days × (Replica Factor + 1)

Organizations should also reserve additional capacity for future growth and recovery operations.

Conclusion

Building a Wazuh Indexer cluster is one of the most effective ways to improve the scalability, resiliency, and performance of a Wazuh deployment.

By distributing data across multiple nodes, organizations can ensure that security monitoring continues even when individual servers experience failures.

Throughout this guide, we covered the complete Wazuh Indexer clustering process, including architecture planning, hardware sizing, node installation, cluster configuration, certificate deployment, component integration, health validation, performance tuning, and disaster recovery planning.

The primary benefits of a clustered deployment include:

• High availability
• Improved scalability
• Data redundancy
• Faster recovery from failures
• Better long-term performance

However, deploying a cluster is only the beginning.

Ongoing monitoring, capacity planning, certificate management, and routine health checks are essential for maintaining a stable production environment.

Regular validation of cluster health, shard allocation, storage utilization, and backup processes helps ensure your security platform remains reliable as your environment grows.

As a next step, consider strengthening your broader Wazuh deployment by implementing advanced monitoring and detection capabilities.

Guides such as How to Monitor AWS CloudTrail Logs Using Wazuh, How to Integrate Wazuh with Suricata for Better Threat Detection, How to Detect Ransomware Activity Using Wazuh, and How to Reduce False Positives in Wazuh can help you maximize the value of your clustered infrastructure while improving overall threat visibility and response capabilities.

With a properly designed Wazuh Indexer cluster in place, your organization will be better positioned to handle growing log volumes, maintain continuous visibility into security events, and support future expansion without sacrificing reliability.

For more Wazuh guides, you may also find these resources helpful:

 Installation Guides

• Wazuh Agent Not Connecting to Manager? 12 Proven Fixes
• How to Upgrade a Wazuh Agent

Configuration Guides

• How to Configure File Integrity Monitoring (FIM) in Wazuh
  How to Create Custom Detection Rules in Wazuh (With Examples)
  
• How to Configure Wazuh Log Retention
  How to Reduce False Positives in Wazuh

 Integration Guides

• How to Integrate Wazuh with VirusTotal for Threat Intelligence 
• How to Integrate Wazuh with Suricata for Better Threat Detection
  How to Integrate Wazuh with OPNsense

Monitoring Guides

• How to Monitor Kubernetes Using Wazuh
  
• How to Monitor Active Directory With Wazuh
  
• How to Monitor AWS CloudTrail Logs Using Wazuh

Troubleshooting Guides

• Wazuh Vulnerability Detection Not Working? Here’s How to Fix It
  
• How to Fix Wazuh Certificate Errors
  
• How to Detect Ransomware Activity Using Wazuh

Comparison Guides

• Wazuh vs OSSEC
• Wazuh vs Splunk
• Security Onion vs Wazuh
• Wazuh vs OpenVAS
• Wazuh vs Nessus