Kỹ thuật giám sát nhiệm vụ cron?

Có các kỹ thuật tốt để giám sát các tác vụ cron qua một cụm không?

Chúng tôi đang bắt đầu sử dụng cron để khởi chạy các nhiệm vụ hàng ngày. Một vài ý tưởng để kiểm tra thông tin:

1. Thêm xử lý ứng dụng đặc biệt để ghi thông tin vào một số nơi "nhận biết mạng", như DB
2. Xây dựng một hệ thống logfile chuyển nhật ký cron định kỳ đến một điểm trung tâm để xử lý / truy vấn (cùng với các tệp nhật ký có thể khác)

Tôi tự hỏi liệu mọi người có thành công với việc làm mọi thứ riêng biệt cho cron so với những thứ khác hay không, nếu các nhiệm vụ được tích hợp hoàn toàn vào một cách tiếp cận khác. Tôi đang nghiêng về số 2, nhưng tôi muốn biết những gì dân gian có kinh nghiệm hơn có thể thử.

Ngoài các câu trả lời khác:

• hãy để công việc viết dấu thời gian vào một tệp khi nó kết thúc cùng với giá trị trả về từ công việc thực tế
• tuyên truyền giá trị trả về cho người gọi ban đầu

Chúng tôi sử dụng lần đầu tiên để giúp Nagios ( Icinga ) dễ dàng kiểm tra hơn, ví dụ: nếu dấu thời gian bằng văn bản cuối cùng cũ hơn n giờ (cộng với bất kỳ logic nào bạn cần) - chúng tôi biết đã xảy ra sự cố.

Cách tiếp cận phổ biến của tôi là như vậy:

• Không tạo ra bất kỳ thiết bị xuất chuẩn nào khi ứng dụng cron'ed của bạn hoàn thành thành công.
• Không đặt bất kỳ đầu ra nào thành / dev / null.
• Đừng tạo ra đầu ra stderr có ý nghĩa khi có sự cố.
• Đừng đặt địa chỉ $ MAILTO trong crontab để gửi đầu ra lỗi đó đến nhóm được yêu cầu.

Ngoài những điều trên:

• Gọi "logger" cùng với viết vào stderr khi có sự cố. Định cấu hình nhật ký hệ thống để chuyển tiếp đến máy chủ trung tâm, còn gọi là "loghost". (Logger sẽ sử dụng tiện ích "user.notice" theo mặc định, nhưng bạn có thể thay đổi nó.)

Có một vài kỹ thuật bạn có thể sử dụng để theo dõi cronjobs.

Để nhận thông báo về sự cố cronjob:

• Sử dụng chức năng MAILTO = tiêu chuẩn của cron. Nếu một cronjob tạo đầu ra trên STDERR, nó sẽ được gửi đến địa chỉ bạn chọn.
• Để theo dõi và đối phó với các thư điện tử, bạn có thể hướng chúng vào một hệ thống bán vé.

Hệ thống bạn đề xuất để đăng nhập thông tin vào một nơi "nhận biết mạng" nghe có vẻ như syslog . syslog cung cấp một phương thức đơn giản để tạo nhật ký, nó thường quản lý các tệp như / var / log / message. Bạn có thể thực hiện các tùy chỉnh cơ bản, chẳng hạn như chọn tệp nào nhận thông điệp tường trình.

Syslog có thể được bắt đầu trong chế độ nhận biết mạng. Ví dụ: bạn có thể định cấu hình nó để nô lệ có thể đăng nhập vào bản gốc:

