시스템이 완전히 계측되면 시스템 인프라와 인프라가 지원하는 앱 간의 데이터를 상호 연관시킬 수 있습니다. 하지만 다양한 앱에 리소스를 할당하는 수천 개의 익명 호스트가 있을 가능성이 높습니다. 어디서 무슨 일이 일어나고 있는지 전체 맥락을 알 수 없기 때문에 관련 데이터를 찾는 것이 부담스러울 수 있습니다. 앱 실패의 인프라 관련 원인을 찾기 위해 모든 데이터를 어떻게 정렬합니까?
목표
이 문서는 인프라 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 문제 해결과 같은 보다 구체적인 공지 이벤트를 더 깊이 파고드는 방법을 다룹니다.