우리는 코끼리를 부분적으로 먹습니다. 예제가 포함된 애플리케이션 상태 모니터링 전략

안녕하십니까!

우리 회사는 소프트웨어 개발 및 후속 기술 지원에 종사하고 있습니다. 기술 지원에는 오류 수정뿐만 아니라 애플리케이션 성능 모니터링도 필요합니다.

예를 들어 서비스 중 하나가 충돌한 경우 이 문제를 자동으로 기록하고 해결을 시작해야 하며 불만족한 사용자가 기술 지원에 문의할 때까지 기다리지 않아야 합니다.

우리는 소규모 회사이고 모니터링 애플리케이션을 위한 복잡한 솔루션을 연구하고 유지할 리소스가 없기 때문에 간단하고 효과적인 솔루션을 찾아야 했습니다.

모니터링 전략

애플리케이션의 기능을 확인하는 것은 쉽지 않습니다. 이 작업은 결코 사소하지 않으며 창의적이라고 할 수도 있습니다. 복잡한 다중 링크 시스템을 검증하는 것은 특히 어렵습니다.

코끼리를 어떻게 먹을 수 있나요? 부분적으로만! 우리는 이 접근 방식을 사용하여 애플리케이션을 모니터링합니다.

모니터링 전략의 핵심은 다음과 같습니다.

애플리케이션을 구성요소로 나누세요.
각 구성 요소에 대한 제어 검사를 만듭니다.

모든 제어 점검이 오류 없이 수행되면 구성 요소가 작동하는 것으로 간주됩니다. 모든 구성 요소가 작동하는 경우 애플리케이션은 정상으로 간주됩니다.

따라서 모든 시스템은 구성 요소 트리로 표현될 수 있습니다. 복잡한 구성 요소는 더 간단한 구성 요소로 분류됩니다. 간단한 구성 요소에는 확인 사항이 있습니다.

벤치마크는 기능 테스트를 수행하기 위한 것이 아니며 단위 테스트도 아닙니다. 제어 점검에서는 구성 요소가 현재 순간에 어떻게 느껴지는지, 기능에 필요한 모든 리소스가 있는지, 문제가 있는지 확인해야 합니다.

기적은 없습니다. 대부분의 검사는 독립적으로 개발되어야 합니다. 하지만 두려워하지 마십시오. 대부분의 경우 하나의 검사에는 5~10줄의 코드가 필요하지만 어떤 논리도 구현할 수 있으며 검사가 어떻게 작동하는지 명확하게 이해할 수 있습니다.

감시 체계

애플리케이션을 구성요소로 분할하고 각 구성요소에 대한 검사를 생각해내고 구현했다고 가정해 보겠습니다. 그런데 이러한 검사 결과를 어떻게 처리해야 할까요? 일부 검사가 실패했는지 어떻게 알 수 있나요?

모니터링 시스템이 필요합니다. 그녀는 다음 작업을 수행합니다.

• 테스트 결과를 수신하고 이를 사용하여 구성 요소의 상태를 확인합니다.
  시각적으로 이는 구성 요소 트리를 강조 표시하는 것처럼 보입니다. 기능적 구성요소는 녹색으로 변하고, 문제가 있는 구성요소는 빨간색으로 변합니다.
• 기본적으로 일반 점검을 수행합니다.
  모니터링 시스템은 일부 검사를 자체적으로 수행할 수 있습니다. 바퀴를 재발명하는 이유는 무엇입니까? 그것을 사용해 봅시다. 예를 들어, 웹사이트 페이지가 열리는지, 서버가 핑을 보내는지 확인할 수 있습니다.
• 문제에 대한 알림을 이해관계자에게 보냅니다.
• 모니터링 데이터의 시각화, 보고서, 그래프, 통계 제공.

ASMO 시스템에 대한 간략한 설명

예를 들어 설명하는 것이 가장 좋습니다. ASMO 시스템의 성능 모니터링이 어떻게 구성되어 있는지 살펴보겠습니다.

ASMO는 자동화된 기상 지원 시스템입니다. 이 시스템은 도로 서비스 전문가가 제빙 재료로 도로를 처리해야 하는 장소와 시기를 이해하는 데 도움이 됩니다. 시스템은 도로 통제 지점에서 데이터를 수집합니다. 도로 통제 지점은 기상 관측소, 비디오 카메라 등 장비가 도로에 설치되는 장소입니다. 위험한 상황을 예측하기 위해 시스템은 외부 소스로부터 일기 예보를 수신합니다.

따라서 시스템 구성은 웹 사이트, 에이전트, 장비 등 매우 일반적입니다. 모니터링을 시작해 보겠습니다.

