kubeflow / kubeflow/notebooks

[EPIC] OpenTelemetry Metrics Endpoints

Open
#884 3 comments 0 reactions 0 assignees View on GitHub
area/controller area/v2 kind/plan-epic
Dominant language
No language data
Stars
84
Forks
149
Avg merge
5d 15h
Merged PRs (30d)
29

Description

### Certification

- [x] I certify I am an Epic Owner for Kubeflow Notebooks 2.0 and expected to create planning-related issues.

### User Story

As an AI/ML practitioner, Bella benefits from understanding the historical behavior of her Workspaces
beyond point-in-time observations. While the Workspace status shows her current state—whether it's running,
paused, or in error—she cannot easily answer questions like "How often has my workspace been in an error
state this week?" or "What's the typical idle time before my workspaces get culled?" Time series metrics
enable Bella to observe patterns in her workspace lifecycle, helping her optimize her workflows and
anticipate issues before they disrupt her work.

As an ML Platform Admin, Joel needs operational visibility into the Notebooks platform itself—not just the
compute resources workspaces consume, but how the system behaves over time. He needs to answer questions
like "How many workspaces across the cluster are in an error state, and is that trending up?" or "Which
WorkspaceKinds are seeing increased adoption, and which deprecated configurations still have active users?"
Time series metrics transform the point-in-time status data already captured in Workspace and
WorkspaceKind custom resources into actionable operational intelligence.

While epics like https://github.com/kubeflow/notebooks/issues/542 and
https://github.com/kubeflow/notebooks/issues/307 focus on compute resource utilization metrics (CPU,
memory, GPU usage), this epic focuses on application-level operational metrics—observations about the
Kubeflow Notebooks 2.0 system's behavior derived from CRD status fields.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the Workspace and WorkspaceKind custom-resource status fields described in the issue, then compare the related compute-metrics epics in issues #542 and #307. Done would mean defining and implementing the application-level OpenTelemetry metrics needed for workspace lifecycle and platform visibility, including historical trends and WorkspaceKind adoption.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes
Domain
observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.