관측성 장애 그래프

문제와 백엔드

의존성, 담당 팀, 경보를 연결해 흩어진 텔레메트리를 하나의 진단 경로로 만듭니다. TinkerGraph를 써서 컨테이너와 네트워크 편차를 빼고 모델부터 검증합니다. 먼저 핵심 모델과 TinkerPop을 읽고, 운영 전에는 선택 가이드를 적용합니다.

그래프 모델

정점: Service/Api/Team/Alert/Incident
간선: DEPENDS_ON/OWNED_BY/ALERTS_ON/ROOT_CAUSE
주요 속성: serviceId, apiId, teamId, alertId, incidentId, severity, status

준비와 릴리스 경계

JDK 21, 커밋 3e0fa7cb9e3bc70c2743aeebda2487f3e45e4907, 저장소의 Gradle Wrapper가 필요합니다. 예제는 배포되지 않으므로 릴리스 소스를 체크아웃하고 Gradle 프로젝트로 실행합니다. 소비자 애플리케이션에서는 bluetape4k-dependencies:<ecosystem-version>만 선택하고 필요한 그래프 모듈은 개별 버전 없이 추가합니다.

실행과 관찰

./gradlew :observability-graph-examples:test --tests "io.bluetape4k.graph.examples.observability.TinkerGraphObservabilityIncidentTest"

테스트는 하류 의존성, 영향을 받는 상류 서비스와 공개 API, 여러 경보가 만나는 서비스 경계, 담당 팀을 각각 검증합니다. 실패한 항목에 해당하는 텔레메트리 관계나 상관 경로부터 확인하면 전체 모델 문제와 일부 연결 문제를 구분할 수 있습니다.

코드 읽는 순서

network-topology 다음에 읽고 data-lineage로 이어가십시오. 동기·코루틴 API, 테스트, 운영도 함께 보십시오.

확장과 운영 진단

결과를 바꾸는 간선과 단언을 하나 추가하고 suspend API로 반복하십시오. 영속 백엔드 테스트는 직렬로 실행하고 끊어진 경로와 잘못된 입력도 검증하십시오. 이 고정 데이터는 처리량, 군집, 권한, 테넌트 격리, 마이그레이션, 백업, 원격 드라이버 제한 시간, 인덱스 품질을 증명하지 않습니다.

배포본 다이어그램

아래 그림은 0.5.1 배포본의 README 자산을 해당 배포 커밋에서 직접 불러옵니다. 이후 SNAPSHOT이 아니라 이 매뉴얼 버전의 구조와 실행 흐름을 보여 줍니다. 미리보기를 누르면 같은 배포 커밋의 SVG 원본이 열립니다.