시스템을 구성 요소로 나누기

ASMO 시스템에서는 다음 구성요소를 구별할 수 있습니다.

1. 개인 계정
이것은 웹 애플리케이션입니다. 최소한 인터넷에서 애플리케이션을 사용할 수 있는지 확인해야 합니다.

2. 데이터베이스
데이터베이스는 보고에 중요한 데이터를 저장하므로 데이터베이스 백업이 성공적으로 생성되었는지 확인해야 합니다.

3. 서버
서버란 애플리케이션이 실행되는 하드웨어를 의미합니다. HDD, RAM, CPU 상태를 확인해야 합니다.

4. 대리인
이는 일정에 따라 다양한 작업을 수행하는 Windows 서비스입니다. 최소한 서비스가 실행 중인지 확인해야 합니다.

5. 에이전트 작업
에이전트가 작동하고 있다는 사실을 아는 것만으로는 충분하지 않습니다. 에이전트는 작업을 수행할 수 있지만 할당된 작업을 수행할 수는 없습니다. 에이전트 구성 요소를 작업으로 분할하고 각 에이전트 작업이 성공적으로 작동하는지 확인해 보겠습니다.

6. 도로 통제 지점(모든 MPC 컨테이너)
도로 통제 지점이 많기 때문에 모든 MPC를 하나의 구성 요소로 결합해 보겠습니다. 이렇게 하면 모니터링 데이터를 읽는 것이 더 편리해집니다. "ASMO 시스템" 구성요소의 상태를 보면 문제가 어디에 있는지 즉각적으로 알 수 있습니다: 애플리케이션, 하드웨어 또는 최대 제어 시스템.

7. 도로 통제 지점(최대 XNUMX개)
이 MPC의 모든 장치가 서비스 가능한 경우 이 구성요소를 서비스 가능한 것으로 간주합니다.

8. 장치
최대 농도 한계에 설치된 비디오 카메라 또는 기상 관측소입니다. 장치가 제대로 작동하는지 확인하는 것이 필요합니다.

모니터링 시스템에서 구성 요소 트리는 다음과 같습니다.

웹 애플리케이션 모니터링

그래서 우리는 시스템을 구성 요소로 나누었습니다. 이제 각 구성 요소에 대한 점검을 해야 합니다.

웹 애플리케이션을 모니터링하기 위해 다음 검사를 사용합니다.

1. 메인페이지 오픈 확인하기
이 점검은 모니터링 시스템에 의해 수행됩니다. 이를 실행하기 위해 페이지 주소, 예상 응답 조각 및 최대 요청 실행 시간을 나타냅니다.

2. 도메인 결제 기한 확인
매우 중요한 점검입니다. 도메인이 미결제 상태로 유지되면 사용자는 사이트를 열 수 없습니다. 문제를 해결하는 데 며칠이 걸릴 수 있습니다. 왜냐하면... DNS 변경 사항은 즉시 적용되지 않습니다.

3. SSL 인증서 확인
요즘 거의 모든 웹사이트는 https 프로토콜을 사용하여 액세스합니다. 프로토콜이 올바르게 작동하려면 유효한 SSL 인증서가 필요합니다.

다음은 모니터링 시스템의 "개인 계정" 구성 요소입니다.

위의 모든 확인 사항은 대부분의 애플리케이션에 적용되며 코딩이 필요하지 않습니다. 어떤 웹 애플리케이션이라도 5분 안에 모니터링을 시작할 수 있다는 점에서 이는 매우 멋진 기능입니다. 다음은 웹 애플리케이션에 대해 수행할 수 있는 추가 검사이지만 해당 구현은 더 복잡하고 애플리케이션별로 다르므로 이 문서에서는 다루지 않습니다.

또 무엇을 확인할 수 있나요?

웹 애플리케이션을 보다 완벽하게 모니터링하려면 다음 검사를 수행할 수 있습니다.

• 기간당 JavaScript 오류 수
• 해당 기간 동안의 웹 애플리케이션 측(백엔드) 오류 수
• 실패한 웹 애플리케이션 응답 수(응답 코드 404, 500 등)
• 평균 쿼리 실행 시간

Windows 서비스 모니터링(에이전트)

ASMO 시스템에서 에이전트는 예약된 작업을 백그라운드에서 실행하는 작업 스케줄러 역할을 합니다.

모든 에이전트 작업이 성공적으로 완료되면 에이전트가 제대로 작동하는 것입니다. 에이전트를 모니터링하려면 해당 작업을 모니터링해야 합니다. 따라서 "에이전트" 구성요소를 작업으로 나눕니다. 각 작업에 대해 모니터링 시스템에 "에이전트" 구성 요소가 "상위" 구성 요소가 되는 별도의 구성 요소를 생성합니다.

