morozovsk Jun 19 2017 at 00:31

Обзор систем мониторинга серверов. Заменяем munin на…

9 min

186K

DevOps*Configuring Linux*Server Administration*

Tutorial

+73

111

Comments 111

stanislav-belichenko Jun 19 2017 at 01:18

Спасибо, интересно! А не встречали в ваших изысканиях подобную конфигурацию, но сразу и для *nix, и для win* наблюдаемых машин?

Wernisag Jun 19 2017 at 06:31

Icinga умеет, у неё есть клиенты для обеих систем + wmi + snmp. С развитием IoT скоро можно будет и чайник на кухне мониторить

banzayats Jun 19 2017 at 09:52

Могу посоветовать два решения для мониторинга 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

Dromok Jun 19 2017 at 02:28

На своем проекте, на более чем 10 машинах, использую munin и не испытываю никаких проблем. Легкая, не грузит сервер. И есть все метрики какие нужны прямо из коробки. Есть оповещение на почту если что-то нехорошее происходит на сервере. Имхо мне этого более чем достаточно и даже не планирую менять.
А вот на работе да, там везде zabbix + grafana и шлет алерты в слак.

razielvamp Jun 19 2017 at 06:58

А чем плох/недостаточен стандартный интерфейс Zabbix? Или grafana просто визуально красивее?

PS в zabbix раздражает узкая направленность на мониторинг серверов (например, чтобы мониторить web с внешки, приходится создавать фейковый сервер, чтобы вешать на него веб сценарии и триггеры с аляртами) и невозможность создавать хоть сколько-то динамические оповещения с использованием условий и регулярных выражений.

Dromok Jun 19 2017 at 11:52

Прошу прощения, напутал. Там graphite, а не zabbix.

Waso Jun 19 2017 at 04:37

А сравнение-то где?

morozovsk Jun 19 2017 at 15:41

Смотрите Update2 в статье.

alexhouse Jun 19 2017 at 05:02

Многие, кто пользуются связкой Prometheus + Grafana, говорят о случаях когда grafana досит прометея.

Ветка обсуждения — https://github.com/prometheus/prometheus/issues/2238

freeseacher Jun 19 2017 at 11:35

Это довольно старое обсуждение, в более менее свежих версиях проблема ушла.

GHostly_FOX Jun 19 2017 at 05:53

Советую еще посмотреть в сторону Quest Software — Spotlight
Windows клиент для мониторинга серверов различного типа (Windows, Linux, Oracle и др.)

bormotov Jun 19 2017 at 13:02

потратил минуту на сайте Quest Software не нашел даже раздел где брать на посмотреть.
Только маркетинговое бла-бла-бла, как круто они умеют всё мониторить.

GHostly_FOX Jun 19 2017 at 13:31

https://support.quest.com/spotlight-on-unix/9.0
https://www.quest.com/products/spotlight-on-sql-server-enterprise/

bormotov Jun 19 2017 at 13:49

то есть это SQL Server performance monitoring

GHostly_FOX Jun 19 2017 at 14:27

Не только… Он мониторит различные системы.
Вот например мониторинг сервера под управлением CentOS

Civil Jun 19 2017 at 07:18

Непонятны причины выбора. Даже более того, с учётом длительной истории проблем с influxdb и платной кластеризации, я бы не стал его ставить в Production.

banzayats Jun 19 2017 at 09:44

А можно подробнее о проблемах с InfluxDB?
В данный момент у нас работает связка Zabbix/MySQL. В следующей версии вроде бы обещали экспорт во внешние хранилища временных рядов (в том числе и InfluxDB) и хотелось бы заранее знать о подводных камнях.

smartlight Jun 19 2017 at 10:07

В InfluxDB кластеризация доступна только в enterpise версии

Civil Jun 19 2017 at 10:10

