저는 웹 서비스를 관리하고 있는데 서비스가 중단되었는지, 그리고 수행하는 작업이 응답하는 데 너무 오래 걸리는지 여부를 회사에서 감지하고 알리는 것이 매우 중요합니다. 지금까지 15분마다 해당 엔드포인트에 임의의 작업을 요청하기 위해 별도의 웹 애플리케이션(프런트 엔드와 백엔드 포함)이 있었지만 이 목적을 위해서만 전체 웹 애플리케이션을 유지 관리해야 하므로 복잡하다는 것을 알았고 많은 무료 웹 서비스를 알고 있습니다. 그 일을 해야 합니다.
폴링 웹앱을 대체하기 위해 AWS Healthchecks를 설정했으며 가동 시간 부분에 완벽하게 작동합니다. 이제 질문은 응답 시간 부분과 함께 제공됩니다.
이러한 모든 API 상태 확인 서비스는 그리 복잡하지 않은 요청에 대해 준비된 것으로 보이므로 상태 확인 서비스에 대한 "상태" 끝점을 제공하고 데이터베이스 대기 시간과 같은 "정상" 항목을 포함하는 API의 책임이거나 "상태 확인기"여야 합니다. " 복잡한 요청을 수행하는 사람이요? 어떤 접근 방식이 더 정확합니까?
감사해요!
답변1
애플리케이션의 상태 확인 경로를 통해 데이터베이스 성능을 모니터링해서는 안 됩니다. 일부 위험한 경우가 발생할 수 있습니다. AWS 내에서 ASG를 사용하고 ASG가 시스템을 회전해야 하는지 결정하기 위해 LB 상태 확인을 사용한다고 가정해 보겠습니다. 앱과 관련되지 않은 데이터베이스 경합이 발생하기 시작하면 ASG가 노드 제거를 시작합니다. 따라서 데이터베이스 성능이 좋지 않을 뿐만 아니라 ASG도 고갈됩니다.
일반적으로 성능은 상태 범위 밖에서 모니터링해야 합니다. 우리는 statsd를 많이 사용하고 모든 지표, 애플리케이션 및 데이터베이스를 여기에 펌핑하여 이를 기반으로 그래프를 작성하고 경고할 수 있습니다.
또한 확장함에 따라 상태 확인 속도도 함께 확장된다는 점을 명심하세요. 초당 수천 개의 상태 확인 요청을 수신하는 일부 서비스가 있으며, 각 서비스가 비용이 많이 드는 합성 쿼리를 수행하는 경우 데이터 계층이 오프라인 상태가 됩니다. .
캐싱 레이어를 추가하면 논리도 더욱 복잡해집니다. 데이터베이스는 정상이지만 KV 캐시는 그렇지 않은 경우 상태 확인 엔드포인트는 무엇을 반환해야 할까요?
전반적으로, 효과적인 모니터링 전략을 위해서는 엔드투엔드 모니터링이 중요하지만, 데이터베이스로 흐르는 기존 쿼리 지표에 대해서는 대역 외 모니터링을 적극 권장합니다. 이는 실제 사용자 성능을 대표하며 정량화 가능한 지표를 제공합니다. 애플리케이션 상태가 실제로 어떻게 작동하는지.