Каковы лучшие практики для отслеживания предупреждений / ошибок в длительных процессах? - PullRequest
5 голосов
/ 21 марта 2009

У нашей команды есть ряд процессов, которые мы запускаем вручную, но которые могут выполняться в течение многих дней. Процессы делают разные вещи для большого количества объектов (веб-страниц, строк базы данных, изображений, файлов и т. Д.). Очевидно, что время от времени возникают сбои, и мы должны спроектировать или процессы, чтобы изящно обрабатывать эти сбои и двигаться дальше, чтобы не свалить всю работу.

В зависимости от конкретного рассматриваемого процесса, частота, серьезность и срочность сбоев варьируются. В некоторых случаях мы отправляем электронные письма, когда возникает редкая, но важная ошибка, в других случаях мы просто регистрируем ее и продолжаем, и так далее.

Проблема в том, что у нас разный код обработки ошибок, разбросанный повсюду, и чаще, чем когда мы «регистрируем его и движемся дальше», никто никогда не возвращается и не читает журналы, поэтому никто никогда не знает, какие проблемы возникли. Мы не можем по умолчанию отправлять электронные письма для всех проблем, потому что просто было бы слишком много писем.

Это длительные процессы, но не демоны, где что-то вроде SNMP или Nagios может показаться подходящим. Конечно, это довольно распространенная проблема, но я не могу найти много решений в Интернете. Я слышал, как люди говорили об использовании log4j (или других подобных пакетов журналов) для входа в базу данных и т. Д., Что может показаться шагом в правильном направлении, но наверняка к настоящему времени существуют более сложные решения .. ? Я представляю себе, что ваш регистратор записывает события в базу данных, и есть веб-интерфейс, похожий на Nagios, который позволяет вам видеть, какие ошибки происходят с какими процессами в реальном времени, а также настраивать оповещения по электронной почте для определенных шаблонов и т. Д.

Существует ли что-то подобное? Если нет, то какие подходы вы использовали для успешного решения подобных проблем?

(Для чего бы то ни было, большая часть нашей кодовой базы написана на python, но я бы предположил, что любые приличные реализации этой идеи в значительной степени не специфичны для anguage, и, очевидно, любые концептуальные решения также подойдут).

Обновление: я просто потратил некоторое время, глядя на Chainsaw, что-то вроде того, что я ищу, но я бы хотел, чтобы оно было веб-приложением, а не настольным приложением, и имело функцию оповещения.

Обновление: я только что обнаружил hoptoadapp и исключительные , которые в некоторой степени совпадают с тем, о чем я думал, хотя оба ориентированы конкретно на Rails.

Ответы [ 2 ]

1 голос
/ 21 марта 2009

Ну, похоже, что реальным решением было бы переварить журналы ошибок. У каждого nite есть процесс, просматривают журналы ошибок и собирают ошибки / предупреждения / и т. Д. За день и помещают их в электронное письмо. Вы можете даже сгруппировать их по степени серьезности и / или применению, если хотите.

В конце концов, вы получаете только одно электронное письмо в день, и вся информация у вас под рукой. Не «быстрое» или даже элегантное решение, но в долгосрочной перспективе оно может быть очень работоспособным.

Это также не дает никаких опций в реальном времени. Но из этого вы можете превратить его в решение в реальном времени. Нетрудно написать процесс, который отслеживает изменения в файлах журналов, а затем запускает некоторые правила, основанные на последнем сообщении об ошибке. Это анализ, который становится сложным. ;) Удачи.

0 голосов
/ 21 марта 2009

Я думаю, что то, что вам нужно здесь, слишком специфично, чтобы найти что-то уже построенное, которое бы вписывалось в ваши потребности. Но ...

То, что вы описали в log4j, кажется мне замечательным: как только вы зарегистрируете ошибки в БД, простое веб-приложение позволит вам взглянуть на них, отфильтровать и настроить шаблоны для отправки электронных писем, таких как ошибки из конкретное приложение, порог уровня ошибки, сообщение, содержащее регулярное выражение и т. д.

Кроме того, вам понадобится небольшой cronjob, который будет подключаться к БД, искать новые записи (на основе последней проверки), соответствующие критериям электронной почты, и отправлять их.

Кодирование всего этого в худшем случае может занять не более нескольких дней, и, что бы это ни стоило, у вас в конечном итоге будет 100% пользовательский инструмент для вас.

...