Ниже freeseacher хорошо описал основные текущие. К этому можно добавить разве что следующее:
1. Кластеризация и HA только в платной версии (в бесплатной предлагается писать в две базы параллельно и дальше получить проблемы с синхронизацией данных и пр.). Притом что когда кластеризация была в OpenSource она не работала, поэтому нет оснований верить в нее и сейчас.
2. Апдейты как хождение по минному полю — не знаешь что оторвет сейчас в целом по всему их стеку. Можно посмотреть баги телеграфа, в InfluxDB в каждом апдейте сопоставимый бардак.

mrobespierre Jun 19 2017 at 07:34

отличная статья, спасибо
отдельное спасибо за то, что не надо тащить docker вместе с тысячами его багов т.к. «контейнеры это безопасно»

evnp Jun 19 2017 at 08:04

Незаслуженно пропущен NetXMS. У каких-нибудь других систем мониторинга есть дерево объектов в духе первой картинки из https://habrahabr.ru/post/190360/?

Вообще из систем мониторинга нового поколения есть что-то для мониторинга+инвентаризации с разделением объектов мониторинга на группы (возможно вложенные и пересекающиеся)?

pprwlf Jun 19 2017 at 09:59

Да, AggreGate как минимум, также незаслуженно пропущенный :)

qtask Jun 19 2017 at 10:52

AggreGate без сомнений достойный продукт, но уж точно не легковесный…
Хотя возможности безагентского мониторинга очень даже!

evnp Jun 19 2017 at 11:51

А из свободных?

UFO just landed and posted this here

morozovsk Jun 19 2017 at 12:11

Древовидная структура серверов есть даже в munin.

evnp Jun 20 2017 at 08:14

А покажите. Ничего похожего на скриншотах и в документации не нашел, демо-сервер у них сдох

okondrashin Jun 19 2017 at 08:33

Спасибо за статью! Не рассматривали в качестве агента logstash (из ELK)?

NickyX3 Jun 19 2017 at 12:37

Если не надо «рубить» данные, то сейчас в связке с ELK для многих применений хватает их же Beats.

chupasaurus Jun 19 2017 at 13:32

Который хочет везде JRE и работает как черепаха? Нет, спасибо.

IvanGur Jun 19 2017 at 08:34

Пропустили, вот такую радость https://github.com/riemann

freeseacher Jun 19 2017 at 08:38

Рекомендую рассмотреть довольно удобную связку prometheus + telegraf.
Преимущества такой связки становятся очевидны после некоторой эксплуатации. Дело в том, что influxdb довольно плохо себя ведет на значительных объемах метрик.
Когда колво серверов измеряется десятками influx справлятся на ура, но масштабирование за эти пределы для нее становится неприятным. Из-за

Неоднозначного времени старта. Из-за механики хранения метрик на диске во время старта надо построить индекс в памяти. это может занять любое колличество времени. Его нет возможности предсказать и оно практически не зависит от характеристик сервера(есть мнение, что такое построение индекса упирается в производительность одного ядра). Есть надежда, что в релизе 1.3 у парней получится решить эту проблемму через использования дискового индекса.
Предсказуеммости операции compact. Потребление диска предсказать так же почти невозможно. В настройках по уполчанию compact будет отложен на 4 часа после последней записанной точки в кусок. С одной стороны эта операция сама по себе может занять до 12 часов. С другой стороны в это время на диске метрики будут лежать в режиме не максимального сжатия. Для примера скажу, что полностью сжатый кусок занимает 25G, а не сжатый 457G. Прогнозировать утилизацию диска в такой ситуации на грани возможного.

Предложенная мною связка решает вопрос с хранением метрик.

prometheus очень быстро стартует
хранит метрики в раздельных файлах и
очень бережно относится к диску я одно время проводил сравнение большую часть времени по использоемому месту идут нос к носу, бывает что prometheus потребляет на 3-5% больше диска.

Кроме этого prometheus умеет алертинг, в связке Influx+telegraf приходится добавлять capacitor, а его конфигурация не самое приятное занятие.

