사용자 단위에서 실행되는 2MB 바이너리와 같은 가벼운 서비스가 있지만 각 서비스마다 약간 다른 구성으로 실행되는 유사한 서비스가 120개 있습니다.
이러한 모든 서비스를 모니터링하고 그 중 하나라도 다운되면 API 엔드포인트를 통해 경고를 발생시키고 싶습니다.
지금까지 나는 목록(한 줄에 하나의 서비스 이름)을 반복하는 bash 스크립트를 작성했으며 다음을 사용하고 있습니다.
systemctl status name.service
서비스의 상태 및 서비스 이름도 표시됩니다 grep. awk마지막으로 if이 while루프에는 서비스 중 하나가 활성화되지 않은 경우(실행 중) 게시물을 API 엔드포인트로 컬링하는 조건이 있습니다.
나는 이 스크립트를 1분마다 실행할 계획입니다. 나는 너무 걱정하지 않으며 다음과 같은 질문이 있습니다.
- 분당 크론이 너무 많은가요?
- 이와 같은 스크립트/크론탭에서 어떤 점에 주의해야 합니까?
- 더 좋은 방법이 있나요? 이것은 나에게 약간 아마추어처럼 보이지만 작업을 수행하는 빠른 방법입니다.
나는 단지 crontab에 문제가 생길 수 있다는 점을 걱정하고 있으며 너무 늦을 때까지 그것에 대해 알 수 없거나 다른 것이 손상될 수 있거나 더 나쁜 경우 시스템이 충돌할 수 있다는 점을 걱정하고 있습니다.
여기에 더 나은 길이 있다면 어떤 아이디어가 있습니까?
답변1
이것은 주석이어야 하는데, 조금 깁니다.
모니터링할 수 있는 무료 소프트웨어 패키지가 너무 많다는 점을 고려하면 이는 문제를 해결하는 이상한 방법처럼 보입니다.
규모 문제가 있습니다(규모 문제는 항상 존재하지만 더 적합한 플랫폼을 사용하면 이러한 문제는 몇 배로 줄어들 수 있습니다). 예를 들어, 각 인스턴스가 응답하는 데 1초 이상 걸리면 어떻게 될까요? 기능적 문제가 있습니다. 감시 창을 정의하는 방법, 문제를 알리는 방법, 모니터링하고 싶지만 알리지 않는 창은 어떻습니까? 개입의 효과를 측정하기 위해 기록을 어떻게 관리합니까? ...
결국 모니터링 플랫폼에서 실행하게 됩니다. 빨리 시작할수록 앞으로는 덜 고통스러울 것입니다.
답변2
스크립트도 필요하지 않으며 폴링도 필요하지 않습니다. systemd는 장치가 실패할 때 무언가를 시작하는 방법을 이미 알고 있습니다. 이 OnFailure=지침을 읽으십시오. 예를 들어, 컬을 사용하여 오류 단위 이름으로 REST 엔드포인트를 호출하는 등 일회성 서비스를 간단히 정의할 수 있습니다.
답변3
이를 수행하는 방법에는 여러 가지가 있습니다. 기존 모니터링 솔루션을 사용하거나 보다 기본적인 솔루션을 구축하도록 선택할 수 있습니다. 시간과 노력을 투자할 가치가 있는지 판단하려면 시장 조사를 수행하고 솔루션을 다른 요구 사항에 맞게 일반화할 수 있는지 알아보세요.
개인적으로 데모 목적으로 Prometheus + Grafana + Alert Manager를 선택하겠지만 이는 사전 경험이 있고 이미 이러한 도구를 사용하고 있기 때문입니다.
간단히 말해서 API 엔드포인트를 노출하는 것이 아이디어입니다.귀하의 신청서에미리 정해진 포트(소위 프로메테우스)에서수출업자). 그런 다음 Prometheus 인스턴스는 엔드포인트("대상")에 연결하고 다음을 가져옵니다.색인주기적으로(기본값은 일반적으로 15초)
Go 또는 Python을 사용하는 경우 애플리케이션에 내보내기를 쉽게 포함할 수 있습니다. 따라서 사용하는 기술 스택에 따라 다릅니다.
나중에 유용할 수도 있지만 지금은 지표에 관심이 없을 수도 있습니다. 그러나 경고 관리자를 사용하면 특정 시간 또는 연결 시도 후에 엔드포인트가 더 이상 응답하지 않을 때 경고를 받을 수 있습니다. 그러면 일반적으로 장치에 액세스할 수 없거나 엔드포인트가 충돌했음을 의미합니다. 당신이 원하는 것 같네요.
한 가지 이점은 다음과 같습니다.역사또한. 따라서 문제가 발생한 시기를 알면(로그와 연관되어) 문제를 더 쉽게 추적할 수 있습니다.
아키텍처에서 허용하는 경우 모니터링을 위해 별도의 장치를 사용하는 것이 합리적입니다. 여기서의 아이디어는 외부 프록시가 서비스를 조사(풀)하도록 하는 것입니다. 실패한 서비스가 항상 알림(푸시)을 보내고 정상적으로 중단될 수 있는 것은 아닙니다.
하지만 귀하의 서비스가 내부적으로 실제로 무엇을 하는지 아는 것은 흥미로울 것입니다.즉, 실패가 무엇을 의미하는지, 원하는 결과가 어떤 모습이어야 하는지 정의합니다. 서비스가 HTTP 쿼리에 응답한다고 해서 반드시 예상대로 작동한다는 의미는 아닙니다. 이는 인터넷 액세스, 파일 액세스 또는 기타 기능과 같은 특정 기능에 따라 달라질 수 있습니다. 지표가 유용한 곳입니다.
예를 들어 웹 서버 내보내기는 전송된 바이트 또는 제공된 페이지와 같은 측정항목에 대한 누적 및 평균 데이터를 반환합니다. 숫자 중 일부가 0으로 떨어지면 어딘가에 문제가 있다고 의심할 수 있습니다. 결국 웹 서버는 제대로 작동하지만 업스트림 네트워크 중단으로 인해 액세스할 수 없어 측정항목이 중단될 수 있습니다.
API 엔드포인트를 갖는 것은 재미있지만, 단순히 "일어났어요"라고 말하는 것보다 실제로 유용한 정보를 제공한다면 훨씬 더 재미있을 것입니다.