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.
The 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 our 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. This 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’ve migrated your NetEye environment, for instance from virtual to physical, and need to re-import your InfluxDB metrics, this project provides a simple foundation for making metric migrations predictable, auditable, and automated.
Learn more here: https://bitbucket.org/siwuerthphoenix/influxdb-extract-metrics
These Solutions are Engineered by Humans
Are you passionate about performance metrics or other modern IT challenges? Do you have the experience to drive solutions like the one above? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this as well as other roles here at Würth IT Italy.
Matteo Cipolletta
Author