blind_oracle Jun 19 2017 at 09:49

Графана с некоторых пор умеет алерты, конденсатор не нужен.

Civil Jun 19 2017 at 10:10

К сожалению функциональности графаны хватает только на простые алерты, зачастую слишком простые.

freeseacher Jun 19 2017 at 11:30

Это увы не так. Когда серверов достаточно, выясняется что нужны templated дашборды и соответственно аварии по ним. Но графана с таких пока не умеет делать алярмы.

undro Jun 19 2017 at 08:38

1,5к хостов, 100к элементов, 15к триггеров.
Для мониторинга крупных сетей альтернативы zabbix пока не встречал.
Подборка хорошая.

ky0 Jun 19 2017 at 09:39

Поддерживаю. Завяление автора про то, что заббикс грузит сервер, имхо, крайне субьективно.

blind_oracle Jun 19 2017 at 09:47

Грузит не заббикс, а его бд, которую после энного объема итемов и values per second приходится партиционировать вручную и так далее. Когда (если?) заббикс перейдёт для хранения метрик на какую либо time series db ему должно сильно полегчать.

ky0 Jun 19 2017 at 10:00

Согласен насчёт партиционирования, но лично у нас (в качестве базы используется постгрес) это происходит автоматически после единоразовой настройки. Существенной нагрузки на сервер с СУБД нет (300 vps), на текущем оборудовании, по приблизительным прикидкам, можно опрашивать на порядок больше элементов.

acmnu Jun 19 2017 at 09:50

Как вы его настраиваете на таких объемах? Неужили правите xml руками? Или используете какие-то сторонние генераторы конфигов?

Fox_exe Jun 19 2017 at 11:29

Есть такая вещь как «Шаблоны» и «Автообнаружение».
Шаблоны позволяют быстро добавлять новые узлы в мониторинг, а Автообнаружение вообще позволяет заббиксу автоматом подкючать нужные триггеры и прочее.
Может дажу карту сети построить…

acmnu Jun 19 2017 at 12:12

Я знаю про шаблоны, но ими тоже надо управлять. На таком парке (1500 хостов) шаблонов будет тоже будь здоров.

Fox_exe Jun 19 2017 at 16:19

Само собой. Но по сути все эти 1500 хостов врятли сильно отличаются. Скажем 90% из них — просто виртуалки. Тогда и шаблон на всех будет один (Причем можно взять стандартный «Template Virt VMware Guest» / «Hypervisor»)
Ну и свитчи/камеры (SNMP + свой шалон для нестандартных девайсов)
Думаю, десятком можно обойтись. Для знакомого с Zabbix админа — дел на пару часов. (А вот новичек потратит пару недель, т.к. теже макросы и триггеры без готовых примеров понять сложновато)

acmnu Jun 19 2017 at 16:23

Скажем 90% из них — просто виртуалки.

Сильное предположение. Т.е. просто виртуалки: стоят, воздух греют. А какая бизнес нагрузка на них? Везде apache+php? Тогда да, хватит пары шаблонов. А если все же вариативность повыше?

undro Jun 19 2017 at 17:31

Думаю не надо объяснять, что такое кол-во контента вносится не за 2 часа после установки. В свое время отказались от nagios, ввиду проблем с производительностью, с тех пор прошло года 3-4.
Разнообразия хватает: сервера, виртуалки, свичи, упсы, датчики, герконы, хотспоты и т.п. железки, в телекоме на 200-300к абонентов такого добра полно. Но это не мешает заливать их в мониторинг пакетно.
В крайний раз добавлял КТВ железки, это пара десятков EMR с пулом в 100-200 каналов и пара сотен всяких PBI, стримеров. Через API и pyzabbix, скриптом на питоне в 10 строк, залил за несколько часов. С max/min триггерами, действиями и графиками на каждый элемент данных (около 3к). Вариантов автоматизации в zabbix много.
Изначальный посыл был про производительность, которой мало что из списка может похвастаться. В zabbix даже если упрешься вертикально, развернуть прокси дело получаса.

