March 2025 Summaries

Groundcover has entered frontend observability with its Real User Monitoring (RUM) capability, expanding its Bring Your Own Cloud (BYOC) deployment model to include eBPF and BYOC on the client side. This allows for complete privacy of user data, leveraging groundcover's unique backend observability capabilities in a single platform with frontend observability, facilitating end-to-end correlation and visibility over the entire experience. Frontend teams can now benefit from real-time performance insights, improved user experience and engagement, faster debugging and issue resolution, by monitoring real user behavior and correlating it with backend telemetry. The RUM capability is built into a lightweight custom SDK that seamlessly integrates into existing groundcover backends, collecting detailed data on navigation events, user interactions, custom events, frontend errors and exceptions, and comprehensive session context. This unified view of frontend user experiences alongside backend metrics, logs, and traces accelerates troubleshooting and improves user satisfaction.

At groundcover, security and observability are deeply intertwined. The company has built its sensor with eBPF at its core and uses a unique BYOC deployment model to ensure secure data ingestion and storage. To address this, groundcover is introducing Role-Based Access Control (RBAC), which provides granular control over user access to observability data. This feature allows organizations to define fine-grained access policies, enforce data limitations, seamlessly integrate with Single Sign-On (SSO) solutions, limit access to only necessary data, and ensure real-time policy enforcement. With RBAC, administrators can create custom access policies directly within the groundcover UI, giving them total control over how observability data is accessed across their organization. The system also integrates with SSO providers like Okta, Azure AD, and Google Workspace, ensuring seamless access management for large enterprises.

Groundcover has introduced One-Click Kubernetes Dashboards, powered by eBPF technology, to simplify observability and troubleshooting for engineering teams. These dashboards provide instant, context-rich insights into Kubernetes node and cluster health, allowing teams to quickly respond to alerts or proactively monitor system performance. Powered by eBPF, these dashboards offer real-time data collection with minimal overhead, enabling teams to gather granular insights without impacting system performance. The integration also includes seamless data exploration, making it easy for engineers to pivot from visualization to deep-dive data exploration. Additionally, the dashboards are integrated with OpenTelemetry, providing trace and analysis capabilities. Groundcover's platform prioritizes user experience, offering a simplified interface for generating and exploring queries, eliminating the need to master complex query languages or manually configure dashboards. The company aims to build a unified observability experience that empowers teams to monitor, troubleshoot, and optimize their systems effortlessly.

In Kubernetes, resource quotas are a key method for managing resources and preventing applications from consuming excessive amounts of CPU, memory, or storage. They work by setting limits on the total number of objects, total resource requests, and total resource usage levels permissible within a given namespace. Resource quotas can be used to manage compute resources, storage resources, object count resources, and extended resources. They offer several advantages, including improved resource utilization, simple limit configurations, and granular controls, but also have some drawbacks, such as complexity, limitations on application performance, and limited granularity. To get the most out of resource quotas, it's recommended to set up namespaces strategically, start high and scale down, monitor and adjust quotas, include both resource requests and limits, and use tools like groundcover for comprehensive visibility into resource usage.

We built a data visualization platform, Dashboards and Data Exploration, from scratch in just 12 weeks. We started by building the Query Bar, which became the backbone of our platform, allowing users to generate PromQL queries easily. The Query Bar was expanded to support Logs and Traces, and later Infra Metrics, showcasing one of our biggest advantages over competitors: great Infra Monitoring out of the box. We prioritized user feedback, releasing features in quick cycles and iterating in days instead of months. Our platform is now fully integrated with Grafana, but we're shifting focus to building a custom graphing library for full control over visualizations. Future plans include driving adoption, closing feature gaps, and reimagining what dashboards can be, including enhanced sharing capabilities and intelligent automation.

In Kubernetes, draining a node is an essential process that allows you to remove pods from a node without disrupting your applications and services. The kubectl drain command provides a way to do this, but it requires careful planning and execution to avoid issues such as downtime, data loss, or application failures. By understanding the benefits of draining nodes, how to use the kubectl drain command, and how to troubleshoot common challenges, you can ensure a smooth and efficient node draining process that minimizes risks and maximizes availability for your applications.

Kubernetes liveness probes are a crucial component of Kubernetes monitoring and observability, allowing you to determine whether a container is "alive" or running normally. By providing visibility into what's happening inside a pod, probes play an important role in detecting issues before they become major problems. Liveness checks can be categorized into four types: command execution, TCP socket, HTTP GET, and gRPC. Probes offer several benefits, including improved application availability, efficient health checks, automated restarts, and customizability. However, liveness probes also have limitations, such as providing little insight into why a container is not working normally and not assessing performance. To configure Kubernetes liveness probes, you can use YAML code that defines the type of probe to run, parameters like initial delay and period seconds, and failure threshold. It's essential to test probes manually before deploying them automatically and to update probes as applications change. By combining liveness probes with observability tools, such as groundcover, you can gain deeper insights into container performance issues and fix problems permanently.