How much does groundcover cost?

groundcover's unique pricing model is the first to decouple data volumes from cost of owning and operating the solution. For example, subscribing to our Enterprise plan costs $30 per node/host per month.

Overall, the cost of owning and operating groundcover is based on two factors:

• The number of nodes (hosts) you are running in the environment you are monitoring

• The costs of hosting groundcover's backend in your environment

Check out our TCO calculator to simulate your total cost of ownership for groundcover.

Can I use groundcover across multiple clusters?

Definitely. As you deploy groundcover each cluster is automatically assigned the unique name it holds inside your cloud environment. You can browse and select all your clusters at one place with our UI experience.

What K8s flavors are supported?

groundcover has been tested and validated on the most common K8s distributions. See full list in the Requirements section.

What protocols are supported?

groundcover supports the most common protocols in most K8s production environments out-of-the-box. See full list here.

What types of data does groundcover collect?

groundcover's kernel-level eBPF sensor automatically collects your logs, application metrics (such as latency, throughput, error rate and much more), infrastructure metrics (such as deployment updates, container crashes etc.), traces, and Kubernetes events. You can control which data is left out of the automatic collection using data obfuscation.

Where is my data being stored?

groundcover stores all the data it collects inside your environment, using the state-of-the-art storage services of ClickHouse and Victoria Metrics, with the option to offload data to object storage such as S3 for long-term retention. See our Architecture section for more details.

Is my data secure?

groundcover stores the data it collects in-cluster, inside your environment without ever leaving the cluster to be stored anywhere else.

Our SaaS UI experience stores only information related to the account, user access and general K8s metadata used for governance (like the number of nodes per cluster, the name given to the cluster etc.).

All the information served to the UI experience is encrypted all the way to the in-cluster data sources. groundcover has no access to your collected data, which is accessible only to an authenticated user from your organization. groundcover does collect telemetry information (opt-out is of course possible) which includes metrics about the performance of the deployment (e.g. resource consumption metrics) and logs reported from the groundcover components running in the cluster.

All telemetry information is anonymized, and contains no data related to your environment.

Regardless, groundcover is SOC2 and ISO 27001 compliant and follows best practices.

How can I invite my team to my workspace?

If you used your business email to create your groundcover account, you can invite your team to your workspace by clicking on the purple "Invite" button on the upper menu. This will open a pop-up where you can enter the emails of the people you want to invite. You also have an option to copy and share your private link.

Note: The Admin of the account (i.e. the person that created it) can also invite users outside of your email domain. Non-admin users can only invite users that share the same email domain. If you used a private email, you can only share the link to your workspace by clicking the "Share" button on the top bar.

Read more about invites in our installation guide.

Is groundcover open source?

groundcover's CLI tool is currently Open Source along side more projects like Murre and Caretta. We're working on releasing more parts of our solution to Open Source very soon. Stay tuned in our GitHub page!

What operating system (OS) do I need to use groundcover?

groundcover’s sensor uses eBPF, which means it can only deployed on a Kubernetes cluster that is running on a Linux system.

Installing using the CLI command is currently only supported on Linux and Mac.

You can install using the Helm command from any operating system.

Once installed, accessing the groundcover platform is possible from any web browser, on any operating system.

The following architectures are fully supported for all groundcover workloads:

• x86

• ARM

The groundcover platform consolidates all your traces, metrics, logs, and Kubernetes events into a single pane of glass, allowing you to identify issues faster than ever before and conduct granular investigations for quick remediation and long-term prevention.

Our pricing is not impacted by the volume of data generated by the environments you monitor, so you can dare to start monitoring environments that had been blind spots until now - such as your Dev and Staging clusters. This, in turn, provides you visibility into all your environments, making it much more likely to identify issues in the early stages of development, rather than in your live product.

groundcover introduces game-changing concepts to observability:

eBPF sensor

eBPF (extended Berkeley Packet Filter) is a groundbreaking technology that has significantly impacted the Linux kernel, offering a new way to safely and efficiently extend its capabilities.

By powering our sensor with eBPF, groundcover unlocks unprecedented granularity on your cloud environment, while also practically eliminating the need for human involvement in the installation and deployment process. Our unique sensor collects data directly from the Linux kernel with near-zero impact on CPU and memory.

Advantages of our eBPF sensor:

• Zero instrumentation: groundcover's eBPF sensor gathers granular observability data without the need for integrating an SDK or changing your applications' code in any way. This enables all your logs, metrics, traces, and other observability data to flow automatically into the platform. In minutes, you gain full visibility into application and infrastructure health, performance, resource usage, and more.

• Minimal resources footprint: groundcover’s sensor in installed on a dedicated node in each monitored cluster, operating separately from the applications it is monitoring. Without interference with the application's primary functions, the groundcover platform operates with near-zero impact on your resources, maintaining the applications' performance and avoiding unexpected overhead on the infrastructure.

• A new level of insight granularity: With direct access to the Linux kernel, our eBPF sensor enables the collection of data straight from the source. This guarantees that the data is clean, unaltered, and precise. It also offers access to unique insight on your application and infrastructure, such as the ability to view the full traces of payloads, or analyzing network performance over time.

Bring-your-own-cloud (BYOC) architecture

The one-of-a-kind architecture on which groundcover was built eliminates all requirements to stream your logs, metrics, traces, and other monitoring data outside of your environment and into a third-party's cloud. By leveraging integrations with best-of-breed technologies, including ClickHouse and Victoria Metrics, all your observability is stored data locally, with the ability of being fully managed by groundcover.

Advantages of our BYOC architecture:

• By separating the data plane from the control plane, you get the advantages of a SaaS solution, without its security and privacy challenges.

• With multiple deployment models available, you also get to choose the level of security and privacy your organization needs, up to the highest standards (FedRamp-level).

• Automated deployment, maintenance & resource optimization with our inCloud Managed deployment option.

This concept is unique to groundcover, and takes a while to grasp. Read about our BYOC architecture more in detail in this dedicated section.

Disruptive pricing model

Enabled by our unique BYOC architecture, groundcover's vision is to revolutionize the industry by offering a pricing model that is unheard of anywhere else. Our fully transparent pricing model is based only on the number of nodes being monitored, and the costs of hosting the groundcover backend in your environment. Volume of logs, metrics, traces, and all other observability data don’t affect your cost. This results in savings of 60-90% compared to SaaS platforms.

In addition, all our subscription tiers never limit your access to features and capabilities.

Advantages of our nodes-based pricing model:

• Cost is predictable and transparent, becoming an enabler of growth and expansion.

• The ability to deploy groundcover in data-intensive environments enables the monitoring of Dev and Staging clusters, which promotes early identification of issues.

• No cardinality or retention limits

Read our latest customer stories to learn how organization of varying sizes all reduce their observability costs dramatically by migrating to groundcover:

Stream processing

groundcover applies a stream processing approach to collect and control the continuous flow of data to gain immediate insights, detect anomalies, and respond to changing conditions. Unlike batch processing, where data is collected over a period and then analyzed, stream processing analyzes the data as it flows through the system.

Our platform uses a distributed stream processing engine that enables it to ingest huge amounts of data (such as logs, traces and Kubernetes events) in real time. It also processes all that data and instantly generates complex insights (such as metrics and context) based on it.

As a result, the volume of raw data stored dramatically decreases which, in turn, further reduces the overall cost of observability.

Capabilities

Log Management

Designed for high scalability and rapid query performance, enabling quick and efficient log analysis from all your environments. Each log is enriched with actionable context and correlated with relevant metrics and traces, providing a comprehensive view for fast troubleshooting.

Learn more →

Infrastructure Monitoring

