Каковы требования к системе мониторинга работоспособности приложений?

ответ 'это зависит'. Зачем вам монитор? Насколько велик ваш оперативный персонал? Вам нужна отчетность? Что такое среда приложения? Кого волнует, если приложение не работает? Кого волнует, если случится исключение? Можно ли восстановить какие-либо ошибки? Я мог бы задавать подобные вопросы долгое время.

Это такой открытый вопрос, но я бы начал с физических измерений.
1. Все машины, которые я думаю, размещают этот сайт pingable.
2. Являются ли все машины, которые должны обслуживать контент, обслуживающий некоторый контент. (В идеале это было бы попадание из внешней сети.
3. Каждая ожидаемая служба на каждой машине работает
3а. Эти службы работали в последнее время?
4. У каждой машины осталось место на жестком диске? (Не забудьте db)
5. Эти машины были скопированы? Когда это было в последний раз?

Еще один излагаются физические мониторинг систем, можно решать эти конкретные системы?

1. Может ли автоматический скрипт войти в систему? Сколько времени это заняло?
2. Сколько пользователей живут? Был ли добавлен миллион поддельных счетов?
...
Такие вопросы становятся более туманными и могут быть очень специфичными для системы. Их также обычно можно вывести реактивно отвечая к замеры спортивные гости. Жесткий диск заполняется, возможно, журналы веб-сервера заполняются, потому что куча агентов создала слишком много поддельных пользователей. Такого рода вещи.

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

большой вопрос.

некоторое время назад мы искали какое-то решение для мониторинга на уровне приложений для наших нужд без каких-либо успехов. Популярные решения мониторинга в основном адресованы мониторингу инфраструктуры и - на мой взгляд-они слишком сложны для требований большинства малых и средних компаний.

мы требовали (главным образом) следующих особенностей:

• оповещения - мы хотели знать о инцидент как можно быстрее
• безболезненное управление-размещенный сервис wouldbe лучший
• визуализации-это хорошо, чтобы знать, что происходит, и взять некоторые знания из данных

поскольку мы не нашли подходящего решения, мы начали писать свои собственные. Наконец, мы закончили с up-and-running сервисом под названием AlertGrid. (Вы можете проверить это бесплатно конечно.)

идея в том, чтобы обеспечить простой способ для обработки пользовательских сценариев мониторинга. API интеграции очень прост (одна функция с двумя требуемыми параметрами). На momment мы и другие используем его для:

• мониторинг запланированных задач (задания cron)
• мониторинг всего выполнения логики приложения
• предупреждение об ошибках в приложениях
• мы также работаем над примерами мониторинга базовой инфраструктуры с помощью AlertGrid

минимум: убедитесь, что она работает :)

Я думаю, что это достаточно простой монитор, так что вы можете быть предупреждены достаточно рано, прежде чем что-то пойдет не так. Это означает мониторинг зависимостей и самого приложения.

очень сложно предоставить специфику, если вы не собираетесь давать подробную информацию о приложении, которое вы отслеживаете, поэтому я бы сказал, используйте это как общее правило.

как минимум вы хотите знать, что система здорова. Это субъективно в том, что определяет вашу систему здоровой. Это компьютеры, необходимые ресурсы существуют, данные текут через систему, данные правильно производят результаты и т. д.

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

есть также" готовые " инструменты, которые сделают много тяжелой работы для вас, если вы просто слишком усердно смотрите на результаты данных. Мне особенно понравилось среда когда я осматривался, но нам нужно было больше, чем он мог легко показать, поэтому я написал нашу собственную систему мониторинга. В основном мы также наблюдаем за "особенностями" в шипы системы, памяти / К. П. У., ЕТК...

спасибо всем за ввод, я действительно искал мониторинг на уровне приложений, а не мониторинг инфраструктуры, но хорошо знать об обоих

разница в том, что:

• мониторинг инфраструктуры будет серверы плюс MS Exchange Server, Apache, IIS и так далее
• мониторинг приложений будет пользовательскими машинами и конкретными программами, которые они используют для выполнения своих задач, и / или серверами, а также приложениями для перемещения данных / бэкэнда, которые они работают, чтобы сохранить поток данных

иногда трудно провести черту - упрощенное определение может быть "если ваша команда написала это, это приложение; если вы купили его, это инфраструктура"

Я думаю, что на практике лучше контролировать как

Что вам нужно сделать, это сломать бизнес-процесс приложения, а затем программное обеспечение испускает события на основных бизнес-компонентах. Кроме того, вам нужно будет создать сквозные синтетические транзакции (например. эмуляция конечных пользователей, щелкающих по веб-сайту). Все эти данные будут введены в инструмент мониторинга. В прошлом я делал JMX для приложений, которые текли в адаптер JMX Tivoli Monitoring, а затем я делал сценарии, которые реализуют "поддельного пользователя", а затем конвейер в результатах в адаптер сценариев Tivoli Monitoring. Tivoli Monitoring берет данные, а затем создает диаграммы работоспособности и производительности приложений из этих необработанных данных.