Это Канонический вопрос о программном обеспечении для мониторинга.
Также по теме: Какой инструмент вы используете для мониторинга своих серверов?
Мне нужно следить за своими серверами; что мне нужно учитывать при выборе решения для мониторинга?
Существует множество решений для мониторинга. У каждого свои предпочтения, и у каждого бизнеса свои потребности, поэтому правильного ответа нет. Тем не менее, я могу помочь вам понять, на что вы можете обратить внимание при выборе решения для мониторинга.
В целом системы мониторинга служат двум основным целям. Первый - это сбор и хранение данных с течением времени. Например, вы можете захотеть собрать данные об использовании ЦП и построить график с течением времени. Вторая цель - предупредить, когда что-то либо не отвечает, либо находится за пределами определенных пороговых значений. Например, вам могут потребоваться предупреждения, если определенный сервер не может быть достигнут с помощью эхо-запросов или если загрузка ЦП превышает определенный процент. Существуют также системы мониторинга журналов, такие как Splunk, но я рассматриваю их как отдельные для этого.
Эти две основные роли иногда входят в один продукт, а иногда и чаще всего - иметь продукт, предназначенный для каждой цели.
Голосующие:
Всем системам мониторинга нужен какой-то опросчик для сбора данных. Не все данные собираются одинаково. Вам следует посмотреть на свою среду и решить, какие данные вам нужны и как их можно собирать. Затем убедитесь, что выбранная вами система мониторинга поддерживает то, что вам нужно. Некоторые распространенные методы включают:
Если у вас в основном одна ОС в вашей среде или основная ОС, некоторые системы могут иметь больше возможностей, чем другие.
Конфигурация:
В системах мониторинга часто бывает много повторного использования объектов. Например, вы хотите отслеживать определенное приложение, такое как Apache или IIS, на нескольких серверах. Или вы хотите, чтобы определенные пороги применялись к группам серверов. У вас также могут быть определенные группы людей, которые будут «по вызову». Поэтому хорошая система шаблонов жизненно важна для системы мониторинга.
Конфигурация обычно выполняется через пользовательский интерфейс или текстовые файлы. Вариант пользовательского интерфейса, как правило, проще, но текстовые файлы, как правило, лучше подходят для повторного использования и переменных. Поэтому в зависимости от вашего ИТ-персонала вы можете предпочесть простоту мощности.
Пользовательский интерфейс:
В наши дни наиболее распространенным интерфейсом для систем мониторинга является веб-интерфейс. В отношении веб-интерфейса следует оценить следующие моменты:
Система предупреждений:
Механизм оповещения должен быть гибким и надежным. Получить уведомление можно разными способами, в том числе:
Другие особенности, на которые стоит обратить внимание:
Важно быть уверенным, что когда что-то пойдет не так, вы получите предупреждение. Это сводится к двум вещам:
Хранилище данных:
Если система собирает и хранит данные (то есть системы, включающие графики), то система хранит данные. Например, очень распространенной реализацией как для хранилища, так и для построения графиков является 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 веб-сервера и сервер базы данных, обслуживающий сайт за балансировщиком нагрузки, которым вы не владеете (например, интернет-провайдер). Предоставляемая вами Служба - это порт 80 на двух серверах, и у них есть огромные кеши, которые могут выжить, например. время простоя базы данных (база данных на третьем сервере).
В этом случае полный отказ веб-сервера не приведет к его отключению. Произошло то, что избыточность исчезла, так что риск неудачи просто поднялся. Который должен вызвать предупреждение.
Полный отказ базы данных может вообще не повлиять на возможность обслуживания сайта из-за хорошо настроенных кешей; Тогда это не влияет на Сервис обслуживания веб-сайта, но это может повлиять на другую Службу, а именно на обновление веб-сайта или прием заказов ...
У каждой службы будет свой уровень обслуживания, который определяет, насколько важно восстановить обслуживание или избежать сбоев.
Каждый раз, когда вы получаете предупреждение, вы должны делать одно из следующих действий: - изменить отслеживаемую систему, чтобы устранить проблему, вызвавшую предупреждение (например, заменить диск или перенастроить logrotate или что-то в этом роде); - изменить систему мониторинга, чтобы предупреждение не отображалось. разослано в следующий раз, когда возникнет такая ситуация. (например, измените уровни для «свободного диска», чтобы диск мог заполнять до 90% вместо 80%)
Я в основном знаком с Nagios и его подробной конфигурацией, и с тех пор был привязан к мультисайту Check-mk. Недавно я узнал, что в check_mk есть концепция Business Intelligence (начиная с 1.11), которая, кажется, хорошо соответствует этому мышлению. Вы можете определить, что проверки в nagios являются частью более крупной службы и имеют правила, которые определяют состояние «Службы» как функцию состояния многих проверок, агрегированных в наихудший или Лучший штат.
Один из наиболее важных моментов, которые компании забывают при выборе решения для мониторинга: Дело не только в решении сиюминутных оперативных вопросов, а в завтрашних непредвиденных проблемах! Я имею в виду, конечно, решение неотложных вопросов важно, но поверьте мне, во многих случаях эта недальновидная стратегия не гарантирует выживания компании.
На рынке представлены десятки отличных решений для мониторинга. Составить короткий список решений, отвечающих вашим требованиям, - сложная и долгая задача, более того, найти то, что соответствует вашему бюджету, еще сложнее. Интересная часть найти тот, который соответствует вашему настоящему и вашему будущему. И нет процесса оценки, чтобы обнаружить это, это вопрос опыта + интуиции + очень важный фактор: Доверять, что непросто взломать.
Как правило, ищите и копайте Истории успеха вашего избранного набора решений для мониторинга, особенно если это касается компании из вашего сектора. Спросите продавца об их историях успеха и даже попросите разрешения поговорить с одним из их клиентов. Компании, которые не боятся этого шоу, имеют настоящий отношения со своими клиентами, и они не скрывают этого, и это невероятно редкий вещь, которую нужно найти в наши дни.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... у всех есть свои взлеты и падения, но реальная проблема находит, какой из них лучше подходит для вашего будущего.
Если вы рассматриваете возможность удаленного мониторинга системы, то может быть хорошей идеей поискать фактические места проведения тестов. Проблемы с подключением не остались в прошлом, и если ваше оборудование обслуживает группу в определенном регионе, вы можете убедиться, что ваши ресурсы доступны в этом конкретном месте.