The groundcover platform provides cloud-native infrastructure monitoring, enabling automatic collection and real-time monitoring of infrastructure health and efficiency.

Learn more →

Application Performance Monitoring (APM)

Gain end-to-end observability into your applications performance, identify and resolve issues instantly, all with zero code changes.

Learn more →

Real User Monitoring (RUM)

Real User Monitoring (RUM) extends groundcover’s observability platform to the client side, providing visibility into actual user interactions and front-end performance. It tracks key aspects of your web application as experienced by real users, then correlates them with backend metrics, logs, and traces for a full-stack view of your system.

Learn more →

Our traces philosophy

Traces are a powerful observability pillar, providing granular insights into microservice interactions. Traditionally, they were hard to implement, requiring coordination of multiple teams and constant code changes, making this critical aspect very challenging to maintain.

groundcover's eBPF sensor disrupts the famous tradeoff, empowering developers to gain full visibility into their applications, effortlessly and without any code changes.

The platform supports two kinds of traces:

eBPF traces

These traces are automatically generated for every supported service in your stack. They are available out-of-the-box and within seconds of installation. These traces always include critical information such as:

• All services that took part in the interaction (both client and server)

• Accessed resource

• Full payloads, including:

  • All headers

  • All query parameters

  • All bodies - for both the request and response

3rd-party traces

These can be ingested into the platform, allowing to leverage already existing instrumentation to create a single pane of glass for all of your traces.

Traces are stored in groundcover's ClickHouse deployment, ensuring top notch performance on every scale.

Sampling

groundcover further disrupts the customary traces experience by reinventing the concept of sampling. This innovation differs between the different types of traces:

eBPF traces

These are generated by using 100% of the data, always processing every request being made, on every scale. However, the groundcover platform utilizes smart sampling to only store a fraction of the traces, while still generating an accurate picture. In general, sampling is performed according to these rules:

• Requests with unusually high or low latencies, measured per resource

• Requests which returned an error response (e.g 500 status code for HTTP)

• "Normal" requests which form the baseline for each resource

Lastly, stream processing is utilized to make the sampling decisions on the node itself, without having to send or save any redundant traces.

3rd-party traces

These traces are always ingested fully - meaning, no sampling is applied to traces which have been generated elsewhere and ingested by the platform.

Additional Context

Each trace is enriched with additional information to give as much context as possible for the service which generated the trace. This includes:

• Container information - image, environment variables, pod name

• Logs generated by the service around the time of the trace

• Golden Signals of the resource around the time of the trace

• Kubernetes events relevant to the service

• CPU and Memory utilization of the service and the node it is scheduled on

Distributed Tracing

One of the advantages of ingesting 3rd-party traces is the ability to leverage their distributed tracing feature. groundcover natively displays the full trace for ingested traces in the Traces page.

Trace Attributes

Trace Attributes enable advanced filtering and search capabilities. groundcover support attributes across all trace types. This encompasses a diverse range of protocols such as HTTP, MongoDB, PostgreSQL, and others, as well as varied sources including eBPF or manual instrumentations (for example - OpenTelemetry).

groundcover enriches your original traces and generates meaningful metadata as key-value pairs. This metadata includes critical information, such as protocol type, http.path, db.statement, and similar attributes, aligning with OTel conventions. Furthermore, groundcover seamlessly incorporates this metadata from spans received through supported manual instrumentations. For an in-depth understanding of attributes in OTel, please refer to OTel Attributes Documentation (external link to OpenTelemtry website).

Each attribute can be effortlessly integrated into your filters and search queries. You can add them directly from the trace side-panel with a simple click or input them manually into the search bar.

Example: If you want to filter all HTTP traces that contain the path "/products". The query would be formatted as: @http.path:"/products". For a comprehensive guide on the query syntax, see Syntax table below.

Trace Tags

Trace Tags enable advanced filtering and search capabilities. groundcover support tags across all trace types. This encompasses a diverse range of protocols such as HTTP, MongoDB, PostgreSQL, and others, as well as varied sources including eBPF or manual instrumentations (for example - OpenTelemetry).

Tags are powerful metadata components, structured as key-value pairs. They offer insightful information about the resource generating the span, like: container.image.name ,host.name and more.

Tags include metadata enriched by the our sensor and additional metadata if provided by manual instrumentations (such as OpenTelemetry traces) . Utilizing these Tags enhances understanding and context of your traces, allowing for more comprehensive analysis and easier filtering by the relevant information.

Each tag can be effortlessly integrated into your filters and search queries. You can add them directly from the trace side-panel with a simple click or input them manually into the search bar.

Example: If you want to filter all traces from mysql containers - The query would be formatted as: container.image.name:mysql. For a comprehensive guide on the query syntax, see Syntax table below.

Search and filter

The Trace Explorer integrates dynamic filters and a versatile search functionality, to enhance your trace data analysis. You can filter out traces using specific criteria, including trace-status, workload, namespace and more, as well as limit your search to a specific time range.

Learn more about how to use our search syntaxes

Traces Pipelines

groundcover natively supports setting up log pipelines using Vector transforms. This allow for full flexibility in the processing and manipulation of traces being collected - parsing additional patterns by regex, renaming attributes, and many more.

Learn more about how to configure traces pipelines

Controlling retention

groundcover allows full control over the retention of your traces. Read here to learn more.

Custom Configuration

Tracing can be customized in several ways:

• Configuring which protocols should be traced

• Configuring obfuscation for sensitive payload data

• Configuring the sampling mechanism

Overview

The groundcover platform collects data all across your stack using the power of eBPF instrumentation. Our proprietary eBPF sensor is installed
in seconds and provides 100% coverage into application metrics and traces with zero code changes or configurations.

Resolve faster - By seamlessly correlating traces with application metrics, logs, and infrastructure events, groundcover’s APM enables you to detect and resolve root issues faster.

Improve user experience - Optimize your application performance and resource utilization faster than ever before, avoid downtimes and make poor end-user experience a thing of the past.

Collection

Our revolutionary eBPF sensor, Flora, is deployed as a DaemonSet in your Kubernetes cluster. This approach allows us to inspect every packet that each service is sending or receiving, achieving 100% coverage. No sampling rates or relying on statistical luck - all requests and responses are observed.

This approach would not be feasible without a resource-efficient eBPF-powered sensor. eBPF not only extends the ability to pinpoint issues - it does so with much less overhead than any other method. eBPF can be used to analyze traffic originating from every programming language and SDK - even for encrypted connections!

Reconstruction

After being collected by our eBPF code, the traffic is then classified according to its protocol - which is identified directly from the underlying traffic, or the library from which it originated. Connections are reconstructed, and we can generate transactions - HTTP requests and responses, SQL queries and responses etc.

Enrichment

In order to give as much context as possible each transaction is enriched with as much metadata as possible. Some examples might include the pods that took part in this transaction (both client and server), the nodes on which these pods are scheduled, and the state of container at the time of the request.

It is important to emphasize the impressive granularity level with which this process takes place - every single transaction observed is fully enriched. This allows us to perform more advanced aggregations.

Aggregation

After being enriched by as much context as possible, the transactions as grouped together into meaningful aggregations. These could be defined by the workloads involved, the protocols detected and the resources that were accessed in the operations. These aggregations will mostly come into play when displaying golden signals.

Exporting

After collecting the data, contextualizing it and putting it together in meaningful aggregations - we can now create metrics and traces to provide meaningful insights into the services' behaviors.

Metrics

Learn how groundcover's application metrics work:

Traces

Learn how groundcover's application traces work:

Overview

Our Log Management solution is built for high scale and fast query performance so you can analyze logs quickly and effectively from all your cloud environments.

