[OTel+K8s+Spring+Grafana] 세부 대시보드 구현(4): 대시보드 구성 Recap

About this offer

이번 포스팅에서는, 지난 몇 차례의 포스팅을 통해 구현한 통합 대시보드와 세부 대시보드 구현 과정을 돌아보며 계획 수립, 구현, 마무리 과정을 정리하려고 한다. 1. 대시보드 구현 과정 정리 지난 포스팅 통합 대시보드 구현 계획 수립 통합 대시보드 구현 세부 대시보드 구현(1): Nodes & Hosts 세부 대시보드 구현(2): K8s Workloads 세부 대시보드 구현(3): Kubelet & Storage, Spring Application, Telemetry+Usage 1.1 구현 계획 수립, 워크플로 정의 전체적인 워크플로는 이전 SI 개발 현업에서 경험한 개발 프로세스를 참고했다. 이전 경험 회고 유관부서로부터 1) 모니터링할 Pod Statistics 리스트를 받아 개발에 착수 . 2) SQL 쿼리 스크립트를 작성하고 성능을 튜닝 . 실개발 인원인 중국 개발 팀에 3) 쿼리 스크립트가 배포된 Testbed에 접속을 허가 . 해당 서버 상에서 4) Demo를 개발하고 UI를 구현 . 현재 프로젝트와의 공통점 비교 이전 SI 개발 프로젝트(2025) 현재 관측성 플랫폼 구축 프로젝트(2026) 1 Pod Statistics 리스트 A 수집 Metrics 리스트 2 SQL 쿼리 스크립트 B PromQL 3 Testbed/상용 인프라 환경 C 현재 구축한 클러스터 인프라 4 외주 개발 대시보드 UI D Grafana Cloud 대시보드 UI 위와 같은 공통점을 바탕으로 구현 계획 자체를 수립하는 과정은 어렵지 않았으나, 유관부서와의 협업 결과물을 개인 프로젝트에 대입하려 하니, 작업의 순서와 사용 툴, 작업 목적을 명확히 하는 과정이 필요했다. 대시보드 구현 계획 수립 (통합 대시보드/세부 대시보드 공통) 단계 수행 내용 활용 가능 툴 1 수집 Metrics 목록 확정, Metrics 리스트 파일 작성 MS Excel, AI Tool(Codex) 2 Metrics별 PromQL 작성 Grafana Explore 3 Metrics 계측 검증 및 결측 확인 Grafana Explore 4 대시보드/패널 규모 및 분류 기준 확정 Grafana Cloud Dashboard 5 대시보드 UI 구현 및 수집 검증 Grafana Cloud Dashboard (6) 선택적 관측 사항 보강 협업 툴(Jira)에 관련 Task 생성 혼자서 작업하는 환경이지만, 협업 상황에서의 스케줄 관리 등을 간접 경험할 겸.. 개발 과정을 기록해 온 Jira Backlog에 관련 Task를 추가했다. (완료 작업과 처음 백로그 구성 시 설정한 마감 기한이 약 3주 넘게 차이가 난다... 협업 환경에서는 스케줄 설정 시 개인 일정을 꼭 고려하자.. ) 1.2 수집 Metrics 리스트 생성 현재 클러스터에서 수집 중인 Metrics 중 대시보드에 시각화 할 Metrics를 정리한 리스트를 작성했다. Metrics 리스트를 작성하기 위해, 다음과 같은 과정으로 진행했다. 클러스터에서 수집하고 있는 Metrics 목록 확보 Metrics 분류 기준 수립 및 대시보드 구성 확정 Microsoft Excel 형식의 Metrics 리스트로 변환 OpenTelemetry Collector의 6개 Receiver를 통해 수집하고 있는 모든 Metrics를 아래와 같은 방식으로 JSON 형식으로 Export했다. 수집 Metrics 조회 (PromQL) { job=~"node-exporter|kubelet|cadvisor|kube-state-metrics|otel-collector|spring-app" } 조회 결과를 JSON 형식으로 Export (Grafana Cloud Web) Metrics 분류 기준 및 대시보드 구성 방안 수립 대시보드 구성은 통합 대시보드 1개 와 그 대시보드를 통해 파악한 문제점을 상세히 파악할 세부 대시보드 5개 로 분류했다. 이전 SI 개발 현업에서 개발한 모니터링 소프트웨어가 Overall한 모니터링을 위한 메인 페이지 와 세부 모니터링을 위한 복수의 탭 을 두었던 점을 참고했다. 통합 대시보드 (1개) 대시보드 모니터링 타깃 1 Platform Overview 통합 대시보드. 확인이 필요한 구성요소 탐지 및 세부 대시보드 이동 세부 대시보드 (5개) 대시보드 모니터링 타깃 2 Nodes & Hosts Host 리소스 부족 탐지 3 Kubernetes Workloads K8s 리소스/구성요소 상태 확인 4 Kubelet & Storage 실행 관리 + 볼륨 이상 탐지 5 Spring Application Spring App 요청 실패 탐지 6 Telemetry + Grafana Usage Scraped Samples, Collector 상태, Grafana Cloud 리소스 사용량 확인 메인 페이지 성격의 통합 대시보드(00-Platform Overview)와 5개의 세부 대시보드를 Link로 연결 하여 탭 버튼을 클릭하면 세부 대시보드로 이동하는 구조이다. Metrics 리스트 파일 생성 다음으로, AI Tool인 Codex 에 다음 프롬프트와 같이 명령하여 .xlsx 형식의 Metrics 리스트를 생성했다. # 프롬프트 * Metrics Snapshot JSON 파일을 읽고, 파일 내에 기록된 Metrics를 누락 없이 리스트에 반영할 것 * 제시한 대시보드 구분점을 정확히 반영하여 Metrics를 분류할 것 * Metrics가 수집된 Receiver와 데이터의 성격(Counter/Gauge 등)을 명시할 것 * 각 Metrics에 대한 간략한 설명을 첨부할 것 1.3 Metrics 상세 분석 및 PromQL 작성 생성한 Metrics 리스트를 바탕으로 대시보드 패널의 규모를 대략적으로 구상하고, 시각화를 위한 PromQL을 작성하기 위해 아래와 같은 과정으로 진행했다. Metrics 분석(Metrics 리스트 내 설명 기반, 필요 시 Deep-dive) 대시보드/패널 규모 산정 및 Metrics 선별 (필수 구현/필요 시 보강) 최종 선별한 Metrics Query를 위한 PromQL 작성 Metrics 분석 가장 많은 시간을 할애한 부분이다. 과거 SI 개발 프로젝트 수행 당시 느꼈던 어려움으로, "모니터링 소프트웨어를 개발하고 있는데, 무엇을 모니터링하는 건지 모르는 상황" 이 있다. Pod Statistics 지표들이 다소 Specific해서, 외주 개발진과 함께 어떤 시각화 타입이 효과적일지 논의하는 데 어려움을 느낀 경험이 있다. 따라서, 적어도 "무엇을 모니터링할 지" 와 "어떻게 시각화할 지" 두 가지에 대해서는 가시적인 성과보다 "내가 이해하고 있는가" 에 초점을 맞추고 진행했다. 공부 방법은 간단했다. 해당 Metrics를 그대로 포털에 검색하고 알아보는 방식이다. 인프라 구축 과정에서는 공식 문서 이외의 외부 링크를 참고하는 것을 지양했지만, Use Case에 대한 정보를 얻는 데에는 외부 링크가 더 효과적이었던 것 같다. 대시보드/패널 규모 산정 리스트의 Metrics를 모두 시각화하면 전체 대시보드의 규모가 방대해지는 문제가 있어, 우선 10~12개의 패널을 가진 소규모 대시보드 를 구성하고 필요 시 보강하는 방향으로 구성했다. 핵심적인 모니터링 방향성을 "안정적인 상태와 장애 상황을 명확히 구분하는 것" 으로 정하고, Metrics를 선별했다. 대부분의 모니터링 지표를 변화량 으로, 패널을 시계열 그래프 로 구성했다. 추후 목표가 클러스터에 의도적으로 장애를 일으키고, 대시보드를 통해 변화 감지(or 알람 발생) → 원인 분석 → 대응 → 확인 하는 장애 대응과 트러블슈팅을 경험하기 위함임을 고려했다. PromQL 작성 Codex를 활용해 PromQL을 작성하고, 포털에 검색하여 검증했다. 추가로, Metrics 가공에 사용된 여러 함수의 적절성을 검토하고 각 패널의 시각화 그래프의 종류를 선정했다. 이후, Grafana Cloud 웹에서 대시보드를 구성하고 각각의 PromQL을 적용해 패널을 구성했다. 2. Dashboard Outputs 구현 계획 수립 수집 Metrics 리스트 작성 Metrics 상세 분석 및 PromQL 작성 의 과정을 거쳐 구현한 대시보드는 아래와 같다. 2.1 Overall Dashboard 2.2 통합 대시보드 클러스터의 전반적인 상태를 확인할 수 있도록 구성한 통합 대시보드이다. 상단에 링크를 클릭하면 세부 대시보드로 이동한다. 2.3 세부 대시보드 1) Nodes & Hosts 모니터링 클러스터를 구성하는 4대의 VM과 호스트의 리소스 부족 등을 탐지 하기 위한 세부 대시보드이다. 2) Kubernetes Workloads 모니터링 클러스터를 구성하는 Kubernetes 리소스 및 컴포넌트의 상태 등을 확인 하기 위한 세부 대시보드이다. 3) Kubelet & Storage 모니터링 클러스터 내에서 작업의 실행 관리 및 스토리지/볼륨의 이상을 탐지 하기 위한 세부 대시보드이다. 4) Spring Application 모니터링 클러스터 내에서 동작하는 Spring Application의 요청 실패 등을 탐지 하기 위한 세부 대시보드이다. 5) Telemetry & Usage 모니터링 OpenTelemetry Collector의 수집 상태와 Sample Relabeling, Grafana Cloud 리소스 사용량을 확인 하기 위한 세부 대시보드이다. 3. 의의, 추후 개발 계획 이 프로젝트 목표는 1.3절에 작성한 바와 같이, "클러스터에 의도적으로 장애를 일으키고, 대시보드를 통해 변화 감지(or 알람 발생) → 원인 분석 → 대응 → 확인하는 장애 대응과 트러블슈팅을 경험" 이다. 3.1 얻은 것 Metrics 최적화 이전, 구현한 모니터링은 Spring Application에 국한 되어 있었다. 외부 개발자가 개발한 Spring Application 모니터링 대시보드를 import한 단일 대시보드 형태였고, Spring Application의 역할도 "테스트용 텔레메트리를 생성"하는 것에 지나지 않았다. 모니터링 범위를 기존의 Application only에서 Cluster-wide로 확장 하면서, 아래 3가지를 확보할 수 있었다. Metrics 최적화를 통해 Grafana Cloud Tenant Limit으로 인한 Metrics Drop 해소 및 Limit 내에서 모니터링 구현 Cluster 전반의 상태에 대한 관측성 확보 Customized 대시보드 구현으로 관측 데이터에 대한 이해 확보 3.2 얻어야 할 것 (추후 개발 계획) 추후 개발을 통해 확보해야 할 내용들도 존재한다. Spring Application 고도화 현재 "테스트용 텔레메트리를 생성"하는 역할에 국한된 Spring App을 고도화하여, 실질적인 Logs와 Traces 데이터, HTTP Requests를 생성하도록 보강한다. 또한, Spring App에 지속적인 트래픽을 발생시키고, 부하를 모니터링하며 핵심 모니터링 타깃인 Spring Application의 모니터링을 보강 개발을 통해 고도화할 계획이다. 관측 데이터 보강 Spring Application 보강 개발에 따라, 확보해야 할 Metrics를 추가로 수집하여 04-Spring Application 에 시각화할 계획이다. 또한, Spring Application의 PostgreSQL 데이터베이스 등 모니터링 타깃을 더 확장할 필요성도 있다. 장애 대응 및 트러블슈팅 Case Studies 위 두 가지 보강 개발이 진행되면, 프로젝트의 최종 목표를 수행할 수 있다. 장애를 유발하는 Case를 조사하고, 실제로 클러스터에 장애를 유발한다. 그 해결 과정을 통해 미처 확인하지 못한 클러스터의 세부적인 사항들과 통신 원리를 알아보고, 실제 장애 대응 프로세스를 따라 트러블슈팅을 진행할 수 있다. 다음 포스팅부터는 Spring Application을 고도화하고, 역할 확대에 따른 모니터링 범위 확장 과정을 기록해보려 한다.