데이터센터 도시에서의 가동 시간 및 지연 시간 모니터링

데이터센터 도시에서 모니터링하는 이유는 무엇입니까?

데이터센터 도시에서 모니터링하면 사용자 트래픽이 통과하는 네트워크 허브에서 서비스가 어떻게 동작하는지 보여줍니다. 사무실에서의 확인은 하나의 경로만 테스트합니다. 프랑크푸르트, 싱가포르 또는 상파울루에서의 확인은 해당 지역에 제공되는 경로, DNS 응답 및 CDN 엣지를 테스트합니다.

이것이 답하는 일반적인 질문:

• 모든 시장에서 사이트가 응답합니까, 아니면 특정 지역에서 오류가 발생합니까?
• CDN이 도쿄 방문자를 아시아 엣지로 보냅니까, 아니면 멀리 버지니아까지 보냅니까?
• DNS 또는 인증서 변경이 모든 지역에 반영되었습니까?
• 느린 페이지는 서버 문제입니까, 거리 문제입니까?

데이터센터 IP는 데이터센터 경로를 측정하며, Wi-Fi나 모바일을 통한 가정 사용자의 마지막 구간을 측정하지 않습니다. 이는 반복 가능한 확인에는 장점이고, 실제 사용자 타이밍이 필요할 때는 한계입니다.

두 도시 간의 최소 지연 시간은 얼마입니까?

밀리초 단위의 최소 왕복 시간은 킬로미터 단위 거리를 100으로 나눈 값과 거의 같습니다. 광섬유 내 빛은 밀리초당 약 200km를 이동하며, 왕복은 거리를 두 번 이동합니다. 실제 경로는 직선보다 길기 때문에 측정값은 더 높습니다.

해당 페이지의 거리를 기준으로 한 데이터센터 도시 페이지 중 가장 가까운 쌍:

암스테르담에서 런던 서버로의 확인이 40ms 걸린다면, 거리로 설명되는 것은 4ms 미만입니다. 라우팅, TLS 설정 또는 서버를 살펴보십시오. 도시 데이터 표에는 각 도시의 시설과 가장 가까운 이웃이 나열되어 있습니다.

프록시는 측정값을 어떻게 바꿉니까?

프록시는 모든 요청에 구간을 하나 추가합니다: 검사기가 프록시와 통신하고, 프록시가 서비스와 통신합니다. 총 시간은 두 구간의 합이므로, 도쿄 IP를 사용하는 파리의 검사기는 대부분 파리에서 도쿄까지를 측정합니다.

수치를 해석하는 두 가지 명확한 방법:

1. 검사기를 프록시 근처에서 실행하십시오. 같은 지역의 작은 서버는 첫 구간을 짧게 유지하므로, 타이밍이 선택한 도시를 반영합니다.
2. 첫 구간을 별도로 측정하십시오. 프록시를 통해 가벼운 엔드포인트로 요청 시간을 재고, 그 기준값을 서비스 타이밍에서 빼십시오.

가동 시간만 본다면 추가 구간은 중요하지 않습니다: 문제는 해당 도시에서 서비스가 응답하는지 여부와 어떤 상태 코드와 콘텐츠로 응답하는지입니다.

# Documentation address; use an IP, port and credentials from your account
curl -x http://USERNAME:[email protected]:8000 \
  -o /dev/null -s \
  -w "status=%{http_code} connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" \
  https://example.com/health

간단한 다중 도시 모니터는 어떻게 구축합니까?

간단한 다중 도시 모니터에는 지역당 IP 하나, 자체 측의 상태 확인 URL 하나, 스케줄러 하나가 필요합니다.