Gain context - Each log data is enriched with actionable context and correlated with relevant metrics and traces in one single view so you can find what you’re looking for and troubleshoot, faster.

Centralize to maximize - The groundcover platform can act as a limitless, centralized log management hub. Your subscription costs are completely unaffected by the amount of logs you choose to store or query. It's entirely up to you to decide.

Collection

Seamless log collection

groundcover ensures a seamless log collection experience with our proprietary eBPF sensor, which automatically collects and aggregates all logs in all formats - including JSON, plain text, NGINX logs, and more. All this without any configuration needed.

This sensor is deployed as a DaemonSet, running a single pod on each node within your Kubernetes cluster. This configuration enables the groundcover platform to automatically collect logs from all of your pods, across all namespaces in your cluster. This means that once you've installed groundcover, no further action is needed on your part for log collection. The logs collected by each sensor instance are then channeled to the OTel Collector.

OTel Collector: A vendor-agnostic way to receive, process and export telemetry data.

Acting as the central processing hub, the OTel Collector is a vendor-agnostic tool that receives logs from various sensor pods. It processes, enriches, and forwards the data into groundcover's ClickHouse database, where all log data from your cluster is securely stored.

Logs Attributes

Logs Attributes enable advanced filtering capabilities and is currently supported for the formats:

• JSON

• Common Log Format (CLF) - like those from NGNIX and Kong

• logfmt

groundcover automatically detects the format of these logs, extracting key:value pairs from the original log records as Attributes.

Each attribute can be added to your filters and search queries.

Example: filtering a log in a supported format with a field of a request path "/status" will look as follows: @request.path:"/status". Syntax can be found here.

Configuration

groundcover offers the flexibility to craft tailored collection filtering rules, you can choose to set up filters and collect only the logs that are essential for your analysis, avoiding unnecessary data noise. For guidance on configuring your filters, explore our Customize Logs Collection section.

You also have the option to define the retention period for your logs in the ClickHouse database. By default, logs are retained for 3 days. To adjust this period to your preferences, visit our Customize Retention section for instructions.

Log Explorer

Once logs are collected and ingested, they are available within the groundcover platform in the Log Explorer, which is designed for quick searches and seamless exploration of your logs data. Using the Log Explorer you can troubleshoot and explore your logs with advanced search capabilities and filters, all within a clear and fast interface.

Search and filter

The Log Explorer integrates dynamic filters and a versatile search functionality that enables you to quickly and easily identify the right data. You can filter out logs by selecting one or multiple criteria, including log-level, workload, namespace and more, and can limit your search to a specific time range.

Learn more about how to use our search syntaxes

Log Pipelines

groundcover natively supports setting up log pipelines using Vector transforms. This allow for full flexibility in the processing and manipulation of logs being collected - parsing additional patterns by regex, renaming attributes, and many more.

Learn more about how to configure log pipelines

Intro

groundcover’s eBPF sensor uses state-of-the-art kernel features to provide full coverage at low overhead. In order to do so it requires certain kernel features which are listed below.

Kernel Version

Version v5.3 or higher (anything since 2020).

Linux Distributions

Permissions

CO:RE support

You can check if your kernel has CO:RE support by manually looking for the BTF file:

If the file exists, congratulations! Your kernel supported CO:RE.

What happens if my kernel is not supported?

Kubernetes version

groundcover supports any K8s version from v1.21.

Kubernetes distributions

Kubernetes RBAC permissions

For the installation to complete successfully, permissions to deploy the following objects are required:

• StatefulSet

• Deployment

• ConfigMap

• Secret

• PVC

Outgoing traffic

groundcover's portal pod sends HTTP requests to the cloud platform app.groundcover.com on port 443.

To ensure a seamless experience with groundcover, it's important to confirm that your environment meets the necessary requirements. Please review the detailed requirements for Kubernetes, our eBPF sensor, and the necessary hardware and resources to guarantee optimal performance.

Kubernetes requirements

groundcover supports a wide range of Kubernetes versions and distributions, including popular platforms like EKS, AKS, and GKE.

Kernel requirements for eBPF sensor

Our state-of-the-art eBPF sensor leverages advanced kernel features to deliver comprehensive monitoring with minimal overhead, requiring specific Linux kernel versions, permissions, and CO:RE support.

Hardware and resource requirements

groundcover fully supports both x86 and ARM processors, ensuring compatibility across diverse environments.

ClickHouse resources

groundcover operates ClickHouse to support many of its core features. This requires suitable resources given to the deployment, which needs to be considered when deploying the platform.

Capture real end-user experiences directly from their browsers and unify these insights with your backend observability data.

Overview

Real User Monitoring (RUM) extends groundcover’s observability platform to the client side, providing visibility into actual user interactions and front-end performance. It tracks key aspects of your web application as experienced by real users, then correlates them with backend metrics, logs, and traces for a full-stack view of your system.

Understand user experience - capture every interaction, page load, and performance metric from the end-user perspective to pinpoint front-end issues in real time.

Resolve issues faster - seamlessly tie front-end events to backend traces and logs in one platform, enabling end-to-end troubleshooting of user journeys.

Privacy first - groundcover’s Bring Your Own Cloud (BYOC) model ensures all RUM data stays in your own cloud environment. Sensitive user data never leaves your infrastructure, ensuring privacy and compliance without sacrificing insight.

Collection

groundcover RUM collects a wide range of data from users’ browsers through a lightweight JavaScript SDK. Once integrated into your web application, the SDK automatically gathers and sends the following telemetry from each user session to the groundcover platform:

• Network requests: Every HTTP request initiated by the browser (such as API calls) is captured as a trace. Each client-side request can be linked with its corresponding server-side trace, giving you a complete picture of the request from the user’s click to the backend response.

• Front-end logs: Client-side log messages (e.g., console.log outputs, warnings, and errors) are collected and forwarded to groundcover’s log management. This ensures that browser logs are stored alongside your application’s server logs for unified analysis.

• Exceptions: Uncaught JavaScript exceptions and errors are automatically captured with full stack traces and contextual data (browser type, URL, etc.). These front-end errors become part groundcover monitors, letting you quickly identify and debug issues in the user’s environment.

• Performance metrics (Core Web Vitals): Key performance indicators like page load time and Core Web Vitals like Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift are measured for each page view. groundcover RUM records these metrics to help you track real-world performance and detect slowdowns affecting users.

• User interactions: RUM tracks user interactions such as clicks, keydown, and navigation events. By recording which elements users interact with and when, groundcover helps you reconstruct user flows and understand the sequence of actions leading up to any issue or performance problem.

• Custom events: You can instrument your application to send custom events via the RUM SDK. This allows you to capture domain-specific actions or business events (for example, a checkout completion or a specific UI gesture) with associated metadata, providing deeper insight into user behavior beyond automatic captures.

All collected data is streamed securely to your groundcover deployment. Because groundcover runs in your environment, RUM data (including potentially sensitive details from user sessions) is stored in the observability backend within your own cloud. From there, it is aggregated and indexed just like other telemetry, ready to be searched and analyzed in the groundcover UI.

Full-Stack Visibility

One of the core advantages of groundcover RUM is its native integration with backend observability data. Every front-end trace, log, or event captured via RUM is contextualized alongside server-side data:

• Trace correlation: Client-side traces (from browser network requests) are automatically correlated with server-side traces captured by groundcover’s eBPF-based instrumentation. This means when a user triggers an API call, you can see the complete distributed trace that spans the browser and the backend services, all in one view.

