Moving time-series data between two NetEye systems is a common but often underestimated challenge. Whether driven by infrastructure migrations, platform refactoring, customer onboarding/offboarding, or environment consolidation, the need to relocate InfluxDB metrics reliably and selectively comes up again and again.
We created this repository to address that need from a high-level, operational perspective: enabling self-service migration of InfluxDB metrics for customers.
Why this repository exists
In many real-world environments, InfluxDB metrics are business-critical. At the same time, moving them safely is often difficult because existing solutions tend to be:
- all-or-nothing (full backups instead of selective exports)
- hard to delegate to customers
- or must be done with both influxdb instances shut down (cold start)
As a result, even relatively simple migration requests frequently turn into manual, error-prone operations.
What problem it solves
This repository provides a pragmatic way to:
- migrate metrics between two InfluxDB systems on two different NetEye systems
- limit migrations to a specific time range
- scope operations to a single database and retention policy
- repeat imports safely without risking data duplication
All of this is achieved without requiring direct filesystem access to the InfluxDB nodes and without introducing complex tooling.
In practice, this means that migrations can be:
- planned and executed incrementally
- delegated to customers or project teams
- standardized across environments
What you can do with it
At a high level, the repository enables a simple but powerful workflow:
- Extract metrics from an existing InfluxDB instance for a defined time window
- Store the exported data in a portable, transparent format
- Re-import the metrics into another InfluxDB system when and where needed
This makes it suitable for scenarios such as:
- migrating customers to a new platform or cluster
- splitting or merging environments
- moving historical data ahead of a cutover
- giving customers-controlled ownership of their metric data
Design principles
A few key principles guided the implementation:
- Self-service first: users should be able to run migrations independently
- Minimal assumptions: no special access to servers or storage
- Safety by design: re-importing the same data should not create duplicates
- Transparency: exported data remains inspectable and portable
Rather than aiming to replace native backup and restore mechanisms, the project intentionally focuses on selective, operationally friendly migrations.
The bigger picture
From an organizational standpoint, this approach shifts metric migration from a low-level infrastructure task to a repeatable operational process.
That has tangible benefits:
- fewer manual interventions
- reduced risk during migrations
- clearer ownership boundaries
- faster turnaround for customer requests
Ultimately, the repository exists to reduce friction: between teams, between systems, and between the need to move data and the fear of doing it wrong.
If you have migrated your NetEye environment, maybe from virtual to physical, and need to reimport your InfluxDB metrics, this project provides a simple foundation for making metric migrations predictable, auditable, and self-service.
Learn more here: https://bitbucket.org/siwuerthphoenix/influxdb-extract-metrics
Matteo Cipolletta
Author
