Kubernetes Observability

쿠버네티스 모니터링 솔루션

클러스터, 노드, 포드, 컨테이너, 워크로드, 서비스, 이벤트, 로그, 애플리케이션 링크를 동일한 운영 컨텍스트에 배치합니다. 문제가 재부팅, 스케줄링 실패, 인터페이스 느려짐, 릴리스 예외 등을 바탕으로 자원, 구성, 코드 또는 의존성 중 발생하는지 판단하세요.

즉시 시작하세요 데모 일정 잡기

왜 K8s 모니터링은 통합된 모니터링 맥락이 필요한가요?

01객체 관계는 동적으로 변합니다

포드, 노드, 서비스, 워크로드는 자주 변경되어 자동 발견과 지속적인 맥락 연결이 필요합니다.

02자원과 애플리케이션은 서로 영향을 미칩니다

CPU, 메모리, 재부팅, 스케줄링, 인터페이스 시간을 함께 검토하여 문제가 어느 계층에 위치하는지 파악해야 합니다.

03방출 위험은 가시화되어야 합니다

배포, 확장, 구성 변경 후에는 오류율, 지연 시간, 사용자 영향을 신속히 모니터링하는 것이 필요합니다.

04다중 클러스터 거버넌스는 복잡합니다

다중 클러스터, 다중 네임스페이스, 다중 팀 협업은 통합된 태그, 권한, 경고 수준을 필요로 합니다.

Kubernetes Troubleshooting

단일 이상 현상에서 근본 원인까지 같은 증거 사슬을 추적했습니다

팀은 처음에 문제가 어느 층인지 추측할 필요가 없습니다. 실제 장애 신호를 진입점으로 삼아 클러스터, 워크로드, 서비스, 버전 범위를 점차 좁힌 뒤, 메트릭, 이벤트, 로그, 트레이스를 이용해 상호 검증을 진행합니다.

  1. 01

    사업의 영향력을 확인하세요

    인터페이스 지연, 오류율, 알림, 사용자 경험 변화를 바탕으로 영향 범위와 처리 우선순위를 결정합니다.

  2. 02

    실행 중인 객체를 잠그세요

    예외 객체는 클러스터, 네임스페이스, 워크로드, Pod, Node, 버전별로 축소합니다.

  3. 03

    관련 현장에서 나온 증거

    자원 수준, Kubernetes 이벤트, 컨테이너 로그, 트레이스, 릴리스 변경 사항을 동일한 타임라인에 정렬하세요.

  4. 04

    복구 결과를 확인하세요

    변경 전후의 오류, 지연, 자원, 경보 상태를 비교함으로써 증상을 일시적으로 숨기는 것이 아니라 회복을 확인합니다.

첫째, 실패 수준을 추측하지 말고 객체 간 관계를 살펴보세요

Guance Kubernetes 클러스터, 노드, 네임스페이스, 워크로드, 포드, 컨테이너, 서비스, 인그레스, 이벤트 등에서 데이터를 지속적으로 수집하고, 이들 간의 관계를 유지합니다. 팀은 예외 포드에서 워크로드, 노드, 서비스를 계속 볼 수 있고, 서비스 오류로 인해 영향을 받은 인스턴스를 역추적하여 여러 콘솔에 걸쳐 객체와 시간을 수동으로 연결하는 것을 피할 수 있습니다.
데모 일정 잡기
첫째, 실패 수준을 추측하지 말고 객체 간 관계를 살펴보세요
자원 알림 이후에는 서비스가 영향을 미치는지 계속 평가하세요

자원 알림 이후에는 서비스가 영향을 미치는지 계속 평가하세요

CPU, 메모리, 디스크, 네트워크, 자원 요청과 제한, 포드 재부팅, 스케줄링 실패는 단지 경고 신호일 뿐입니다. Guance 자원 수준을 인터페이스 지연, 오류율, 처리량, 대기열, 비즈니스 지표와 동일한 창에 배치하여, 플랫폼과 SRE 팀이 실제 용량 병목, 부당한 구성, 단기 변동을 구분할 수 있도록 돕고, 임계값만을 기반으로 확장하는 데 따른 자원 낭비를 줄입니다.
데모 일정 잡기

릴리스 변경사항, 추적, 로그를 동일한 타임라인에 정렬하세요