• Unified logging: Front-end log entries and error reports are ingested into the same backend as your server-side logs. In the groundcover Log Explorer, you can filter and search across logs from both client and server, using common fields (like timestamp, session ID, or trace ID) to connect events.

• End-to-end troubleshooting: With full-stack data in one platform, you can pivot easily between a user’s session replay, the front-end events, and the backend metrics/traces involved. This end-to-end context significantly reduces the time to isolate whether an issue originated in the frontend (browser/UI) or the backend (services/infrastructure), helping teams pinpoint problems faster across the entire stack.

By bridging the gap between the user’s browser and your cloud infrastructure, groundcover’s RUM capability ensures that no part of the user journey is invisible to your monitoring. This holistic view is critical for optimizing user experience and rapidly resolving issues that span multiple layers of your application.

Sessions Explorer

Once RUM data is collected, it becomes available in the groundcover platform via the Sessions Explorer — a dedicated view for inspecting and troubleshooting user sessions. The Sessions Explorer allows you to navigate through user journeys and understand how your users experience your application.

Clicking on any session opens the Session View, where you can inspect a full timeline of the user’s experience. This view shows every key event captured during the session - including clicks, navigations, network requests, logs, custom events, and errors.

Each event is displayed in sequence with full context like timestamps, URLs, and stack traces. The Session View helps you understand exactly what the user did and what the system reported at each step, making it easier to trace issues and user flows.

Supported protocols

Supported encryption libraries and runtimes

groundcover seamlessly supports APM for encrypted communication - as long as it's listed below.

Overview

The groundcover platform offers infrastructure monitoring capabilities that were built for cloud-native environments. It enables you to track the
health and efficiency of your infrastructure instantly, with an effortless deployment process.

Troubleshoot efficiently - acting as a centralized hub for all your infrastructure, application and customer metrics allows you to query, correlate and troubleshoot your cloud environments using real time data and insight on your entire stack.

Collection

groundcover's proprietary eBPF sensor leverages all its innovative powers to collect comprehensive data across your cloud environments without the burden of performance overhead. This data is sourced from various Kubernetes components, including kube-system workloads, cluster information via the Kubernetes API, and the applications' interactions with the Kubernetes infrastructure. This level of detailed collection at the kernel level enables the ability to provide actionable insights into the health of your Kubernetes clusters, which are indispensable for troubleshooting existing issues and taking proactive steps to future-proof your cloud environments.

Configuration

Enrichment

Infrastructure Metrics

Monitoring a cluster involves tracking resources that are critical to the performance and stability of the entire system. Monitoring these essential metrics is crucial for maintaining a healthy Kubernetes cluster:

• CPU consumption: It's essential to track the CPU resources being utilized against the total capacity to prevent workloads from failing due to insufficient CPU availability.

• Memory utilization: Keeping an eye on the remaining memory resources ensures that your cluster doesn't encounter disruptions due to memory shortages.

• Disk space allocation: For Kubernetes clusters running stateful applications or requiring persistent storage for data, such as etcd databases, tracking the available disk space is crucial to avert potential storage deficiencies.

• Network usage: Visualize traffic rates and connections being established and closed on a service-to-service level of granularity, and easily pinpoint cross availability zone communication to investigate misconfigurations and surging costs.

Container CPU and Memory

Available Labels

type

clusterId region namespace node_name workload_name

pod_name container_name container_image

Available Metrics

Node CPU, Memory and Disk

Available Labels

type clusterId region node_name

Available Metrics

PVC Usage

Available Labels

type clusterId region name namespace

Available Metrics

Network Usage

Available Labels

clusterId workload_name namespace container_name remote_service_name remote_namespace remote_is_external availability_zone region remote_availability_zone remote_region is_cross_az protocol role server_port encryption transport_protocol is_loopback

Notes:

• is_loopback and remote_is_external are special labels that indicate the remote service is either the same service as the recording side (loopback) or resides in an external network, e.g managed service outside of the cluster (external).

  • In both cases the remote_service_name and the remote_namespace labels will be empty

• is_cross_az means the traffic was sent and/or received between two different availability zones. This is a helpful flag to quickly identify this special kind of communication.

  • The actual zones are detailed in the availability_zone and remote_availability_zone labels

Available Metrics

ClickHouse is one of the two core databases used by groundcover. It is responsible for logs, traces, events, monitors, dashboards and many more features available in the platform.

As such, it requires suitable resources to operate without issues. The default resources in the groundcover chart were chosen according to both ClickHouse docs (here and here) but also according to our extensive experience of running it in all types of plans and deployments.

The default values for ClickHouse resources are:

resources:
  requests:
    cpu: 2
    memory: 4Gi
  limits:
    memory: 8Gi

Before installing groundcover, please make sure your cluster meets the requirements.

Sign up to groundcover

The first thing you need to do to start using groundcover is sign up using your email address (no credit card required for the free tier account). Signing up is only possible using a computer and will not be possible using a mobile phone or tablet. It is highly recommended you use your corporate email address, as it will make it easier to use other features such as inviting your colleagues to your workspace. However, signing up using Gmail, Outlook or any other public domains is also possible.

After signing up, you can install groundcover using any one of these methods:

Installing using our UI

When signing in to groundcover for the first time, the platform automatically detects your organization based on the domain you used to sign in. If your organization already has existing workspaces available, the workspace selection screen will be displayed, where you can choose which of the existing workspaces you would like to join, or if you want to create a new workspace.

Available workspaces will be displayed only if either of the following applies:

• You have been invited to join existing workspaces and haven't joined them yet

• Someone has previously created a workspace that has auto-join enabled for the email domain that you used to sign in (applicable for corporate email domains only)

To join an existing workspace:

1. Click the Join button next to the desired workspace

2. You will be added as a user to that workspace with the user privileges that were assigned by default or those that were assigned to you specifically when the invite was sent.

3. You will automatically be redirected to that workspace.

To create a new workspace:

1. Click the Create a new workspace button

2. Specify a workspace name

3. Choose whether to enable auto-join (those settings can be changed later)

4. Click continue

1. Copy the command line displayed on the screen using the Copy Command button (Note: This is not your API key)

2. Open your CLI

3. Paste the command line in your CLI (Note: Make sure your kubectl context is pointing to the desired cluster)

1. The installation screen will open automatically and will let you know on-screen when the installation has completed.

Within 10 minutes after installation completes, all of your cluster's data will appear in your workspace.

Enabling Auto-join for a new or existing Workspace

Workspace owners and admins can allow teammates that log in with the same email domain as them to join the Workspace they created automatically, without an admin approval. This capability is called "Auto-join". It is disabled by default, but can be switched on during the workspace set up process, or any time in the workspace settings.

Installing using a CLI

Use groundcover CLI to automate the installation process. The main advantages of using this installation method are:

• Auto-detection of cluster incompatibility issues

• Tolerations setup automation

• Tuning of resources according to cluster size

• It supports passing helm overrides

• Automated detection of new versions and upgrades suggestions

Read more here.

Installing groundcover CLI

sh -c "$(curl -fsSL https://groundcover.com/install.sh)"

SET CLI_VERSION=0.22.3
SET ARCH=amd64 # [amd64,arm64]
curl -sSL https://github.com/groundcover-com/cli/releases/download/v%CLI_VERSION%/groundcover_%CLI_VERSION%_windows_%ARCH%.tar.gz -o groundcover.tar.gz
tar -xvf groundcover.tar.gz -C C:\Windows

Deploying groundcover using the CLI

groundcover deploy

------
# If you need to provide configuration values from a values.yaml file:
groundcover deploy -f values.yaml

Installing using Helm

groundcover can be installed using the official helm chart.

