Overview

groundcover’s unique Bring Your Own Cloud (BYOC) architecture enables all of your observability data - logs, infrastructure metrics, custom metrics, traces, Kubernetes events - to remain within the "four walls" of your infrastructure, at all times.

Setup options

inCloud

Instant deployment, multiple backends

inCloud Managed

Fully managed, unified backend

onPrem

Fully on-premises, secure authentication

airGapped

Complete, offline isolation.

inCloud

Deploy groundcover in minutes, with one backend installed in each cluster you choose to monitor. Frontend is accessed from our own cloud, offering a SaaS-like model. This setup option is available in our Free & Team plans and can be deployed via our in-app, self-serve upgrade.

Deployed in your environment:

• eBPF sensors - in each monitored cluster

• groundcover backend - in each monitored cluster

Accessed via external cloud:

• Frontend

• User authentication

Diagram: inCloud architecture

---

inCloud Managed

With a fully managed backend, this setup offers the most hands-off setup in terms of installation and ongoing maintenance. It is comprised of a single groundcover backend (instead of one backend for each cluster, like for inCloud), deployed in a dedicated cluster in your cloud environment. Frontend is accessed via a secure communication with groundcover's cloud, and authentication is done using SSO.

This setup option requires an Enterprise plan.

Deployed in your environment:

• eBPF sensors - in each monitored cluster

• groundcover backend - in a dedicated cluster, including:

  • Ingestion endpoints for Prometheus, OpenTelemetry, and cloud integrations

  • Ingestion and offloading to object storage

Accessed via external cloud:

• Frontend

• User authentication via SSO

• Managed control plane - which is used for managing the backend

Diagram: inCloud Managed architecture

---

onPrem

Using a similar deployment model as inCloud Managed, excluding backend management, which is handed over to you and is entirely under your control. Only user authentication is achieved via secure access to a third-party cloud.

Our onPrem setup suits the requirements of most organizations that require a heightened level of data security and privacy.

Deployed in your environment:

• eBPF sensors - in each monitored cluster

• groundcover backend - in one of your clusters, including:

  • Ingestion endpoints for Prometheus, OpenTelemetry, and cloud integrations

  • Ingestion and offloading to object storage - for AWS / GCP / Azure

• Frontend

Accessed via external cloud:

• User authentication

Diagram: onPrem architecture

---

airGapped

All data, backend processes, frontend interaction, and user authentication are installed on-premises and require no communication with external clouds, removing all risks related to third-party exposure or external threats.

This setup option is most suitable for organizations that take absolutely zero risk in terms of security and privacy.

Deployed in your environment:

• eBPF sensors - in each monitored cluster

• groundcover backend - in one of your clusters, including:

  • Ingestion endpoints for Prometheus, OpenTelemetry, and cloud integrations

  • Ingestion and offloading to object storage - for AWS/GCP/Azure

• Frontend

• User authentication

Accessed via external cloud:

• None

Diagram: airGapped architecture

---

Key advantages

Unlike traditional solutions, groundcover's backend is deployed inside your cloud or offline (on-premises) environments, providing two primary advantages:

Slicing total cost of ownership:

The cost of observability is completely separated from the volume of data produced by your monitored clusters. groundcover's pricing is based only on one criteria - the average number of monitored nodes in your clusters. The word "average" is key, as it speaks to our pricing model's "spikes-proof" approach. Sudden and temporary growth in your environment does not incur penalties in the form of disproportionate bills.

Answering the most stringent privacy and security needs:

With our backend being installed on your premises, observability data is only "streamed" internally. At most, with our inCloud and inCloud Managed setup models, our UI (frontend) is deployed on our external cloud, to offer that SaaS-like experience. Yet even then, risks of third-party exposure and external threats are significantly reduced. Our unique onPrem and airGapped models tune these risks down all the way to zero.

Additional advantages:

• Stream data processing for high scalability - data is processed as it travels through each node in the cluster, eliminating the need to be written to a storage, hence reducing storage costs. This also enables any amount of data to be ingested in real-time, without trucking it outside your cluster.

