크론 작업을 모니터링하는 기술?

클러스터에서 cron 작업을 모니터링하는 좋은 기술이 있습니까?

cron을 사용하여 매일 간격으로 작업을 시작하고 있습니다. 정보를 확인하기위한 몇 가지 아이디어 :

1. DB와 같은 "네트워크 인식"장소에 정보를 기록하는 특수 애플리케이션 처리 기능 추가
2. 처리 / 조회를 위해 cron 로그를 중앙 지점으로 주기적으로 전송하는 로그 파일 시스템을 구축합니다 (다른 가능한 로그 파일과 함께)

사람들이 cron과 다른 작업을 별도로 수행하는 데 성공했는지, 또는 작업이 완전히 다른 접근 방식으로 통합되었는지 궁금합니다. 나는 2 번으로 기울고 있지만 더 숙련 된 사람들이 시도 할 수있는 것을 알고 싶습니다.

다른 답변 외에도 :

• 작업이 실제 작업의 리턴 값과 함께 완료되면 파일에 시간 소인을 쓰도록하십시오.
• 반환 값을 원래 발신자에게 다시 전파

우리는 Nagios ( Icinga )가 확인 하기 쉽도록 첫 번째를 사용합니다 . 예를 들어 마지막으로 쓴 타임 스탬프가 n 시간보다 오래된 경우 (필요한 논리 포함)-문제가 있음을 알고 있습니다.

내 일반적인 접근 방식은 다음과 같습니다.

• cron'ed 응용 프로그램이 성공적으로 완료되면 stdout을 생성하지 마십시오.
• 출력을 / dev / null로 파이프하지 마십시오.
• 무언가 잘못되었을 때 의미있는 stderr 출력을 생성하십시오.
• crontab에서 $ MAILTO 주소를 설정하여 해당 오류 출력을 필요한 팀으로 보내십시오.

위의 것 외에도 :

• 문제가 발생하면 stderr에 쓰는 것과 함께 "logger"를 호출하십시오. 중앙 호스트 인 일명 "loghost"로 추가로 전달하도록 syslog를 구성하십시오. (로거는 기본적으로 "user.notice"기능을 사용하지만 변경할 수 있습니다.)

크론 작업을 모니터링하는 데 사용할 수있는 몇 가지 기술이 있습니다.

cronjob 실패에 대한 경보를 받으려면 다음을 수행하십시오.

• cron의 표준 MAILTO = 함수를 사용하십시오. cronjob이 STDERR에서 출력을 생성하면 선택한 주소로 우송됩니다.
• 크론 메일을 추적하고 처리하기 위해 티켓 시스템으로 보낼 수 있습니다.

정보를 "네트워크 인식"장소에 로그인하도록 제안한 시스템은 syslog 와 같은 소리가납니다 . syslog는 로그를 작성하는 간단한 방법을 제공하며 일반적으로 / var / log / messages와 같은 파일을 관리합니다. 로그 메시지를받을 파일 선택과 같은 기본 사용자 정의를 수행 할 수 있습니다.

네트워크 인식 모드에서 Syslog를 시작할 수 있습니다. 예를 들어 슬레이브가 마스터에 로그인 할 수 있도록 구성 할 수 있습니다.

[root@slave ~]#  echo "hello world from slave" | logger -p local1.info

[root@master ~]# tail /var/log/myapp
Jun 29 13:07:01 192.168.1.2 logger: hello world from slave

Red Hat 기반 배포의 경우 구성 예는 다음과 같습니다.

[root@slave ~]# cat /etc/syslog.conf | grep local1
local1.*                                                @192.168.1.3

[root@master ~]# cat /etc/sysconfig/syslog | grep SYSLOGD_OPTIONS
SYSLOGD_OPTIONS="-m 0 -r"

[root@master ~]# cat /etc/syslog.conf | grep local
local1.* /var/log/myapp

첫 번째 구성 행은 local1. * 로그 통지를 @ 192.168.1.3 ( "master")으로 리디렉션합니다. 두 번째 SYSLOGD_OPIONS 행의 -r 플래그는 네트워크 지원을 설정합니다. 마지막으로 세 번째 구성 행은 "master"에서 수신 한 local1. * 메시지를 지시합니다. 파일로).

syslog 접근 방식은 로깅 오류 / 정보에만 적합합니다. 로그 파일은 전자 메일보다 가시성이 떨어 지므로 문제가 발생하지 않으면 로그를 보지 못할 수 있습니다.

syslog 스타일 경로를 선택하면 syslog-ng : http://freshmeat.net/projects/syslog-ng/ 도 고려 하십시오 .

물론 두 가지를 모두 사용하여 두 가지 기술을 모두 활용할 수 있습니다. 예를 들어, 실패와 성공을 syslog하고 실패를 메일로 보내는 것입니다.

