Мы являемся независимым поставщиком программного обеспечения и собираемся развернуть наше приложение SaaS через Интернет для наших конечных пользователей и в настоящее время ищем решение для мониторинга приложений. В дополнение к мониторингу обычных подозреваемых на уровне ОС (ввод-вывод, дисковое пространство, журналы, ЦП, ОЗУ, подкачка и т. Д.), Мы также стремимся отслеживать, предупреждать и сообщать о внутренних событиях, условиях и счетчиках приложений. (подумайте о размере очереди для внутренней службы или о задержке службы, которую мы получаем от третьей стороны через пользовательские API).
Мы начали искать Nagios, Zenoss и т. Д., Но выяснили, что они делают только низкоуровневые вещи, и в настоящее время изучаем MOM и ManageEngine. Тем не менее, они далеки от специального инструмента для мониторинга приложений.
Итак - у вас есть что предложить?
Пара возможностей:
Большинство систем мониторинга - от Nagios до Zenoss и HP OpenView - позволяют создавать собственные мониторы, которые могут вам понравиться.
Вы можете написать более простой монитор, но сделать его более независимым от системы мониторинга, экспортировав его с помощью функций настройки (linux) net-snmpd. Они позволяют экспортировать любые случайные числа или строки по snmp; все, что вам нужно сделать, это написать небольшой скрипт для извлечения самих чисел из вашего приложения. Это может быть файл журнала или файл состояния, который ваше приложение периодически записывает, или что-то еще.
Возможно, ваше приложение «Программное обеспечение как услуга» может выводить информацию SNMP, которую можно собирать с помощью любого количества инструментов (Nagios, Munin и т. Д.).
Сервер сообщений Sun Java System Messaging - это пример приложения, которое предоставляет большой объем статистики через SNMP. В Реализация SNMP в их Руководстве для администраторов говорится:
Активная информация сосредоточена на сообщениях в очереди и открытых сетевых подключениях (например, количестве сообщений в очереди, исходных IP-адресах открытых сетевых подключений), в то время как историческая информация предоставляет совокупные итоги (например, общее количество обработанных сообщений, общее количество входящих подключений).
StackHub делает то, о чем вы просите: «отслеживает, предупреждает и сообщает о внутренних событиях, условиях и счетчиках приложений». Это сам SaaS, поэтому вам не нужно устанавливать и настраивать что-то громоздкое, например Nagios / Zenoss / и т. Д.
Сервис находится в стадии бета-тестирования и изначально ориентирован на приложения Java (например, Log4J / Logback), поэтому ранние отзывы приветствуются.
zabbix по-прежнему имеет много причуд, но мне он подходит.
Не уверен, что он точно подходит для того, что вам нужно, но monit может сделать то, что вам нужно.
Я бы выложил ссылку, но я новый пользователь. Так что вам просто нужно будет погуглить :(
Вам следует посмотреть Quest Foglight. Он имеет стандартные серверные метрики, а также мониторинг приложений для J2EE, .Net, а также для всех больших пакетов приложений (PeopleSoft, E-Business Suite и т. Д.). Одна из функций, которая может вам подойти, - это Foglight Experience Monitor. Он перехватывает HTTP-запросы по сети (без агентов) и сообщает о времени ответа на разных уровнях технологического стека. Вы можете использовать это для мониторинга тех третьих лиц, на которых вы полагаетесь, и даже можете предоставить это в качестве дополнительной функции своим клиентам, которые затем смогут отслеживать производительность вашего предложения SaaS.
Я использую Nagios для мониторинга именно этих вещей, а также дискового пространства, средней нагрузки и прочего. Дело в том, что Nagios - это всего лишь система управления сбоями, и она полагается на плагины для проверки чего-либо. Он поставляется с некоторыми хорошими плагинами по умолчанию для мониторинга переменных SNMP, ping и тому подобного, но вы можете отслеживать с его помощью что угодно, если вы можете написать программу, чтобы что-то проверять и возвращать индикацию ОК / предупреждение / критическое / неизвестное.
Обозначение «плагин» немного глупо, поскольку «плагин API» состоит из аргументов команд, переменных среды, статуса выхода и того, что вы печатаете на stdout. У меня есть несколько плагинов, которые представляют собой всего лишь 20-строчные скрипты ksh.
Nagios очень хорош. Вы также можете написать свои собственные плагины и довольно легко их настроить.
Если ваше приложение использует log4j или что-то подобное, попробуйте logFaces - он идеально подходит для мониторинга событий, связанных с приложениями, особенно для распределенных приложений.
Zenoss позволит вам повторно использовать любые плагины Nagios, которые у вас есть, и добавит мониторинг WMI и JMX для приложений. Вы также можете настроить свои приложения для отправки событий через syslog или xml-rpc и REST прямо в Zenoss.
У нас есть инструмент мониторинга приложений под названием RMS (Remote Monitoring System), который может вас заинтересовать. RMS может сузить основную причину проблем приложения в течение нескольких минут. Он может отправлять предупреждения и ссылаться на API службы поддержки для создания заявок. Он также может отслеживать SLA и создавать отчеты. Дайте мне знать, если вам понадобится дополнительная информация.
Ганс
Если вы чувствуете себя больше разработчиком, чем сисадмином, советую взглянуть на AlertGrid служба. Возможно, вам будет полезно выполнить некоторые задачи по мониторингу приложений (сверхлегкая интеграция). Однако это не так полезно для статистики системы мониторинга (другие инструменты имеют больше плагинов).