[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

Đối với phân phối dựa trên Red Hat, cấu hình ví dụ như sau:

[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

(Dòng cấu hình đầu tiên chuyển hướng local1. * Thông báo nhật ký tới @ 192.168.1.3 ("chính") thành một tập tin).

Cách tiếp cận nhật ký hệ thống tốt hơn khi chỉ ghi nhật ký lỗi / thông tin. Các tệp nhật ký có khả năng hiển thị ít hơn so với e-mail, vì vậy bạn có thể sẽ không nhìn vào nhật ký trừ khi có sự cố.

Nếu bạn chọn đi theo con đường kiểu syslog, hãy xem xét syslog-ng: http://freshmeat.net/projects/syslog-ng/ .

Tất nhiên, bạn có thể có được tốt nhất của cả hai kỹ thuật bằng cách sử dụng cả hai. Ví dụ, syslog'ing cả thất bại và thành công, và chỉ gửi thư cho những thất bại.

Tôi đã đăng một câu trả lời tương tự cho một câu hỏi trên StackOverflow ( /programming/21025495/system-for-monitoring-cron-jobs-and-automated-t task )

Cronitor ( https://cronitor.io ) là một công cụ tôi xây dựng chính xác cho mục đích này. Về cơ bản, nó trở thành một đèn hiệu theo dõi sử dụng các yêu cầu http làm ping.

Tuy nhiên, một trong những nhu cầu mà OP đề cập trong bình luận của ông là cần được thông báo khi một công việc bắt đầu mất quá nhiều thời gian để chạy.

Tôi có cùng nhu cầu này và thấy rằng các công cụ tương tự không dễ dàng hỗ trợ kiểu giám sát này. Cronitor giải quyết điều này bằng cách cho phép bạn tùy ý kích hoạt một sự kiện bắt đầu và một sự kiện kết thúc để theo dõi thời lượng.

Theo dõi thời lượng là điều bắt buộc đối với tôi vì tôi có một cronjob được lên lịch mỗi giờ, nhưng theo thời gian bắt đầu mất hơn một giờ để chạy. Hi vọng bạn tìm được thứ hữu dụng!

Nó vẫn đang được phát triển khá nặng nề vào thời điểm tôi viết bài này nhưng tôi khuyến khích hãy xem https://github.com/jamesrwhite/minicron . Nó được phát triển để giải quyết các vấn đề bạn mô tả. Với một sửa đổi nhỏ cho lệnh bạn chạy, nó có thể ghi lại trạng thái đầu ra và thoát của công việc và gửi dữ liệu đó trở lại máy chủ trung tâm trong thời gian thực và có thể gửi thông báo qua email, SMS và PagerDuty khi công việc không thành công (trạng thái thoát> 0) hoặc không thực thi khi cần.

Tuyên bố miễn trừ trách nhiệm: Tôi là nhà phát triển làm việc về nó.

Điều này trông giống như một trường hợp sử dụng cổ điển cho AlertGrid .

Nó không yêu cầu cài đặt, tất cả những gì bạn cần làm để nhận được lợi ích từ công cụ này là:

1. gửi Tín hiệu đến AlertGrid mỗi khi công việc định kỳ của bạn hoàn thành công việc (điều này có thể được thực hiện bằng API đơn giản cực hạn, tín hiệu chỉ là một yêu cầu HTTP). Bạn cũng có thể gửi một số thông số như execution_time!
2. thiết lập quy tắc thông báo như theo dõi:

nếu my_job không phản hồi sau X phút (giờ trong trường hợp của bạn) -> gửi SMS đến quản trị viên

hoặc là

if exec_time> 60 giây -> gửi email cho những người quan tâm

Thật ra đó là tất cả. Bạn có thể quản lý các quy tắc thông báo bằng trình chỉnh sửa hình ảnh đẹp. Bạn không phải sửa đổi mã nguồn hoặc một số tệp cấu hình nếu có gì đó thay đổi. Đó là giải pháp tập trung, vì vậy bạn có thể hưởng lợi từ việc quản lý các quy tắc từ một nơi duy nhất.

Hy vọng điều này sẽ giúp được ai đó. Có một tài khoản miễn phí được cung cấp để bạn có thể kiểm tra và sử dụng AlertGrid nếu bạn quan tâm. Tôi là một trong những thành viên nhóm AlertGrid - vui lòng hỏi nếu bạn có một số câu hỏi.

Công việc định kỳ của bạn đã được ghi lại thông qua syslog. Dữ liệu đó có thể được gửi đến một máy chủ trung tâm bằng syslogd, một dịch vụ tiêu chuẩn khác.

http://www.debfox.org/how-to-remote-syslog-logging-on-debian-and-ubfox/ có chi tiết về cách thiết lập tính năng này.

tôi sử dụng http://cronrat.com chỉ cần thêm && curl "... url cronrat của bạn" vào công việc định kỳ của bạn. Tính năng tốt nhất tôi thích là bạn không cần thiết lập bất cứ điều gì sau khi bạn tạo tài khoản ban đầu. Mỗi cảnh báo được bật lên và chạy ngay khi bạn sử dụng nó. do đó tôi có thể sử dụng bất kỳ công cụ tự động nào để bắt đầu công việc chưa tồn tại, không giống như trên một số dịch vụ mà tôi cần thiết lập công việc trước.

Tôi đã tạo ra Power Cron sau những nhu cầu chính xác này. Tôi cần một cái nhìn tập trung đối với các công việc định kỳ của mình và một khái niệm về sự phụ thuộc giữa các công việc của các thành viên cụm khác nhau.

Tôi cũng cần nhiều thông tin hơn những gì tôi có thể tìm thấy trong nhật ký, và thêm hồ sơ công việc.

Chúng tôi đã xây dựng PushMon, http://www.pushmon.com , cho việc này. Giả sử công việc hàng ngày của bạn chạy vào lúc 3 giờ sáng và thường kết thúc lúc 4 giờ sáng. Bạn có thể thiết lập lịch trình PushMon là "trước 4:00 sáng mỗi ngày". Hoặc lịch trình nâng cao hơn một chút như "trước 4:00 sáng mỗi ngày trong vòng 1 giờ". Tất cả những gì bạn cần làm là "ping" URL PushMon mỗi khi công việc của bạn chạy và nó sẽ cảnh báo bạn về những lần ping bị thiếu. Nếu bạn biết chắc chắn đã xảy ra lỗi, như khi bạn bắt gặp một ngoại lệ mà bạn không thể xử lý, bạn có thể sử dụng tính năng cảnh báo theo yêu cầu.

Healthchecks ( https://github.com/healthchecks/healthchecks/ ) là một dịch vụ & bảng điều khiển được xây dựng chính xác để theo dõi các công việc định kỳ. Nó đang được sử dụng trong sản xuất, được duy trì và chấp nhận đóng góp mã.

Nó hoạt động tương tự như Cronitor, Dead Man's Snitch và những người bạn: bạn thiết lập công việc định kỳ của mình để thực hiện yêu cầu HTTP / HTTPS thành một URL đặc biệt, duy nhất ngay trước khi kết thúc. Healthchecks nhận và ghi lại những ping này. Nó liên tục kiểm tra nếu các ping đến khoảng thời gian dự kiến. Khi phát hiện sự cố, nó sẽ gửi cho bạn một thông báo. Các phương thức thông báo được hỗ trợ là email, webhooks, Slack, Telegram, Discord, SMS, Pushover, PusbONS, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie.

Bạn có thể tự thiết lập tất cả và lưu trữ, nhưng với bất kỳ dịch vụ web nào, bạn cũng phải mất một số nỗ lực để thiết lập tên miền, chứng chỉ, định cấu hình proxy ngược HTTP, thiết lập sao lưu cơ sở dữ liệu, v.v ... Cách dễ dàng để có được chạy là sử dụng phiên bản phù hợp với Heroku này: https://github.com/iphoting/healthchecks . Tôi biết những người tự điều hành dự án này và sử dụng nó để giám sát hàng trăm dịch vụ.

Tuyên bố miễn trừ trách nhiệm: Tôi là tác giả và tôi cũng chạy Healthchecks dưới dạng dịch vụ được lưu trữ tại https://healthchecks.io