Snowflake Observe Observability Context Graph란, 장애 원인 추적법

장애 조사에서 막히는 지점

관측 데이터가 많아져도 시스템의 각 부분이 서로 어떻게 연결되는지는 텔레메트리만으로 설명되지 않습니다. 원문도 장애 조사에서 가장 어려운 일은 알림을 찾는 게 아니라 서비스, 인프라, 의존성 전반에서 무슨 일이 있었는지 이해하는 것이라고 짚어요. 보통은 사람이 개별 이벤트를 하나씩 뒤져 이벤트와 리소스를 손으로 엮는 구간입니다. Context Graph는 바로 이 수작업 상관분석을 줄이는 데 맞춰져 있어요.

Context Graph가 구성되는 방식

구조는 데이터 세트, 링크, 상관관계 태그 세 가지로 나뉩니다. 먼저 외부 인프라의 원시 텔레메트리가 통합 기능이나 수집기를 거쳐 Telemetry Data Lakehouse로 들어오고, Observe가 이를 데이터 세트로 가공합니다.

• 데이터 세트: Kubernetes 로그, Prometheus 지표, 트레이스 스팬 같은 형태로 정리돼요. 리소스 데이터 세트는 Kubernetes 파드와 컨테이너, 사용자, 제품, 장바구니 같은 개별 리소스를 기본키로 식별합니다. 기본키는 필드 하나일 수도, 여러 필드의 조합일 수도 있어요.
• 링크: 기본키와 외래키 링크가 리소스 식별을 기준으로 데이터 세트를 잇습니다. 파드 리소스가 자신이 실행되는 노드와 연결되는 식이에요. 리니지는 다른 관계를 보여주는데, 어떤 데이터 세트가 다른 데이터 세트를 만드는 데 쓰였는지를 나타냅니다.
• 상관관계 태그: 'cluster.name'이나 'service.name'처럼 데이터 세트마다 같은 개념을 가리키는 필드에 붙는 라벨입니다. 필드가 같은 태그를 공유하면 Observe가 일치하는 값으로 관련 데이터를 찾아요. 태그 상당수는 지원되는 규칙에 따라 자동으로 붙습니다.

정리하면 데이터 세트가 노드, 링크와 리니지가 엣지이고, 상관관계 태그는 같은 개념으로 데이터 세트 사이를 넘나드는 보완 층이에요. 덕분에 데이터 세트를 하나씩 따로 들여다보지 않고 연결된 채로 조사할 수 있습니다.

화면과 API로 쓰는 방법

그래프는 뒤에서 동작하지만 그 바탕 데이터는 Observe 화면에서 볼 수 있습니다. 데이터 세트 페이지에서 스키마, 속성, 상관관계 태그, 관계를 확인하고, Links와 Focus 뷰에서 데이터 세트 연결을, Lineage 뷰에서 데이터가 파생된 경로를 봅니다. 모든 상관관계 태그를 한곳에서 보는 별도 태그 관리 페이지도 있어요.

API는 에이전트용 접점입니다. 원문 기준으로 조사 흐름은 이렇게 이어져요.

• 'payments', 'apiserver' 같은 용어에서 출발해 'search tag values' API로 서비스나 리소스를 식별하는 상관관계 태그 값을 찾습니다.
• 'list of data sets'와 'list metrics' API로 그 개념에 연결된 데이터 세트와 지표를 찾아요.
• 'list APM services with RED metrics' API 한 번으로 서비스의 요청률, 오류, 지연 시간을 받고, 'invocation graph' API로 서비스 호출 관계를 그려냅니다.

각 답변이 근거가 된 데이터 세트, 지표, 시간 구간을 가리키기 때문에 다음 조사 단계가 맹목적인 탐색이 아니라 표적이 있는 탐색이 됩니다. API는 에이전트가 쓰기 좋게, 불필요한 토큰을 쓰지 않고 정확한 답을 빠르게 돌려주도록 설계됐다고 해요. 태그가 검색 가능한 메타데이터라서 환경에 태그가 수천 개여도 이 방식이 통한다는 설명도 있습니다.

실무 적용 포인트

• 먼저 인프라 데이터를 Telemetry Data Lakehouse에 넣어야 합니다. 원문은 Observe Agent로 수집하길 권하고, 커스텀 통합이나 기존 OpenTelemetry collector도 쓸 수 있다고 안내해요.
• 서비스와 클러스터를 가리키는 필드에 'service.name', 'cluster.name' 같은 공통 태그가 붙는지 점검하세요. 태그가 맞아야 데이터 세트 사이를 같은 개념으로 넘나듭니다.
• 장애 회고 질문을 그래프로 풀어보세요. 새벽 3시에 결제 서비스가 왜 내려갔는지, 최근 배포가 하위 고객에 어떤 영향을 줬는지, 새 기능 배포 후 노드 수를 늘려야 하는지 같은 질문이 원문이 드는 예시입니다.
• 에이전트를 붙인다면 용어 한 개에서 출발해 관련 데이터를 좁혀가는 흐름을 기준으로 권한과 조회 범위를 설계하세요.

자주 묻는 질문

Observability Context Graph란 무엇인가요?

Observe by Snowflake에서 텔레메트리를 연결된 지도로 정리해주는 구조층이에요. 데이터 세트가 노드가 되고, 링크와 리니지가 엣지가 되며, 상관관계 태그가 개념 단위 탐색을 더해줍니다. 사용자는 전체 시스템을 훑으며 인사이트를 찾을 수 있어요.

Snowflake Observe는 장애 원인 추적에 어떻게 쓰나요?

Links, Lineage, Focus 뷰로 데이터 세트 연결과 파생 경로를 직접 살펴볼 수 있어요. 코드에서 API로 그래프를 순회하거나 Observe의 AI SRE에게 조사를 맡길 수도 있습니다. 용어 하나에서 출발해 관련 데이터 세트와 지표로 좁혀가는 방식이에요.

상관관계 태그는 무엇이고 직접 달아야 하나요?

데이터 세트마다 같은 개념을 가리키는 필드에 붙는 라벨입니다. 'cluster.name', 'service.name'이 예시이고, 필드가 같은 태그를 공유하면 일치하는 값으로 관련 데이터를 찾아줘요. 원문에 따르면 지원되는 규칙을 기준으로 상당수가 자동으로 적용되고, 전체 태그는 별도 관리 페이지에서 볼 수 있어요.

시작하려면 무엇이 필요한가요?

먼저 인프라 데이터를 Telemetry Data Lakehouse로 가져와야 합니다. Observe Agent를 권장하고, 커스텀 통합이나 기존 OpenTelemetry collector도 가능합니다.