올바른 모니터링 데이터 수집

클라우드 솔루션의 상태 및 가용성을 관찰하면 시스템에서 예상되는 신호를 파악하여 수집해야 하는 데이터를 결정할 수 있습니다.

이 문서는 클라우드 모니터링 가이드의 시리즈의 일부입니다.

데이터 수집 고려 사항

모니터링 구성에 대한 기준을 설정하려면 다음 질문을 스스로에게 묻습니다.

• 서비스 컴퍼지션: 서비스의 구성은 무엇인가요? 현재 이러한 종속성이 모니터링되고 있나요? 그렇다면 여러 도구가 관련되어 있으며 추가 위험을 도입하지 않고 통합할 수 있는 기회가 있나요?

• 예측 가능한 오류 상태 정의: 이러한 신호는 원인이 아니라 실패의 증상입니다. 모니터링 도구는 고급 진단 및 근본 원인 분석을 위해 메트릭과 로그를 사용합니다.

• 서비스 SLA: 서비스의 SLA(서비스 수준 계약)는 무엇이며 어떻게 측정하고 보고합니까?

• 서비스 대시보드 디자인: 인시던트 검토 시 서비스 대시보드는 어떤 모습일까요? 서비스 소유자와 서비스를 지원하는 팀에게 대시보드는 어떤 모습이어야 하나요?

• 리소스 메트릭: 모니터링해야 하는 솔루션에서 생성되는 리소스 메트릭은 무엇인가요?

• 로그 검색: 서비스 소유자, 지원 팀 및 기타 직원이 로그를 검색하려면 어떻게 할까요?

• 관련자 참여: 계획 단계에서 모니터링 서비스 소유자, IT 운영 관리자 및 기타 이해 관계자를 포함합니다. 모니터링 솔루션의 개발 및 릴리스 주기 전반에 걸쳐 계속 참여합니다.

• 중요한 데이터: 운영자에게 노출하지 않으려는 애플리케이션에 대한 수집을 피해야 하는 중요한 데이터는 무엇인가요?

이러한 질문에 답하는 방법과 경고 기준에 따라 모니터링 플랫폼을 사용하는 방법이 결정됩니다.

필요한 모니터링 신호 평가

새 모니터링 솔루션을 사용하여 새 워크로드를 배포하든, 기존 모니터링 플랫폼 또는 모니터링 도구 집합에서 마이그레이션하든 관계없이 필요한 모니터링 신호를 평가하는 것이 중요합니다. 필요한 신호를 신중하게 디자인하면 예상 결과를 유도하고 노이즈를 줄일 수 있습니다.

다음을 고려하십시오.

• 실행 가능: 모니터링 데이터는 노이즈 및 가양성 감소를 위해 실행 가능해야 합니다.
• 최적화됨: 수집된 데이터를 최적화하여 서비스의 전반적인 상태를 전체적으로 볼 수 있습니다.
• 인시던트 계측: 실제 인시던트 식별을 위해 정의된 계측은 가능한 한 간단하고 예측 가능하며 안정적이어야 합니다.

모니터링 구성 개발

일반적으로 모니터링 서비스의 소유자와 해당 팀은 표준 활동 집합을 준수하여 모니터링 구성을 만듭니다. 이러한 활동에는 계획 단계, 비프로덕션 환경에서 테스트 및 유효성 검사, 프로덕션에 배포 등이 포함됩니다.

모니터링 구성을 개발하기 위해 팀은 알려진 오류 모드, 시뮬레이션된 실패로 인한 테스트 결과 및 서비스 데스크, 운영 담당자, 엔지니어 및 개발자와 같은 조직 내의 다양한 개인의 경험을 활용합니다.

이러한 구성은 서비스가 이미 존재하고 클라우드로 마이그레이션 중이며 재구성되지 않았다는 가정 하에 설계되었습니다. 서비스 수준 품질 결과를 달성하려면 개발 프로세스 초기에 이러한 서비스의 상태 및 가용성을 모니터링해야 합니다. 서비스 또는 애플리케이션의 설계를 모니터링하는 것이 사후 고려 사항으로만 간주되는 경우 결과는 성공하지 못할 수 있습니다.

인시던트를 더 빨리 해결하려면 다음 권장 사항을 고려합니다.

• 개별 구성 요소 대시보드: 애플리케이션 및 인프라의 지정된 영역에서 알려진 문제를 신속하게 식별할 수 있도록 각 서비스 구성 요소에 대한 대시보드를 정의합니다.

• 메트릭 사용: 근본 원인을 식별할 수 없는 경우 다양한 구성 요소에 기본 제공되는 메트릭 신호를 활용하여 해결 방법 또는 해결 방법을 진단하고 식별할 수 있습니다.

• 대시보드 사용자 지정 사용: 모니터링 대시보드에서 데이터를 쉽게 드릴다운할 수 있도록 대시보드를 디자인합니다. 보기를 동적으로 사용자 지정하여 쉽게 필터링하고 문제를 해결할 수 있도록 지원해야 합니다.

이 기본 원칙을 수용하면 거의 실시간에 가까운 인사이트와 더 나은 서비스 관리를 제공하는 데 도움이 될 수 있습니다.

다음 단계

응답 전략