Use case · DevOps & CI/CD
Monitoring stacks
A monitoring stack collects metrics, logs, and traces, stores them, and provides dashboards and alerting to observe systems. Its time-series data accumulates, so storage and retention matter, alongside compute for querying. Self-hosting gives control, cost efficiency, and sovereignty over operational data. Dedicated, EU-hosted infrastructure keeps a monitoring stack's data sovereign and under your control.
Key points
- A monitoring stack observes systems through metrics, logs, traces, dashboards, and alerting.
- Its metrics are time-series data that accumulate, making storage and retention important.
- It needs compute to query and visualise the data and to run alerting.
- Self-hosting gives control, cost efficiency, and sovereignty over operational data.
- EU hosting keeps monitoring data — which reveals much about systems — sovereign.
What is a monitoring stack, and what does it need?
A monitoring stack is the set of tools that observe systems — collecting metrics, logs, and traces, storing them, and providing dashboards and alerting so that the systems' behaviour and health can be seen and problems caught. Observability has become essential to running systems well, since understanding what systems are doing, spotting problems, and being alerted to issues all depend on collecting and making sense of the data systems produce. A monitoring stack gathers this data, keeps it, lets it be visualised and queried, and raises alerts when something is wrong, so that those running the systems can see and respond to what is happening.
A monitoring stack needs infrastructure suited to its parts: collecting the monitoring data, storing it — often a great deal, accumulating over time — and providing the compute to query, visualise, and alert on it. The storage is a particular consideration, since monitoring data, especially metrics collected continuously, accumulates into large volumes; and compute is needed to query and display it and run alerting. This page focuses on hosting a monitoring stack; the related case of log aggregation is covered on its own page, while what follows attends to what a monitoring stack needs from its infrastructure.
The components: collection, storage, visualisation, alerting
A monitoring stack typically has several components working together: collection that gathers the monitoring data, storage that holds it, visualisation that presents it in dashboards, and alerting that raises notifications when something is wrong. Collection gathers metrics and other data from the systems being monitored; storage keeps that data so it can be queried; visualisation, through dashboards, presents the data in a form people can understand and explore; and alerting watches the data and notifies when conditions indicate a problem. Together these turn raw system data into observability people can act on.
Hosting a monitoring stack means providing infrastructure for all these components, which run together to observe the systems. The collection must gather data reliably; the storage must hold it with the capacity and performance the data needs; the visualisation must serve dashboards responsively; and the alerting must run to catch problems. Each runs on infrastructure and consumes resources. We provide the infrastructure a monitoring stack's components need — for collection, storage, visualisation, and alerting — so that the stack can gather, keep, present, and alert on the data that makes systems observable, on a foundation resourced for each part of the work.
Time-series data and its storage
Much of a monitoring stack's data is time-series data — metrics measured repeatedly over time — which accumulates continuously and can grow into large volumes, making storage a central consideration. Metrics are gathered at intervals from the monitored systems, producing a steady stream of measurements over time, and as this continues, the volume of stored metrics grows, especially when many metrics are collected from many systems frequently. This makes the storage of time-series data, and its ability to hold and serve the accumulating measurements, important to a monitoring stack.
Storing time-series data well means storage with the capacity for the accumulating metrics and the performance to query them, often using databases designed for time-series data. Time-series databases are built to store and query measurements over time efficiently, handling the continuous accumulation and the queries that analyse it, so a monitoring stack's storage often uses such a database on infrastructure sized for the data. Fast storage helps both writing the incoming metrics and querying them for dashboards and alerts. We provide storage sized and performant for a monitoring stack's time-series data, so that the accumulating metrics are held and can be queried, which is central to a monitoring stack that collects data continuously over time.
Compute and performance
A monitoring stack needs compute to query and visualise its data and to run its alerting, and its performance affects how responsive the monitoring is. Querying the monitoring data for dashboards, especially over large volumes or long time ranges, takes compute; serving dashboards responsively needs the queries to complete quickly; and alerting continuously evaluates the data against conditions, which also consumes resources. A monitoring stack that is slow to query or serve dashboards is frustrating and less useful, so adequate compute and good performance matter to the stack being usable.
Providing for this means compute matched to the querying, visualisation, and alerting the stack does, with fast storage feeding the queries. A busy monitoring stack, collecting much data and serving many dashboards and alerts, needs the compute to keep up; fast storage speeds the queries over the time-series data. The resources should be sized to how much the stack monitors and how heavily it is used. We provide compute and fast storage sized to a monitoring stack's querying, visualisation, and alerting, so that dashboards are responsive, queries complete quickly, and alerting runs reliably — keeping the monitoring stack usable and useful for observing the systems it watches.
Retention: keeping monitoring data over time
How long to keep monitoring data — its retention — is an important decision for a monitoring stack, balancing the value of historical data against the storage it consumes. Keeping monitoring data longer allows analysis of trends over time, comparison with the past, and investigation of issues after the fact, which is valuable; but it also means storing more data, which consumes more storage as the retention period lengthens. So retention involves a trade-off between how much history is kept and how much storage that requires, which shapes the storage a monitoring stack needs.
Managing retention well means choosing how long to keep data at what detail, and providing storage for it. Approaches such as keeping recent data in full detail and older data in summarised form can extend useful history without storing everything at full resolution indefinitely, controlling the storage growth. The right retention depends on how much history is useful and the storage available. We provide storage sized for a monitoring stack's chosen retention, and support the retention arrangements that balance history against storage, so that a monitoring stack keeps the historical data that is useful without its storage growing without limit — matching the retention to the value of the history and the storage provided.
Self-hosted versus managed monitoring
A significant choice is between self-hosting a monitoring stack on infrastructure you control and using a managed observability service. Managed services are convenient — the provider runs the monitoring, and you send it your data — but they carry trade-offs: your operational data sits on the provider's platform, costs can grow substantially with the volume of monitoring data, which for busy systems can be considerable, and you depend on the provider's terms. Self-hosting a monitoring stack on infrastructure you control requires running it but keeps the operational data, the stack, and the cost in your hands, and can be far more cost-effective at scale.
The honest basis for choosing is your scale and what you value. Managed observability suits those who want to avoid running the monitoring and accept sending their data to the provider, and it can be reasonable at modest volumes. Self-hosting suits larger volumes, where managed services' costs grow steep, and cases where the operational data should stay on infrastructure you control, for sovereignty or cost. Organisations often self-host monitoring when their data volume makes managed services costly, or their operational data should not leave their infrastructure. We provide the infrastructure for a self-hosted monitoring stack, while being candid that managed observability suits some, especially at modest scale.
Sovereignty, and where VV Internet Hosting fits
Monitoring data can reveal a great deal about an organisation's systems, usage, and operations, so where the monitoring stack runs governs sensitive operational data, making sovereignty a consideration. The metrics, logs, and traces a monitoring stack collects can expose how systems are built, how they perform, how they are used, and where problems lie — information an organisation may not want on a third party's platform or under a foreign jurisdiction. VV Internet Hosting is incorporated in the Netherlands, within the EU, so a monitoring stack hosted with us runs under European jurisdiction and outside the direct reach of the US CLOUD Act, keeping the operational data under European law and on infrastructure the organisation controls.
We host dedicated infrastructure for a self-hosted monitoring stack: storage sized for its accumulating time-series data and chosen retention, compute for querying, visualisation, and alerting, and fast storage to serve the queries — in EU datacenters under European jurisdiction. This suits organisations self-hosting their monitoring that want control, cost-effectiveness at scale, and European sovereignty over their operational data. We are clear about our limits: we provide the dedicated infrastructure the monitoring stack runs on, not a managed observability service that operates it for you. We are the dedicated, sovereign infrastructure on which you self-host your monitoring stack — and if that fits your needs, we can host it well.
Related use cases
See also
Questions
Monitoring stacks, answered plainly
Common questions about hosting for Monitoring stacks.
What is a monitoring stack?
The set of tools that observe systems — collecting metrics, logs, and traces, storing them, and providing dashboards and alerting so systems' behaviour and health can be seen and problems caught. It gathers the data systems produce, keeps it, lets it be visualised and queried, and raises alerts when something is wrong, so those running the systems can see and respond to what's happening.
Why does storage matter so much for monitoring?
Because much monitoring data is time-series data — metrics measured repeatedly over time — that accumulates continuously and grows into large volumes, especially when many metrics are collected from many systems frequently. Storing it needs capacity for the accumulating metrics and performance to query them, often using databases built for time-series data. Retention — how long to keep it — trades history against storage.
Should I self-host monitoring or use a managed service?
It depends on scale and values. Managed observability is convenient but places your operational data on the provider's platform, and costs can grow steep with data volume. Self-hosting keeps the data, stack, and cost in your hands, and can be far more cost-effective at scale. Organisations often self-host when data volume makes managed services costly, or their operational data should stay on their infrastructure.
Planning Monitoring stacks infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.