If you’re interested in installing the helm chart using a CI/CD solution, such as ArgoCD, make sure you read our CI/CD installation section as well.

# Make sure you have groundcover CLI installed

# (1) Login to your groundcover account
groundcover auth login

# (2) Fetch your api key
groundcover auth print-api-key

# (3) Make sure groundcover Helm repoistory is present (once)
helm repo add groundcover https://helm.groundcover.com

# (4) Update groundcover Helm repository to fetch latest charts
helm repo update groundcover

# (5) Deploy groundcover release
helm upgrade \
    groundcover \
    groundcover/groundcover \
    -i \
    --create-namespace \
    -n groundcover \
    --set global.groundcover_token={api-key},clusterId={cluster-name}
    
------

# If you need to provide configuration values from a values.yaml file:
# (5*) Deploy groundcover release
helm upgrade \
    groundcover \
    groundcover/groundcover \
    -i \
    --create-namespace \
    -n groundcover \
    --set global.groundcover_token={api-key},clusterId={cluster-name} \
    --values values.yaml

What can you do next?

• Set up your first alert

• Set up your first dashboard

• Invite your colleagues

• Installing groundcover on additional clusters

Adding more clusters

groundcover can monitor multiple clusters, and new clusters can be added at any given time. You can add new clusters using the UI.

Click on the cluster picker in the top right corner and then on the + Add Cluster option.

Updating groundcover

To update the groundcover agent to the latest version:

Using CLI

groundcover deploy

------
# If you need to provide configuration values from a values.yaml file:
groundcover deploy -f values.yaml

Using Helm

# Make sure you have groundcover CLI installed

# (1) Login to your groundcover account
groundcover auth login

# (2) Fetch your api key
groundcover auth print-api-key

# (3) Make sure groundcover Helm repoistory is present (once)
helm repo add groundcover https://helm.groundcover.com

# (4) Update groundcover Helm repository to fetch latest charts
helm repo update groundcover

# (5) Deploy groundcover release
helm upgrade \
    groundcover \
    groundcover/groundcover \
    -i \
    --create-namespace \
    -n groundcover \
    --set global.groundcover_token={api-key},clusterId={cluster-name}
    
------

# If you need to provide configuration values from a values.yaml file:
# (5*) Deploy groundcover release
helm upgrade \
    groundcover \
    groundcover/groundcover \
    -i \
    --create-namespace \
    -n groundcover \
    --set global.groundcover_token={api-key},clusterId={cluster-name} \
    --values values.yaml

Uninstalling

groundcover delete

helm uninstall groundcover -n groundcover

# delete the namespace in order to remove the PVCs as well
kubectl delete ns groundcover

Learn how to create and configure monitors using the Wizard, Monitor Catalog, or Import options. The following guide will help you set up queries, thresholds, and alert routing for effective monitoring.

In the Monitors section (left navigation bar), navigate to the Issues page or the Monitor List page to create a new Monitor. Click on the blue “Create Monitor” button and select one of the following options from the dropdown:

Using the Monitor Wizard

Overview

The Monitor Wizard is a guided, user-friendly approach to creating and configuring monitors tailored to your observability needs. By breaking down the process into simple steps, it ensures consistency and accuracy.

Section 1: Information

Set up the basic information for the monitor.

Monitor Title (Required):

Add a title for the monitor. The title will appear in notifications and in the Monitor List page.

Description (Optional):

Add description for your monitor, The description will appear when viewing monitor details, you can also use this for your alerts.

Section 2: Query

Select the data source, build the query and define thresholds for the monitor.

• Data Source (Required):

  • Select the type of data (Metrics, Infra Metrics, Logs, or Traces).

• Query Functionality:

  • Choose how to process the data (e.g., average, count).

  • Add group-by clauses if applicable.

• Time Window (Required):

  • Specify the period over which data is aggregated.

  • Example: “Over the last 5 minutes.”

• Threshold Conditions (Required):

  • Define when the monitor triggers. You can use:

    • Greater Than - Trigger when the value exceeds X.

    • Lower Than - Trigger when the value falls below X.

    • Within Range - Trigger when the value is between X and Y.

    • Outside Range - Trigger when the value is not between X and Y.

  • Example: “Trigger if disk space usage is greater than 10%.”

• Visualization Type (Optional):

  • Preview data using Stacked Bar or Line Chart for better clarity. This is just for helping visualize while building the monitor.

Section 3: Display

Customize how the Monitor’s Issues will appear. This section also includes a live preview of the way it will appear in the Issues page.

Issue Header (required):

Define a name for issues that this Monitor will raise. It's useful to use labels that can include information from the query.

For example, adding {{ alert.labels.statusCode }} to the header will inject the status code to the name of the issue - this becomes especially useful when one Monitor raises multiple issues and you want to quickly understand their content without having to open each one.

Severity (required):

Use severity to categorize alerts by importance.

Select a severity level (S1-S4).

Resource Labels (optional):

The labels here should give you team the context of what is the subject of the issue.

Examples:

• span_name for an API based monitor

• pod_name for a Pod Crash monitor

Context Labels (optional):

The labels here should give you team the context of where the issue happened.

• Examples:

  • cluster

  • namespace

Section 4: Metadata Labels

Organize and categorize monitors, you can use these to route issues using advanced workflows.

• Labels (optional):

  • Add key-value pairs for metadata.

Section 5: Evaluation Settings

Define how often the monitor evaluates its conditions.

Evaluation Interval (Required):

Specify how often the monitor evalutes the query

Example: “Evaluate every 1 minute.”

Pending Period (Required):

This ensures that transient conditions do not trigger alerts, reducing false positives. For example, setting this to 10 minutes ensures the condition must persist for at least 10 minutes before firing.

Example: “Wait for 10 minute before alerting.t

Section 6: Routing

Set up how issues from this monitor will be routed.

Select Workflow (Optional):

Route alerts to existing workflows only, this means that other workflows will not process them. Use this to send alerts for a critical application to Slack or PagerDuty.

No Routing (Optional):

This means that any workflow (without filters), will process the issue.

Quick tips to create effective Monitors

Use the Monitor Catalog as much as you can

Whenever possible, use our carefully crafted monitors from the Monitor Catalog. This will save you time, ensure the Monitors are built effectively, and help you align your alerting strategy with best practices. If you can't find one that perfectly matches your needs, use them as your starting point and edit their properties to customize them to your needs.

Give the Monitor a short and clear title

Give the Monitor a clear, short name, that describes its function at a high level.

Examples:

• “Workload High API Error Rate”

• “Workload Pods High Memory”

Use a Descriptive Issue Header

Choose a clear name for the Issue header, offering a bit more details and going into a more specific description of the monitor name. A Header is a specific property of an issue, so you can add templated dynamic values here. For example, you can use dynamic label values in the header name.

Examples:

• “HTTP API Error {{ alert.labels.status_code }}”,

• “Workload {{ alert.labels.workload }} Pod Restart”

• “{{ alert.labels.customer }} APIs High Latency”.

Use up to 3 Resource Labels

We recommend using up to 3 ResourceHeaderLabels. The labels here should give your team the context of what is the subject of the issue.

Examples:

span_name , pod_name

Use up to 3 Context Labels

We recommend using up to 3 ContextHeaderLabels. The labels here should give you team the context of where the issue happened.

Examples:

cluster, namespace , workload

Using the Import option

Here you can add multiple Monitors using an array of Monitors that follows the Monitor YAML structure.

monitors:
- title: HTTP API Errors Monitor
  ...
- title: K8s Node Low Disk Space Monitor
  ...

Click on "Create Monitors" to create them.

Our metrics philosophy