출시, 확장 또는 구성 변경 후에는 인터페이스 느려짐, 오류율 증가, 그리고 포드 이상 현상이 동시에 발생하는 경우가 많습니다. Guance 배포, 버전, 서비스, 포드 등 태그를 배포 이벤트, 서비스 토폴로지, APM 추적, 컨테이너 로그에 통합하여, R&D 팀이 이슈가 새 버전, 상류 의존성, 데이터베이스 호출, 자원 경쟁 등으로 인해 발생하는지 판단하는 데 도움을 주며, 검증 가능한 현장 증거를 유지합니다.
데모 일정 잡기
릴리스 변경사항, 추적, 로그를 동일한 타임라인에 정렬하세요
멀티클러스터 거버넌스는 단순한 대시보드 그 이상입니다

멀티클러스터 거버넌스는 단순한 대시보드 그 이상입니다

멀티클러스터 환경은 통합된 객체 명명, 라벨, 권한, 대시보드, 알림 수준을 요구하며, 팀도 비즈니스 경계를 따라 더 깊이 탐색할 수 있어야 합니다. Guance 클러스터, 환경, 네임스페이스, 팀, 서비스별로 데이터를 조직하는 것을 지원하여, 플랫폼, 연구개발(R&D), SRE 팀이 동일한 증거를 공유하면서 각자의 데이터 접근 범위와 경고 책임을 통제할 수 있습니다.
데모 일정 잡기

Connected Observability

쿠버네티스를 온사이트 상태로 완전한 실행 컨텍스트로 되돌리기

제품 카탈로그에서 진입 지점을 다시 검색하지 않고도 현재 문제에 기반한 해당 기능에 계속 접근할 수 있습니다.

컨테이너 모니터링Pods, 컨테이너, 워크로드, 자원 요청 및 제한, 그리고 Kubernetes 이벤트를 볼 수 있습니다. APM 애플리케이션 성능 모니터링서비스 오류와 느린 인터페이스에서 트레이스, 의존성, 코드 메서드로 계속 깊이 들어가세요. 로그 모니터링 및 로그 분석서비스, 포드, 버전, trace_id별로 컨테이너 및 애플리케이션 로그를 검색하세요. 인프라스트럭처 모니터링노드, 호스트, 네트워크, 데이터베이스, 클라우드 자원의 운영 상태를 연계하세요.

이미 프로메테우스나 그라파나가 있나요? 기존 모임 자산 유지를 위한 점진적 이주 가이드를 참조하세요

클라우드 네이티브 기술 스택을 지속적으로 개선하세요

OpenTelemetry 접근

OpenTelemetry 접근

 AWS 모니터링

AWS 모니터링

 알리바바 클라우드 모니터링

알리바바 클라우드 모니터링

 Azure monitoring

Azure monitoring

 화웨이 클라우드 모니터링

화웨이 클라우드 모니터링

자주 묻는 질문

Kubernetes의 모니터링은 어떤 객체를 포함해야 하나요?

일반적으로 클러스터, 노드 노드, 네임스페이스, 배포, 데몬셋, 서비스, 포드, 컨테이너, 네트워크, 스토리지, 이벤트, 로그, 애플리케이션 링크를 포함해야 합니다.

Pod 재부팅이나 서비스 지연을 어떻게 찾아내나요?

Pods, 노드, 자원 수준, 이벤트, 로그, 트레이스 등 여러 층을 층별로 분석하여 문제가 자원 부족, 일정 이상 현상, 의존성 오류, 코드 성능 중 어떤 원인인지 판단할 수 있습니다.

다중 클러스터 환경을 균일하게 모니터링할 수 있을까요?

네, 할 수 있습니다. 태그, 공간, 권한, 대시보드, 알림 정책을 통합하여 동일한 플랫폼 내 여러 Kubernetes 클러스터를 관리할 Guance.

Kubernetes의 모니터링과 컨테이너 모니터링의 차이점은 무엇인가요?

컨테이너 모니터링은 컨테이너와 워크로드 자체에 더 중점을 둡니다; 쿠버네티스 모니터링은 클러스터, 노드, 서비스, 일정, 이벤트, 네트워크, 애플리케이션 간의 관계를 이해하는 것도 필요합니다. 운영 문제 해결은 보통 두 가지를 동일한 맥락에 배치하는 것을 요구합니다.

프로메테우스와 그라파나가 여전히 Guance와 연결될 수 있을까요?

네, 가능합니다. 팀은 기존의 데이터 수집 및 대시보드 기능을 유지한 후, 쿠버네티스 메트릭과 로그, 추적, RUM, 알림 이벤트, 비즈니스 데이터를 통합하여 통합 모니터링 및 모니터링 시스템을 구축하여 도구 간 맥락적 단편화를 점차 줄일 수 있습니다.

클러스터 크기, 장애 시나리오, 기존 도구를 결합해 Kubernetes 모니터링 경로를 계획하세요

데모 일정 잡기

궁금할 수도 있겠네요

지금 > 시작하세요 문서 보기 > 가격을 확인해 보세요>