undro Jun 19 2017 at 13:27

Что касается автоматизации наполнения, как уже писали, автообнаружение и шаблоны покрывают бОльшую часть задач, в остальных случаях есть внешние скрипты, параметры агента и Zabbix API.

stanislav-belichenko Jun 19 2017 at 11:09

А подскажите, правда ли, что лучше использовать не sql и им подобные базы данных? У меня скромные задачи, но и скромные возможности — может быть, есть какая-то «формула», по которой примерно можно оценить размер бедствия?

banzayats Jun 19 2017 at 11:19

Здесь описано как можно оценить будущий размер базы данных для Zabbix.

Civil Jun 19 2017 at 12:21

Всегда надо отталкиваться от задач. Если Time-Series это именно то что вы хотите и вы их хотите за какое-то значимое время, то SQL совсем не годится. Хотя бы потому что авторы заббикса оценивают размер одной точки в 90 байт, а в современных базах получается какое-то такое распределение:
1. *SQL-based базы и прочие попытки притянуть за уши решение — 80+ байт на точку.
1. Cassandra-based без кастомного сжатия — около 14 байт на точку
2. Graphite'овый Whisper и прочие RRD-подобные — 8-12 байт на точку
3. Более современные базы со сжатием — 2-6 байт на точку

Везде будут свои недостатки и преимущества, выбирать надо исходя из задач. Но я бы в 2017 году начал бы выбор с вопроса «почему не Prometheus?»

little-brother Jul 26 2017 at 21:33

SQLite может хранить 1-4байта (в зависимости от типа и величины) на числовое значение. Это дело можно еще пожать: отказаться от rowid (минус 64-байта со строки) и результат опроса хранить как строку, с одной датой, т.е. не как обычно: "время + значение1", "время + значение2" и так далее, а "время + значение1, значение2 и далее", сэкономив по 4байта на каждой паре, кроме первой.

Civil Jul 26 2017 at 23:59

Ну в принципе конечно можно, но:
1. Зачем?
2. А какая производительность как у чтения так и у записи будет?

little-brother Jul 27 2017 at 01:46

Согласен, что time-series базы для мониторинга предпочтительнее, просто пока выбор так-себе. Тот же Influx еще в процессе. В целом мне не очень понятно почему у них такой объем на точку выходит: казалось бы фиксируем тип float (4 байта) и пишем последовательно. При фиксированном промежутке между измерениями даже дату рядом со значением хранить не надо.

На небольших объемах (скажем до 100-300 устройств) SQLite с описанной выше оптимизацией, должен вполне справляться, по моим прикидкам. На практике, надо будет проверять.

Civil Jul 27 2017 at 13:10

Писать подряд float'ы конечно хорошо (кстати 4 байта это float32, а принято писать float64), но тебе надо фиксировать этот самый промежуток измерений (что не всегда удобно и приведет к тому что даже если измерений не было, место будет тратиться). Собственно по такому принципу, например, работает Graphite'овый Ceres, просто пишет в файлик float64 подряд, а дату первой точки кодирует в имени файла.

На небольших объемах работать будет что угодно, например запись данных в виде строк в csv/json. TSDB все же появляются в тот момент когда у тебя объемы становятся порядка хотя бы десятков тысяч точек в секунду, а веселье начинается когда это уже сотни тысяч или миллионы в секунду.

И я бы исходя из всего этого не советовал бы переизобретать велосипед на базе SQLite :) ну не для этого он сделан.

little-brother Jul 27 2017 at 17:46

Поздно, велосипед уже готов!

Для мониторинга, как мне кажется, одно- и двух-байтных значений в большинстве случаев достаточно, значащих цифр в метриках не так много.