The groundcover platform generates 100% of its metrics from the actual data. There are no sample rates or complex interpolations to make up for partial coverage. Our measurements represent the real, complete flow of data in your environment.

Stream processing allows us to construct the majority of the metrics on the very node where the raw transactions are recorded. This means the raw data is turned into numbers the moment it becomes possible - removing the need for storing or sending it elsewhere.

Metrics are stored in groundcover's victoria-metrics deployment, ensuring top-notch performance on every scale.

Golden signals

In the world of excessive data, it's important to have a rule of thumb for knowing where to start looking. For application metrics, we rely on our golden signals.

The following metrics are generated for each resource being aggregated:

• Requests per second (RPS)

• Errors rate

• Latencies (p50 and p95)

The golden signals are then displayed in two important ways: Workload and Resource aggregations.

Resource aggregations are highly granularity metrics, providing insights into individual APIs.

Workload aggregations are designed to show an overview of each service, enabling a higher level inspection. These are constructed using all of the resources recorded for each service.

Controlling retention

groundcover allows full control over the retention of your metrics. Learn more here.

List of available metrics

Below you will find the full list of our APM metrics, as well as the labels we export for each. These labels are designed with high granularity in mind for maximal insight depth. All of the metrics listed are available out of the box after installing groundcover, without any further setup.

Our labels

Golden Signals Metrics

Resource metrics

Workload metrics

Storage usage metrics

Kafka specific metrics

Supported Environments

Supported architectures: AMD64 + ARM64

For the following providers, we will fetch the machine metadata from the provider's API.

Sensor capabilities

• Infrastructure Host metrics: CPU/Memory/Disk usage

• Logs

  • Natively from docker containers running on the machine

  • JournalD (requires configuration)

  • Static log files on the machine (requires configuration)

• Traces

  • Natively from docker containers running on the machine

• APM metrics and insights from the traces

How to install?

Installation currently requires running a script on the machine.

The script will pull the latest sensor version and install it as a service: groundcover-sensor (requires privileges)

Install/Upgrade existing sensor:

Where:

• {apiKey} - Your unique backend token, you can get it using groundcover auth print-api-key

• {inCloud_Site} - Your backend ingress address (Your inCloud public ingestion endpoint)

• {selected_Env} - The Environment that will group those machines on the cluster drop down in the top right corner (We recommend setting a separate one for non k8s deployments)

Remove installed sensor:

Customize sensor configuration:

The sensor supports overriding its default configuration (similarly to the Kubernetes sensor), only in this case it's required to write the overrides to a file on disk.

The file is located in /etc/opt/groundcover/overrides.yaml, after writing it you should restart the sensor service using systemctl restart groundcover-sensor

Example - override Docker max log line size:

Once installed, we recommend following these steps to help you quickly gain the most our of groundcover's unique observability platform.

1. Get a complete view of your workloads

The "Home page" of the groundcover app is our Workloads page. From here, you can get a- service-centric view,

2. Check out full payloads of traces

3. Build a native dashboard

4. Set up a Monitor

5. Invite your team

Invites lets you share your workspaces with your colleagues in just a couple of clicks. You can find the "Invite Members" option at the bottom of the left navigation bar. Type in the email addresses of the teammates you want to invite, and set their user permissions (Admin, Editor, Read Only), then click "Send Invites".

groundcover’s Real User Monitoring (RUM) SDK allows you to capture front-end performance data, user events, and errors from your web applications.

This guide will walk you through installing the SDK, initializing it, identifying users, sending custom events, capturing exceptions, and configuring optional settings.

Install the SDK

Initialize the SDK

At your app’s entry point:

Identify Users

Link RUM data to specific users:

Send Custom Events

Instrument key user interactions:

Capture Exceptions

Manually track caught errors:

Optional Configuration

You can customize SDK behavior (event sampling, data masking, enabled events). The following properties are customizable:

You can pass the values by calling the init function:

Or via the updateConfig function:

Overview

The Monitor Catalog is a library of pre-built templates to efficiently create new Monitors. Browse and select one or more Monitors to quickly configure their environment with a single click. The Catalog groups monitors into "Packs", based on different use cases.

Key Features

Batch Monitor Creation

You can select as many monitors as you wish, and add them all in one click. Select a complete pack or multiple Monitors from different packs, then click "Create Monitor". All Monitors will be automatically created. You can always edit them later.

Single Monitor Creation

The Issues page provides a detailed view of active and resolved issues triggered by Monitors. This page helps users investigate, analyze, and resolve problems in their environment by visualizing issue trends and providing in-depth context through an issue drawer.

Issues drawer

Clicking on an issue in the Issues List opens the Issue drawer, which provides an in-depth view of the Monitor and its triggered issue. You can also navigate if possible to related entities like workload, node, pod, etc.

Details tab

Displays metadata about the issue, including:

• Monitor Name: Name of the Monitor responsible for the issue, including a link to it.

• Description: Explains what the Monitor tracks and why it triggered.

• Severity: Shows the assigned severity level (e.g., S3).

• Labels: Lists contextual labels like cluster, namespace, and workload.

• Creation Time: Shows when the issue started firing.

Events tab

Displays the Kubernetes events related to the selected issue within the timeframe selected in the Time Picker dropdown (upper right of the issue drawer).

Traces tab

When creating a Monitor using a traces query, the Traces tab will display the matching traces generated within the timeframe selected in the Time Picker dropdown (upper right of the issue drawer). Click on "View in Traces" to navigate to the Traces section with all relevant filter automatically applied.

Logs tab

When creating a monitor using a log query, the Logs tab will display the matching logs generated within the timeframe selected in the Time Picker dropdown (upper right of the issue drawer). Click on "View in Logs" to navigate to the Logs section with all relevant filter automatically applied.

Map tab

A focused visualization of the interactions between workloads related to the selected issue.

Overview

The Silences page lists all Silences you and your team created for your Monitors. In this section, you can also create and manage your Silence rules, to suppress notifications and Issues noise, for a specified period of time. Silences are a great way to reduce alert fatigue, which can lead to missing important issues, and help focus on the most critical issues during specific operational scenarios such as scheduled maintenances.

Create a new Silence

Follow these simple steps to create a new Silence.

Section 1: Schedule

Specify the timeframe for the silence rule. Note that the starting point doesn't have to be now, and can also be any time in the future.

Below the From / Until boxes, you'll see a Silence summary, showing its approximate length (rounded down to full days) and starting date.

Section 2: Matchers

Define the criteria for Monitors or Issues to be silenced.

1. Click Add Matcher to specify match conditions (e.g., cluster, namespace, span_name).

2. Combine multiple matchers for more granular control.

Example: Silence all Monitors in the "demo" namespace.

Section 3 - Affected Active Issues

Preview the issues currently affected by the Silence rule, based on any defined Matchers. This list contains only actively firing Issues.

Tip: Us this preview to see the list of impacted issues and adjust your Matchers before finishing to create the Silence.

Section 4: Comment

Add notes or context for the Silence rule. These comments help you and other users understand the purpose of the rule.

The following guides will help you setup and import your alerts from Grafana:

Monitor fields explained

In this section, you'll find a breakdown of the key fields used to define and configure Monitors within the groundcover platform. Each field plays a critical role in how a Monitor behaves, what data it tracks, and how it responds to specific conditions. Understanding these fields will help you set up effective Monitors to track performance, detect issues, and provide timely alerts.

Below is a detailed explanation of each field, along with examples to illustrate their usage, ensuring your team can manage and respond to incidents efficiently.

Monitor YAML Examples

Traces Based Monitors

MySQL Query Errors Monitor

gRPC API Errors Monitor

Log Based Monitors

High Error Log Rate Monitor

