Comments 111
Могу посоветовать два решения для мониторинга nix/win:
- Zabbix
- TICK stack
Например агент Telegraf по умолчанию умеет снимать метрики из Windows Performance Counters. Вот пример из конфига:
[[inputs.win_perf_counters]]
[[inputs.win_perf_counters.object]]
# Processor usage, alternative to native, reports on a per core.
ObjectName = "Processor"
Instances = ["*"]
Counters = [
"% Idle Time",
"% Interrupt Time",
"% Privileged Time",
"% User Time",
"% Processor Time",
]
Measurement = "win_cpu"
# Set to true to include _Total instance when querying for all (*).
#IncludeTotal=false
[[inputs.win_perf_counters.object]]
# Disk times and queues
ObjectName = "LogicalDisk"
Instances = ["*"]
Counters = [
"% Idle Time",
"% Disk Time","% Disk Read Time",
"% Disk Write Time",
"% User Time",
"Current Disk Queue Length",
]
Measurement = "win_disk"
# Set to true to include _Total instance when querying for all (*).
#IncludeTotal=false
А вот на работе да, там везде zabbix + grafana и шлет алерты в слак.
PS в zabbix раздражает узкая направленность на мониторинг серверов (например, чтобы мониторить web с внешки, приходится создавать фейковый сервер, чтобы вешать на него веб сценарии и триггеры с аляртами) и невозможность создавать хоть сколько-то динамические оповещения с использованием условий и регулярных выражений.
Ветка обсуждения — https://github.com/prometheus/prometheus/issues/2238
Windows клиент для мониторинга серверов различного типа (Windows, Linux, Oracle и др.)
Только маркетинговое бла-бла-бла, как круто они умеют всё мониторить.
Непонятны причины выбора. Даже более того, с учётом длительной истории проблем с influxdb и платной кластеризации, я бы не стал его ставить в Production.
В данный момент у нас работает связка Zabbix/MySQL. В следующей версии вроде бы обещали экспорт во внешние хранилища временных рядов (в том числе и InfluxDB) и хотелось бы заранее знать о подводных камнях.
1. Кластеризация и HA только в платной версии (в бесплатной предлагается писать в две базы параллельно и дальше получить проблемы с синхронизацией данных и пр.). Притом что когда кластеризация была в OpenSource она не работала, поэтому нет оснований верить в нее и сейчас.
2. Апдейты как хождение по минному полю — не знаешь что оторвет сейчас в целом по всему их стеку. Можно посмотреть баги телеграфа, в InfluxDB в каждом апдейте сопоставимый бардак.
отдельное спасибо за то, что не надо тащить docker вместе с тысячами его багов т.к. «контейнеры это безопасно»
Вообще из систем мониторинга нового поколения есть что-то для мониторинга+инвентаризации с разделением объектов мониторинга на группы (возможно вложенные и пересекающиеся)?
Рекомендую рассмотреть довольно удобную связку prometheus + telegraf.
Преимущества такой связки становятся очевидны после некоторой эксплуатации. Дело в том, что influxdb довольно плохо себя ведет на значительных объемах метрик.
Когда колво серверов измеряется десятками influx справлятся на ура, но масштабирование за эти пределы для нее становится неприятным. Из-за
- Неоднозначного времени старта. Из-за механики хранения метрик на диске во время старта надо построить индекс в памяти. это может занять любое колличество времени. Его нет возможности предсказать и оно практически не зависит от характеристик сервера(есть мнение, что такое построение индекса упирается в производительность одного ядра). Есть надежда, что в релизе 1.3 у парней получится решить эту проблемму через использования дискового индекса.
- Предсказуеммости операции compact. Потребление диска предсказать так же почти невозможно. В настройках по уполчанию compact будет отложен на 4 часа после последней записанной точки в кусок. С одной стороны эта операция сама по себе может занять до 12 часов. С другой стороны в это время на диске метрики будут лежать в режиме не максимального сжатия. Для примера скажу, что полностью сжатый кусок занимает 25G, а не сжатый 457G. Прогнозировать утилизацию диска в такой ситуации на грани возможного.
Предложенная мною связка решает вопрос с хранением метрик.
- prometheus очень быстро стартует
- хранит метрики в раздельных файлах и
- очень бережно относится к диску я одно время проводил сравнение большую часть времени по использоемому месту идут нос к носу, бывает что prometheus потребляет на 3-5% больше диска.
Кроме этого prometheus умеет алертинг, в связке Influx+telegraf приходится добавлять capacitor, а его конфигурация не самое приятное занятие.
Графана с некоторых пор умеет алерты, конденсатор не нужен.
Это увы не так. Когда серверов достаточно, выясняется что нужны templated дашборды и соответственно аварии по ним. Но графана с таких пока не умеет делать алярмы.
Для мониторинга крупных сетей альтернативы zabbix пока не встречал.
Подборка хорошая.
Грузит не заббикс, а его бд, которую после энного объема итемов и values per second приходится партиционировать вручную и так далее. Когда (если?) заббикс перейдёт для хранения метрик на какую либо time series db ему должно сильно полегчать.
Как вы его настраиваете на таких объемах? Неужили правите xml руками? Или используете какие-то сторонние генераторы конфигов?
Шаблоны позволяют быстро добавлять новые узлы в мониторинг, а Автообнаружение вообще позволяет заббиксу автоматом подкючать нужные триггеры и прочее.
Может дажу карту сети построить…
Я знаю про шаблоны, но ими тоже надо управлять. На таком парке (1500 хостов) шаблонов будет тоже будь здоров.
Ну и свитчи/камеры (SNMP + свой шалон для нестандартных девайсов)
Думаю, десятком можно обойтись. Для знакомого с Zabbix админа — дел на пару часов. (А вот новичек потратит пару недель, т.к. теже макросы и триггеры без готовых примеров понять сложновато)
Скажем 90% из них — просто виртуалки.
Сильное предположение. Т.е. просто виртуалки: стоят, воздух греют. А какая бизнес нагрузка на них? Везде apache+php? Тогда да, хватит пары шаблонов. А если все же вариативность повыше?
Разнообразия хватает: сервера, виртуалки, свичи, упсы, датчики, герконы, хотспоты и т.п. железки, в телекоме на 200-300к абонентов такого добра полно. Но это не мешает заливать их в мониторинг пакетно.
В крайний раз добавлял КТВ железки, это пара десятков EMR с пулом в 100-200 каналов и пара сотен всяких PBI, стримеров. Через API и pyzabbix, скриптом на питоне в 10 строк, залил за несколько часов. С max/min триггерами, действиями и графиками на каждый элемент данных (около 3к). Вариантов автоматизации в zabbix много.
Изначальный посыл был про производительность, которой мало что из списка может похвастаться. В zabbix даже если упрешься вертикально, развернуть прокси дело получаса.
1. *SQL-based базы и прочие попытки притянуть за уши решение — 80+ байт на точку.
1. Cassandra-based без кастомного сжатия — около 14 байт на точку
2. Graphite'овый Whisper и прочие RRD-подобные — 8-12 байт на точку
3. Более современные базы со сжатием — 2-6 байт на точку
Везде будут свои недостатки и преимущества, выбирать надо исходя из задач. Но я бы в 2017 году начал бы выбор с вопроса «почему не Prometheus?»
1. Зачем?
2. А какая производительность как у чтения так и у записи будет?
На небольших объемах (скажем до 100-300 устройств) SQLite с описанной выше оптимизацией, должен вполне справляться, по моим прикидкам. На практике, надо будет проверять.
На небольших объемах работать будет что угодно, например запись данных в виде строк в csv/json. TSDB все же появляются в тот момент когда у тебя объемы становятся порядка хотя бы десятков тысяч точек в секунду, а веселье начинается когда это уже сотни тысяч или миллионы в секунду.
И я бы исходя из всего этого не советовал бы переизобретать велосипед на базе SQLite :) ну не для этого он сделан.
Для мониторинга, как мне кажется, одно- и двух-байтных значений в большинстве случаев достаточно, значащих цифр в метриках не так много.
Почему то все сразу мыслят глобально: если база данных, так надо поддерживать тысячи, а лучше миллионы строк в секунду. Для маркетинга циферки конечно нужные — продать «серьезный» продукт видимо проще.
P.S. Проверил SQLite на массовую вставку: добавление 100К записей занимаем ~60сек, т.е. скорость ~1.5К строк/сек (с pragma synchronous = 0). В статьях встречаются цифры 70К строк/сек, но там и железо и ОС другие. При увеличении количества столбцов скорость упала совсем незначительно, что для велосипеда отрадно.
Уведомлений «из коробки» найдено не было
Уведомления на почту есть из коробки.
Работает на запись примерно в 10 раз быстрее того же influx-а, на чтение — примерно на том же уровне (median), но более стабильно (три-сигма сильно ниже). Пока еще нет кластеризации и интеграции со всяким мониторингом вроде графаны и collectd. Send nudes^W pull-requests!
Несколько раз спотыкался от influx при апдейтах, ушел на prometheus, доволен.
Плюсы:
- гибкий синтаксис запросов
- просто интегрировать метрики в свои сервисы (клиентские либы почти под всё)
- большой выбор механизмов обнаружения сервисов
А что из этого укладывается в парадигму Infrastructure As Code?
Ну кроме Nagios/Munin?
Grafana, на сколько я понимаю, мышкой все строить надо. Да и все остальное тоже?
Grafana позволяет один раз руками настроить все нужные датасорсы и дашборды, а потом автоматом делать их бэкап/рестор через curl
Демка, следящая за стендовым оборудованием.
эта система мониторинга является частью «process manager» PM2, тем более сейчас у них условия для бесплатного пользования стали более привлекательными: $0 per month 4 processes 1 user.
https://habrahabr.ru/company/pc-administrator/blog/304356/
Observium — для сетевых устройств.
Munin — для локалхоста
Zabbix — для всего
По поводу Update2: может сразу на википедию вносить обзор (https://en.wikipedia.org/wiki/Time_series_database)? Частично он там уже есть. Ну или результат туда запостить — многим бы пригодился.
Да я понимаю, что не совсем по адресу написал, но не придумал сходу куда. Щас вспомнил, что там же чат есть вроде бы. Касаемо википедии — там не нужно новой статьи, там уже похожая таблица даже есть, со схожим набором полей. И по результатам стихийного обзора можно вынести туда все основное, чтобы оно не кануло в лету в недрах google docs:) не думаю, что модераторы википедии воспримут в штыки.
Ещё можно на Pandora fms посмотреть. легкая, простая, и новые хосты подключаются методом установки агента который из коробки есть кажется что в убунтах, что в дебианах, что в центосях каких
В данном обзоре я не сравниваю nagios и graphana. Я специально написал "Отдельно хотелось бы упомянуть такой продукт, как grafana". Если этот текст путает, то предложите свой вариант и я внесу изменения в статью.
Вроде бы, мигрируют на прометей+графана.
Prometheus хорош своей модульностью, можно включить только то что нужно и прикрутить модули для сборки нужных метрик. Ну и там всё предельно просто по настройке и транспорту метрик с клиентов на сервер.
Чуть более проработанный, мне кажется, но систем меньше
- Параметры типа Write Performance/Query Perfromance сравниваются по заверениям авторов без учета разного железа и методик тестирования — то есть по фатку это профанация.
- Для показателей bytes per point нет источника, например непонятно откуда у Dalmatiner'а 1, когда авторы базы об этом ничего не говорят, если из тестов то тогда см п. 1, цифры в этом блоке профанация так как еще и осознанно на разных сетах данных
- Оценки типа Complexity, Functionality, Usability тоже даны примерно от балды по какой-то внутренней логике авторов, которая не очень то афишируется
- Нет упоминаний ни в каком виде что у всего raik-based cross-dc кластеризация платная, что по мне, например важно.
Поэтому я бы честно говоря не советовал бы использовать эту таблицу как источник информации, из-за того что она не учитывает разницу тестовых методик все цифры в ней являются профанацией и по факту бесполезны (не говоря о том, что например для Whisper'а есть более быстрые реализации на Go, чем указанное в таблице, но автор по какой-то причине не хочет их учитывать).
А люди, которые занимаются мониторингом и сопутствующими темами, редко имеют много свободного времени :)
Фактически основная идея таблицы из Update2 в том чтобы собрать более честную и объективную информацию чем собрана в таблице из Update3 — то есть выкинуть по максимуму субъективные факторы, а взамен охватить большее количество систем.
Наверное единственное чего не хватает это лицензии, чтобы цель можно было бы считать достигнутой.
Это еще и API-интерфейс.
Обзор систем мониторинга серверов. Заменяем munin на…