• Running out-of-band for minimal overhead - our eBPF sensor is running on a separate pod, in a separate namespace, hence has no impact on your monitored applications. This also means it can be governed using native K8s primitives, such as resource limits and network policies.

• Private and secure - all your monitored data is always stored inside your environment, so no data ever needs to leave your cluster.

• Open Source compatibility - metrics created by groundcover are stored in a Prometheus-compatible datasource, which is deployed inside your environment and under your control. This makes it very easy to add to your existing Grafana setup.

Our platform is built from three main components:

• eBPF sensor groundcover's data collection and aggregation sensor. The sensor is deployed as a DaemonSet called sensor, running a single pod in each node in the cluster.
• backend groundcover's inCloud data backend and its connector to the groundcover cloud. The groundcover backend contains Pods that manage the data aggregation and data stores for the logs, metrics, traces and events that are created by the groundcover sensor and stored in-cloud.

• cloud groundcover's control plane, taking care of routing the data from the groundcover backend to the user's browser. The groundcover cloud also handles and manages metadata around users, organizations etc.

Data storage

Regardless of the type of setup you choose, the storage components of our architecture are installed inside your environment. To ensure that you get the optimal balance between performance and cost, groundcover integrates with two best-of-breed technologies - ClickHouse and VictoriaMetrics.

ClickHouse: Used for the persistent storage of all collected logs, traces and Kubernetes events. It is a resource efficient database that supports multiple type of datasources. ClickHouse supports SQL as its log query language.

VictoriaMetrics: Used for the persistent storage of all collected metrics. It is a time-series database, which supports a PromQL query interface and is a Prometheus compatible datasource.

Detailed Architecture

The following is a detailed description of groundcover's unique BYOC architecture.

Frontend (in grey) will be deployed either in your environment or in groundcover's cloud, depending on chosen setup option (see diagrams above).

groundcover sensors

• eBPF Sensor(DaemonSet) groundcover's eBPF sensor will appear under the name sensor. It is responsible for loading the eBPF program used to collect the data, aggregating the data, and capturing raw data, based on its internal logic.

• db-manager(Deployment) Responsible for managing and updating the ClickHouse database.

• k8s-watcher(Deployment) k8s-watcher is responsible for gathering and clustering all Kubernetes metadata in the current cluster.

• vector(Deployment) Is used for data aggregation and various pipelines such as log and trace transformations.

• groundcover-metrics-ingester(Deployment) metrics-ingester is responsible for the smart aggregation of all metrics reported from the the different sensor instances in the cluster. metrics-ingester controls the final metric cardinality before it's deposited into the time-series database and other mechanisms like series aging, report interval etc.

• groundcover-custom-metrics(Deployment) custom-metrics is responsible for handling collection of custom metrics from your environments. It handles auto-discovery of targets and scraping of static targets.

• groundcover-victoria-metrics-agent(Deployment) vmagent is a tiny agent which helps collect metrics from various sources. It is used for collecting groundcover's internal metrics.
• groundcover-kubestate-metrics(Deployment) kubestate-metrics is an open source service that communicates with the Kubernetes API server and generates metrics about the state of objects. It is not focused on the health of the individual Kubernetes components, but rather on the health of the various objects inside, such as deployments, nodes and pods.

groundcover backend

• groundcover-clickhouse(StatefulSet) The instance for the ClickHouse database.

• groundcover-monitors-manager (StatefulSet) In charge of implementing the functionality of the Monitors. monitors-manager queries the ClickHouse and VictoriaMetrics databases.

• groundcover-opentelemetry-collector(Deployment) The OpenTelemetry Collector offers a vendor-agnostic implementation of how to receive, process and export telemetry data. It is used to receive, convert and retarget all logs collected from the different sensor instances into the persistent storage database.
• groundcover-postgres (StatefulSet) Used by the monitors manager.

• groundcover-victoria-metrics(StatefulSet) The instance for the VictoriaMetrics database.

• portal(Deployment) When groundcover is installed using our inCloud setup, you will see portal running in your environment. It is responsible for connecting your cluster(s) to groundcover's cloud backend, and allows permitted users to access their data.

If you have any questions, let us know in our Slack community.