> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/wazuh/wazuh-dashboard-plugins/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance Tuning

> Best practices and techniques for optimizing Wazuh Dashboard performance in large deployments

This guide provides best practices and techniques to keep the Wazuh dashboard responsive and efficient in large deployments, covering query optimization, resource management, and client-side performance.

## Overview

Performance optimization involves multiple layers:

* **Query and UI practices**: How you interact with the dashboard
* **Indexer considerations**: Backend data storage and retrieval
* **Client performance**: Browser and network optimization
* **Dashboard configuration**: Server-side settings
* **Resource allocation**: System resources and capacity planning

## Query and UI Practices

### Time Range Management

**Narrow time ranges** when exploring data-heavy views:

* Use shorter time windows (hours or days instead of weeks or months)
* Set specific date ranges rather than relative ranges when possible
* Avoid "All time" queries on large datasets
* Use time range presets for common analysis periods

**Example**: Instead of querying the last 30 days, start with the last 24 hours and expand as needed.

### Filter Before Loading

**Use filters** before opening high-cardinality tables:

* Apply agent filters before loading event tables
* Filter by rule group or severity before exploring alerts
* Use field filters to reduce result sets
* Combine multiple filters to narrow results further

**Example**:

```
1. Select specific agents or groups
2. Apply time range filter
3. Add severity or rule filters
4. Then load the data table
```

### Limit Large Exports

**Avoid exporting very large datasets**:

* Export filtered results rather than entire datasets
* Use pagination for large result sets
* Split large exports into smaller time ranges
* Consider using scheduled reports for regular exports
* Be aware of the CSV export row limit configuration

### Dashboard and Visualization Optimization

**Optimize dashboard loading**:

* Limit the number of visualizations per dashboard (8-12 recommended)
* Use saved searches instead of ad-hoc queries
* Avoid auto-refresh on dashboards with heavy queries
* Use appropriate visualization types for your data
* Disable unused visualizations

### Search Query Optimization

**Write efficient queries**:

* Use specific field queries instead of full-text search when possible
* Avoid wildcards at the beginning of search terms
* Use indexed fields for filtering
* Combine related conditions efficiently
* Cache frequently used queries

**Example of efficient query**:

```
rule.id:5503 AND agent.name:"server-01"
```

Instead of:

```
*5503* AND *server-01*
```

## Indexer Considerations

### Index Management

**Ensure proper indexer sizing**:

* Size the Wazuh indexer appropriately for your data volume
* Plan storage capacity for data retention requirements
* Monitor index growth patterns
* Implement index lifecycle management (ILM)
* Regular index cleanup and rotation

### Shard Management

**Monitor shard counts and sizes**:

* Keep shard size between 10-50 GB for optimal performance
* Avoid too many small shards (over-sharding)
* Use appropriate shard allocation
* Monitor shard distribution across nodes
* Consider shard allocation awareness for multi-node clusters

**Check shard status**:

```bash theme={null}
curl -X GET "https://localhost:9200/_cat/shards?v" -u admin:admin -k
```

### Index Optimization

**Optimize indices regularly**:

```bash theme={null}
# Force merge indices to reduce segment count
curl -X POST "https://localhost:9200/wazuh-events*/_forcemerge?max_num_segments=1" \
  -u admin:admin -k

# Close old indices not frequently accessed
curl -X POST "https://localhost:9200/wazuh-events-2025.01.01/_close" \
  -u admin:admin -k
```

> [!NOTE]
>
> Force merge is resource-intensive. Run during low-usage periods.

### Index Patterns and Mappings

**Optimize field mappings**:

* Disable indexing for fields not used in searches
* Use appropriate field types
* Avoid dynamic mapping when possible
* Limit the number of fields per index
* Use doc\_values efficiently

### Query Performance

**Monitor slow queries**:

```bash theme={null}
# Enable slow log
curl -X PUT "https://localhost:9200/wazuh-events*/_settings" \
  -H 'Content-Type: application/json' \
  -u admin:admin -k \
  -d'{
    "index.search.slowlog.threshold.query.warn": "10s",
    "index.search.slowlog.threshold.query.info": "5s"
  }'
```

