Overview

groundcover’s proprietary eBPF sensor and unique inCloud infrastructure enable all of your observability data (logs, metrics, traces, etc.) to remain in your environment at all times.

This combination enables the groundcover platform to work in a way that doesn't require sending any of your data outside your environment, tackling two of users' top pain points:

• Cost: groundcover's pricing is totally decoupled from data volume

• Security: no more third-party data exposure risks

Setup options

inCloud

Highly secure, full data privacy

onPrem

Enhanced security and privacy

airGapped

Complete offline isolation.

inCloud

On-premises data storage with a secure online SaaS frontend and authentication, balancing convenience with security.

Your Environment: All your observability backend stays in your environment. Data is automatically imported using our eBPF sensor into the groundcover platform, which is also installed on your premise.

Public Internet: User authentication is performed online using
a secure protocol (Auth0). The user interface is housed
on groundcover’s secure cloud, resulting in a SaaS frontend.

onPrem

Maintains all components on-premises, including the frontend, with only user authentication using an online third-party.

Your Environment: Same backend structure as inCloud, 
with the addition of the user interface also being offline and on your permises.

Public Internet: User authentication is the only step that requires online communication via secure protocols.

airGapped

By keeping all data, backend processes, frontend interaction, and user authentication strictly on-premises and offline, 
it eliminates any exposure to the public internet.

It also creates a robust, isolated environment 
for mission-critical operations where security 
is non-negotiable.

Your Environment: A completely offline setup that keeps the entire flow on your premise.

Public Internet: None.

Key Advantages of our unique architecture

• 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 alligator, 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

Here's a detailed description of groundcover's unique in-cloud architecture:

After deploying groundcover, you will see the following components running in your environment:

• eBPF Sensor (alligator)(DaemonSet) groundcover's eBPF sensor will appear under the name alligator. 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(ReplicaSet) Responsible for managing and updating the ClickHouse database.

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

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

• groundcover-kubestate-metrics(ReplicaSet) 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-monitors-manager In charge of implementing the functionality of the Monitors. monitors-manager queries the ClickHouse and VictoriaMetrics databases.

• groundcover-opentelemetry-collector(ReplicaSet) 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 alligators into the persistent storage database.

• groundcover-postgres Used by the monitors manager.

• groundcover-metrics-ingester(ReplicaSet) metrics-ingester is responsible for the smart aggregation of all metrics reported from the the different alligators 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-victoria-metrics(StatefulSet) The instance for the VictoriaMetrics database.

• groundcover-victoria-metrics-agent(ReplicaSet) vmagent is a tiny agent which helps collect metrics from various sources. It is used for collecting groundcover's internal metrics.

• portal(ReplicaSet) 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.