September 2026 Summaries

Alex Turner, groundcover’s Google Cloud Partner Manager, says he joined the company because of its curiosity-driven culture, strong leadership team, and potential to expand its partnership with Google Cloud. He highlights groundcover’s Bring Your Own Cloud architecture, which keeps observability data such as logs, metrics, traces, Kubernetes telemetry, and AI agent activity within customers’ own Google Cloud environments rather than sending it to external vendors. Turner argues that this approach can help organizations manage rapidly growing telemetry volumes, retain high-fidelity production data, and avoid restrictive ingestion costs, particularly as AI-driven systems generate more operational data. He also cites the company’s GKE Autopilot integration as an early partnership milestone, enabling eBPF-based observability for managed Kubernetes clusters while preserving customer data control and managing costs.

Groundcover announced its first acquisition, purchasing Wand to add autonomous Kubernetes resource management to its observability platform. Wand continuously coordinates vertical, horizontal, and node scaling based on workload behavior, aiming to improve performance and availability while reducing excess capacity without relying on static resource settings or extensive manual tuning. Groundcover argues that conventional right-sizing and separate autoscaling tools can create inefficient cluster-wide outcomes because they make localized decisions in dynamic environments. The companies plan to combine Wand’s in-cluster optimization engine with groundcover’s high-fidelity telemetry, which collects application and infrastructure data in customers’ cloud environments and can be connected with engineering systems such as GitHub, Slack, and PagerDuty. The acquisition reflects groundcover’s broader view that observability will evolve from helping engineers investigate incidents toward enabling agents and automated systems to make bounded operational decisions, with engineers defining goals, constraints, and approval requirements. Groundcover will first use Wand internally to optimize its bring-your-own-cloud observability architecture, then offer Kubernetes resource optimization to customers, while positioning the deal as a step toward broader autonomous infrastructure rather than solely a cost-management product.

The post argues that eBPF and OpenTelemetry are complementary observability tools: OpenTelemetry provides intentional application-level business context, while eBPF supplies always-on, code-free visibility into kernel and network activity that may reveal details absent from standard instrumentation. It describes groundcover’s eBPF-based Kubernetes sensor, which collects telemetry from system calls, probes, and network traffic, including request payloads and database bind parameters, while allowing in-cluster aggregation and sensitive-field filtering. In a featured example, a Postgres service experienced intermittent latency despite normal error rates and a seemingly reasonable parameterized query; OpenTelemetry exposed the query template but not the parameter value, whereas eBPF captured the responsible user ID and response data. Filtering that user substantially reduced high-percentile latency, and a saved agent investigation identified a hot shard containing roughly one million rows as the likely cause, recommending data archiving, pagination, cleanup, or rebalancing rather than an additional index. The post presents this as part of a broader series on failures involving database tables, index rebuilds, and service regressions, and suggests that eBPF-derived evidence can guide more targeted OpenTelemetry instrumentation and reusable automated investigations.

A payment-service latency regression illustrates how OpenTelemetry and eBPF can provide complementary observability: OTel supplied detailed trace timing and application-level spans, while eBPF captured the outbound HTTP payload that revealed legacy payment tokens were being rate-limited, a detail intentionally omitted from standard instrumentation because request bodies can be costly and sensitive. Kubernetes data collected through the same sensor then exposed both the relevant environment configuration and a failed remediation rollout, where an unintended readiness-probe change prevented new pods from becoming ready. The account argues that eBPF offers broad, no-code visibility into network protocols, infrastructure, and uninstrumented workloads, though it has limits in identifying application functions without symbols and frame pointers. Across four incident examples, it presents OTel as the source of deliberate business and application context and eBPF as continuous underlying evidence, with automated investigation skills proposed as a more reusable outcome than dashboards alone.

Software engineer and open-source maintainer Naor Peled argues that contributing to open source remains highly valuable in the AI era, despite models’ ability to generate code quickly. He recommends that newcomers begin with documentation improvements or “good first issues,” which help them learn a project and become part of its community. Maintaining projects such as TypeORM, PR-Agent, and Cyphernetes involves reviewing pull requests, reducing issue backlogs, updating documentation, coordinating maintainers, and guiding features, with community participation providing benefits that automation cannot replace. Peled acknowledges that AI-generated pull requests can create significant review fatigue, particularly when contributors submit unexamined, repetitive solutions, but he uses automated AI review feedback and contributor responsiveness to distinguish serious effort from abandoned submissions. He maintains that open source contributions strengthen the knowledge underlying AI systems, expose developers to broader technical challenges, and offer opportunities to influence emerging AI tools, standards, and software practices.

eBPF can complement OpenTelemetry by providing kernel-level observability for instrumented and uninstrumented workloads without requiring application code changes or downtime. Using the ShopIQ e-commerce demo, the post describes a Kubernetes Job running raw psql that repeatedly attempted to insert data into a nonexistent PostgreSQL table, a failure that conventional OpenTelemetry tracing could not capture because the script had no instrumentation. An eBPF-based sensor detected the failing database connection and exposed the full SQL statement, PostgreSQL 42P01 undefined-table errors, request outcomes, latency, pod, cluster, and container context. The post argues that OpenTelemetry remains valuable for business and application-specific context, while eBPF supplies broad baseline coverage across services and jobs, enabling teams to identify where targeted instrumentation is most useful. It also envisions combining eBPF ground-truth telemetry, OpenTelemetry semantics, and cloud-hosted investigative agents that can rerun saved troubleshooting workflows.

eBPF and OpenTelemetry can jointly improve database observability by combining always-on, no-code telemetry with application-level context. The example describes a non-concurrent PostgreSQL index rebuild on a large events table that blocked index-backed readers, causing widespread latency increases without errors or an obvious explanation in individual traces. By providing an agent with a slow span and a plain-language question, the system analyzed traces, metrics, workloads, and eBPF-generated database spans to identify the blocking REINDEX operation, recommend using REINDEX CONCURRENTLY, surface an unrelated missing-table error storm, and suggest investigating table partitioning. The post argues that eBPF captures database activity even from uninstrumented services and ad hoc jobs, while OpenTelemetry adds business and application semantics, enabling agents to investigate recurring incidents using saved skills rather than requiring manually built dashboards.

groundcover has become an approved Google Kubernetes Engine Autopilot partner, enabling its eBPF-based observability sensor to run on Autopilot clusters through Google’s official allowlisting process for privileged workloads. GKE Autopilot manages infrastructure, scaling, node lifecycles, and security but restricts elevated-permission software, including many eBPF agents, to preserve its security model. The approval allows organizations to deploy groundcover without modifying applications or adding manual instrumentation, while collecting telemetry across infrastructure, Kubernetes workloads, applications, and AI services. groundcover positions the integration as a way for teams to retain Autopilot’s managed operational experience while gaining kernel-level, full-stack visibility for troubleshooting, monitoring AI workloads, and operating Kubernetes environments at scale.