Почему то все сразу мыслят глобально: если база данных, так надо поддерживать тысячи, а лучше миллионы строк в секунду. Для маркетинга циферки конечно нужные — продать «серьезный» продукт видимо проще.

P.S. Проверил SQLite на массовую вставку: добавление 100К записей занимаем ~60сек, т.е. скорость ~1.5К строк/сек (с pragma synchronous = 0). В статьях встречаются цифры 70К строк/сек, но там и железо и ОС другие. При увеличении количества столбцов скорость упала совсем незначительно, что для велосипеда отрадно.

Civil Jul 27 2017 at 18:07

Так вопрос был изначальный — а нафига это все? Есть 40 с лишним TSDB решающих эту задачу эффективнее, в том числе с точки зрения ресурса. Нафига делать на sqlite еще одного кадавра?

samsan Jun 19 2017 at 08:43

Cacti

Уведомлений «из коробки» найдено не было

Уведомления на почту есть из коробки.

format_cd Jun 19 2017 at 09:57

а как же observium?

ELazin Jun 19 2017 at 09:58

Порекламирую свою TSDB поажалуй — https://github.com/akumuli/Akumuli
Работает на запись примерно в 10 раз быстрее того же influx-а, на чтение — примерно на том же уровне (median), но более стабильно (три-сигма сильно ниже). Пока еще нет кластеризации и интеграции со всяким мониторингом вроде графаны и collectd. Send nudes^W pull-requests!

farcaller Jun 19 2017 at 10:17

Несколько раз спотыкался от influx при апдейтах, ушел на prometheus, доволен.

Плюсы:

гибкий синтаксис запросов
просто интегрировать метрики в свои сервисы (клиентские либы почти под всё)
большой выбор механизмов обнаружения сервисов

Singaporian Jun 19 2017 at 11:07

Sensu. Почему он не участвовал?

morozovsk Jun 19 2017 at 11:27

Потому что я выбирал готовую систему мониторинга, которая будет делать «из коробки» всё что мне нужно, а Sensu — это «фреймворк для мониторинга». Об этом в частности упоминается в сравнении его с другими системами мониторинга

KraT_by Jun 19 2017 at 11:19

А кто-нибудь пробовал работать с monitorix или Acronis Monitoring? Есть положительные отзывы?

trapwalker Jun 20 2017 at 02:12

Monitorix пробовал, но сравнивать особо не с чем. Работает, настраивается несложно, графики довольно бедны по функциональности (простые картинки), их нельзя скроллить и масштабировать. Нельзя динамически включать разные метрики на одном графике, а хотелось бы. Буду искать замену. Используется в игровом проекте на начальных этапах. Нужно больше метрик.

Fox_exe Jun 19 2017 at 11:24

Обновите скриншотик для Zabbix (как бы уже давно версия 3.x выпущена и отлично работает. Да и с Grafana подружить можно, если хочется красивостей)

morozovsk Jun 19 2017 at 11:49

Я хотел скриншот интерфейса с графиками, но по запросу zabbix 3 в гуглокартинках находятся только скриншоты с таблицами, скриншоты с графиками старой версии либо интерфейс графаны прикрученный к заббикусу. Смотрел скриншоты из недавней статьи о выходе новой версии заббикса — та же проблема: маркетинговая картинка (а не скриншот), скриншоты с таблицами и один скриншот с одним графиком на весь экран что по-моему получается ещё менее показательно, чем скриншот от старой версии.

morozovsk Jun 19 2017 at 12:03

Update: удалось найти подходящий скриншот у них на сайте.

evnp Jun 19 2017 at 11:57

Спасибо за Netdata — любопытная система, очень многое действительно работает из коробки, кастомизируется судя по документации тоже неплохо — надо будет попробовать.

dmitriylyalyuev Jun 19 2017 at 12:59

А что из этого укладывается в парадигму Infrastructure As Code?
Ну кроме Nagios/Munin?

