Cloud Operations

운영 포털·모니터링: 모니터링 화면에서 리소스가 누락될 때 - 수집 흐름 관점

모니터링 화면에서 리소스가 누락될 때를 수집 흐름 관점에서 좁혀 보는 케이스. Monitoring / Portal 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 47

이 글은 운영 포털·모니터링: 모니터링 화면에서 리소스가 누락될 때 - 수집 흐름 관점 케이스를 다룬다. 핵심은 모니터링 화면에서 리소스가 누락될 때를 수집 흐름 관점에서 좁혀 보는 케이스다.

수집한 운영 단서에서 고객명, 내부 주소, 노드명을 제거하고 장애 흐름과 확인 순서만 남겼다.

모니터링과 포털 장애는 실제 서비스 장애와 다르게 접근해야 한다. 화면이 틀렸는지, 수집기가 멈췄는지, 원천 platform 값이 바뀌었는지 분리해야 잘못된 장애 전파를 막을 수 있다.

모니터링 누락은 실제 VM 장애와 다른 성격의 문제다. platform API 값은 정상인데 dashboard만 비어 있을 수 있고, collector는 정상인데 포털 DB 집계만 밀릴 수도 있다.

이 글에서 다루는 케이스

케이스 초점모니터링 화면에서 리소스가 누락될 때를 수집 흐름 관점에서 좁혀 보는 케이스
정리한 주제Monitoring / Portal
주요 계층Monitoring collector, portal DB, dashboard, scheduler
운영 단서주제 프로파일과 장애 흐름 기준으로 재구성

겉으로 보이는 증상

  • Watch, dashboard, Grafana, 운영 포털에서 VM 또는 metric이 누락된다.
  • 실제 리소스는 정상인데 화면의 상태, 집계, 알림이 맞지 않는다.
  • collector, cron, DB table, API 연동 중 어느 지점인지 분리해야 한다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 아래 신호는 실제 값 대신 예시 placeholder로 바꿔 흐름만 볼 수 있게 정리했다.

  • Monitoring / Portal 계층에서 증상이 시작되지만 실제 원인은 다른 계층에 있을 수 있다.
  • 눈에 보이는 에러보다 장애 시각, 대상 리소스, 직전 변경 이력을 먼저 맞추는 편이 빠르다.
  • 읽기 전용 확인과 상태 변경 작업을 분리하면 급한 상황에서도 판단이 흐려지지 않는다.

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

  • 실제 platform API 결과와 포털 DB/대시보드 집계를 비교한다.
  • collector cron, scheduler, last run time, error log를 확인한다.
  • 누락 범위가 단일 VM, 계정, zone, 전체인지 먼저 나눈다.

확인에 쓴 명령 흐름

아래 명령은 공개 가능한 형태로 일반화했다. 실제 값은 환경마다 다르므로 placeholder를 대상 리소스에 맞춰 바꿔야 한다.

systemctl list-timers
crontab -l
tail -n 200 /var/log/<collector>/<collector>.log

mysql -h <portal-db> -u <readonly_user> -p <portal_db>
select count(*), max(updated_at) from <metric_table>;
select * from <metric_table> where vm_id = '<vm-id>' order by updated_at desc limit 10;

curl -sS http://<collector-endpoint>/health

조치 전에 판단할 지점

  • collector 재수집 전에 중복 insert와 stale row 여부를 확인한다.
  • 대시보드 테이블 변경은 read-only 검증 쿼리와 rollback 쿼리를 함께 준비한다.
  • 알림 오탐은 threshold, label mapping, source metric을 분리해서 조정한다.

복구됐다고 판단하는 기준

  • 누락되던 리소스가 API, DB, dashboard에서 같은 값으로 보이는지 확인한다.
  • 다음 cron cycle 이후에도 값이 유지되는지 본다.
  • alert가 정상 복구 또는 clear 되었는지 확인한다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.

BGM EVER