Это канонический вопрос о программном обеспечении для мониторинга.
Также по теме: Какой инструмент вы используете для мониторинга своих серверов?
Мне нужно следить за моими серверами; Что я должен учитывать при выборе решения для мониторинга?
Ответы:
Существует множество решений для мониторинга. У каждого свои предпочтения, у каждого бизнеса свои потребности, поэтому нет правильного ответа. Тем не менее, я могу помочь вам понять, на что вы можете обратить внимание при выборе решения для мониторинга.
В целом, системы мониторинга служат двум основным целям. Первый заключается в сборе и хранении данных с течением времени. Например, вы можете собирать данные об использовании процессора и отображать их с течением времени. Вторая цель состоит в том, чтобы предупредить, когда вещи или не отвечают или не находятся в определенных порогах. Например, вам могут потребоваться оповещения, если определенный сервер не может быть достигнут с помощью пингов или если загрузка ЦП превышает определенный процент. Существуют также системы мониторинга журналов, такие как Splunk, но я рассматриваю их как отдельные для этого.
Эти две основные роли иногда входят в один продукт, в других случаях более распространенным является наличие продукта, предназначенного для каждой цели.
Опрашивающие устройства .
Всем системам мониторинга для сбора данных необходим какой-либо опрашивающий модуль. Не все данные собираются одинаково. Вы должны посмотреть на свою среду и решить, какие данные вам нужны и как они могут быть собраны. Затем убедитесь, что выбранная вами система мониторинга поддерживает то, что вам нужно. Некоторые распространенные методы включают в себя:
Если в вашей среде в основном одна ОС или основная ОС, у некоторых систем может быть больше опций, чем у других.
Конфигурация :
в системах мониторинга, как правило, много повторного использования объектов. Например, вы хотите отслеживать определенные приложения, такие как Apache или IIS, на нескольких серверах. Или вы хотите, чтобы определенные пороги применялись к группам серверов. Вы также можете иметь определенные группы людей, которые будут «по вызову». Поэтому хорошая система шаблонов жизненно важна для системы мониторинга.
Конфигурация обычно выполняется через пользовательский интерфейс или текстовые файлы. Опция пользовательского интерфейса, как правило, будет проще, но текстовые файлы, как правило, лучше для повторного использования и переменных. Поэтому, в зависимости от вашего ИТ-персонала, вы можете предпочесть простоту, а не мощность.
Пользовательский интерфейс :
Наиболее распространенный интерфейс для мониторинга систем в эти дни является веб - интерфейсом. Некоторые вещи, которые нужно оценить в отношении веб-интерфейса:
Alerting двигателя :
оповещения двигатель должен быть гибким и надежным. Есть много разных способов получить уведомление, в том числе:
Другие функции для поиска:
Важно верить, что когда что-то пойдет не так, вы получите предупреждение. Это сводится к двум вещам:
Хранилище данных :
если система собирает и хранит данные (т.е. системы, которые включают графики), то система сохраняет данные. Например, очень распространенной реализацией как хранилища, так и графики является RRD.
Некоторые функции для поиска в хранилище данных:
Библиотека
графиков : графики могут быть полезны для быстрого выявления тенденций и предоставления контекста текущего состояния чего-либо на основе его истории. Некоторые из них включают в себя тренды, которые могут быть полезны для предсказания вещей до того, как они произойдут (например, нехватка места на диске). Убедитесь, что графики дадут вам ясную информацию, которая, по вашему мнению, вам понадобится.
Контроль доступа .
Если у вас большая организация, вам могут потребоваться элементы управления доступом, потому что некоторые администраторы должны иметь возможность настраивать только определенные параметры. Возможно, вы также захотите публичных панелей. Если это важно, вы должны убедиться, что система мониторинга имеет необходимые элементы управления.
Отчетность :
система, которая предоставляет хорошие отчеты, может помочь вам определить, что необходимо улучшить в течение длительных периодов времени. Например, он может дать хороший ответ на такие вещи, как «какие системы выходят из строя чаще всего?». Это может быть важно, когда вы пытаетесь убедить руководство тратить деньги на определенные вещи - бизнес - это неопровержимое доказательство.
Специализированные функции :
некоторые системы мониторинга ориентированы на конкретные продукты или имеют большую поддержку, чем другие. Например, если главное, что вам нужно отслеживать - это сервер SQL, или если вы интенсивно используете продукты VMWare, вы должны увидеть, насколько хорошо они поддерживаются.
Предопределенные шаблоны мониторинга :
система, которая поставляется с большим количеством предопределенных шаблонов (или имеет пользовательскую базу, которая создала много шаблонов), может значительно сэкономить время.
Обнаружение :
если у вас большая или изменяющаяся среда. Некоторые системы предоставляют возможность добавлять новые системы через API или выполнять сканирование для поиска новых серверов или компонентов.
Распределенный мониторинг:
если у вас есть несколько мест для мониторинга, может быть полезно иметь опросы мониторинга в каждом месте, а не множество независимых систем, которые осуществляют мониторинг через глобальную сеть.
Есть много систем мониторинга там. У нас есть список с кратким изложением этого старого вопроса . Для быстрого ознакомления некоторые из них, о которых я слышу больше всего:
Причина, по которой я не могу сказать вам, что использовать, заключается в том, что у каждой организации есть свои потребности. Если вы хотите сделать правильный выбор, вы должны продумать все перечисленные выше компоненты и выяснить, какие функции важны для вашей организации. Затем найдите систему или системы, которые утверждают, что предоставляют то, что вам нужно, и попробуйте их. Некоторые из них стоят немного, много или бесплатно. Принимая все это во внимание, вы можете сделать свой выбор. Из того, что я использовал, все они далеки от совершенства, но, по крайней мере, вы можете попытаться получить то, что подходит.
Полезно различать мониторинг и оповещение. Мониторинг означает сбор данных и построение графиков. Оповещение означает отправлять мне SMS, когда сервер выходит из строя среди ночи.
Nagios для оповещения. Кактусы и Мунин для мониторинга. Другие продукты объединяют две функции. Zenoss и Zabbix являются примерами.
Я бы начал с ответа на несколько вопросов:
Вам нужно контролировать серверы, сетевые устройства, приложения или все три?
Существуют ли ограничения на методы, которые вы можете использовать для мониторинга? Можете ли вы установить на серверах клиентов мониторинга, таких как NRPE, или вы будете использовать SNMP, или, может быть, оба?
Кто будет использовать графики, а кто будет использовать оповещения? Как бы вы хотели, чтобы конечный результат выглядел? Имеет ли значение внешний вид интерфейса (будут ли его использовать деловые люди или только технический персонал?)
Каковы ваши ресурсы, как с точки зрения времени, навыков и оборудования? У вас есть хотя бы скромная скриптовая способность? Вам нужно готовое решение?
На мой взгляд, первое правило как оповещения, так и мониторинга должно быть «Держите его простым»! Организация может жить или умирать от того, как она оповещает и собирает данные, и в большинстве случаев она сама по себе все усложняется. Начните с основ и постройте оттуда.
Подумайте об услугах, предоставляемых вашим программным обеспечением , отправьте оповещения о сбоях этих служб или увеличении риска отказа этих служб.
Теория, лежащая в основе стратегий мониторинга, заключается в том, чтобы связать мониторинг и оповещения с каким-либо соглашением об уровне обслуживания . В конце концов, вы хотите, чтобы вас предупреждали о том, что вы теряете деньги, а вовсе не обязательно о том, что количество подключений TCP к nji0019.myserver.com резко возросло. Существуют различные инструменты, которые будут давать вам тонны предупреждений, определять зависимости между оповещениями, но многие из этих проверок не имеют прямого отношения к услуге, которую вы предоставляете кому-либо.
Определите важные услуги, которые вы предоставляете, такие как возможность обслуживания веб-сайта и возможность изменять этот веб-сайт (например, какая-либо CMS). Они должны быть проверены (например, путем мониторинга, что вы можете получить веб-страницу, и что вы можете). Сбой этих двух Сервисов (используется здесь с большой буквы S) должен вызвать предупреждение, чтобы уведомить вас.
Если важно, чтобы сайт отвечал в течение разумного периода времени, это также должно вызывать оповещения. Вроде «нарушение SLA», если хотите.
Обычно существует неотъемлемый риск сбоя Сервиса, и достаточно часто, чтобы риск был смягчен тем фактом, что вы вводите избыточность, например, второй сервер или подчиненную базу данных, или дополнительные сетевые карты ...
Когда эта избыточность потеряна, Служба все еще в порядке, но риск сбоя Службы только возрос.
Это вторая основная причина для запуска оповещений; эта избыточность исчезла (например, из-за того, что второй сервер умер) или существует неизбежная опасность того, что риск увеличится (например, на диске осталось всего 500 МБ или тренд диска указывает, что диск заполнится примерно через 5 часов).
Но check_mk дает мне 50-60 проверок на хост, все это бесполезно?
Нет. Все это не означает, что вы хотите отказаться от множества автоматических проверок, которые вы получаете, например, с check_mk, но это означает, что вы должны попытаться классифицировать каждую проверку на то, какие службы могут быть затронуты, если что-то не получится.
Какая служба будет затронута, если заполнится раздел / var /? Какая служба будет затронута, если интерфейс eth0 не работает? ... если исходящие соединения TCP заблокированы каким-либо брандмауэром? ... если количество потоков превышает 800? ... если база данных выходит из строя?
У вас есть 2 веб-сервера и сервер базы данных, обслуживающий сайт за балансировщиком нагрузки, которым вы не владеете (например, ISP). Предоставляемая вами услуга - это порт 80 на двух серверах, и они имеют огромные кэши, которые могут выжить, например, время простоя базы данных (база данных на третьем сервере).
В этом случае полный сбой веб-сервера не приведет к отключению сайта. Произошло то, что избыточность исчезла, так что риск сбоя просто возрос. Это должно вызвать предупреждение.
Полный сбой базы данных может вообще не повлиять на способность обслуживать сайт из-за хорошо настроенных кэшей; Это не влияет на Службу обслуживания веб-сайта, но может повлиять на другую Службу, а именно на обновление веб-сайта или принятие заказов ...
Каждый Сервис будет иметь свой собственный уровень сервиса, который определяет, насколько важно восстановить сервис или избежать перебоев в работе.
Каждый раз, когда вы получаете предупреждение, вы должны выполнить одно из следующих действий: - изменить отслеживаемую систему, чтобы устранить проблему, вызвавшую предупреждение (например, заменить диск или перенастроить logrotate или что-то еще) - изменить систему мониторинга, чтобы избежать появления предупреждения рассылается в следующий раз, когда возникает такая ситуация. (например, измените уровни на «без диска», чтобы диск мог заполняться до 90% вместо 80%)
Я в основном знаком с Nagios и его подробной конфигурацией, и с тех пор подсел на мультисайт Check-mk. Недавно я узнал, что check_mk имеет эту концепцию бизнес-аналитики (начиная с 1.11), которая, кажется, хорошо соответствует этому мышлению. Вы можете определить, что проверки в nagios являются частью более крупного сервиса и имеют правила, которые определяют состояние «Сервиса» как функцию состояния многих проверок, агрегирующих в худшее или лучшее состояние.
При выборе решения для мониторинга компании забывают о том, что не только решение неотложных оперативных проблем, но и непредвиденные проблемы завтрашнего дня! Я имею в виду, конечно, что решение неотложных вопросов важно, но, поверьте мне, во многих случаях эта близорукая стратегия не гарантирует выживание компании.
На рынке представлены десятки отличных решений для мониторинга. Составление списка небольшого набора решений, удовлетворяющих вашим требованиям, является сложной и длительной задачей, более того, найти решение, которое соответствует вашему бюджету, еще сложнее. Интересная часть - найти ту, которая соответствует вашему настоящему и вашему будущему . И нет никакого процесса оценки, чтобы обнаружить это, это вопрос опыта + интуиция + очень важный фактор: доверие , которое нелегко взломать .
Как правило, ищите и выискивайте истории успеха вашего краткого списка решений для мониторинга, особенно если это затрагивает компанию из вашего сектора. Спросите у продавца их истории успеха, и даже попросите у них разрешения поговорить с одним из их клиентов. Компании, которые не боятся этого, показывают, что у них есть реальные отношения со своими клиентами, и они этого не скрывают, а в наши дни это встречается крайне редко .
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... все они имеют свои взлеты и падения, но реальная проблема заключается в поиске того, какой из них лучше адаптируется к вашему будущему.
Если вы рассматриваете возможность удаленного мониторинга системы, то было бы неплохо найти фактические местоположения, с которых выполняются тесты. Проблемы с подключением не ушли в прошлое, и если ваше оборудование обслуживает группу в определенном регионе, вы можете убедиться, что ваши ресурсы доступны в этом конкретном месте.