Agent 구성 요소를 하위 구성 요소(작업)로 분할합니다.

그래서 우리는 복잡한 구성 요소를 여러 개의 간단한 구성 요소로 나누었습니다. 이제 우리는 각각의 간단한 구성요소에 대한 점검을 해야 합니다. 모니터링 시스템은 하위 구성 요소의 상태에 따라 독립적으로 상태를 계산하므로 상위 구성 요소 "에이전트"에는 검사가 없습니다. 즉, 모든 작업이 성공적으로 완료되면 에이전트가 성공적으로 실행되고 있는 것입니다.

ASMO 시스템에는 XNUMX개가 넘는 작업이 있는데, 각 작업마다 고유한 검사를 수행하는 것이 꼭 필요한가요? 물론 각 에이전트 작업에 대해 고유한 특수 검사를 고안하고 구현하면 제어가 더 좋아지지만 대부분의 경우 범용 검사를 사용하는 것으로 충분합니다.

ASMO 시스템은 작업에 대해 범용 검사만 사용하며 이는 시스템 성능을 모니터링하는 데 충분합니다.

진행 상황 확인 중
가장 간단하고 효과적인 확인은 실행 확인입니다. 검사를 통해 작업이 오류 없이 완료되었는지 확인합니다. 모든 작업에는 이 검사가 있습니다.

검증 알고리즘

각 작업 실행 후 작업 실행이 성공하면 SUCCESS 검사 결과를 모니터링 시스템으로 보내야 하고, 실행이 오류와 함께 완료되면 ERROR를 보내야 합니다.

이 검사를 통해 다음과 같은 문제를 발견할 수 있습니다.

1. 작업이 실행되지만 오류와 함께 실패합니다.
2. 작업 실행이 중지되었습니다. 예를 들어 정지되었습니다.

이러한 문제가 어떻게 해결되는지 좀 더 자세히 살펴보겠습니다.

문제 1 – 작업이 실행되지만 오류와 함께 실패합니다.
아래는 태스크가 실행되었으나 14:00~16:00 사이에 실패한 경우입니다.

그림은 작업이 실패하면 신호가 즉시 모니터링 시스템으로 전송되고 모니터링 시스템의 해당 검사 상태가 경보가 되는 것을 보여줍니다.

모니터링 시스템에서는 확인 상태에 따라 구성요소의 상태가 달라지므로 주의하시기 바랍니다. 점검의 알람 상태는 모든 상위 레벨 구성요소를 알람으로 변경합니다. 아래 그림을 참조하십시오.

문제 2 - 작업 실행이 중지되었습니다(동결됨).
모니터링 시스템은 작업이 중단되었음을 어떻게 이해합니까?

확인 결과에는 유효 기간이 있습니다(예: 1시간). 한 시간이 지나도 새로운 테스트 결과가 없으면 모니터링 시스템은 테스트 상태를 알람으로 설정합니다.

위 사진은 오후 14시에 조명이 꺼진 모습입니다. 00:15에 모니터링 시스템은 테스트 결과(00:14부터)가 부패했음을 감지합니다. 관련 시간(00시간)이 만료되었으나 새로운 결과가 없으므로 확인을 알람 상태로 전환합니다.

16:00에 조명이 다시 켜지고 프로그램이 작업을 완료하고 실행 결과를 모니터링 시스템으로 보내면 테스트 상태가 다시 성공이 됩니다.

어떤 검사 관련성 시간을 사용해야 합니까?

관련성 시간은 작업 실행 기간보다 커야 합니다. 관련성 시간은 작업 실행 기간보다 2~3배 길게 설정하는 것이 좋습니다. 이는 작업이 평소보다 오래 걸리거나 누군가가 프로그램을 다시 로드하는 등의 경우 잘못된 알림을 받는 것을 방지하는 데 필요합니다.

진행 상황 확인 중

ASMO 시스템에는 한 시간에 한 번씩 외부 소스에서 새 예측을 다운로드하려고 시도하는 “Load Forecast” 작업이 있습니다. 외부 시스템에 새로운 예보가 나타나는 정확한 시점은 알 수 없으나, 하루에 2번씩 발생하는 것으로 알려져 있다. 몇 시간 동안 새로운 예측이 없으면 이는 정상이지만 하루 이상 새로운 예측이 없으면 어딘가에서 문제가 발생한 것입니다. 예를 들어 외부 예측 시스템의 데이터 형식이 변경될 수 있으므로 ASMO에서는 새로운 예측 릴리스가 표시되지 않습니다.

