Это один из тех общих вопросов, на который единственный правильный ответ - это зависит от обстоятельств. Какие критерии?
Все, что полагается на SNMP для мониторинга серверов, терпит неудачу. Существуют фундаментальные проблемы с SNMP, которые делают невозможным надлежащий мониторинг сервера. Более того, большинство агентов SNMP - отстой. Net-SNMP - отстой.
Обычно подобные проблемы игнорируются, пока создаются красивые графики. Я сказал менеджерам по развитию, что данные, на которые они смотрят, бесполезны, что мы делаем это только для того, чтобы выполнить требование по созданию хороших графиков, и они согласились с этим, и продолжали задавать вопросы о графике.
Например, для получения информации об одном потоке требуется около 20 запросов SNMP. В системе с миллионом потоков, которая требует опроса один раз в минуту, это 20 миллионов пакетов в минуту для мониторинга! Я понимаю, что миллион потоков - это много, и не всем нужен поминутный опрос, но это тоже разумно, и многим людям нужно больше.
Обычно путают значение «свободная» память. Я видел, что это игнорируется, потому что это позволяет приобретать дополнительную память - весьма выгодно в финансовой среде, где напряженный день может привести к трехкратному нормальному использованию памяти и где руководство отказывается рассчитывать размер для этих пиков. По сути, ложь сводится на нет.
Часто инструменты мониторинга, предназначенные для мониторинга коммутаторов / маршрутизаторов, получают статистику по процессорам через SNMP для сервера и сообщают данные на видном месте. Многие люди не хотят слышать, что статистика по процессорам - это не то, что им нужно, а статистика по потокам.
Независимо от того, как данные извлекаются, для понимания многих распространенных проблем требуется менее или даже менее секундный опрос. К счастью, Linux sar может без проблем выполнять выборку данных с интервалом в 1 секунду. Он не сохраняет все данные, что делает iostat, что может помочь понять узкое место хранения. Я просто сохраняю данные «iostat -x 1». Например, если пользователь жалуется на субсекундные зависания (или, если клиент жалуется, что их транзакции, которые обычно занимают 10 мс, иногда занимают 200 мс), полезен субсекундный опрос всей статистики процесса / потока. К сожалению, несколько ядер предоставляют разумный механизм для этого. (нет законной причины, по которой я не могу получить эти данные структурированным образом за один системный вызов, и мне не придется иметь дело с преобразованием данных в десятичное в ядре и из десятичного в моем приложении, а также с другими глупыми накладными расходами).
Неспособность сохранить статистику производительности диска разумным образом - обычная ошибка.
Отсутствие хорошо синхронизированных часов - распространенная проблема. Многие люди упускают из виду тот факт, что NTP требуется всегда. Тот факт, что неправильная конфигурация NTP может означать, что вы не знаете, насколько синхронизированы два тактовых сигнала, является распространенной проблемой. Часто упускается из виду тот факт, что серьезный бизнес должен тратить деньги на собственные часы с GPS. Для компаний, участвующих в торговле NASDAQ, я указываю на правила, пишу объяснение для наших клиентов о том, какую точность времени следует ожидать (они часто спрашивают), и, когда просят одобрения этого объяснения, описываю, какие настройки нам нужны, чтобы соблюдать правила , выполняйте наши обещания, данные нашим клиентам, и устраняйте проблемы с поставщиками, которые полагаются на синхронизацию времени.
Доставка предупреждений - распространенная проблема. По сути, вам нужно убедиться, что человек будет реагировать на предупреждения, что он несет ответственность за предупреждения, которые он подтверждает, и что предупреждение будет повторно отправлено другим путем или другому человеку, если оно не подтверждено. Если люди получают поддельные предупреждения, которые мешают им серьезно относиться к страницам, системе мониторинга необходимо уделить внимание.
Важно понимать разницу между тенденциями и предупреждениями об ошибках.
Сообщения об ошибках в системном журнале важны, как и наличие механизма для выявления новых типов ошибок, даже если это не вовремя.
Я затронул здесь несколько действительно важных вещей. Но нет ничего более важного, чем это - независимо от того, какое решение для мониторинга / отслеживания тенденций / оповещений вы покупаете, его установка и настройка для вашей среды потребуют значительных затрат. Не существует решения, которое значительно снижает стоимость настройки / обслуживания. Распространенная ошибка - продолжать покупать новые системы мониторинга, оставлять их в настройках по умолчанию и оставлять их бесполезными.
Обещания поставщика, что они помогут настроить бесплатно, бесполезны. Если у вас нет четкого письменного представления. Обещания поставщика, что он продаст вам дорогие услуги настройки, бесполезны - нельзя доверять, что они сделают это грамотно.
Если у вас есть критически важные собственные приложения, а разработчики отказываются добавлять в свое приложение инструментарий, ведение журнала и другую помощь для мониторинга, у вас есть проблема. В основном это нерадивые разработчики, которые не заботятся об операционных аспектах своего программного обеспечения. С другой стороны, разработчики должны участвовать в обсуждении того, какие аспекты их программного обеспечения следует отслеживать, чтобы можно было разработать удобный метод раскрытия этого. Они могут быть вынуждены добавить функции и не учитывать надежность или предупреждение о проблемах.
Раньше Nagios был меньшей системой нижнего уровня, но я бы сказал, что самые последние версии действительно были «корпоративного класса». На основе SNMP, с открытым исходным кодом, интегрируется со всем, от Cacti до RRDTool. Вам нужно будет потратить время на настройку и создание пользовательских сценариев отчетов, но, честно говоря, это касается и коммерческих инструментов.
Traverse (назывался NetVigil) - это коммерческий инструмент, который больше, чем «старые Nagios», и наравне, если не немного лучше, чем нынешние Nagios.
Существует множество систем мониторинга среднего уровня.
В верхней части у вас есть HP OpenView, IBM Tivoli, CA Unicenter и многие другие. Ценник может достигать миллионов долларов США за консультации по лицензированию и внедрению, что является обязательным требованием.
Независимо от того, где вы находитесь в спектре, программное обеспечение для мониторинга потребует затрат вашего времени. Это легко может быть полный рабочий день по уходу и питанию системы мониторинга в более крупном магазине.
Недавно мы начали оценивать Зенос с различными плагинами Nagios. Вроде бы вполне настраиваемый. Мы пробовали Nagios около года назад и столкнулись с проблемами конфигурации. Zenoss казался немного проще в использовании.
Мы также обсуждали "Чувак" но хотел сервер на базе * nix.
Я также недавно наткнулся на статья информационного мира подробное описание некоторых весьма ценных инструментов мониторинга с открытым исходным кодом.
Я использовал продукт от Castle Rock под названием SNMPc - это не самый совершенный из инструментов, но он делает все, что вы можете захотеть, и не обойдется вам дорого.
По сути, это инструмент сопоставления статистики SNMP, который может определять базовые показатели и предупреждать об отклонениях от базовых показателей. Ему могут быть заданы пороговые значения для предупреждений о росте и снижении, и он хорошо работает с любым устройством, поддерживающим SNMP.
Включить SNMP в * nix так же просто, как и в Windows. Расширяемость SNMP тоже довольно проста (по крайней мере, на * nix)
SNMP бесплатный - есть 3 уровня; все связано с безопасностью. SNMP 1 представляет собой обычный текст и очень «небезопасен». SNMP 2 зашифрован, но это тривиально. SNMP 3 использует сертификаты. Хотя заставить его работать в первый раз может быть немного утомительно.
Потому что есть очень много счетчиков и статистики, которые вы можете получить, также может потребоваться время, чтобы определить, какие из них подходят вам, но как только это будет сделано, все будет очень просто.
Вы платите за сортировку внешнего интерфейса и запуск по событиям, чтобы сделать SNMP полезным. Вы можете сделать это с помощью программного обеспечения с открытым исходным кодом, но мне нужна была небольшая коммерческая поддержка.
Данные могут быть опрошены с устройств (обычно), а в критических системах вы можете заставить отдельную систему отправлять событие прерывания, уведомляющее диспетчер прерываний, что что-то пошло не так, и им нужно знать сейчас, а не ждать следующего периода опроса .
Опрос удаленных устройств может выполняться с помощью агента сбора данных - того же типа, что и консоль, но без всяких волшебных средств отчетности - который затем периодически отправляет статистику на центральную консоль.
Из всех систем мониторинга, которые я использовал, SNMP продолжал обеспечивать то, что мне было необходимо, и в рамках выделенного мне бюджета.
Существует продукт для серверов Microsoft под названием MOM «Microsoft Operations Manager», где версия для рабочей группы из 5 серверов является (или, по крайней мере, была) бесплатной ... но расширение ее для отслеживания корпоративных систем, таких как Exchange и SQL, может стоить очень дорого. в лицензиях и коннекторах.
Помимо этого - мой опыт ограничен SNMP, MOM и Spotlight (от Quest), что было потрясающе и слишком далеко за пределами нашего бюджетного диапазона для всех баз данных Oracle, кроме наиболее важных.
Я большой поклонник nagios и настроил его для мониторинга всех моих серверов и многих служб, которые они запускают. Это одна из тех программ, над которыми я постоянно работаю, особенно потому, что вещи, которые мы действительно меняем, довольно часто меняются. Я даже могу заставить его проверять наличие определенного текста на наших общедоступных веб-сайтах.
Изначально у меня были уведомления, настроенные как электронные письма, но я экспериментировал с SMS-предупреждениями, а в последнее время - с IM-предупреждениями.
Я использую его уже более года, но до сих пор не могу довести его до совершенства. Один из недостатков, который я обнаружил, заключается в том, что исторические данные плохо хранятся, но это может быть больше связано с тем фактом, что я не нашел нужный плагин.
Я не могу рекомендовать Nagios достаточно высоко. Абсолютно бесплатно (при условии, что вы не учитываете часы, необходимые для того, чтобы согласовать значительную кривую обучения) и расширяемо практически всеми способами - все средства мониторинга и оповещения имеют модульную архитектуру, поэтому вы можете писать свои собственные плагины, сценарии пейджера, без разницы. Если вы не так уж много программиста, есть также большое и полезное сообщество, производящее плагины всех видов, хотя комплектные из них довольно хороши - есть удаленные агенты, которые вы можете установить на свои серверы, или интерфейсы, позволяющие выполнять WMI / SNMP проверяет или разговаривает с агентами сервера Tivoli / OpenView. Существуют также надстройки для полезного расширения базового движка Nagios, например, запись данных о производительности в MySQL или RRDTool. Конфигурация немного сложна, но при достаточном количестве издевательств вы можете заставить ее контролировать практически все, что имеет сетевое соединение. Кроме того, после того, как вы настроили все родительско-дочерние отношения хоста и расширенную информацию (IP-адрес, идентификатор цепи и т. Д.), Вы можете использовать ее в качестве сетевой документации.
На самом деле я не очень заинтересован в системе мониторинга, но всегда заинтересован, так что спасибо, что подняли этот вопрос, и я буду внимательно проверять.
Ранее я использовал один из ManageEngine (http://www.manageengine.com/products/opmanager/index.html), и это очень нравится.
Я предпочитаю хорошую систему мониторинга, основанную на веб-интерфейсе, без агента и на основе SNMP.