Каковы требования к системе мониторинга работоспособности приложений? - PullRequest
10 голосов
/ 17 сентября 2008

Что, как минимум, должна делать система мониторинга работоспособности приложений для вас (разработчика) и / или вашего босса (ИТ-менеджера) и / или оперативного (по вызову) персонала?

Что еще нужно сделать сверх минимальных требований?

Достаточно ли мониторинга «инфраструктурных» приложений (ms-exchange, apache и т. Д.) Или необходимо также контролировать отдельные пользовательские приложения, веб-сайты и базы данных?

если последнее, что вам нужно знать о них?

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

Ответы [ 9 ]

12 голосов
/ 17 сентября 2008
  • Работает ли приложение.
  • Необычное использование процессора / памяти / сети.
  • Сообщить о любых необработанных исключениях.
  • Состояние различных модулей (если применимо).
  • Состояние внешних компонентов (базы данных, веб-сервисы, файловые серверы и т. Д.)
  • Количество ожидающих фоновых задач (если применимо).
  • Может быть, отслеживать использование приложения и сообщать статистику по наиболее / менее используемым функциям, чтобы вы знали, где оптимизации наиболее полезны.
2 голосов
/ 27 августа 2010

Отличный вопрос.

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

Нам потребовались (в основном) следующие функции:

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

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

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

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

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

Как только кто-то излагает физический мониторинг систем, он может обратиться к тем, которые специфичны для системы?

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

Хотя план А не обязательно должен быть реактивным, именно так многие строят систему мониторинга.

2 голосов
/ 17 сентября 2008

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

1 голос
/ 18 июня 2010

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

1 голос
/ 13 ноября 2008

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

разница:

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

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

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

1 голос
/ 17 сентября 2008

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

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

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

1 голос
/ 17 сентября 2008

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

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

1 голос
/ 17 сентября 2008

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

Однако, некоторые другие вещи были бы очень полезны. Например, загрузка процессора, использование ОЗУ и (в многопользовательских системах), какой пользователь работает, что. Кроме того, для приложений, которые получают доступ к сети, список сетевых подключений для каждого приложения. И (если у вас есть доступ к клиентским компьютерам), было бы здорово увидеть «заголовок окна» приложения - возможно, проверять каждые 2-3 минуты, если оно изменилось, и сохранять его. Кроме того, список файлов, открытых приложением, может быть очень полезным, но это не обязательно.

...