검증 알고리즘

작업은 진행 상황(새 일기 예보 다운로드)에 성공하면 SUCCESS 검사 결과를 모니터링 시스템으로 보냅니다. 진행이 없거나 오류가 발생하면 모니터링 시스템으로 아무 것도 전송되지 않습니다.

검사에는 이 시간 동안 새로운 진행 상황이 보장되도록 관련성 간격이 있어야 합니다.

모니터링 시스템은 마지막 스캔 결과의 유효기간이 만료될 때까지 대기하기 때문에, 지연되는 문제에 대해 안내드리오니 양해 부탁드립니다. 따라서 수표의 유효기간을 너무 길게 할 필요는 없습니다.

데이터베이스 모니터링

ASMO 시스템의 데이터베이스를 제어하기 위해 다음 검사를 수행합니다.

1. 백업 생성 확인 중
2. 여유 디스크 공간 확인

백업 생성 확인 중
대부분의 응용 프로그램에서는 서버에 오류가 발생할 경우 프로그램을 새 서버에 배포할 수 있도록 최신 데이터베이스 백업을 유지하는 것이 중요합니다.

ASMO는 일주일에 한 번씩 백업 복사본을 생성해 스토리지로 보냅니다. 이 절차가 성공적으로 완료되면 성공 확인 결과가 모니터링 시스템으로 전송됩니다. 검증 결과는 9일간 유효합니다. 저것들. 백업 생성을 제어하기 위해 위에서 설명한 "진행률 확인" 메커니즘이 사용됩니다.

여유 디스크 공간 확인
디스크에 여유 공간이 충분하지 않으면 데이터베이스가 제대로 작동할 수 없으므로 여유 공간을 조절하는 것이 중요합니다.

수치 매개변수를 확인하려면 메트릭을 사용하는 것이 편리합니다.

측정항목 숫자 변수이며 그 값은 모니터링 시스템으로 전송됩니다. 모니터링 시스템은 임계값을 확인하고 지표 상태를 계산합니다.

다음은 모니터링 시스템에서 "데이터베이스" 구성 요소가 어떻게 보이는지에 대한 그림입니다.

서버 모니터링

서버를 모니터링하기 위해 우리는 다음 검사와 지표를 사용합니다.

1. 여유 디스크 공간
디스크 공간이 부족하면 애플리케이션이 작동할 수 없습니다. 우리는 2개의 임계값을 사용합니다. 첫 번째 수준은 WARNING이고 두 번째 수준은 ALARM입니다.

2. 시간당 백분율로 나타낸 평균 RAM 값
시간당 평균을 사용하는 이유는 다음과 같습니다. 우리는 희귀종에는 관심이 없습니다.

3. 시간당 평균 CPU 비율
시간당 평균을 사용하는 이유는 다음과 같습니다. 우리는 희귀종에는 관심이 없습니다.

4. 핑 확인
서버가 온라인 상태인지 확인합니다. 모니터링 시스템은 이 검사를 수행할 수 있으므로 코드를 작성할 필요가 없습니다.

다음은 모니터링 시스템에서 "서버" 구성 요소가 어떻게 보이는지에 대한 그림입니다.

장비 모니터링

데이터를 얻는 방법을 알려 드리겠습니다. 각 도로 통제 지점(MPC)에 대해 작업 플래너에 "Survey MPC M2 km 200"과 같은 작업이 있습니다. 작업은 30분마다 모든 MPC 장치로부터 데이터를 수신합니다.

통신채널 문제
대부분의 장비는 도시 외부에 있으며 GSM 네트워크는 데이터 전송에 사용되는데 안정적으로 작동하지 않습니다(네트워크가 있거나 없음).

빈번한 네트워크 장애로 인해 처음에는 모니터링에서 MPC 조사를 확인하는 것이 다음과 같았습니다.

문제에 대한 잘못된 알림이 많았기 때문에 이것이 작동하는 옵션이 아니라는 것이 분명해졌습니다. 그런 다음 각 장치에 대해 "진행 확인"을 사용하기로 결정했습니다. 장치가 오류 없이 폴링되면 성공 신호만 모니터링 시스템으로 전송됩니다. 관련 시간은 5시간으로 설정되었습니다.

이제 모니터링은 5시간 이상 장치를 폴링할 수 없는 경우에만 문제에 대한 알림을 보냅니다. 높은 확률로 이는 잘못된 경보가 아니라 실제 문제입니다.

아래는 모니터링 시스템에서 장비가 어떻게 보이는지 보여주는 그림입니다.

