콘솔과 대시보드

콘솔과 대시보드 (Consoles and dashboards)

대시보드에 가능한 한 많은 데이터를 표시하고 싶은 유혹이 크지만, 사실 그 반대로 해야 해요. 이 문서는 운영용 콘솔(console)을 설계할 때 따라야 할 실무 지침을 다뤄요. 정보가 너무 많으면 시스템 전문가조차 의미를 끌어내기 어려운, 뚫을 수 없는 콘솔이 되기 십상이거든요.

핵심은 아주 명확해요. 보유한 모든 데이터를 표현하려 하지 말고, 가장 가능성 높은 실패 모드(failure modes)가 무엇인지 생각하고, 콘솔로 그 실패 모드를 어떻게 구분할지 고민하는 거예요. 이 문서는 그런 접근을 위한 구체적인 지침과 수치 기준도 함께 알려 줘요.

출처: 문서

본문

주의: Prometheus 3.0부터 콘솔 템플릿과 라이브러리는 더 이상 Prometheus에 번들로 포함되지 않아요. 콘솔 템플릿을 사용하려면 --web.console.templates와 --web.console.libraries 커맨드라인 플래그를 지정해 직접 템플릿과 라이브러리를 제공해야 해요. 이 문서 페이지는 역사적 참고를 위해, 그리고 콘솔 템플릿의 기능을 보여 주기 위해 유지보수되고 있어요. Prometheus 2.x 브랜치의 참조된 콘솔 라이브러리는 더 이상 유지보수되지 않으며 알려진 보안 취약점(CVE)을 포함할 수 있다는 점을 알아 두세요.

대시보드에 가능한 한 많은 데이터를 표시하고 싶은 유혹이 들 수 있어요. 특히 Prometheus 같은 시스템이 애플리케이션에 그렇게 풍부한 계측을 제공할 수 있을 때 더 그렇죠. 이는 정보가 너무 많아서 시스템 전문가조차 의미를 끌어내기 어려운, 뚫을 수 없는 콘솔로 이어질 수 있어요.

보유한 모든 데이터 조각을 표현하려고 하기보다는, 운영 콘솔에서는 가장 가능성 높은 실패 모드가 무엇인지, 그리고 그 실패 모드를 구분하는 데 콘솔을 어떻게 사용할지 생각하세요. 서비스의 구조를 활용하세요. 예를 들어 온라인 서빙 시스템에 서비스의 큰 트리가 있다면, 어떤 하위 서비스의 지연시간이 전형적인 문제예요. 모든 서비스의 정보를 하나의 큰 대시보드에 보여 주기보다는, 각 서비스가 통신하는 각자의 지연시간과 오류를 포함하는 각 서비스별 별도 대시보드를 구축하세요. 그러면 위에서 시작해 문제가 있는 서비스까지 내려갈 수 있어요.

다음 지침이 매우 효과적이라는 것을 우리는 발견했어요.

  • 콘솔에 그래프를 5개 이상 두지 마세요.

  • 각 그래프에 플롯(선)을 5개 이상 두지 마세요. 스택/영역 그래프라면 더 두어도 괜찮아요.

  • 제공된 콘솔 템플릿 예제를 사용할 때 오른쪽 테이블에는 20~30개를 넘지 않게 하세요.

이 기준을 넘어서는 자신을 발견한다면, 덜 중요한 정보의 가시성을 낮추는 것이 합리적일 수 있어요. 일부 하위 시스템을 새 콘솔로 분리하는 것도 방법이에요. 예를 들어 분해된(broken-down) 데이터 대신 집계된 데이터를 그래프로 그리고, 오른쪽 테이블로 옮기거나, 거의 유용하지 않다면 데이터를 완전히 제거할 수도 있어요 — 표현식 브라우저에서 언제든 다시 볼 수 있으니까요!

마지막으로, 한 세트의 콘솔이 두 주인을 섬기는 것은 어려워요. 온콜(oncall)일 때 알고 싶은 것(무엇이 고장났는가?)은 기능을 개발할 때 알고 싶은 것(얼마나 많은 사람이 엣지 케이스 X에 부딪혔는가?)과 매우 다르기 마련이에요. 그런 경우 두 개의 분리된 콘솔 세트가 유용할 수 있어요.

더 알아보기 (Learn more)