Groundcover — Aviv Zommer

Context

Why this mattered

Groundcover's eBPF sensor automatically collects logs from across a user's cloud infrastructure, which means everything flows in by default. For teams running large Kubernetes environments, this quickly becomes unmanageable: noisy, unstructured logs fill the system with low-value data while high-signal events get buried.

The real problem wasn't technical. It was the absence of scalable, productized control. Parsing rules had to be written in YAML. Drop rules required manual configuration. Both often meant opening a support ticket and waiting for a CSM to help, not because users couldn't understand the system, but because the product gave them no accessible surface to act on it themselves.

This project was about changing that. Not with a new product area, but with a focused, usable addition to an existing flow.

How logs flow through the groundcover system

My role

My design challenge

I had six weeks and no room for a traditional research phase. The domain, observability, eBPF, log pipelines, is technically dense, and the users are DevOps engineers and SREs who think in infrastructure terms. Getting even a few hours of their time for usability testing wasn't realistic in this cycle.

So I adapted. Internal developers became my primary feedback loop, the closest available stand-in for the actual persona. They understood the domain, they had intuitions about what "good" looked like for this type of workflow, and they were available for rapid back-and-forth across two-week sprints.

This wasn't a compromise. It was the right call given the timeline. The challenge was translating that feedback into design decisions that would hold up for the actual user, not just internal reviewers.

6 wks

Full delivery, from kick-off to shipped feature

2 wks

Iteration cycles with internal developer feedback

0

External user research sessions during this cycle

Competitive landscape, how similar products handle log pipeline management

Design thinking

The pattern I identified

Early in the work, I noticed that users approached this problem from two very different starting points, and conflating them was making the design harder than it needed to be.

The first mode is reactive: a user is already inside the logs view, investigating something specific. They encounter a noisy or problematic log and want to act on it immediately, drop it or define a parsing rule, without leaving what they're doing.

The second mode is proactive: a user goes to settings intentionally to manage their pipeline configuration as a whole. They want to review existing rules, reorder pipelines, or create new ones from a high-level view.

These are two distinct jobs. Separating them gave each mode a clear, appropriate entry point.

Reactive

Acting from within a specific log

The user is already in the logs view, investigating an error or filtering a specific workload. From the log detail drawer, they can immediately create a drop rule or add a parsing rule. The action is contextual and doesn't require navigating away.

Proactive

Managing rules from the settings view

The user navigates to Parsing Pipelines in system settings with a deliberate intent, to review their current rules, create new ones, reorder pipeline priority, or clean up outdated configurations. This is the management surface, not the investigation surface.

Iterations

How the solution evolved

The solution went through three distinct iterations over the six weeks. Each one was shaped by a clear piece of feedback, and each one moved the design closer to something that matched how engineers actually think about this workflow.

Iteration 01

YAML-first builder mode

The first approach kept the existing YAML interface but wrapped it in a product UI. Users could write configuration directly, see a real-time test result, and let the LLM suggest a configuration from a sample log. It was fast to validate internally, but feedback quickly showed that raw YAML felt too technical for a product-level experience.

YAML rule builder. The initial design gave engineers a structured interface to write OTTL parsing rules directly, with real-time field extraction preview and per-rule validation feedback.

LLM-assisted suggestion. Paste a sample log line and the model infers a parsing rule configuration, reducing manual authoring time and lowering the skill barrier for writing new rules from scratch.

Iteration 02

Parsing Pipelines settings page

The second iteration introduced a dedicated Parsing Pipelines settings page, the product's first proactive planning surface. Users got a centralized view of existing rules with system-level metrics like drop rate and error count. Simultaneously, the reactive flow was refined with in-context actions, keeping both modes coherent within a single system.

Parsing Pipelines dashboard. A dedicated settings surface showing all active rules with system-level throughput metrics, error rates, and drag-and-drop pipeline priority reordering.

Contextual rule creation from a single log

Contextual entry from a log. From within the investigation view, engineers can act on a noisy or unwanted log immediately, creating a drop rule or adding a parsing rule without leaving their current context.

Iteration 03

Query Builder for Settings

The next planned iteration allows users to create and edit parsing pipelines directly from the Settings screen, without needing to start from a specific log entry. A query builder helps search and filter logs before defining a rule. This step completes the loop: full rule creation from both reactive and proactive entry points, making the system coherent for any workflow.

Settings-first query builder. Enables rule creation directly from the Parsing Pipelines screen. Engineers search and filter logs without starting from a specific log entry, completing both reactive and proactive entry paths in a single coherent system.

Outcome

What shipped in 6 weeks, and what changed

In six weeks, Groundcover shipped a self-serve log pipeline management experience, including rule creation from the logs view, a dedicated Parsing Pipelines settings surface, and drag-and-drop pipeline reordering. What previously required a CSM and a YAML file could now be done directly inside the product.

Users gained direct control over parsing and drop rules without requiring support involvement for routine configuration tasks.

The reactive entry point made the action contextual and immediate, removing a key friction point in the investigation workflow.

Pipeline management became visible. Engineers could now see their full configuration, understand priority order, and modify it without touching files.

This created the foundation for broader self-serve expansion across other configuration areas.

Drag-and-drop pipeline control. Engineers can reorder parsing rules directly from the settings page. No config files, no support request. Priority is visual, immediate, and reversible.

Inserting a step into the pipeline at a specific position

Ordered step insertion. When adding a new rule, users choose exactly where it lands in the pipeline sequence, giving them precise control over how logs are processed without losing context of the existing order.

New design system components introduced in this project

Design system contributions. The project introduced several reusable components, including rule cards, status indicators, pipeline list items, and inline action menus, now part of groundcover's shared component library.

Simplified how users control data ingestion in a complex observability product