중요!
GSM 네트워크 작동이 중지되면 모든 MDC 장치가 폴링되지 않습니다. 모니터링 시스템에서 보내는 이메일 수를 줄이기 위해 당사 엔지니어는 "장치"가 아닌 "MPC" 유형의 구성 요소 문제에 대한 알림을 구독합니다. 이를 통해 각 장치에 대해 별도의 알림을 받는 대신 각 MPC에 대해 하나의 알림을 받을 수 있습니다.

최종 ASMO 모니터링 방식

모든 것을 하나로 모아 우리가 어떤 종류의 모니터링 체계를 가지고 있는지 살펴 보겠습니다.

결론

요약해보자.
ASMO 성능 모니터링을 통해 우리에게 무엇을 가져다 주었나요?

1. 결함 제거 시간이 단축되었습니다.
이전에 사용자로부터 결함에 대해 들었지만 모든 사용자가 결함을 보고하는 것은 아닙니다. 시스템 구성 요소가 나타난 지 일주일 만에 시스템 구성 요소의 오작동에 대해 알게 되었습니다. 이제 모니터링 시스템은 문제가 감지되는 즉시 문제를 알려줍니다.

2. 시스템 안정성이 향상되었습니다.
결함이 더 일찍 제거되기 시작했기 때문에 시스템 전체가 훨씬 더 안정적으로 작동하기 시작했습니다.

3. 기술 지원 통화 횟수 줄이기
이제 많은 문제가 사용자가 알기도 전에 해결되었습니다. 사용자가 기술 지원에 문의하는 빈도가 줄어들기 시작했습니다. 이 모든 것이 우리의 평판에 좋은 영향을 미칩니다.

4. 고객 및 사용자 충성도 향상
고객은 시스템 안정성에 긍정적인 변화가 있음을 확인했습니다. 사용자는 시스템을 사용하면서 발생하는 문제가 줄어듭니다.

5. 기술지원 비용 절감
수동 검사 수행을 중단했습니다. 이제 모든 점검이 자동화되었습니다. 이전에는 사용자로부터 문제에 대해 배웠는데, 사용자가 말하는 문제가 무엇인지 이해하기 어려운 경우가 많았습니다. 이제 대부분의 문제는 모니터링 시스템에 의해 보고되며, 알림에는 기술 데이터가 포함되어 있어 무엇이 잘못되었는지, 어디서 문제가 발생했는지 항상 명확하게 알 수 있습니다.

중요!
애플리케이션이 실행되는 동일한 서버에 모니터링 시스템을 설치할 수 없습니다. 서버가 다운되면 애플리케이션 작동이 중지되며 이에 대해 알릴 사람이 없습니다.

모니터링 시스템은 다른 데이터 센터에 있는 별도의 서버에서 실행되어야 합니다.

신규 데이터센터에서 전용 서버를 사용하고 싶지 않다면 클라우드 모니터링 시스템을 활용하면 된다. 저희 회사는 Zidium 클라우드 모니터링 시스템을 사용하지만 다른 모니터링 시스템을 사용해도 됩니다. 클라우드 모니터링 시스템 비용은 새 서버를 임대하는 것보다 저렴합니다.

권장 사항 :

1. 애플리케이션과 시스템을 구성요소 트리 형태로 최대한 자세히 분류하여 어디에서 무엇이 손상되었는지 이해하는 것이 편리하고 제어가 더욱 완벽해질 것입니다.
2. 구성 요소의 기능을 확인하려면 테스트를 사용하세요. 하나의 복잡한 검사보다는 여러 개의 간단한 검사를 사용하는 것이 좋습니다.
3. 코드로 작성하는 대신 모니터링 시스템 측면에서 측정항목 임계값을 구성하세요. 이렇게 하면 응용 프로그램을 다시 컴파일, 재구성 또는 다시 시작하지 않아도 됩니다.
4. 사용자 정의 검사의 경우 일부 검사는 완료하는 데 평소보다 시간이 조금 더 걸리기 때문에 잘못된 알림을 받지 않도록 관련 시간 여유를 사용하세요.
5. 확실히 문제가 있는 경우에만 모니터링 시스템의 구성 요소가 빨간색으로 변하도록 해보세요. 아무 이유 없이 빨간색으로 바뀌면 모니터링 시스템의 알림에 대한 주의가 중단되고 그 의미가 상실됩니다.

아직 모니터링 시스템을 사용하고 있지 않다면 지금 시작해보세요! 보이는 것만큼 어렵지는 않습니다. 직접 키운 녹색 재료나무를 감상해 보세요.

행운을 빕니다.

출처 : habr.com