Deploying OpenSearch and OpenSearch

What we are setting up and why

We will be deploying a combination of OpenSearch and OpenSearch Dashboards. OpenSearch is a distributed, scalable search and analytics engine built on Apache Lucene. It is a fork of Elasticsearch and is designed for processing large volumes of data in real-time, performing full-text search, aggregation, and analysis. OpenSearch Dashboards (a Kibana fork) is a powerful data visualization and management tool that allows you to create interactive dashboards, analyze logs, metrics, and other data stored in OpenSearch.

Ultimately, you will get a fully functional platform for centralized logging, monitoring, and analytics, capable of collecting logs from various sources (applications, servers, network devices), storing them, performing complex queries, and visualizing the results. This is critically important for debugging applications, identifying performance issues, ensuring security, and complying with regulatory requirements.

For example, a developer can easily find errors in their application logs, a SaaS solo founder can track user activity and service performance, and a crypto enthusiast can monitor their node's operation by analyzing its logs. The application possibilities are virtually limitless.

Alternatives: Cloud vs. Self-Hosted

There are several approaches to deploying such systems. The main alternatives are cloud-managed services (e.g., Amazon OpenSearch Service, Google Cloud Logging, Azure Monitor) or self-hosted deployment on your own VPS or dedicated server.

Cloud-managed services offer convenience, on-demand scalability, and eliminate the need for deep administrative knowledge. However, they are often more expensive, especially with large data volumes, and may have customization limitations. Furthermore, you are dependent on a specific provider and their pricing policy.

The self-hosted solution on a VPS, which we will be configuring, gives you full control over data, configuration, and costs. You only pay for server resources, which is often significantly cheaper in the long run. This is an ideal option for those who value privacy, want to deeply understand how the system works, or have specific requirements that are difficult to implement in the cloud. Yes, it requires more effort for setup and maintenance, but that's precisely what this guide is for.

What VPS Configuration is Needed for This Task

OpenSearch is a fairly resource-intensive system, especially regarding RAM and disk subsystem. The correct choice of VPS configuration is critically important for stable and fast operation.

Minimum Requirements for OpenSearch and OpenSearch Dashboards (single node)

• Processor (CPU): 2 cores. Modern Intel Xeon or AMD EPYC are preferred.
• Random Access Memory (RAM): Minimum 8 GB. OpenSearch actively uses the file system cache and JVM Heap. It is recommended to allocate half of the available RAM for the JVM Heap.
• Disk: 100 GB NVMe SSD. Disk speed is one of the most important factors for OpenSearch performance, as it constantly indexes and searches data. NVMe SSD significantly outperforms SATA SSD.
• Network: 1 Gbit/s. For log transfer and Dashboards access.

Recommended VPS Plan for Small Production Workloads

If you plan to collect logs from several services or process a significant volume of data (e.g., more than 10-20 GB of logs per day), the following configuration is recommended:

• Processor (CPU): 4 cores.
• Random Access Memory (RAM): 16-32 GB. This will allow OpenSearch to cache data more efficiently and process complex queries.
• Disk: 250-500 GB NVMe SSD. Disk size will depend on the volume of logs and the desired retention period. Ensure the disk is sufficiently performant.
• Network: 1 Gbit/s.

For such characteristics, you can consider a VPS with the specified characteristics, which will provide the necessary performance and stability.

When a Dedicated Server is Needed, Not a VPS

A dedicated server becomes preferable to a VPS when:

• Data volume is very large: If you plan to store terabytes of logs or process hundreds of gigabytes per day.
• Maximum performance is required: For mission-critical systems where every millisecond matters.
• Complete resource isolation is necessary: A dedicated server guarantees that you will not share resources with other users.
• Hardware customization is needed: For example, using specialized RAID controllers or very large amounts of RAM.

For very large OpenSearch installations, it is often deployed in a cluster of several dedicated servers. For small to medium tasks, a VPS is usually sufficient.

Location: What it Affects

Choosing a VPS location has several important aspects:

• Latency: Choose a location that is geographically close to your log sources (servers, applications, users). This minimizes data transfer delays and improves Dashboards responsiveness.
• Legislation: Depending on the type of data you will store, various data privacy laws (e.g., GDPR) may apply. Choose a location that complies with your legal requirements.
• Availability: Some locations may be more stable or have better connectivity to certain regions of the world.

For most users, a data center in Europe or North America will be the optimal choice, depending on your primary audience and the location of your other servers.

Server Preparation

Before installing OpenSearch and OpenSearch Dashboards, you need to perform basic setup and security hardening of your VPS. We will be using Ubuntu Server 24.04 LTS.

1. System Update and Installation of Basic Utilities

Connect to the server via SSH using the root account or a user with sudo privileges.

sudo apt update && sudo apt upgrade -y # Update package list and install updates
sudo apt install -y curl wget git vim htop screen net-tools # Install useful utilities

2. Creating a New User with Sudo Privileges

Working as root is not recommended. Create a new user and add them to the sudo group.

sudo adduser adminuser # Create a new user, follow instructions
sudo usermod -aG sudo adminuser # Add user to the sudo group

Now log out of the root session and log in as adminuser.

exit # Exit current session
ssh adminuser@ВАШ_IP_АДРЕС # Log in as the new user

3. SSH Key Setup (Recommended)