**Review slow queries**:

```bash theme={null}
tail -f /var/log/wazuh-indexer/wazuh_index_search_slowlog.log
```

## Client Performance

### Browser Optimization

**Use modern browsers**:

* Chrome 90+ or Firefox 88+ recommended
* Keep browsers updated to the latest version
* Enable hardware acceleration
* Clear browser cache regularly
* Disable unnecessary browser extensions

**Browser cache management**:

* Clear cache after dashboard upgrades
* Use incognito mode for troubleshooting
* Monitor browser memory usage
* Close unused tabs

### Network Considerations

**Optimize network performance**:

* Prefer wired connections over wireless
* Use low-latency networks for large datasets
* Monitor bandwidth utilization
* Consider CDN for geographically distributed users
* Enable compression (handled by dashboard by default)

### Client-Side Resource Management

**Monitor client resources**:

* Watch browser memory consumption
* Close unused dashboard tabs
* Limit concurrent queries
* Avoid running multiple intensive operations simultaneously
* Use browser task manager to identify resource-heavy tabs

## Dashboard Configuration

### Server Settings

Optimize dashboard settings in `/etc/wazuh-dashboard/opensearch_dashboards.yml`:

#### Request Timeout

```yaml theme={null}
# Increase timeout for long-running queries
opensearch.requestTimeout: 60000  # 60 seconds
```

#### Operations Interval

```yaml theme={null}
# Increase monitoring interval to reduce overhead
ops.interval: 10000  # 10 seconds
```

#### Logging Level

```yaml theme={null}
# Reduce logging verbosity in production
logging.verbose: false
logging.quiet: true
```

#### Connection Pool

```yaml theme={null}
# Optimize connection pool settings
opensearch.maxSockets: 100
opensearch.keepAlive: true
```

#### Response Size Limits

```yaml theme={null}
# Set appropriate response size limits
opensearch.maxConcurrentShardRequests: 5
```

### Memory Configuration

Adjust Node.js memory limits if needed:

```bash theme={null}
# Edit service file
sudo systemctl edit wazuh-dashboard

# Add memory limit
[Service]
Environment="NODE_OPTIONS=--max-old-space-size=4096"
```

Restart the service:

```bash theme={null}
sudo systemctl daemon-reload
sudo systemctl restart wazuh-dashboard
```

### Advanced Settings UI

Configure performance-related settings through the UI:

1. Navigate to **Dashboard Management** > **Advanced Settings**
2. Adjust these settings:

* **Discover: Number of rows**: Reduce default row count (default: 500)
* **Discover: Sample size**: Lower sample size for faster previews
* **Histogram: Interval**: Use appropriate time buckets
* **Search: Timeout**: Adjust query timeout values

## Resource Allocation

### System Requirements

**Minimum requirements**:

* **CPU**: 2 cores
* **RAM**: 4 GB
* **Disk**: 10 GB (system) + storage for logs

**Recommended for production**:

* **CPU**: 4+ cores
* **RAM**: 8-16 GB
* **Disk**: SSD with sufficient IOPS
* **Network**: 1 Gbps or higher

### Memory Management

**Monitor memory usage**:

```bash theme={null}
# Check system memory
free -h

# Check dashboard process
ps aux | grep opensearch-dashboards
```

**Adjust swap settings** if needed:

```bash theme={null}
# Check current swap
swapon --show

# Disable swap for better performance (if sufficient RAM)
sudo swapoff -a
```

### Disk I/O Optimization

**Use SSD storage**:

* Significantly improves dashboard responsiveness
* Reduces query latency
* Better for log file access

**Monitor disk performance**:

```bash theme={null}
# Check disk I/O
iostat -x 1

# Check disk usage
df -h
```

### CPU Optimization

**Monitor CPU usage**:

```bash theme={null}
# Real-time CPU monitoring
top -u wazuh-dashboard

# CPU statistics
mpstat 1
```

## Monitoring and Metrics

### Dashboard Performance Metrics

**Monitor dashboard health**:

1. Navigate to **Dashboard Management** > **Health Check**
2. Review all checks for issues
3. Monitor API response times
4. Check indexer connectivity

### System Monitoring

**Key metrics to track**:

* Dashboard response time
* API request latency
* Memory utilization
* CPU usage
* Disk I/O
* Network throughput
* Query execution time

**Set up monitoring**:

```bash theme={null}
# Monitor dashboard logs
sudo tail -f /var/log/wazuh-dashboard/opensearch_dashboards.log

# Watch for errors
sudo grep -i error /var/log/wazuh-dashboard/opensearch_dashboards.log
```

### Performance Baselines

**Establish baselines**:

* Document typical query response times
* Record normal resource utilization
* Monitor trends over time
* Set alerts for anomalies
* Review baselines quarterly

## Scaling Strategies

### Vertical Scaling

**Increase server resources**:

* Add more CPU cores
* Increase RAM
* Upgrade to faster disks (NVMe SSD)
* Improve network connectivity

### Horizontal Scaling

**Distribute load** (for very large deployments):

* Use multiple dashboard instances behind a load balancer
* Implement session affinity
* Scale indexer cluster appropriately
* Consider geo-distributed deployments

### Load Balancing

**Configure load balancer** for multiple dashboard instances:

```nginx theme={null}
upstream wazuh_dashboard {
    least_conn;
    server dashboard1.example.com:443;
    server dashboard2.example.com:443;
    server dashboard3.example.com:443;
}

server {
    listen 443 ssl;
    server_name dashboard.example.com;
    
    location / {
        proxy_pass https://wazuh_dashboard;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
```

## Troubleshooting Performance Issues

### Slow Dashboard Loading

**Symptoms**: Dashboard takes a long time to load initially.

**Solutions**:

1. Clear browser cache
2. Check network connectivity to indexer
3. Review dashboard logs for errors
4. Verify indexer cluster health
5. Check API response times

### Slow Query Execution

**Symptoms**: Queries take a long time to return results.

**Solutions**:

1. Reduce time range
2. Add more specific filters
3. Check indexer shard health
4. Review slow query logs
5. Optimize index mappings
6. Consider index lifecycle policies

### High Memory Usage

**Symptoms**: Dashboard consumes excessive memory.

**Solutions**:

1. Reduce number of open visualizations
2. Limit concurrent operations
3. Clear browser cache
4. Increase Node.js memory limit
5. Restart dashboard service
6. Review for memory leaks in logs

### Unresponsive Interface

**Symptoms**: UI becomes sluggish or unresponsive.

**Solutions**:

1. Reduce data volume being queried
2. Simplify complex visualizations
3. Check browser resource usage
4. Verify network stability
5. Review system resource availability
6. Check for JavaScript errors in browser console

## Best Practices Summary

### Query Optimization

* [ ] Use narrow time ranges
* [ ] Apply filters before loading data
* [ ] Limit export sizes
* [ ] Write efficient search queries
* [ ] Use saved searches

### Infrastructure

* [ ] Size indexer appropriately
* [ ] Monitor and optimize shards
* [ ] Implement ILM policies
* [ ] Use SSD storage
* [ ] Allocate sufficient memory

### Client Side

* [ ] Use modern, updated browsers
* [ ] Prefer wired networks
* [ ] Clear browser cache regularly
* [ ] Close unused tabs
* [ ] Monitor browser memory

### Configuration

* [ ] Optimize timeout settings
* [ ] Adjust operations interval
* [ ] Configure connection pools
* [ ] Set appropriate limits
* [ ] Tune Node.js memory

### Monitoring

* [ ] Track performance metrics
* [ ] Establish baselines
* [ ] Monitor resource usage
* [ ] Review logs regularly
* [ ] Set up alerts

## Additional Resources

* **OpenSearch performance tuning**: [https://opensearch.org/docs/latest/tuning-your-cluster/](https://opensearch.org/docs/latest/tuning-your-cluster/)
* **Index lifecycle management**: Configure automated index management
* **Hardware recommendations**: Review system requirements documentation
* **Monitoring guide**: Set up comprehensive monitoring


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.