프로메테우스 공식 레퍼런스를 한글로 번역한 문서입니다.
전체 목차는 여기에 있습니다.
대시보드에선 가능한 한 많은 데이터를 그려보고 싶을 거다. 프로메테우스같이 애플리케이션을 풍부하게 계측instrumentation할 수 있는 시스템을 사용한다면 특히 더 그렇다. 하지만 너무 과해지면 시스템의 전문가라도 의미를 파악하기 어려울만큼 난해한 콘솔을 만들게될 수도 있다.
가지고 있는 데이터를 하나하나 전부 표현하기보단, 운영 콘솔에서 가장 발생하기 쉬운 오류 상황은 무엇인지, 어떻게하면 이런 상황들을 구분할 수 있을지에 집중해라. 가지고 있는 서비스 구조를 최대한 활용해라. 예를 들어서 온라인 서비스 시스템 안에서 다양한 서비스들이 하나의 트리를 구성하고 있다면, 대표적으로 겪을 수 있는 상황은 일부 하위 서비스들의 지연 시간이 길어지는 상황이다. 모든 서비스들의 정보를 하나의 대형 대시보드로 나타내지 말고, 각 서비스마다 해당 서비스에서 발생하는 통신 지점별로 지연 시간과 에러를 보여주는 별도 대시보드를 구축해라. 그러면 맨 위에서부터 시작해서 문제가 있는 서비스를 파악할 때까지 쭉 내려가볼 수 있다.
아래 가이드라인을 지켜주면 실효성 있는 대시보드를 만들 수 있다:
- 콘솔 하나에 그래프는 5개 이하로 유지해라.
- 각 그래프에 있는 플롯(라인)은 5개 이하로 유지한다. 누적 그래프나 영역 차트에선 조금 더 늘려도 좋다.
- 프로메테우스에서 제공하는 콘솔 템플릿 예제를 사용한다면, 우측 테이블에 추가하는 지표는 20-30개를 넘기지 말자.
그래프를 만들다가 이 기준점을 넘어갔다면, 덜 중요한 정보는 눈에 덜 띄게 바꾸고, 가능하면 하위 시스템 일부는 다른 콘솔로 분리해주는 게 맞다. 예를 들어, 그래프에선 세세하게 나뉜 데이터 대신 집계 데이터를 보여주고, 우측 테이블로 이동하거나, 거의 잘 안쓰는 데이터는 완전히 제거할 수도 있다. 제거하더라도 언제든지 표현식 브라우저에서 조회해볼 수 있다!
마지막으로, 하나의 콘솔 셋에 마스터를 둘 이상의 두는 것은 힘들다. 장애 모니터링 시 알고 싶은 것들은 (어디에 문제가 생겼나?) 보통 기능들을 개발 중일 때 필요한 것과는 (코너 케이스를 재현하는 사람이 얼마나 되나?) 매우 다른 편이다. 이럴 땐 두 개의 콘솔 셋으로 따로 분리해주는 게 더 좋다.
Next :
Instrumentation
코드 계측을 위한 가이드라인
전체 목차는 여기에 있습니다.