To enhance security, use SSH keys instead of passwords. First, generate keys on your local machine (if you haven't already).

ssh-keygen -t rsa -b 4096 # On your local machine

Copy the public key to the server (replace adminuser and YOUR_IP_ADDRESS).

ssh-copy-id adminuser@ВАШ_IP_АДРЕС # On your local machine

Then disable password authentication and root login in the /etc/ssh/sshd_config file on the server.

sudo vim /etc/ssh/sshd_config # Open SSH configuration file

Find and modify the following lines (or add them if missing):

# Disable root login
PermitRootLogin no

# Disable password authentication after setting up SSH keys
PasswordAuthentication no

# Ensure key authentication is used
PubkeyAuthentication yes

Save changes and restart the SSH service.

sudo systemctl restart sshd # Restart SSH service

4. Firewall Setup (UFW)

Configure UFW (Uncomplicated Firewall) to allow only necessary traffic.

sudo ufw allow OpenSSH # Allow SSH traffic
sudo ufw allow http # Allow HTTP traffic (for Caddy)
sudo ufw allow https # Allow HTTPS traffic (for Caddy)
sudo ufw enable # Enable firewall
sudo ufw status # Check firewall status

If you are using a non-standard port for SSH, allow it instead of OpenSSH (e.g., sudo ufw allow 2222/tcp).

5. Installing Fail2Ban

Fail2Ban helps protect against brute-force attacks by blocking IP addresses from which failed login attempts occur.

sudo apt install -y fail2ban # Install Fail2Ban
sudo systemctl enable fail2ban # Enable Fail2Ban autostart
sudo systemctl start fail2ban # Start Fail2Ban

For basic setup, the default configuration is usually sufficient. You can copy the main configuration file to modify it:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Create a local copy
sudo vim /etc/fail2ban/jail.local # Edit local file

In the [sshd] section, ensure that enabled = true.

Your server is now ready for OpenSearch and OpenSearch Dashboards installation.

Software Installation — Step-by-step

Software Installation — Step-by-Step

We will be installing OpenSearch 2.15 (the current version for 2026, or a newer stable 2.x) and OpenSearch Dashboards 2.15 on Ubuntu 24.04 LTS, using the official APT repositories.

1. Install Java Development Kit (JDK)

OpenSearch requires a JVM. It is recommended to use OpenJDK 17 LTS or OpenJDK 21 LTS.

sudo apt update # Update package list
sudo apt install -y openjdk-17-jdk # Install OpenJDK 17
java -version # Check installed Java version

Ensure that the command java -version outputs information about OpenJDK 17.

2. Add OpenSearch Repository

Add the OpenSearch repository GPG key and the repository itself to your system.

# Import OpenSearch GPG key
wget -qO - https://artifacts.opensearch.org/publickeys/opensearch.gpg | sudo gpg --dearmor -o /usr/share/keyrings/opensearch-keyring.gpg

# Add OpenSearch repository for OpenSearch 2.x
echo "deb [signed-by=/usr/share/keyrings/opensearch-keyring.gpg] https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch-2.x.list

# Update package list after adding the repository
sudo apt update

Note: If OpenSearch 3.x is the current version for 2026, change the repository path to /3.x/apt accordingly.

3. Install OpenSearch

Now you can install OpenSearch itself.

sudo apt install -y opensearch # Install OpenSearch package

After installation, configure autostart and start the service.

sudo systemctl daemon-reload # Reload systemd
sudo systemctl enable opensearch # Enable OpenSearch autostart
sudo systemctl start opensearch # Start OpenSearch service
sudo systemctl status opensearch # Check service status

Ensure that the service is running and active (Active: active (running)).

4. Install OpenSearch Dashboards

OpenSearch Dashboards uses the same repository as OpenSearch.

sudo apt install -y opensearch-dashboards # Install OpenSearch Dashboards package

Configure autostart and start the Dashboards service.

sudo systemctl daemon-reload # Reload systemd
sudo systemctl enable opensearch-dashboards # Enable Dashboards autostart
sudo systemctl start opensearch-dashboards # Start OpenSearch Dashboards service
sudo systemctl status opensearch-dashboards # Check service status

Ensure that the service is running.

5. Install Caddy (for HTTPS)

Caddy is a powerful, easy-to-use web server with automatic HTTPS support via Let's Encrypt. We will use it as a reverse proxy for OpenSearch Dashboards.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https # Install necessary packages
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg # Add Caddy GPG key
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list # Add Caddy repository
sudo apt update # Update package list
sudo apt install -y caddy # Install Caddy
sudo systemctl enable caddy # Enable Caddy autostart
sudo systemctl start caddy # Start Caddy service
sudo systemctl status caddy # Check Caddy status

Now all components are installed. Let's proceed to their configuration.

Configuration

Configuring OpenSearch and OpenSearch Dashboards requires attention to detail, especially regarding security. We will configure TLS for OpenSearch, the built-in security system, and a reverse proxy with HTTPS for Dashboards.

1. OpenSearch Configuration

The main OpenSearch configuration file is located at /etc/opensearch/opensearch.yml.

sudo vim /etc/opensearch/opensearch.yml # OpenSearch configuration file

Make the following changes (or uncomment and modify):

# Basic cluster settings
cluster.name: opensearch-cluster
node.name: node-1

# Network settings
network.host: 0.0.0.0 # Allow connections from all interfaces
http.port: 9200
transport.port: 9300

# Discovery settings (for a single node)
discovery.type: single-node

# Data and log paths
path.data: /var/lib/opensearch
path.logs: /var/log/opensearch

# Security settings (Security Plugin)
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.clientauth_mode: OPTIONAL
plugins.security.ssl.http.pemcert_filepath: /etc/opensearch/certs/opensearch.pem
plugins.security.ssl.http.pemkey_filepath: /etc/opensearch/certs/opensearch.key
plugins.security.ssl.http.rootcas_filepath: /etc/opensearch/certs/root-ca.pem

plugins.security.ssl.transport.enabled: true
plugins.security.ssl.transport.clientauth_mode: OPTIONAL
plugins.security.ssl.transport.pemcert_filepath: /etc/opensearch/certs/opensearch.pem
plugins.security.ssl.transport.pemkey_filepath: /etc/opensearch/certs/opensearch.key
plugins.security.ssl.transport.rootcas_filepath: /etc/opensearch/certs/root-ca.pem
plugins.security.allow_unsafe_democertificates: false # Always false in production
plugins.security.audit.type: internal_opensearch
plugins.security.audit.config.internal_opensearch.enabled: true
plugins.security.nodes_dn:
  - "CN=node-1,OU=opensearch,O=OpenSearch,L=Seattle,ST=Washington,C=US" # Replace with your node's DN

# For built-in authentication
plugins.security.authcz.admin_dn:
  - "CN=admin,OU=opensearch,O=OpenSearch,L=Seattle,ST=Washington,C=US" # Replace with your admin's DN

Certificate Generation

OpenSearch requires TLS certificates for secure operation. We will use the built-in opensearch-certgen tool.

sudo /usr/share/opensearch/modules/opensearch-security/tools/securityadmin.sh -cd /usr/share/opensearch/plugins/opensearch-security/securityconfig/ -icl -nhnv -cacert /usr/share/opensearch/plugins/opensearch-security/securityconfig/root-ca.pem -cert /usr/share/opensearch/plugins/opensearch-security/securityconfig/kirk.pem -key /usr/share/opensearch/plugins/opensearch-security/securityconfig/kirk-key.pem

# Create directory for certificates
sudo mkdir -p /etc/opensearch/certs

# Generate certificates using opensearch-certgen
# Follow the instructions, enter 'y' to create the CA, then to generate certificates.
# Ensure that the Common Name (CN) for the node matches 'CN=node-1,OU=opensearch,O=OpenSearch,L=Seattle,ST=Washington,C=US'
# and for the admin 'CN=admin,OU=opensearch,O=OpenSearch,L=Seattle,ST=Washington,C=US'
sudo /usr/share/opensearch/plugins/opensearch-security/tools/opensearch-certgen.sh -p /etc/opensearch/certs

# Move generated files
sudo mv /etc/opensearch/certs/kirk-key.pem /etc/opensearch/certs/opensearch.key
sudo mv /etc/opensearch/certs/kirk.pem /etc/opensearch/certs/opensearch.pem
sudo mv /etc/opensearch/certs/root-ca.pem /etc/opensearch/certs/root-ca.pem # This is already the correct name
sudo chown -R opensearch:opensearch /etc/opensearch/certs # Set correct permissions
sudo chmod -R 700 /etc/opensearch/certs # Protect private keys

Configuring Built-in Security (Security Plugin)

After generating certificates, you need to initialize the security plugin. First, restart OpenSearch.

sudo systemctl restart opensearch # Restart OpenSearch
sudo systemctl status opensearch # Ensure the service is running

Initialize the security plugin. This will load standard roles and users.

# Run this script. It will prompt for passwords for built-in users (admin, kibanaserver, logstash, readall, snapshotrestore).
# Set a strong password for the 'admin' user.
sudo /usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh -cd /usr/share/opensearch/plugins/opensearch-security/securityconfig/ -icl -nhnv -cacert /etc/opensearch/certs/root-ca.pem -cert /etc/opensearch/certs/opensearch.pem -key /etc/opensearch/certs/opensearch.key

After this, the script will ask you to enter new passwords for system users. Be sure to set a strong password for admin.

Check OpenSearch access using curl (you will be prompted for login/password, use admin and the password you set).

curl -k --user admin:YOUR_ADMIN_PASSWORD https://localhost:9200/_cat/health?v # Check cluster health

If you see a response, OpenSearch is running with security enabled.

2. OpenSearch Dashboards Configuration

The main Dashboards configuration file is located at /etc/opensearch-dashboards/opensearch_dashboards.yml.

sudo vim /etc/opensearch-dashboards/opensearch_dashboards.yml # Open Dashboards configuration file

Make the following changes:

server.port: 5601
server.host: "localhost" # Dashboards will only be available locally, Caddy will proxy requests

# OpenSearch settings
opensearch.hosts: ["https://localhost:9200"] # Connect to OpenSearch via HTTPS
opensearch.ssl.verificationMode: certificate # Verify OpenSearch certificates
opensearch.ssl.certificateAuthorities: ["/etc/opensearch/certs/root-ca.pem"] # Path to OpenSearch root CA

# Dashboards authentication
opensearch.username: "kibanaserver" # Use system user for Dashboards
opensearch.password: "YOUR_KIBANASERVER_PASSWORD" # Password set during securityadmin.sh initialization

# Dashboards security settings
opensearch_security.auth.type: "basic" # Use basic authentication
opensearch_security.cookie.secure: true

Replace YOUR_KIBANASERVER_PASSWORD with the password you set for the kibanaserver user when running securityadmin.sh.

Save the changes and restart OpenSearch Dashboards.

sudo systemctl restart opensearch-dashboards # Restart OpenSearch Dashboards
sudo systemctl status opensearch-dashboards # Check service status

3. Caddy Configuration for HTTPS

We will configure Caddy as a reverse proxy for OpenSearch Dashboards to provide HTTPS access and automatic SSL certificate management.

sudo vim /etc/caddy/Caddyfile # Open Caddy configuration file

Replace the file content with the following (replace YOUR_DOMAIN with your actual domain):

YOUR_DOMAIN {
    # Automatic HTTPS with Let's Encrypt
    tls {
        dns cloudflare {ENV.CLOUDFLARE_API_TOKEN} # Example for Cloudflare DNS.
                                                # If you use a different DNS provider,
                                                # install the corresponding Caddy plugin.
                                                # For HTTP-01 challenge without DNS - just tls
    }

    # Compression
    encode gzip zstd

    # Reverse proxy to OpenSearch Dashboards
    reverse_proxy localhost:5601 {
        # Add headers for correct operation
        header_up Host {http.request.host}
        header_up X-Real-IP {http.request.remote}
        header_up X-Forwarded-For {http.request.remote}
        header_up X-Forwarded-Proto {http.request.scheme}
    }

    # Clickjacking protection
    header {
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        X-XSS-Protection "1; mode=block"
    }

    # Logging (optional)
    log {
        output file /var/log/caddy/access.log {
            roll_size 10MiB
            roll_keep 5
        }
    }
}

Important: For automatic issuance of TLS certificates via DNS-01 challenge (recommended if your server is not directly accessible externally on ports 80/443 or if you want wildcard certificates), you need to install the appropriate Caddy plugin (e.g., for Cloudflare) and specify the API token in an environment variable. If your server is accessible on ports 80/443, simply using tls without additional settings is sufficient.

For DNS-01 with Cloudflare, create the file /etc/systemd/system/caddy.service.d/override.conf:

[Service]
Environment="CLOUDFLARE_API_TOKEN=YOUR_CLOUDFLARE_API_TOKEN"

Replace YOUR_CLOUDFLARE_API_TOKEN with your actual token (created in your Cloudflare dashboard). Then:

sudo systemctl daemon-reload # Reload systemd
sudo systemctl restart caddy # Restart Caddy
sudo systemctl status caddy # Check Caddy status

If Caddy cannot obtain a certificate, check Caddy logs: sudo journalctl -u caddy --no-pager.

4. Firewall Configuration (UFW) for OpenSearch

By default, OpenSearch is available on port 9200. If you do not plan direct external access to OpenSearch (which is highly discouraged), ensure that port 9200 is closed to external connections. If you plan a cluster or access for Logstash/Filebeat from other servers, allow traffic only from those IP addresses.

# If OpenSearch should only be accessible locally:
sudo ufw deny 9200/tcp # Deny external access to OpenSearch

# If you need to allow access from a specific IP address (e.g., for another cluster node or Logstash)
# sudo ufw allow from 192.168.1.10 to any port 9200 # Allow from 192.168.1.10

sudo ufw reload # Reload UFW rules
sudo ufw status # Check UFW status

5. Verify Operation

Open https://YOUR_DOMAIN in your browser. You should see the OpenSearch Dashboards login page. Use the login admin and the password you set for it earlier.

After logging in, you can go to "Stack Management" -> "Index Management" or "Dev Tools" to check the OpenSearch status.

In Dev Tools, execute the query:

GET /_cat/health?v

You should receive a response showing the cluster status (e.g., green or yellow).

Backups and Maintenance

Regular backup is critically important for any production system. OpenSearch provides powerful tools for creating snapshots, and standard utilities can be used for configuration files.

1. What to back up

• OpenSearch Data: Indices, documents, metadata. This is the most important. Use OpenSearch's built-in snapshot feature.
• Configuration files: /etc/opensearch/opensearch.yml, /etc/opensearch/certs/, /etc/opensearch-dashboards/opensearch_dashboards.yml, /etc/caddy/Caddyfile, as well as security files (roles.yml, roles_mapping.yml, etc., if you have modified them).
• System settings: For example, UFW rules, Fail2Ban settings.

2. Setting up a repository for OpenSearch snapshots

OpenSearch can store snapshots in various repositories, including the file system, Amazon S3, Google Cloud Storage, Azure Blob Storage, and others. The most versatile and reliable option is S3-compatible storage.

First, install the S3 plugin for OpenSearch:

sudo /usr/share/opensearch/bin/opensearch-plugin install -b repository-s3 # Install S3 plugin
sudo systemctl restart opensearch # Restart OpenSearch after plugin installation

Then, register the repository in OpenSearch. You will need an AWS Access Key ID and Secret Access Key (or similar for S3-compatible storage). Never store them directly in OpenSearch configuration files.

Create a file to store credentials in a protected mode:

echo "s3.client.default.access_key: ВАШ_AWS_ACCESS_KEY_ID" | sudo tee -a /etc/opensearch/opensearch.yml
echo "s3.client.default.secret_key: ВАШ_AWS_SECRET_ACCESS_KEY" | sudo tee -a /etc/opensearch/opensearch.yml
sudo systemctl restart opensearch # Restart OpenSearch to apply credentials

Now register the snapshot repository via the OpenSearch API (in Dev Tools Dashboards or curl):

PUT /_snapshot/my_s3_repository
{
  "type": "s3",
  "settings": {
    "bucket": "your-s3-bucket-name",
    "region": "us-east-1",
    "base_path": "opensearch_backups/"
  }
}

Replace your-s3-bucket-name and us-east-1 with your data.

3. Simple auto-backup script

Create a script for automatic snapshot creation and configuration file backup.

sudo mkdir /opt/backup_scripts
sudo vim /opt/backup_scripts/opensearch_backup.sh

Contents of opensearch_backup.sh:

#!/bin/bash

DATE=$(date +%Y%m%d%H%M%S)
SNAPSHOT_NAME="snapshot-$DATE"
REPOSITORY_NAME="my_s3_repository"
OPENSEARCH_HOST="https://localhost:9200"
OPENSEARCH_USER="admin"
OPENSEARCH_PASSWORD="ВАШ_ПАРОЛЬ_АДМИНА"
BACKUP_DIR="/var/backups/opensearch_configs"

# Creating OpenSearch snapshot
echo "Creating OpenSearch snapshot: $SNAPSHOT_NAME..."
curl -k -u "${OPENSEARCH_USER}:${OPENSEARCH_PASSWORD}" -XPUT "${OPENSEARCH_HOST}/_snapshot/${REPOSITORY_NAME}/${SNAPSHOT_NAME}?wait_for_completion=true" -H 'Content-Type: application/json' -d'
{
  "indices": "",
  "ignore_unavailable": true,
  "include_global_state": true
}'

if [ $? -eq 0 ]; then
  echo "Snapshot $SNAPSHOT_NAME created successfully."
else
  echo "Error creating snapshot $SNAPSHOT_NAME."
fi

# Deleting old snapshots (example: keep the last 7 snapshots)
# Get a list of all snapshots
SNAPSHOTS=$(curl -k -u "${OPENSEARCH_USER}:${OPENSEARCH_PASSWORD}" "${OPENSEARCH_HOST}/_snapshot/${REPOSITORY_NAME}/_all" | jq -r '.snapshots[].snapshot')
NUM_SNAPSHOTS=$(echo "$SNAPSHOTS" | wc -l)
if [ "$NUM_SNAPSHOTS" -gt 7 ]; then
    SNAPSHOTS_TO_DELETE=$(echo "$SNAPSHOTS" | head -n $((NUM_SNAPSHOTS - 7)))
    for SNAPSHOT in $SNAPSHOTS_TO_DELETE; do
        echo "Deleting old snapshot: $SNAPSHOT"
        curl -k -u "${OPENSEARCH_USER}:${OPENSEARCH_PASSWORD}" -XDELETE "${OPENSEARCH_HOST}/_snapshot/${REPOSITORY_NAME}/${SNAPSHOT}"
    done
fi


# Backup configuration files
echo "Backing up configuration files..."
sudo mkdir -p "$BACKUP_DIR"
sudo tar -czvf "$BACKUP_DIR/opensearch_configs-$DATE.tar.gz" \
  /etc/opensearch/opensearch.yml \
  /etc/opensearch/certs \
  /etc/opensearch-dashboards/opensearch_dashboards.yml \
  /etc/caddy/Caddyfile \
  /etc/fail2ban/jail.local \
  /etc/ssh/sshd_config \
  --absolute-names

echo "Configuration files backed up to $BACKUP_DIR/opensearch_configs-$DATE.tar.gz"

# Clean up old configs (example: keep the last 7 archives)
find "$BACKUP_DIR" -name "opensearch_configs-.tar.gz" -mtime +7 -delete

echo "Backup process finished."

Replace ВАШ_ПАРОЛЬ_АДМИНА with your actual password. Install jq for JSON processing:

sudo apt install -y jq # Install jq
sudo chmod +x /opt/backup_scripts/opensearch_backup.sh # Make the script executable

4. Setting up Cron for automation

Add the script to Cron for daily execution.

sudo crontab -e # Open crontab for root (or sudo -u adminuser crontab -e for your user)

Add the following line to run the script daily at 03:00 AM:

0 3   * /opt/backup_scripts/opensearch_backup.sh >> /var/log/opensearch_backup.log 2>&1

This will create an OpenSearch snapshot and back up configuration files. Snapshots will be stored in your S3-compatible storage, and configs locally on the server, with automatic cleanup of old versions.

5. Updates: Rolling vs. Maintenance Window

• OpenSearch and OpenSearch Dashboards: For a single node, updates should be performed within a "maintenance window". Stop Dashboards, then OpenSearch, update packages via apt upgrade, then start OpenSearch, and only then Dashboards. For a multi-node cluster, a "rolling upgrade" can be used, but this is a more complex procedure.
• System packages: Regularly run sudo apt update && sudo apt upgrade -y.
• Caddy: Updates along with system packages.

Always back up before any significant update.

Troubleshooting + FAQ

OpenSearch does not start or crashes with an OutOfMemoryError

What to check: OpenSearch is very memory-intensive. Make sure JVM Heap Size is configured correctly and that you have enough physical RAM. By default, OpenSearch allocates 1 GB of RAM, but this is insufficient for most tasks.

How to fix: Edit the /etc/opensearch/jvm.options file. Find the lines -Xms1g and -Xmx1g (or similar) and increase their values to half of the available RAM, but no more than 30 GB (e.g., -Xms8g and -Xmx8g for a server with 16 GB RAM). After making changes, restart OpenSearch: sudo systemctl restart opensearch.

OpenSearch Dashboards cannot connect to OpenSearch

What to check:

1. Ensure OpenSearch is running and accessible at https://localhost:9200. Check sudo systemctl status opensearch and curl -k https://localhost:9200/_cat/health?v.
2. Check the /etc/opensearch-dashboards/opensearch_dashboards.yml file. Make sure opensearch.hosts points to the correct address (https://localhost:9200) and that opensearch.username and opensearch.password match the kibanaserver user and its password.
3. Verify that OpenSearch certificates are correctly specified in opensearch.ssl.certificateAuthorities.

How to fix: Correct errors in configuration files, restart services: sudo systemctl restart opensearch, then sudo systemctl restart opensearch-dashboards.

Cannot access Dashboards via domain (Caddy is not working)

What to check:

1. Ensure your domain correctly points to your VPS's IP address.
2. Check that Caddy is running: sudo systemctl status caddy.
3. Check Caddy logs: sudo journalctl -u caddy --no-pager for errors related to TLS certificate acquisition or proxying.
4. Ensure ports 80 and 443 are open in UFW: sudo ufw status.
5. Check that OpenSearch Dashboards is accessible locally: curl http://localhost:5601 (if you are using server.host: "localhost").

How to fix: Correct DNS records, errors in /etc/caddy/Caddyfile, open ports in UFW. If using DNS-01 verification, check your DNS provider's API token.

What is the minimum suitable VPS configuration?

For test or very light loads, for example, for learning OpenSearch or collecting logs from one or two inactive applications, a VPS with 2 vCPU, 8 GB RAM, and 100 GB NVMe SSD will be minimally suitable. This will allow OpenSearch and Dashboards to run, but performance may be limited with increased data volume or number of queries. For any production environment, more powerful configurations are recommended.

What to choose – VPS or dedicated for this task?

The choice between a VPS and a dedicated server depends on the scale of your task and budget. For most individual developers, small teams, or solo SaaS founders who want to centralize logging, a VPS will be the optimal choice, offering a good balance between cost and performance. If you plan to process terabytes of data, require maximum performance, or build a large cluster, a dedicated server will provide the necessary power and resource isolation.

How to configure log collection from other servers?

What to check: OpenSearch itself does not collect logs. For this, you will need agents such as Filebeat, Logstash, or Fluentd. These agents are installed on target servers, configured to collect logs from files or other sources, and send them to OpenSearch.

How to fix: Install and configure Filebeat on your servers. Filebeat is very lightweight and efficient. In its configuration, specify your OpenSearch (or Caddy, if it also proxies for Filebeat, but direct access to OpenSearch with authorization is better) as the target host, as well as the user and password for authentication. Ensure that OpenSearch ports are open for your agents' IP addresses in UFW.

How to update OpenSearch and OpenSearch Dashboards?

What to check: Before updating, always check the official OpenSearch documentation for version compatibility and specific update instructions. Always perform a full backup of OpenSearch data and configuration files before starting the process.

How to fix: For a single-node installation:

1. Stop OpenSearch Dashboards: sudo systemctl stop opensearch-dashboards.
2. Stop OpenSearch: sudo systemctl stop opensearch.
3. Update packages: sudo apt update && sudo apt upgrade -y. This will update OpenSearch and Dashboards to the latest version in your repository.
4. Start OpenSearch: sudo systemctl start opensearch.
5. Start OpenSearch Dashboards: sudo systemctl start opensearch-dashboards.

Conclusions and Next Steps

Congratulations! You have successfully deployed and configured a powerful centralized logging and analytics system based on OpenSearch and OpenSearch Dashboards on your VPS. Now you have full control over your logs and metrics, which is the foundation for effective monitoring, debugging, and decision-making.

Here are some practical steps you can take next:

• Log Collection Setup: Install and configure Filebeat (or Logstash) on your servers and applications to send logs to OpenSearch. Explore Filebeat modules for automatic parsing of logs from popular services (Nginx, Apache, MySQL, etc.).
• Creating Dashboards and Visualizations: Use OpenSearch Dashboards to create informative dashboards that will help you quickly track key metrics, identify anomalies, and analyze user or system behavior.
• Alerting Configuration: OpenSearch has a built-in alerting mechanism. Configure it to receive notifications about critical events, errors, or metric threshold breaches via email, Slack, or other channels.
• Performance Optimization and Scaling: As data volume grows, explore options for index optimization (e.g., Index Lifecycle Management), sharding, and replication to improve performance and fault tolerance. If necessary, consider adding additional OpenSearch nodes to create a cluster.