Grafana, на сколько я понимаю, мышкой все строить надо. Да и все остальное тоже?

zer0access Jun 19 2017 at 14:22

Sensu пытается быть таким решением. Я пытался его настроить в домашней сети, и оно даже заработало, но оказалось довольно тяжеловесным, т.к. потянуло ещё RabbitMQ и Redis. К тому же, это относительно новый продукт и он находится в активной разработке. Возможно, в будущем это будет довольно неплохое средство мониторинга.

freechibis Jun 19 2017 at 16:10

Для Grafana есть обертки вокруг API, например https://github.com/utkarshcmu/wizzy

Eugene_Burachevskiy Jun 19 2017 at 17:20

Связка из Node Exporter + Prometheus + Grafana спокойно разворачивается через CloudInit конфиг (допустим тем же терраформом).

Grafana позволяет один раз руками настроить все нужные датасорсы и дашборды, а потом автоматом делать их бэкап/рестор через curl

sHaggY_caT Sep 7 2017 at 10:32

Я на zabbix делала. Конфиг агента erb/j2 темплейт, xml шаблоны на сервер тоже можно грузить puppet/ansible

divanikus Jun 19 2017 at 13:51

По моему опыту в системах мониторинга все упирается в алерты. Ну т.е. можно сколько угодно любоваться красивыми графиками или динамичным дашбордом, но если алерты настроить сложно, если их много не по делу и т.п. — полезность системы резко падает. В этом плане в моем личном топе пока лидирует Zabbix, хотя веб-интерфейс там так себе, если честно.

nanshakov Jun 19 2017 at 14:22

Огромное спасибо автору за статью. Как раз работаем над стартапом и задумались над этим. У меня есть вопрос к читателям хабра. Сейчас наше ПО пишет логи в БД, мы их разбираем на стороне воркером и выводим, например, «статистику одного дня» и всякое разное. Проблема в том, что менять структуру лога — менять структуру бд — геморно. Какие решения есть и как можно загуглить это?

vgoloviznin Jun 19 2017 at 15:20

Если вам нужно преобразовывать логи, то посмотрите на ELK

morozovsk Jun 19 2017 at 15:39

Проводил небольшое исследование, кто что использует для логов:
1) elk
2) sentry
3) graylog2
4) mongodb
5) любая бд

Это тема отдельной статьи, нужно глубоко копать, а у меня не было такой задачи на текущем проекте — из-за жёсткой специфики нельзя вести логов.

divanikus Jun 19 2017 at 17:38

fluentd еще забыли

little-brother Jun 19 2017 at 14:44

Альтернатив несколько больше чем описано в обзоре (в частности нет PRTG и The Dude), что впрочем не остановило меня от написания еще одной с максимально упрощенным интерфейсом, возможностью опроса устройств несколькими методами (от SNMP до опроса портов) и просмотра истории сгруппированной по типам устройств/узлов.

Демка, следящая за стендовым оборудованием.

dqvsra Jun 19 2017 at 15:03

Для NodeJS мне понравилось работать с Keymetrics.IO, особенно потому что
эта система мониторинга является частью «process manager» PM2, тем более сейчас у них условия для бесплатного пользования стали более привлекательными: $0 per month 4 processes 1 user.

varnav Jun 19 2017 at 15:10

Обзор 51 системы мониторинга:

https://habrahabr.ru/company/pc-administrator/blog/304356/

morozovsk Jun 19 2017 at 15:28

Посмотрел первые 10 — все платные, это не мой кейс.

varnav Jun 19 2017 at 15:12

Лично у меня:

Observium — для сетевых устройств.
Munin — для локалхоста
Zabbix — для всего

serejk Jun 19 2017 at 17:20

