[나이팅게일 모니터링] 알람 관리, 훌륭해요!

모니터링이 방법이고, 알람이 수단이며, 솔루션이 목적입니다.

그런데, 이런 혼란을 겪어보신 적 있으신가요? 수많은 지표를 수집했지만 어떤 지표가 알람을 발생시켜야 하는지, 이러한 알람을 해당 팀이나 개인에게 어떻게 보내야 하는지, 알람을 어떻게 업그레이드해야 하는지 모르겠습니다.

전에 Prometheus+Altermanager를 사용할 때는 팀별로 DingTalk 그룹을 만든 다음 여러 개의 태그를 추가하고 서로 다른 태그를 일치시켜 서로 다른 그룹에 보냈습니다. 시간은 임계값 업그레이드를 통해 달성되지만 동일한 알람은 시간 업그레이드를 통해 처리하기 어렵습니다.

하지만 나이팅게일의 알람 규칙 관리는 그렇게 복잡하지 않고(복잡한 일을 대신 해준다) 매우 우아합니다. "[나이팅게일 모니터링]"에서 나이팅게일을 처음 만났는데, 아직도 강렬해요! 》​​언급됨: Grafana는 모니터링 패널 관리에 더 뛰어나고 N9e는 알람 규칙 관리에 더 좋습니다.

오늘은 나이팅게일이 어떻게 플레이하는지 살펴보겠습니다.

경보 규칙

군인과 말은 아직 움직이지 않으며 음식과 풀이 먼저입니다.

경보하려면 먼저 우리에게 필요한 것이 무엇인지 알아야 합니다. 즉, 어떤 지표에 경고해야 하는지 이해해야 합니다.

예를 들어, 시스템 수준에서는 CPU, 메모리, 디스크, IO 및 기타 지표를 애플리케이션 수준에서 고려해야 하며, 비즈니스 수준에서는 애플리케이션의 포화도, 실패율 및 지연을 고려해야 합니다. 이번에는 실패한 트랜잭션 수, 실패한 트랜잭션 수 등을 고려해야 합니다.

다양한 수준에서는 고려되는 모니터링 지표와 경보 전략이 달라집니다.

나이팅게일의 알람 규칙은 기본 제공 규칙과 사용자 정의 규칙으로 구분됩니다.

내장된 규칙은 모든 사람이 사용할 수 있는 임계값을 낮추고 모든 사람에게 일련의 보편적인 규칙을 제공하도록 설계되었습니다. 주요 내용은 다음과 같습니다.

내장된 알람 규칙은 규칙에 추가하지 않으면 적용되지 않습니다. 특정 규칙이 마음에 들면 이를 활성 규칙에 복제할 수 있습니다. 예를 들어 Linux TIME_WAIT 경보 규칙을 기본 비즈니스 그룹에 복제했습니다.

그런 다음 알람 규칙 개요로 이동하면 기본 비즈니스 그룹에 새로운 알람 규칙이 추가된 것을 확인할 수 있습니다.

이것을 보고 마음에 떠오르는 영감이 있으신가요?

실제 상황에 따라 여러 비즈니스 그룹을 생성한 후, 여러 비즈니스 그룹과 관련된 알람 규칙을 별도로 관리할 수 있나요?

프론트 오피스와 미들 오피스의 두 팀이 있다고 가정하면 지표를 별도로 분류할 수 있습니다.

원칙적으로 기본적으로 가져온 규칙은 유효하지 않으며 몇 가지 추가 구성이 필요합니다.

알람 규칙 이름을 클릭하여 구성 페이지로 들어갑니다.

알람 조건, 데이터 소스, 알람 수준 및 기타 구성을 맞춤 설정할 수 있습니다. 위에서 구성한 정보를 요약하면 다음과 같습니다.