The Monitor List is the central hub for managing and monitoring all active and configured Monitors. It provides a clear, filterable table view of your Monitors, with their current status and key details, such as creation date, severity, and live issues. Use this page to review Monitor performance, identify issues, and take appropriate action.

Key Features

Monitors Table

• Displays the following columns:

  • Name: Title of the monitor.

  • Creation Date: When the monitor was created.

  • Live Issues: Number of live issues currently firing.

  • Status: Is the Monitor "Firing" (alerts active) or "Normal" (no alerts).

• Tip: Click on a Monitor name to view its detailed configuration and performance metrics.

Create Monitor

Filters Panel

Use filters to narrow down monitors by:

• Severity: S1, S2, S3, or custom severity levels.

• Status: Alerting or Normal.

• Silenced: Exclude silenced monitors.

Tip: Toggle multiple filters to refine your view.

Search Bar

Quickly locate monitors by typing a name, status, category, or other keywords.

Cluster and Environment Filters

Located at the top-right corner, use these to focus on monitors for specific clusters or environments.

groundcover enables access to an embedded Grafana, within the groundcover platform's interface. This enables you to easily import and continue using your existing Grafana dashboards and alerts.

The following guides will help you setup and import your visualizations from Grafana:

Slack Webhook Message on Specific Monitor

This workflow is triggered by issue with filter of alertname: Workload Pods Crashed Monitor . Which means only issues created by the monitor named "Workload Pods Crashed Monitor" will trigger the workflow, in this example we use a slack message action using labels from the issue.

workflow: 
  id: slack-alert-on-crashed-pods
  description: Send a slack message on Workload Pods Crashed Monitor 
  triggers:
    - type: alert
      filters:
        - key: alertname
          value: Workload Pods Crashed Monitor
  actions:
    - name: trigger-slack
      provider:
        type: slack
        config: '{{ providers.slack_webhook }}'
        with:
          message: "Pod Crashed - Pod: {{ alert.labels.pod_name }} Container: {{ alert.labels.container }} Exit Code: {{ alert.labels.exit_code }} Reason: {{ alert.labels.reason }}"

Send Only Firing Alerts

In some cases, you may want to avoid sending resolved alerts to your integrations—this prevents incidents from being automatically marked as “resolved” in tools like PagerDuty.

To achieve this, you can add a condition to your action that ensures only firing alerts are sent. Here’s an example of how to configure it in your workflow:

workflow:
  id: send-pagerduty-only-firing
  description: ""
  triggers:
  - type: alert
  name: send-pagerduty-only-firing
  actions:
  - if: '{{ alert.status }} == "firing"'
    name: pagerduty-action
    provider:
      config: "{{ provider.pager_duty_prod }}"
      type: pagerduty
      with:
        title: "{{ alert.alertname }}"

This configuration uses an if condition to check that the alert’s status is firing before executing the PagerDuty action - line 8.

Slack Webhook Message on Issue

This workflow is triggered by an issue and uses the slack_webhook integration to send a Slack message formatted with Block Kit. For more details, see Slack Block Kit.

workflow: 
  id: slack-webhook
  description: Send a slack message on alerts
  triggers:
    - type: alert
  actions:
    - name: trigger-slack
      provider:
        type: slack
        config: ' {{ providers.slack_webhook }} '
        with:
          blocks:
          - type: header
            text:
              type: plain_text
              text: ':rotating_light: {{ alert.labels.alertname }} :rotating_light:'
              emoji: true
          - type: divider
          - type: section
            fields:
            - type: mrkdwn
              text: |-
                *Cluster:*
                {{ alert.labels.cluster}}
            - type: mrkdwn
              text: |-
                *Namespace:*
                {{ alert.labels.namespace}}
            - type: mrkdwn
              text: |-
                *Workload:*
                {{ alert.labels.workload}}

Create Jira Ticket Using Webhook

See Jira Webhook Integration for setting up the integration

Get your Issue Type ID from your Jira, see: https://confluence.atlassian.com/jirasoftwarecloud/finding-the-issue-type-id-in-jira-cloud-1333825937.html

Get your project id from you Jira, see: https://confluence.atlassian.com/jirakb/how-to-get-project-id-from-the-jira-user-interface-827341414.html

Replace in this workflow these by using your values: <issue_id>, <project_id>

Replace in this workflow <integration_name> based on your created integration name.

workflow:
  id: jira_ticket_creation
  description: Create a Jira Ticket
  triggers:
  - type: alert
  consts:
    description: keep.dictget( {{ alert.annotations }}, "_gc_description", '')
    title: keep.dictget( {{ alert.annotations }}, "_gc_issue_header", "{{ alert.alertname }}")
  name: jira_ticket_creation
  actions:
  - name: webhook
    provider:
      config: ' {{ providers.<integration_name> }} '
      type: webhook
      with:
        body:
          fields:
            description: '{{ consts.description }}'
            issuetype:
              id: <issue_id>
            project:
              id: <project_id>
            summary: '{{ consts.title }}'

groundcover inCloud Managed supports integration with customer owned Grafana by exposing Prometheus and ClickHouse data sources.

Requirements

Datasources api-key

The groundcover tenant API KEY is required for configuring the data source connection.

The key can be obtained by running: groundcover auth get-datasources-api-key

For this example we will use the key API-KEY-VALUE

Setup

Prometheus

Configure Grafana prometheus Data Source by following these steps logged in as Grafana Admin.

1. Connections > Data Sources > + Add new data source

2. Pick Prometheus

   1. Name: groundcover-prometheus

   2. Prometheus server URL: https://ds.groundcover.com/datasources/prometheus

   3. Customer HTTP Headers > Add Header

      1. Header: apikey

      2. Value: API-KEY-VALUE

   4. Performance

      1. Prometheus type: Prometheus

      2. Prometheus version: > 2.50.x

3. Click "Save & test"

ClickHouse

Configure Grafana ClickHouse Data Source by following these steps logged in as Grafana Admin.

1. Connections > Data Sources > + Add new data source

2. Pick ClickHouse

   1. Name: groundcover-clickhouse

   2. Server

      1. Server address: ds.groundcover.com

      2. Server port: 443

      3. Protocol: HTTP

      4. Secure Connection: ON

   3. HTTP Headers

      1. Forward Grafana HTTP Headers: ON

   4. Credentials

      1. Username: Leave empty

      2. Password: API-KEY-VALUE

   5. Additional Properties

      1. Default database: groundcover

3. Click "Save & test"

Workflows are YAML-based configurations designed to automate the response and add context to your issues. Each workflow consists of triggers, steps, and actions, which define when and how a workflow is executed and what tasks are performed.

Workflow components

Triggers

After uploading your workflow, it can be executed based on the trigger type. Currently groundcover supports triggering workflows based on issues only.

Issues Trigger

Automatically activates a workflow when an issues is identified by a monitoring source. You can filter issues based on their source or other attributes.

Steps

Define a series of data-fetching or computation tasks that help enrich the workflow. Steps are optional but can be useful for adding context to your issues.

steps:
  - name: fetch-data
    action: http_request
    url: "<https://api.example.com/data>"

Actions

Actions specify what happens when a workflow is triggered. Actions can include notifications, data enrichment, or automation tasks. In groundcover, actions typically interface with external systems (like sending a Slack message).

actions:
  - type: notify
    provider: slack
    message: "An issues has been triggered!"

A dashboard is a great tool for visually tracking, analyzing, and displaying key performance metrics, which enable you to monitor the health of your infrastructure and applications.

Creating a new dashboard

1️⃣ Go to the Dashboards tab in the groundcover app, and click New and then New Dashboard.