По поводу Update2: может сразу на википедию вносить обзор (https://en.wikipedia.org/wiki/Time_series_database)? Частично он там уже есть. Ну или результат туда запостить — многим бы пригодился.

Civil Jun 19 2017 at 17:26

Там есть субъективные комментарии (последнее поле) которое ценны, но не факт что их Википедия примет. Наверное в перспективе можно, если придумать как таблицу оставить сортируемой и перенести все включая комментарии и заметки на полях.

morozovsk Jun 19 2017 at 17:35

Это не я делаю, а энтузиасты, я даже не знаю кто конкретно. Но по своему опыту скажу, что писать статью на википедии, это будет квест посложнее чем табличка в googledocs и даже на порядок сложнее, чем на хабре. Здесь общественность разрулит нужна статья или нет, а там очень жёсткая бюрократия: нужно знать кучу правил, уметь отстоять своё мнение, находить людей, которые могут поддержать тебя и твою статью. После нескольких статей — прямая дорога в политику. Если ты не следуешь правилам, то вся твоя работа по написанию статьи может быть в момент удалена, а это просто непередаваемые впечатления, гораздо более сильные, чем когда твоя статья получает минусы. Я зарёкся когда-либо ещё писать туда статьи. Прошу прощения за то что меня прорвало. 7 лет прошло, до сих пор не отпускает.

serejk Jun 19 2017 at 18:27

Да я понимаю, что не совсем по адресу написал, но не придумал сходу куда. Щас вспомнил, что там же чат есть вроде бы. Касаемо википедии — там не нужно новой статьи, там уже похожая таблица даже есть, со схожим набором полей. И по результатам стихийного обзора можно вынести туда все основное, чтобы оно не кануло в лету в недрах google docs:) не думаю, что модераторы википедии воспримут в штыки.

Civil Jun 19 2017 at 21:08

В принципе можно, вопрос с источниками данных. Для части строк в таблице были использованы источники вида «Эй, ты же автор? А сколько байт занимает точка у тебя?».

foxmuldercp Jun 19 2017 at 18:48

Ещё можно на Pandora fms посмотреть. легкая, простая, и новые хосты подключаются методом установки агента который из коробки есть кажется что в убунтах, что в дебианах, что в центосях каких

morozovsk Jun 19 2017 at 20:19

Я не рассматривал платные или закрытые продукты

esudnik Jun 19 2017 at 20:19

Для простых проектов также могу посоветовать serverstate.ru

morozovsk Jun 19 2017 at 20:22

Тоже рассматривал его, но остановился на бесплатном аналоге.

amarao Jun 19 2017 at 21:25

Про shinken ни слова, в одну кучу свалены perfdata и мониторинг. Я даже не могу дать фитбэка на обзор, т.к. не понимаю как можно вместе сравнивать nagios и graphana. Всё равно, что сравнивать blender и gcc.

morozovsk Jun 19 2017 at 22:48

Я старался, чтобы в этот обзор попало только то, что популярно или перспективно (исходя из моей субъективной оценки). За основу я брал Comparison of network monitoring systems и топ гитхаба. Но если бы я взял от туда в статью весь список, то у меня бы год ушёл или я бы получил ещё одну статью Обзор 51 системы мониторинга. Но у меня не стояло такой задачи, мне нужно было выбирать систему мониторинга на замену munin. Именно по-этому в обзор попал ganglia, потому что я её рассматривал как альтернативу, хотя судя по результатам опроса её вообще никто не использует (считаю это моим самым большим промахом, все остальные ответы на опрос были достаточно предсказуемы).
В данном обзоре я не сравниваю nagios и graphana. Я специально написал "Отдельно хотелось бы упомянуть такой продукт, как grafana". Если этот текст путает, то предложите свой вариант и я внесу изменения в статью.

truezemez Jun 19 2017 at 23:15

Википедия использовала ганглию https://ganglia.wikimedia.org/latest/
Вроде бы, мигрируют на прометей+графана.

amarao Jun 19 2017 at 23:28

Ганглия уныла. Graphana — няшка.

amarao Jun 19 2017 at 23:28