알람의 데이터 소스는 local_prometheus이며, 이는 알람이 어느 클러스터에서 왔는지 나타냅니다.
• 알람 조건은 총 TIME_WAIT 횟수가 20000보다 클 때만 알람이 발생하는 것입니다.
• 알람레벨은 2레벨로 일반적인 중요레벨입니다.
• 실행 빈도는 15초마다 1회입니다. 60초 동안 계속해서 알람이 발생하면 알람이 발생합니다.

다음 단계는 다음과 같은 추가 구성입니다.

알람 규칙을 구성하는 데 사용됩니다. 어떤 기간과 어떤 비즈니스 그룹이 적용됩니까? 알림 구성은 알림 매체, 즉 알람이 발생하면 어떤 채널을 통해 어떤 장소로 보내야 하는지를 구성하는 것입니다.

그러나 알림 구성에서 추가 구성을 할 수도 있습니다.

• 복구 알림을 시작합니다. 즉, 알람이 복구되면 담당자에게도 이 채널을 통해 알림이 전송됩니다.
• 알람 수신 그룹, 비즈니스 그룹이라고도 합니다.
• 알람이 복원된 후 비즈니스 그룹에 복구 알림을 보내는 데 걸리는 시간을 관찰하세요. 경보 및 복구와 같은 문제를 피할 수 있는 휘발성 경보는 무엇입니까?
• 반복 알림, 즉 이 기간 내에 알람이 해결되지 않으면 다시 전송됩니다. 물론 여기에는 경보 에스컬레이션이 포함되지 않습니다.

이것을 보고 일반적인 알람 규칙 관리에 대해 어느 정도 이해가 되셨나요?

내장된 알람 규칙을 복제하는 것 외에도 알람 규칙을 사용자 정의할 수도 있지만 전체적인 구성은 위와 동일합니다.

Block Alarms

일반적으로 차단된 알람은 그다지 중요한 알람은 아닙니다.

어떤 상황에서 알람이 차단되나요?

예를 들어, 애플리케이션을 게시할 때 필연적으로 문제가 발생하게 됩니다. 이때 알람 메시지가 생성되지 않도록 사전에 몇 가지 차단 규칙을 만들 수 있습니다.

차단 규칙도 비즈니스 구성 요소별로 나누어 다음과 같이 새 규칙을 추가하여 메시지 센터 알람을 차단하는 규칙을 만들 수 있습니다.

이를 통해 정해진 시간 내에 알람 정보가 더 이상 전송되지 않습니다.

이렇게 하나씩 추가하는 게 좀 번거롭다고 하시는 분들도 계실 텐데요.

발생한 활성 알람인 경우 클릭 한 번으로 차단할 수 있습니다.

과거 알람이라면 클릭 한번으로 차단도 가능합니다.

또 무엇이 있나요?

무엇이든 차단하고 싶다면 직접 추가하세요!

알람 업그레이드

알람이 일정 시간 내에 처리되지 않으면 어떻게 해야 하나요?

중요한 경고가 아니더라도 규칙을 삭제하고 쓸모 없게 두세요.

또는 해결할 수 없는 알람일 수도 있습니다. 업그레이드하여 더 많은 사람들에게 알리세요.

나이팅게일에서는 구독 규칙에서 알람 업그레이드를 구현할 수 있습니다.

예를 들어 구성은 다음과 같습니다.

server=notice의 알람 이벤트가 1시간 이내에 해결되지 않으면 알람 수준을 1단계로 업그레이드하고 알람 정보를 더 높은 수준으로 보냅니다. 그룹.

여기의 규칙은 사업팀별로 분류하여 관리할 수도 있습니다.

이외에도 현재 알람 정보와 알람 내역을 확인할 수 있습니다.

알람 자가 치유

운영 및 유지 관리 작업이 길어질수록 실제로 많은 일의 처리가 반복된다는 것을 알게 될 것입니다. 일부 단순하고 반복적인 작업은 자동화된 스크립트를 통해 처리될 수 있어 작업 효율성이 향상될 뿐만 아니라 , 또한 특정 수준에서 작업 효율성을 향상시킵니다. 인간 작업의 위험을 어느 정도 줄입니다.

