시스템이 완전히 계측되면 시스템 인프라와 인프라가 지원하는 앱 간의 데이터를 상호 연관시킬 수 있습니다. 하지만 다양한 앱에 리소스를 할당하는 수천 개의 익명 호스트가 있을 가능성이 높습니다. 어디서 무슨 일이 일어나고 있는지 전체 맥락을 알 수 없기 때문에 관련 데이터를 찾는 것이 부담스러울 수 있습니다. 앱 실패의 인프라 관련 원인을 찾기 위해 모든 데이터를 어떻게 정렬합니까?
목표
이 문서는 인프라 UI 내에서 관련 데이터를 찾는 과정을 안내합니다. 당신은:
- 속성별로 인프라 데이터 필터링
- 추가 컨텍스트 없이 특정 호스트 및 앱 식별
- TimePicker를 사용하여 변경이 발생한 시기를 확인하세요.
호스트 데이터를 탐색하여 중단 원인 찾기
장애가 발생한 호스트 식별
시작하는 방법이 확실하지 않은 경우 처음에는 공지 심각도에 따라 호스트 범위를 지정하는 것이 좋습니다. 요약 페이지 개요를 사용하면 시스템에서 세 가지 중요한 공지 사항이 발생하고 있음을 확인할 수 있습니다.
필터 표시줄을 사용하면 세 가지 중요한 경고에 대한 데이터만 볼 수 있습니다. 이 경우 쿼리는 83개 호스트에서 3개 호스트로 집계된 데이터 범위를 지정하는 alertSeverity = 'CRITICAL' 읽습니다.
아직 설정하지 않은 경우 언제든지 호스트 지표별로 요약 테이블을 정렬할 수 있습니다. 예를 들어, 호스트에 장애가 발생했다는 징후는 없지만 여전히 문제에 대한 알림을 받았다고 가정해 보겠습니다.
- 요약 테이블에서 이름 열을 클릭합니다. 오름차순, 내림차순으로 정렬할 수 있습니다.
- 스크린샷에서는 CPU 사용량을 기준으로 호스트를 정렬했는데, 여기서
host-tower-portland이(가) CPU 99.84%로 맨 위에 배치되었습니다. - 필요한 경우 메모리 사용량, 스토리지 사용량 등에 대해 동일한 프로세스를 반복합니다. 비정상적인 행동 패턴을 찾을 때까지 반복합니다.
- 시간이 있으면 중요한 임계값에 대한 경고 생성을 고려해 보십시오.
앱 이름으로 필터링
사건과 관련된 호스트를 식별한 후에는 클릭하여 해당 호스트에 대한 데이터만 볼 수 있습니다. 이 시나리오에서는 apache-svr01 선택했습니다. 앱 관련 문제를 해결하려고 하므로 호스트 페이지의 서비스 맵부터 시작합니다. 이 지도는 선택한 호스트에 의존하는 앱을 보여줍니다.
apache-svr01 범위 뷰에서 두 개의 앱이 이 호스트에 종속되어 있음을 확인할 수 있습니다. 하나는 경고 중입니다.
이 경우 Orders team 앱이 실패한 앱입니다.
쿼리를 업데이트할 수 있도록 인프라 요약 페이지로 돌아갑니다. 아직 경고하지 않더라도 이 앱과 관련된 모든 호스트를 평가하고 싶습니다. 파트너 세트의 맥락에서 문제 호스트를 보면 앱 오류의 원인을 더 잘 이해할 수 있습니다. 예를 들어, 다른 호스트가 임계값에 접근하고 있거나 다른 호스트에 대한 경고를 생성하지 않았을 수 있습니다.
Orders team 앱과 관련된 호스트를 표시하려면 필터 표시줄을 조정하세요. 이제 쿼리가 apmApplicationNames = Orders team 로 표시되어야 합니다.
이 필터는 초기 apache_svr01 호스트 이상으로 사고 반경을 넓혔지만 여전히 데이터 범위를 관련 세트로 유지했습니다. 여기에서 어떤 리소스 제한이 성능에 영향을 미치는지 자세히 알아볼 수 있습니다.
- 이러한 호스트 중 몇 개만 경고하므로 모든 호스트에 영향을 미칠 수 있는 잠재적인 데이터베이스 문제를 배제할 수 있습니다.
- 대신 시스템, 네트워크, 프로세스, 스토리지 또는 Docker 컨테이너 탭에서 더 자세히 알아볼 수도 있습니다. 이 시리즈의 다음 문서에서는 데이터 동작을 비교하고 상관시키는 방법을 다룹니다.
시간 선택기를 조정하여 변경사항이 처음 발생한 시기를 찾으세요.
시간 선택 도구를 조정하면 시간이 지남에 따라 데이터가 어떻게 변경되었는지 확인할 수 있습니다. 이 작업을 통해 변경 사항이 처음 발생한 시기를 추적할 수 있습니다. 3시간 전과 6시간 전 사이에 전환된 이러한 측정항목 그래프를 살펴보겠습니다.
6시간의 시계열에서는 디스크 사용률이 눈에 띄게 증가하지 않습니다. 3시간 매개변수로 전환하면 대략적인 행동 변화 시작 시점을 확인할 수 있습니다. 측정항목 그래프는 급증 또는 하락이 발생할 때 시각적 단서를 제공합니다.
로드가 예기치 않게 증가한 경우
Events
타일에는 예상되는 이벤트가 많거나 너무 적게 표시됩니다.
Alerts
타일은 현재 위험 또는 경고로 경고 중인 호스트 수를 표시합니다. 시간이 지남에 따라 알림이 꾸준히 증가하면 변경 사항으로 인해 인시던트 동작이 확대되었음을 나타낼 수 있습니다.
타일과 측정항목 그래프는 대략적인 사고 시간을 삼각측량하는 데 도움이 될 수 있습니다. 이는 사고의 원인이 외부 공급업체의 업데이트나 다른 팀의 배포로 인해 발생한 경우 특히 유용합니다. 그렇다면 더 깊이 파고드는 다음 단계가 바뀔 것입니다.
다음은 뭐지?
인프라 데이터를 평가하여 실패한 앱을 찾는 방법을 소개했습니다. 요약 페이지부터 시작하면 시간이 지남에 따라 호스트의 성능을 개요하고 어떤 호스트가 실패한 앱을 지원하는지 확인할 수 있습니다.
하지만 리소스 할당에 대한 결정을 내리기 위해 인프라 데이터를 어떻게 사용합니까? 다음 문서에서는 높은 CPU 문제 해결과 같은 보다 구체적인 사건을 더 깊이 파고드는 방법을 다룹니다.