2️⃣ Create your first panel by clicking Add a new panel.

3️⃣ In the New panel view, go to the Query tab.

4️⃣ Choose your data source by pressing the -- Grafana -- on the data source selector. You would see your the metrics collected from each of your clusters an a Prometheus data source called Prometheus@<cluster-name>

5️⃣ Create your first Query in the PromQL query interface.

groundcover’s dashboards are designed to personalize your data visualization and maximize the value of your existing data. Dashboards are perfect for creating investigation flows for critical monitors, displaying the data you care about in a way that suits you and your team, and crafting insights from the data on groundcover.

Easily create a new Dashboard using our guide.

Key Features

• Multi-Mode Query Bar: The Query Bar is central to dashboards and supports multiple modes fully integrated with native pages and Monitors. Currently, the modes include Metrics, Infra Metrics, Logs, and Traces. Learn more in the Query Builder section.

• Variables: Built-in variables allow you to filter data quickly based on a predefined list crafted by groundcover.

• Widget Types: Two widget types are currently supported:

  • Chart Widget: Displays data visually.

  • Textual Widget: Adds context to your dashboards.

• Display Types: Five display types are supported for data visualization:

  • Time Series, Table, Stat, Top List, and Pie. Read more in the Widget Types section.

Alerts in groundcover leverage a fully integrated Grafana interface. To learn how you can create alerts using Grafana Terraform, follow this guide.

Setup an alert based on metrics

Step 1: Access the Alerts section

1. Log in to groundcover and navigate to the Alerts section by clicking on it on the left navigation menu.

2. Once in the Alerts section, click on Alerting in the inner menu on the left.

   • If you can't see the inner menu, click on the 3 bars next to "Home" in the upper left corner.

3. Click on Alert Rules

4. Then click on the blue "+ New alert rule" button in the upper right.

Step 2: Give the alert a name and define query and conditions

1. Type a name for your alert. It's recommended to use a name that will make it easy for you to understand its function later.

2. Select the data source:

   1. ClickHouse: For alerts based on your traces, logs, and Kubernetes events.

   2. Prometheus: For alerts based on metrics (includes APM metrics, infrastructure metrics, and custom metrics from your environment)

3. Click on "Select metric"

   • Note: Make sure you are in "Builder" view (see screenshot) to see this option.

4. Click on "Metrics explorer"

5. Start typing the name of the metric you want this alert to be based on. Note that the Metrics explorer will start displaying matches as you type, so you can find your metric even if you don't remember it exact name. You can also check out our list of Metrics & Labels.

6. Once you see your metric in the list, click on "Select" in that row.

Note: You can click on "Run queries" to see the results of this query.

Step 3: Define expressions - Reduce & Threshold

1. In the Reduce section, open on the "Function" dropdown menu and choose the type of value you want to use.

   • Min - the lowest value

   • Max - the highest value

   • Mean - the average of the values

   • Sum - the sum of all values

   • Count - the number of values in the result

   • Last - the last value

2. In the Threshold section, type a value and choose whether you want the alert to fire when the query result is above or below that value. You can also select a range of values.

Step 4: Set evaluation behavior

1. Click on "+ New folder" and type a name for the folder in which this rule will be stored. You can choose any name, but it's recommended to use a name that will make it easy for you to find the relevant evaluation groups, should you want to use them again in future alerts.

2. Click on "+ New evaluation group" and type a name for this evaluation group. The same recommendation applies here too.

   In the Evaluation interval textbox, type how often the rule should be evaluated to see if it matches the conditions set in Step 3. Then, click "Create". Note: For the Evaluation interval, use the format (number)(unit), where units are:

   • s = seconds

   • m = minutes

   • h = hours

   • d = days

   • w = weeks

3. In the Pending period box, type how often you want the alert to match the conditions before it fires.

Step 5: Choose contact point

If you already have a contact point set up, simply select it from the dropdown menu at the bottom of the "Configure lables and notifications" section. If not, click on the blue "View or create contact points" link, which will open a new tab.

Click on the blue "Add contact point" button

This will get you to the Contact points screen. Then:

1. Type a name for the contact point

2. From the dropdown menu, choose which system you want to use to push the alert to.

3. The information required to push the alert will change based on the system you select. Follow on-screen instructions (for example, if email is selected, you'll need to enter the email address(es) for that contact.

4. Click "Save contact point"

You can now close this tab to go back to the alert rule screen.

Next to the link you clicked to create this new contact point, you'll find a dropdown menu, where you can select the contact point you just created.

Step 6: Add annotations

Under "Add annotations", you have two free text boxes that give you the option to add any information that can be useful to you and/or the recipient(s) of this alert, such as a summary that reminds you of the alert's functionality or purpose, or next step instructions when this alert fires.

Step 7: Save and exit

Once all of it is ready, you can click the blue "Save rule and exit" button on the upper right of the screen, which will bring you back to the Alert rules screen. You will now be able to see your alert, as well as its status - normal (green), pending (yellow), or firing (red), as well as the Evaluation interval (blue).

Configuring Alert from existing dashboard:

1. Log in to your groundcover account and navigate to the dashboard that you want to create an alert from.

2. Locate the Grafana panel that you want to create an alert from and click on the panel's header and select edit .

3. Click on the alert tab as seen in the image below. Select the Manage alerts option from the dropdown menu.

4. Click on the New Alert Rule button.

1. An alert is derived from three parts that will be configured in the screen that you are navigated to:

   • Expression - the query that defines the alert input itself,

   • Reduction - the value that should be leveraged from the aforementioned expression

   • Threshold - value to measure against said reduciton output to see if an alert should be triggered

2. Verify expression value and enter reduction and threshold values in line with your alerting expectation

1. Select folder - if needed you can navigate to dashboard tab in left nav and create new folder

2. Select evaluation ground or type text in order to create a new group as shown below

1. Click "Save and Exit" on top right hand side of screen to create alert

2. Ensure your notification is configured to have alerts sent to end users. See "Configuring Slack Contact Point" section below if needed.

Modes Overview

1. Metrics – Work with all your available metrics. Great for advanced use cases and custom metrics.

2. Infra Metrics – Use expert-built, predefined queries for common infrastructure scenarios. Ideal if you’re not sure which metric to pick or just want a quick start.

3. Logs – Query and visualize Logs data.

4. Traces – Query and visualize Traces, similar to logs.

5. RUM - Query and visualizer RUM Events.

Metrics/Infra Metrics

When you select the Metrics or Infra Metrics modes, you’ll work with something akin to Prometheus queries - but simplified.

groundcover supports a wide variety of metrics - Application and Infrastructure metrics are automatically generated using our eBPF sensor, and custom metrics can be ingested natively.

Metric Selector:

• Search and choose a metric.

• View associated labels and metadata (for groundcover’s built-in metrics).

• If the chosen built-in metric’s type is known, the Query Builder automatically applies the best-suited function to streamline your workflow.

Infra Metrics Mode:

• Select from ready-made queries grouped into categories (e.g., Container CPU, Node Disk).

• Perfect if you’re unsure which metric to choose. Just pick a category, and you’re set.

Filters Bar (Metrics/Infra Metrics):

• Filter by label key/value pairs.

• Use - to exclude values

• All filters are ANDed together, but multiple values for the same key form an OR condition.

• Type a key and : (e.g cluster:) to list its values.

• Use patterns (wildcards, partial matches) to refine results.

Aggregation Function Selector:

• sum: Adds up all values.

• avg: Calculates the average value.

• max: Finds the maximum value.

• min: Finds the minimum value.

• count: Counts how many data points there are.

• no aggregation: Leaves data un-aggregated.