[Design] Investigate and Design Custom Metrics Collection Path in Node-level Resource Monitoring

[Chulhee1Lee]

Background / 배경

Korean

Pullpiri의 MonitoringServer는 현재 CPU, Memory, Container 상태 등 일반적인 시스템 리소스 메트릭을 수집하고 있습니다.

그러나 App 성능 기반 Reconcile Use Case에서 필요한 FPS, Latency 등 애플리케이션 고유의 성능 메트릭(Custom Metrics)을 수집하기 위한 경로 및 구조가 현재 존재하는지 파악되지 않은 상태입니다.

Custom Metrics 수집 경로가 존재하지 않는 경우, FPS 등의 성능 지표를 PolicyManager까지 전달하는 것이 불가능하므로, 먼저 현재 구조를 조사하고 필요 시 수집 경로를 설계해야 합니다.

English

The Pullpiri MonitoringServer currently collects general system resource metrics such as CPU, Memory, and container status.

However, it is not yet clear whether there is an existing path or structure for collecting application-specific custom metrics — such as FPS or Latency — which are required for the App Performance-based Reconcile use case.

If no such path exists, it will be impossible to deliver these performance indicators to the PolicyManager. Therefore, the current architecture must be investigated first, and a collection path must be designed if needed.

---

Objective / 목표

Korean

Node에서 수집되는 리소스 메트릭을 일반 시스템 지표 외에, App이 노출하는 Custom Metrics까지 확장할 수 있는지 조사하고 설계합니다.

조사 및 설계 범위는 다음을 포함합니다.

• 현재 MonitoringServer의 메트릭 수집 구조 파악
• Custom Metrics 수집 경로의 존재 여부 확인
• 수집 경로가 없을 경우 설계 방향 제시
• FPS 등 App 성능 지표를 수집할 수 있는 구조적 기반 마련

English

Investigate and design whether Pullpiri can extend its node-level resource monitoring beyond general system metrics to include application-specific custom metrics exposed by apps.

The scope includes:

• Understanding the current metric collection structure in MonitoringServer
• Identifying whether a custom metric collection path already exists
• Proposing a design direction if no such path exists
• Establishing a structural foundation for collecting app performance metrics such as FPS

---

Tasks / 수행 내용

• 현재 MonitoringServer의 메트릭 수집 구조 분석 (수집 항목, 흐름, 인터페이스)
• Custom Metrics 수집을 위한 기존 경로 또는 확장 포인트 존재 여부 확인
• 기존 경로 부재 시, Custom Metrics 수집 인터페이스 설계 방향 제시
  • App → MonitoringServer 전달 방식 (push vs pull)
  • 메트릭 등록/식별 방법 (메트릭 이름, 타입, 단위)
  • NodeAgent 연동 여부 검토
• FPS 메트릭을 예시로 활용한 수집 가능성 검토
• 설계 결과물 문서화 (구조도, 흐름도, 인터페이스 정의)

---

• Analyze the current metric collection structure of MonitoringServer (collected items, flow, interfaces)
• Check whether an existing path or extension point for custom metric collection is available
• If no existing path is found, propose a design direction for a custom metric collection interface
  • Delivery method from App to MonitoringServer (push vs pull)
  • Metric registration and identification (name, type, unit)
  • Review of NodeAgent involvement
• Assess feasibility using FPS as an example metric
• Document the design output (architecture diagram, flow diagram, interface definition)

---

Acceptance Criteria / 완료 기준

Korean

• 현재 MonitoringServer가 Custom Metrics를 수집할 수 있는지 여부가 명확히 문서화됨
• 수집 경로가 없을 경우, 설계 방향 문서가 작성됨
• FPS와 같은 App 성능 지표를 수집하기 위한 최소한의 구조적 방향이 제시됨
• 설계 결과가 이후 구현 이슈의 입력으로 활용 가능한 수준으로 작성됨

English

• It is clearly documented whether the current MonitoringServer can collect custom metrics
• If no collection path exists, a design direction document is produced
• A minimum structural direction for collecting app performance metrics such as FPS is proposed
• The design output is written at a level that can serve as input for subsequent implementation issues

---

Out of Scope / 제외 범위

Korean

본 이슈에서는 아래 항목을 다루지 않습니다.

• Custom Metrics 수집 기능의 실제 구현
• Network, Storage 모니터링 연결 구현
• MonitoringServer → PolicyManager 전달 경로 검증
• App 성능 기반 Policy 트리거 설계

English

The following items are out of scope for this issue.

• Actual implementation of custom metric collection
• Network and Storage monitoring integration
• End-to-end validation from MonitoringServer to PolicyManager
• Policy trigger design based on app performance metrics