StackOverflow에 대한 질문에 비슷한 답변을 게시했습니다 ( https : //.com/questions/21025495/system-for-monitoring-cron-jobs-and-automated-tasks )

Cronitor ( https://cronitor.io )는이 목적을 위해 정확히 만든 도구였습니다. 기본적으로 http 요청을 핑으로 사용하는 추적 신호로 요약됩니다.

그러나 OP가 자신의 의견에서 언급 한 요구 중 하나는 작업 실행에 너무 오래 걸리기 시작할 때 알려야합니다.

나는 똑같은 요구를 가지고 있었고 유사한 도구가 이러한 유형의 모니터링을 쉽게 지원하지 못한다는 것을 알았습니다. Cronitor는 지속 시간을 추적하기 위해 시작 이벤트와 종료 이벤트를 선택적으로 트리거 할 수 있도록하여이 문제를 해결합니다.

매 시간마다 cronjob이 있었지만 시간이 지남에 따라 실행하는 데 1 시간 이상이 걸리기 때문에 지속 시간 추적은 필연적이었습니다. 유용하다고 생각하십시오!

이 글을 쓰는 시점에서 여전히 상당히 발전하고 있지만 https://github.com/jamesrwhite/minicron을 살펴 보는 것이 좋습니다 . 설명하는 문제를 해결하기 위해 개발되었습니다. 명령을 약간 수정하면 작업의 출력 및 종료 상태를 기록하고 해당 데이터를 실시간으로 중앙 서버로 다시 보낼 수 있으며 작업이 실패하면 전자 메일, SMS 및 PagerDuty를 통해 경고를 보낼 수 있습니다 (종료 상태> 0). 또는 필요할 때 실행되지 않습니다.

면책 조항 : 저는 개발자입니다.

이것은 AlertGrid 의 일반적인 사용 사례처럼 보입니다 .

설치가 필요하지 않습니다.이 도구를 사용하려면 다음을 수행해야합니다.

1. cron 작업이 완료 될 때마다 AlertGrid에 Signal을 보냅니다 (이것은 매우 간단한 API로 수행 할 수 있으며 signal은 HTTP 요청 일뿐입니다). 당신은 또한 같은 매개 변수를 보낼 수 있습니다 execution_time!
2. 다음과 같은 알림 규칙을 설정하십시오.

my_job이 X 분 안에 응답하지 않는 경우 (귀하의 경우 시간)-> 관리자에게 SMS 보내기

또는

execution_time> 60 초인 경우-> 관심있는 사람들에게 이메일 보내기

실제로 그게 전부입니다. 멋진 시각적 편집기를 사용하여 알림 규칙을 관리 할 수 ​​있습니다. 변경 사항이있는 경우 소스 코드 나 일부 구성 파일을 수정할 필요가 없습니다. 중앙 집중식 솔루션이므로 한 곳에서 규칙을 관리 할 수 ​​있습니다.

이것이 누군가를 돕기를 바랍니다. 무료 계정이 제공되므로 관심이있는 경우 AlertGrid를 테스트하고 사용할 수 있습니다. AlertGrid 팀원 중 하나입니다. 궁금한 점이 있으면 언제든지 문의하십시오.

크론 작업은 이미 syslog를 통해 기록됩니다. 이 데이터는 다른 표준 서비스 인 syslogd를 사용하여 중앙 서버로 전송할 수 있습니다.

http://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/ 에는이를 설정하는 방법에 대한 자세한 내용이 있습니다.

나는 http://cronrat.com을 사용 하여 cron 작업에 "... 당신의 cronrat url"을 추가 & 컬합니다. 내가 좋아하는 가장 좋은 기능은 초기 계정을 만든 후 아무것도 설정할 필요가 없다는 것입니다. 각 알림은 사용하는 즉시 작동합니다. 따라서 작업을 먼저 설정해야하는 일부 서비스와 달리 자동 도구를 사용하여 아직 존재하지 않는 작업을 시작할 수 있습니다.

이 정확한 요구 후에 Power Cron 을 만들었습니다 . cron 작업에 대한 중앙 집중식 뷰와 다른 클러스터 구성원의 작업 간 종속성에 대한 개념이 필요했습니다.

또한 로그에서 찾을 수있는 것보다 많은 정보가 필요했으며 작업 프로파일 링이 추가되었습니다.

이를 위해 PushMon ( http://www.pushmon.com )을 구축 했습니다. 매일의 업무가 오전 3시에 실행되고 일반적으로 오전 4시에 끝난다고 가정합니다. "매일 오전 4 시까 지"의 PushMon 스케줄을 설정할 수 있습니다. 또는 "1 시간 내에 매일 오전 4 시까 지"와 같은 좀 더 고급 일정입니다. 작업이 실행될 때마다 PushMon URL을 "핑 (ping)"하면 핑 (ping) 누락을 경고합니다. 처리 할 수없는 예외를 잡을 때와 같이 오류가 발생했다는 것을 확실히 알고 있으면 주문형 경고 기능을 사용할 수 있습니다.

Healthchecks ( https://github.com/healthchecks/healthchecks/ )는 크론 작업 모니터링을 위해 정확하게 구축 된 서비스 및 대시 보드입니다. 프로덕션 환경에서 사용 중이며 유지 관리되며 코드 기여를 허용합니다.

Cronitor, Dead Man 's Snitch 및 friends와 유사하게 작동합니다. 완료 직전에 특수한 고유 URL에 HTTP / HTTPS 요청을 작성하도록 cron 작업을 설정했습니다. 상태 확인은 이러한 핑을 받고 기록합니다. 핑이 예상 간격에 도달하는지 지속적으로 확인합니다. 문제가 감지되면 알림을 보냅니다. 지원되는 알림 방법은 이메일, 웹 후크, 슬랙, 텔레 그램, 불일치, SMS, 푸시 오버, Pusbullet, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie입니다.

이 모든 것을 설정하고 직접 호스팅 할 수 있지만 웹 서비스와 마찬가지로 도메인 이름, 인증서를 설정하고 HTTP 리버스 프록시를 구성하고 데이터베이스 백업을 설정하는 등의 노력이 필요합니다. https://github.com/iphoting/healthchecks 이 Heroku 적응 버전을 사용하는 것입니다 . 나는이 프로젝트를 스스로 실행하고 수백 개의 서비스를 모니터링하는 사람들을 알고 있습니다.

면책 조항 : 나는 저자이며 https://healthchecks.io 에서 Healthchecks를 호스팅 서비스로 실행합니다.