Давайте заменим «graphana» на collectd. Всё равно не понятно как вы сравниваете nagios и collectd. Они просто разные вещи делают. Они близки друг к другу по области применения, но совершенно не взаимозаменяемы. Скорее, дополняющие друг друга.

evnp Jun 20 2017 at 08:41

А что в принципе такого умеет collectd и не умеет nagios (давайте исключим разные плагины для сбора разных специфичных метрик)? Я бы разделил средства мониторинга на универсальные (zabbix, nagios со всеми ответвлениями, netxms и т.д. — они пытаются подгрести под себя все, включая инвентаризацию, чем собственно и хороши) и специализированные (а уж среди них сбор/визуализация метрик в духе collectd — кажется самое популярное направление, обработка логов наверное на втором месте). В этом смысле collectd никак не дополняет nagios, он представляет подмножество его возможностей, но при этом позволяет избежать избыточной сложности и снизить требования у ресурсам на мониторинг. Визуально результаты тоже, конечно, отличаются — но это уже по части «нефункциональных требований»

PRIHLOPer Jun 20 2017 at 08:49

Пользую Prometheus + Grafana.

Prometheus хорош своей модульностью, можно включить только то что нужно и прикрутить модули для сборки нужных метрик. Ну и там всё предельно просто по настройке и транспорту метрик с клиентов на сервер.

AnyKey80lvl Jun 20 2017 at 10:08

Вот еще одно сравнение Open-Source TSDB.в Google Docs.
Чуть более проработанный, мне кажется, но систем меньше

Civil Jun 20 2017 at 11:15

То что он более проработанный это к сожалению видимость. У него есть пара серьезных ~~недостатков~~особенностей:

Параметры типа Write Performance/Query Perfromance сравниваются по заверениям авторов без учета разного железа и методик тестирования — то есть по фатку это профанация.
Для показателей bytes per point нет источника, например непонятно откуда у Dalmatiner'а 1, когда авторы базы об этом ничего не говорят, если из тестов то тогда см п. 1, цифры в этом блоке профанация так как еще и осознанно на разных сетах данных
Оценки типа Complexity, Functionality, Usability тоже даны примерно от балды по какой-то внутренней логике авторов, которая не очень то афишируется
Нет упоминаний ни в каком виде что у всего raik-based cross-dc кластеризация платная, что по мне, например важно.

Поэтому я бы честно говоря не советовал бы использовать эту таблицу как источник информации, из-за того что она не учитывает разницу тестовых методик все цифры в ней являются профанацией и по факту бесполезны (не говоря о том, что например для Whisper'а есть более быстрые реализации на Go, чем указанное в таблице, но автор по какой-то причине не хочет их учитывать).

AnyKey80lvl Jun 20 2017 at 12:06

Согласен! Но сравнивать эти системы по «полной программе» — гигантский труд.

А люди, которые занимаются мониторингом и сопутствующими темами, редко имеют много свободного времени :)

Civil Jun 20 2017 at 12:30

Конечно, поэтому в таблице с бОльшим количеством систем нет никаких разделов о производительности, потому что какая бы цифра там не оказалась, она будет либо чушью, либо наглой ложью.

Фактически основная идея таблицы из Update2 в том чтобы собрать более честную и объективную информацию чем собрана в таблице из Update3 — то есть выкинуть по максимуму субъективные факторы, а взамен охватить большее количество систем.
Наверное единственное чего не хватает это лицензии, чтобы цель можно было бы считать достигнутой.

Hesed Jun 20 2017 at 10:24

Не упомянута OpenNMS [demo]. У меня мониторится порядка 2500 нод (сетевая инфраструктура, сервера), интерфейсов… ммм… много. Стек: Java + PostgreSQL + на выбор time-series database — RRD, JRD, NewTS. Относительно легко разбивается на шарды. Конфигурирование может добавить седых волос, но после настройки работает безупречно.