나이팅게일은 알람 자가 치유 기능을 제공합니다. 기능은 좋으나 욕심내지 마세요.

알람을 처리할 때는 먼저 알람의 실제 원인을 찾아야 문제를 해결할 수 있습니다. 따라서 알람 자가 치유를 위해서는 자동화된 작업의 위험이 매우 낮으며 여러 번 시도했다는 점을 이해해야 합니다. cd /opt/aaa;rm -rf ./ 작업을 사용하지 마십시오.

나이팅게일에서는 ibex 템플릿을 사용하여 알람 자가 치유를 구현합니다. 현재 ibex-server 쪽은 자체적으로 배포해야 하며, ibex-agent 쪽은 Categraf에 통합되었습니다.

Deploy ibex-server

바이너리 패키지를 다운로드하려면 https://github.com/flashcatcloud/ibex/releases로 이동하세요. 다운로드한 후 다음 파일이 있습니다.

# ll
total 21536
drwxr-xr-x 3 root root 4096 Apr 19 10:44 etc
-rwxr-xr-x 1 root root 16105472 Nov 152021 ibex
-rw------- 1 root root5931963 Jun32022 ibex-1.0.0.tar.gz
drwxr-xr-x 2 root root 4096 Nov 152021 sql

데이터베이스 가져오기:

mysql -uroot -p <sql/ibex.sql

그런 다음 주로 데이터베이스 구성을 수정하여 /etc/server.conf 구성 파일을 수정합니다.

마지막으로 서버 시작:

nohup ./ibex server &> server.log &

클라이언트 구성

시스템 구성에서​->알림 구성​->알람 자가 치유 모듈 구성 해당 서버 주소:

테스트 자가 치유

그런 다음 알람 자가 치유​->자가 치유 스크립트로 이동하여 다음과 같이 스크립트를 추가합니다.

저장하고 종료하고 작업 생성을 클릭합니다.

내부 구성을 수정할 필요가 없거나 해당 구성을 수정한 후 즉시 실행을 선택하세요.

이쯤 되면 괜찮다고 생각하시나요?

어쨌든 성공하지 못했습니다. 이 시점에서 이 모듈에 대해 불평해야 합니다.

• ibex-server 배포를 위한 전제 조건이 있습니까?
• ibex-agent(categraf)에 대한 전제 조건이 있나요?
• 자가 복구 스크립트 실행에 실패했습니다. 클라이언트나 서버에 특정 오류 로그가 없습니다.
• N9e V6 버전의 알람 자가 복구 구성 항목을 메시지 알림 모듈에 넣는 방법은 무엇입니까? 이상해요
• 이 모듈의 공식 문서는 좀 너무 간단해요

그래서 저는 여기서 성공하지 못했습니다. 프론트엔드에서 타임아웃이 발생했습니다.

백엔드에 로그가 없습니다.

요약

현재 Nightingale은 경보 규칙 관리, 경보 채널 배포, 경보 메시지 억제 및 업그레이드를 상대적으로 완료할 수 있으며 FlashDuty는 대부분의 기업에서 충분한 다양한 클러스터 경보에 액세스할 수 있습니다.

알람 자가 치유 테스트 시에만 테스트에 성공하지 못했습니다. 내 환경과 관련이 있어야 합니다.

• N9e의 전체 모듈은 Helm을 사용하여 K8s에 배포되지만 ibex 서버 측은 바이너리 형식으로 호스트에 직접 배포됩니다.
• 그러나 특별한 이유는 없습니다. 문제 해결 후 , 사용 가능한 문제 해결 정보가 너무 적었습니다.

위 내용은 [나이팅게일 모니터링] 알람 관리, 훌륭해요!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!