Introduction: The Multi-Cloud Monitoring Challenge

Modern enterprise IT architectures increasingly rely on multi-cloud strategies to ensure high availability, prevent vendor lock-in, and optimize costs. However, monitoring infrastructure across disparate environments like AWS, Google Cloud Platform (GCP), Microsoft Azure, and on-premises private clouds introduces significant operational complexity. Traditional monitoring setups often require deploying heavy, resource-intensive agents on every virtual machine (VM) or container instance. This approach not only inflates infrastructure costs but also expands the security attack surface and creates maintenance nightmares.

To solve this, engineering teams are turning to agentless and lightweight pull/push-based monitoring architectures. This blog post provides an in-depth technical blueprint for configuring an agentless multi-cloud infrastructure monitoring system. By deploying VictoriaMetrics and its ultra-efficient companion, vmagent, on a centralized Virtual Private Server (VPS), you can seamlessly consolidate metrics across multiple cloud providers with minimal resource overhead, enterprise-grade scalability, and simplified long-term data retention.

---

Why VictoriaMetrics and vmagent for Agentless Monitoring?

When designing a centralized monitoring hub, selecting the right Time Series Database (TSDB) is critical. While Prometheus has long been the industry standard, its memory footprint and complex clustering requirements can become prohibitive at scale. VictoriaMetrics addresses these limitations directly, offering a drop-in replacement that is highly optimized for performance and storage efficiency.

Key Benefits of VictoriaMetrics

Cost-Effective Storage: VictoriaMetrics achieves up to 7x better data compression compared to standard TSDBs, significantly lowering storage costs on your centralized VPS.
High Performance: It handles millions of data points per second with low memory usage, ensuring your central monitoring server remains responsive.
PromQL Compatibility: It supports full MetricsQL (an extended version of PromQL), allowing you to reuse existing Grafana dashboards and Prometheus alerting rules seamlessly.

The Power of vmagent

Rather than running a full monitoring stack on every cloud instance, we utilize vmagent—a tiny, highly efficient daemon designed to scrape targets, cache metrics locally during network partitions, and forward them via the Prometheus remote write protocol to the central VictoriaMetrics instance. It serves as the lean data-collection engine that makes this agentless-style architecture incredibly lightweight.

---

Architectural Overview

Our centralized monitoring architecture consists of three main layers:

The Centralized Hub (VPS): Hosts the core VictoriaMetrics database (single-node or cluster), Grafana for visualization, and the central alerting engine.
The Data Collection Layer (vmagent): Deployed as a lightweight service or running centrally on the VPS to pull metrics remotely from edge networks via secure endpoints (e.g., cloud provider APIs, exporter endpoints, or VPN tunnels).
The Target Infrastructure: Multi-cloud virtual instances running standard open-source exporters (like node_exporter for Linux or wmi_exporter for Windows) exposed securely, requiring no proprietary agent software.

Security Note: All metric transmission between the multi-cloud endpoints and the centralized VPS must be encrypted using TLS and protected via basic authentication or network-level firewalls (IP whitelisting).

---

Step-by-Step Configuration Guide

Let's dive into the practical deployment steps to set up this centralized multi-cloud monitoring pipeline.

Step 1: Deploying VictoriaMetrics on the Central VPS

First, update your centralized VPS and install VictoriaMetrics. For simplicity and reproducibility, we will use Docker Compose.

version: '3.8'
services:
  victoriametrics:
    container_name: victoriametrics
    image: victoriametrics/victoria-metrics:stable
    ports:
      - "8428:8428"
    volumes:
      - vmdata:/vmdata
    command:
      - '--storageDataPath=/vmdata'
      - '--retentionPeriod=12m'
    restart: always

volumes:
  vmdata:

Run docker-compose up -d to launch the time-series database. VictoriaMetrics will now be listening for data on port 8428.

Step 2: Configuring vmagent for Cross-Cloud Scraping

Next, we configure vmagent to scrape target metrics from various cloud environments. Create a configuration file named vmagent.yml on your central VPS or a designated collector node:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'aws-infrastructure'
    static_configs:
      - targets: ['aws-ec2-instance1.mycompany.internal:9100', 'aws-ec2-instance2.mycompany.internal:9100']
    relabel_configs:
      - target_label: 'provider'
        replacement: 'aws'

  - job_name: 'gcp-infrastructure'
    static_configs:
      - targets: ['gcp-compute-vm1.mycompany.internal:9100']
    relabel_configs:
      - target_label: 'provider'
        replacement: 'gcp'

  - job_name: 'azure-infrastructure'
    static_configs:
      - targets: ['azure-vm1.mycompany.internal:9100']
    relabel_configs:
      - target_label: 'provider'
        replacement: 'azure'

Now, run the vmagent container, linking it to the configuration file and pointing its remote write target to your VictoriaMetrics instance:

docker run -d \
  --name vmagent \
  -v $(pwd)/vmagent.yml:/etc/prometheus/prometheus.yml \
  victoriametrics/vmagent:stable \
  -promscrape.config=/etc/prometheus/prometheus.yml \
  -remoteWrite.url=http://victoriametrics:8428/api/v1/write

---

Optimizing for Production: Best Practices

Deploying the architecture is only the first step. To ensure a resilient, enterprise-grade multi-cloud monitoring environment, implement these production optimizations:

1. Enable Stream Aggregation

If you are collecting high-frequency metrics across thousands of cloud VMs, network bandwidth and storage costs can escalate. Use VictoriaMetrics' stream aggregation feature directly inside vmagent to downsample metrics (e.g., calculating 5-minute averages) before transmitting them across the internet to your centralized VPS.

2. Handle Network Flakiness with Local Caching

Cross-cloud network connections can occasionally drop. By default, vmagent automatically buffers scraped data to a local disk directory if the central VictoriaMetrics server becomes unreachable. Ensure you allocate adequate disk space to the -remoteWrite.tmpDataPath flag to prevent data loss during extended multi-cloud network partitions.

3. Centralize Visualization with Grafana

Connect a Grafana instance to your VictoriaMetrics database endpoint (http://:8428) using the standard Prometheus data source. You can then build global dashboards that filter infrastructure health dynamically by the provider label we configured in the relabeling step.

---

Conclusion

Consolidating multi-cloud infrastructure monitoring onto a single centralized VPS doesn't have to mean managing bloated, platform-specific agents or enduring skyrocketing software-as-a-service (SaaS) licensing fees. By pairing VictoriaMetrics with vmagent, you build a high-performance, cost-efficient, and truly decoupled observability framework. This setup empowers engineering teams with global visibility across AWS, GCP, Azure, and beyond, all controlled from a single, unified open-source foundation.

Agentless Multi-Cloud Infrastructure Monitoring: A Comprehensive Guide Using VictoriaMetrics and vmagent on a Centralized VPS