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

  • Tutorial
Очень долго хотел написать статью, но не хватало времени. Нигде (в том числе на Хабре) не нашёл такой простой альтернативы munin, как описанная в этой статье.



Я backend developer и очень часто на моих проектах не бывает выделенных админов (особенно в самом начале жизни продукта), поэтому я уже давно занимаюсь базовым администрированием серверов (начальная установка-настройка, бекапы, репликация, мониторинг и т.д.). Мне это очень нравится и я всё время узнаю что-то новое в этом направлении.

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

Интерфейс

Munin


Он легко устанавливается и имеет небольшие требования. Он написан на perl и использует кольцевую базу данных (RRDtool).

Пример установки
Выполняем команды:
apt-get install munin munin-node
service munin-node start

Теперь munin-node будет собирать метрики системы и писать их в бд, а munin раз в 5 минут будет генерировать из этой бд html-отчёты и класть их в папку /var/cache/munin/www

Для удобного просмотра этих отчётов можно создать простой конфиг для nginx
server {
    listen 80;
    server_name munin.myserver.ru;
    root /var/cache/munin/www;
    index index.html;
}


Собственно и всё. Уже можно смотреть любые графики использования процессора, памяти, жёсткого диска, сети и многого другого за день/неделю/месяц/год. Чаще всего меня интересовала нагрузка чтения/записи на жёсткий диск, потому что узким местом всегда была база данных.

Для мониторинга ресурсов сервера его всегда хватало, а для мониторинга доступности сервера использовался бесплатный сервис наподобие uptimerobot.com.

Я использую такую комбинацию для мониторинга своих домашних проектов на виртуальном сервере.

Если проект вырастает из одного сервера, тогда на втором сервере достаточно установить munin-node, а на первом — добавить в конфиге одну строчку для сбора метрик со второго сервера. Графики по обоим серверам будут раздельные, что не удобно для просмотра общей картины — на каком сервере заканчивается свободное место на диске, а на каком оперативная память. Эту ситуации можно исправить добавив в конфиг уже десяток строчек для агрегации одного графика с метриками с обоих серверов. Соответственно целесообразно это делать только для самых основных метрик. Если в конфиге сделать ошибку, то придётся долго читать в логах, что именно к ней привело и не найдя информации попытаться исправить ситуацию «методом тыка».

Стоит ли говорить, что для большего количества серверов это превращается в самый настоящий ад. Может это из-за того, что munin был разработан в 2003 году и изначально не был рассчитан на это.

Альтернативы munin для мониторинга нескольких серверов


Определил для себя необходимые качества, которыми должна обладать новая система мониторинга:
  • количество метрик не меньше чем у munin (у него их около 30 базовых графиков и ещё около 200 плагинов в комплекте)
  • возможность написания собственных плагинов на bash (у меня было два таких плагина)
  • иметь небольшие требования к серверу
  • возможность вывода метрик с разных серверов на одном графике без правки конфигов
  • уведомления на почту, в slack и telegram
  • Time Series Database более мощную чем RRDtool
  • простая установка
  • ничего лишнего
  • бесплатно и с открытым исходным кодом

Я перечислю, всё что я рассматривал.

Cacti


Почти тоже самое, что munin только на php. В качестве базы данных можно использовать rrdtool как у munin или mysql. Первый релиз: 2001 год.
Интерфейс

Ganglia


Почти тоже самое, что и предыдущие, написана на php, в качестве базы данных — rrdtool. Первый релиз: 1998 год.
Интерфейс

Collectd


Ещё более простая система, чем предыдущие. Написан на c, в качестве базы данных — rrdtool. Первый релиз: 2005 год.
Интерфейс

Graphite


Состоит из трёх компонент, написанных на python:
carbon собирает метрики их записывает их в бд
whisper — собственная rrdtool-подобная бд
graphite-web — интерфейс
Первый релиз: 2008 год.
Интерфейс

Zabbix


Профессиональная система мониторинга, используется большинством админов. Есть практически всё, включая уведомления на почту (для slack и telegram можно написать простой bash-скрипт). Тяжёлая для пользователя и для сервера. Раньше приходилось пользоваться, впечатления, как будто вернулся с jira на mantis.
Ядро написано на c, веб интерфейс — на php. В качестве базы данных может использовать: MySQL, PostgreSQL, SQLite, Oracle или IBM DB2. Первый релиз: 2001 год.
Интерфейс

Nagios


Достойная альтернатива Zabbix. Написан на с. Первый релиз: 1999 год.
Интерфейс

Icinga


Форк Nagios. В качестве бд может использовать: MySQL, Oracle, and PostgreSQL. Первый релиз: 2009 год.
Интерфейс

Небольшое отступление


Все вышеперечисленные системы достойны уважения. Они легко устанавливаются из пакетов в большинстве linux-дистрибутивов и уже давно используются в продакшене на многих серверах, поддерживаются, но очень слабо развиваются и имеют устаревший интерфейс.
В половине продуктов используются sql-базы данных, что является не оптимальным для хранения исторических данных (метрик). С одной стороны эти бд универсальны, а с другой — создают большую нагрузку на диски, а данные занимают больше места при хранении.
Для таких задач больше подходят современные бд временных рядов такие как ClickHouse.
Системы мониторинга нового поколения используют базы данных временных рядов, одни из них включают их в свой состав как неотделимую часть, другие используют как отдельную компоненту, а третью могут работать вообще без бд.

Netdata


Вообще не требует базы данных, но может выгружать метрики в Graphite, OpenTSDB, Prometheus, InfluxDB. Написана на c и python. Первый релиз: 2016 год.
Интерфейс

Prometheus


Состоит из трёх компонент, написанных на go:
prometheus — ядро, собственная встроенная база данных и веб-интерфейс.
node_exporter — агент, который может быть установлен на другой сервер и пересылать метрики в ядро, работает только с prometheus.
alertmanager — система уведомлений.
Первый релиз: 2014 год.
Интерфейс

InfluxData (TICK Stack)


Состоит из четырёх компонент, написанных на go которые могут работать со сторонними продуктами:
telegraf — агент, который может быть установлен на другой сервер и пересылать метрики, а также логи в базы influxdb, elasticsearch, prometheus или graphite, а также в несколько серверов очередей.
influxdb — база данных, которая может принимать данные из telegraf, netdata или collectd.
chronograf — веб интерфейс для визуализации метрик из бд.
kapacitor — система уведомлений.
Первый релиз: 2013 год.
Интерфейс

Отдельно хотелось бы упомянуть такой продукт, как grafana, она написана на go и позволяет визуализировать данные из influxdb, elasticsearch, clickhouse, prometheus, graphite, а также отправлять уведомления на почту, в slack и telegram.
Первый релиз: 2014 год.
Интерфейс

Выбираем лучшее


В интернете и на Хабре, в том числе, полно примеров использования различных компонент из разных продуктов, чтобы получить то что надо именно тебе.

carbon (агент) -> whisper (бд) -> grafana (интерфейс)
netdata (в качестве агента) -> null / influxdb / elasticsearch / prometheus / graphite (в качестве бд) -> grafana (интерфейс)
node_exporter (агент) -> prometheus (в качестве бд) -> grafana (интерфейс)
collectd (агент) -> influxdb (бд) -> grafana (интерфейс)
zabbix (агент+сервер) -> mysql -> grafana (интерфейс)
telegraf (агент) -> elasticsearch (бд) -> kibana (интерфейс)
… и т.д.
Видел упоминание даже о такой связке:
… (агент) -> clickhouse (бд) -> grafana (интерфейс)

В большинстве случаев в качестве интерфейса использовалась grafana, даже если она была в связке с продуктом, который уже содержал собственный интерфейс (prometheus, graphite-web).
Поэтому (а также в силу её универсальности, простоты и удобства) в качестве интерфейса я остановился на grafana и приступил к выбору базы данных: prometheus отпал потому что не хотелось тянуть весь его функционал вместе с интерфейсом только из-за одной бд, graphite — бд предыдущего десятилетия, переработанная rrdtool-бд предыдущего столетия, ну и собственно я остановился на influxdb и как выяснилось — не один я сделал такой выбор.

Также для себя я решил выбрать telegraf, потому что он удовлетворял моим потребностям (большое количество метрик и возможность написания своих плагинов на bash), а также работает с разными бд, что может быть полезно в будущем.

Итоговая связка у меня получилась такая:
telegraf (агент) -> influxdb (бд) -> grafana (интерфейс+уведомления)

Все компоненты не содержат ничего лишнего и написаны на go. Единственное, чего я боялся — то что эта связку будет трудна в установке и настройке, но как вы сможете видеть ниже — это было зря.

Итак, короткая инструкция по установке TIG:

influxdb

wget https://dl.influxdata.com/influxdb/releases/influxdb-1.2.2.x86_64.rpm && yum localinstall influxdb-1.2.2.x86_64.rpm #centos
wget https://dl.influxdata.com/influxdb/releases/influxdb_1.2.4_amd64.deb && dpkg -i influxdb_1.2.4_amd64.deb #ubuntu
systemctl start influxdb
systemctl enable influxdb

Теперь можно делать запросы к базе (правда данных там ещё пока нет):
http://localhost:8086/query?q=select+*+from+telegraf..cpu

telegraf

wget https://dl.influxdata.com/telegraf/releases/telegraf-1.2.1.x86_64.rpm && yum -y localinstall telegraf-1.2.1.x86_64.rpm #centos
wget https://dl.influxdata.com/telegraf/releases/telegraf_1.3.2-1_amd64.deb && dpkg -i telegraf_1.3.2-1_amd64.deb #ubuntu
#в случае установки на сервер отличный от того где находится influxdb необходимо в конфиге /etc/telegraf/telegraf.conf в секции [[outputs.influxdb]] поменять параметр urls = ["http://localhost:8086"]:
sed -i 's|  urls = ["http://localhost:8086"]|  urls = ["http://myserver.ru:8086"]|g' /etc/telegraf/telegraf.conf
systemctl start telegraf
systemctl enable telegraf

Telegraf автоматически создаст базу в influxdb с именем «telegraf», логином «telegraf» и паролем «metricsmetricsmetricsmetrics».

grafana

yum install https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana-4.3.2-1.x86_64.rpm #centos
wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana_4.3.2_amd64.deb && dpkg -i grafana_4.3.2_amd64.deb #ubuntu
systemctl start grafana-server
systemctl enable grafana-server

Интерфейс доступен по адресу http://myserver.ru:3000. Логин: admin, пароль: admin.
Изначально в интерфейсе ничего не будет, потому что графана ничего не знает о данных.
1) Нужно зайти в источники и указать influxdb (бд: telegraf)
2) Нужно создать свой дашборд с нужными метриками (уйдёт очень много времени) или импортировать уже готовый, например:
928 — позволяет видеть все метрики по выбранному хосту
914 — тоже самое
61 — позволяет метрики по выбранным хостам на одном графике
Grafana имеет отличный инструмент для импорта сторонних дашбордов (достаточно указать его номер), вы также можете создать свой дашборд и поделиться им с сообществом.
Вот список всех дашбордов, работающие с данными из influxdb, которые были собраны с помощью коллектора telegraf.

Акцент на безопасность


Все порты на ваших серверах должны быть открыты только с тех ip, которым вы доверяете либо в используемых продуктах должна быть включена авторизация и изменены пароли по-умолчанию (я делаю и то и другое).

influxdb

В influxdb по-умолчанию отключена авторизация и кто угодно может делать что угодно. По-этому если на сервере нет файервола, то крайне рекомендую включить авторизацию:

#Создаём базу и пользователей:
influx -execute 'CREATE DATABASE telegraf'
influx -execute 'CREATE USER admin WITH PASSWORD "password_for_admin" WITH ALL PRIVILEGES'
influx -execute 'CREATE USER telegraf WITH PASSWORD "password_for_telegraf"'
influx -execute 'CREATE USER grafana WITH PASSWORD "password_for_grafana"'
influx -execute 'GRANT WRITE ON "telegraf" TO "telegraf"' #чтобы telegraf мог писать метрики в бд
influx -execute 'GRANT READ ON "telegraf" TO "grafana"' #чтобы grafana могла читать метрики из бд
#в конфиге /etc/influxdb/influxdb.conf в секции [http] меняем параметр auth-enabled для включения авторизации:
sed -i 's|  # auth-enabled = false|  auth-enabled = true|g' /etc/influxdb/influxdb.conf
systemctl restart influxdb

telegraf

#в конфиге /etc/telegraf/telegraf.conf в секции [[outputs.influxdb]] меняем пароль на созданный в предыдущем пункте:
sed -i 's|  # password = "metricsmetricsmetricsmetrics"|  password = "password_for_telegraf"|g' /etc/telegraf/telegraf.conf
systemctl restart telegraf

grafana

В настройках источников, нужно указать для influxdb новый логин: «grafana» и пароль «password_for_grafana» из пункта выше.
Также в интерфейсе нужно сменить пароль по-умолчанию для пользователя admin.
Admin -> profile -> change password


Update: добавил пункт к своим критериям «бесплатно и с открытым исходным кодом», забыл его указать с самого начала, а теперь мне советуют кучу платного/условно-бесплатного/триального/закрытого софта. Тут бы с бесплатным разобраться.
Как я выбирал
1) сначала посмотрел на сравнение систем мониторинга на английской википедии
2) посмотрел на гитхабе топовые проекты
3) посмотрел, что есть на эту тему на хабре
4) погуглил какие системы сейчас в тренеде

Update2: сейчас группа энтузиастов создаёт таблицу в google docs, сравнивая различные системы мониторинга по ключевым параметрам (Language, Bytes/point, Clustering). Работа кипит, текущий срез под катом.
Скриншот на момент 15:15


Update3: ещё одно сравнение Open-Source TSDB в Google Docs. Чуть более проработанное, но систем меньше AnyKey80lvl

P.S.: если я опустил какие-то моменты в описании настройки-установки, то пишите в комментариях и я обновлю статью. Опечатки — в личку.
P.P.S.: конечно этого никто не услышит (исходя из предыдущего опыта написания статей), но я всё равно должен попробовать: не задавайте вопросы в личку на хабре, вк, фб и т.д., а пишите комментарии здесь.
P.P.P.S.: размер статьи и потраченное на неё время сильно выбились из начального «бюджета», надеюсь, что результаты этой работы будут для кого-то полезны.
Что вы используете для мониторинга?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 111
  • 0
    Спасибо, интересно! А не встречали в ваших изысканиях подобную конфигурацию, но сразу и для *nix, и для win* наблюдаемых машин?
    • 0
      Icinga умеет, у неё есть клиенты для обеих систем + wmi + snmp. С развитием IoT скоро можно будет и чайник на кухне мониторить
      • 0

        Могу посоветовать два решения для мониторинга 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
      • +1
        На своем проекте, на более чем 10 машинах, использую munin и не испытываю никаких проблем. Легкая, не грузит сервер. И есть все метрики какие нужны прямо из коробки. Есть оповещение на почту если что-то нехорошее происходит на сервере. Имхо мне этого более чем достаточно и даже не планирую менять.
        А вот на работе да, там везде zabbix + grafana и шлет алерты в слак.
        • 0
          А чем плох/недостаточен стандартный интерфейс Zabbix? Или grafana просто визуально красивее?

          PS в zabbix раздражает узкая направленность на мониторинг серверов (например, чтобы мониторить web с внешки, приходится создавать фейковый сервер, чтобы вешать на него веб сценарии и триггеры с аляртами) и невозможность создавать хоть сколько-то динамические оповещения с использованием условий и регулярных выражений.
          • 0
            Прошу прощения, напутал. Там graphite, а не zabbix.
        • +1
          А сравнение-то где?
        • 0
          Многие, кто пользуются связкой Prometheus + Grafana, говорят о случаях когда grafana досит прометея.

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

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

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

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

            • 0
              А можно подробнее о проблемах с InfluxDB?
              В данный момент у нас работает связка Zabbix/MySQL. В следующей версии вроде бы обещали экспорт во внешние хранилища временных рядов (в том числе и InfluxDB) и хотелось бы заранее знать о подводных камнях.
              • +1
                В InfluxDB кластеризация доступна только в enterpise версии
                • 0
                  Ниже freeseacher хорошо описал основные текущие. К этому можно добавить разве что следующее:
                  1. Кластеризация и HA только в платной версии (в бесплатной предлагается писать в две базы параллельно и дальше получить проблемы с синхронизацией данных и пр.). Притом что когда кластеризация была в OpenSource она не работала, поэтому нет оснований верить в нее и сейчас.
                  2. Апдейты как хождение по минному полю — не знаешь что оторвет сейчас в целом по всему их стеку. Можно посмотреть баги телеграфа, в InfluxDB в каждом апдейте сопоставимый бардак.
              • 0
                отличная статья, спасибо
                отдельное спасибо за то, что не надо тащить docker вместе с тысячами его багов т.к. «контейнеры это безопасно»
                • 0
                  Незаслуженно пропущен NetXMS. У каких-нибудь других систем мониторинга есть дерево объектов в духе первой картинки из https://habrahabr.ru/post/190360/?

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

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

                      • 0
                        А из свободных?
                        • +2
                          Это платный софт
                        • 0
                          Древовидная структура серверов есть даже в munin.
                          • 0
                            А покажите. Ничего похожего на скриншотах и в документации не нашел, демо-сервер у них сдох
                        • 0
                          Спасибо за статью! Не рассматривали в качестве агента logstash (из ELK)?
                          • 0
                            Если не надо «рубить» данные, то сейчас в связке с ELK для многих применений хватает их же Beats.
                            • +1
                              Который хочет везде JRE и работает как черепаха? Нет, спасибо.
                            • +2
                              Пропустили, вот такую радость https://github.com/riemann
                              • +1

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


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

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


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

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

                                • +1

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

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

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

                                  • +3
                                    1,5к хостов, 100к элементов, 15к триггеров.
                                    Для мониторинга крупных сетей альтернативы zabbix пока не встречал.
                                    Подборка хорошая.
                                    • 0
                                      Поддерживаю. Завяление автора про то, что заббикс грузит сервер, имхо, крайне субьективно.
                                      • +2

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

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

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

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

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

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

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

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

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

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

                                                Везде будут свои недостатки и преимущества, выбирать надо исходя из задач. Но я бы в 2017 году начал бы выбор с вопроса «почему не Prometheus?»
                                                • 0
                                                  SQLite может хранить 1-4байта (в зависимости от типа и величины) на числовое значение. Это дело можно еще пожать: отказаться от rowid (минус 64-байта со строки) и результат опроса хранить как строку, с одной датой, т.е. не как обычно: "время + значение1", "время + значение2" и так далее, а "время + значение1, значение2 и далее", сэкономив по 4байта на каждой паре, кроме первой.
                                                  • 0
                                                    Ну в принципе конечно можно, но:
                                                    1. Зачем?
                                                    2. А какая производительность как у чтения так и у записи будет?
                                                    • 0
                                                      Согласен, что time-series базы для мониторинга предпочтительнее, просто пока выбор так-себе. Тот же Influx еще в процессе. В целом мне не очень понятно почему у них такой объем на точку выходит: казалось бы фиксируем тип float (4 байта) и пишем последовательно. При фиксированном промежутке между измерениями даже дату рядом со значением хранить не надо.

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

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

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

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

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

                                                          P.S. Проверил SQLite на массовую вставку: добавление 100К записей занимаем ~60сек, т.е. скорость ~1.5К строк/сек (с pragma synchronous = 0). В статьях встречаются цифры 70К строк/сек, но там и железо и ОС другие. При увеличении количества столбцов скорость упала совсем незначительно, что для велосипеда отрадно.
                                                          • 0
                                                            Так вопрос был изначальный — а нафига это все? Есть 40 с лишним TSDB решающих эту задачу эффективнее, в том числе с точки зрения ресурса. Нафига делать на sqlite еще одного кадавра?
                                            • 0
                                              Cacti
                                              Уведомлений «из коробки» найдено не было


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

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


                                                    Плюсы:


                                                    • гибкий синтаксис запросов
                                                    • просто интегрировать метрики в свои сервисы (клиентские либы почти под всё)
                                                    • большой выбор механизмов обнаружения сервисов
                                                    • 0
                                                      Sensu. Почему он не участвовал?
                                                    • 0
                                                      А кто-нибудь пробовал работать с monitorix или Acronis Monitoring? Есть положительные отзывы?
                                                      • 0
                                                        Monitorix пробовал, но сравнивать особо не с чем. Работает, настраивается несложно, графики довольно бедны по функциональности (простые картинки), их нельзя скроллить и масштабировать. Нельзя динамически включать разные метрики на одном графике, а хотелось бы. Буду искать замену. Используется в игровом проекте на начальных этапах. Нужно больше метрик.
                                                      • 0
                                                        Обновите скриншотик для Zabbix (как бы уже давно версия 3.x выпущена и отлично работает. Да и с Grafana подружить можно, если хочется красивостей)
                                                        • 0
                                                          Я хотел скриншот интерфейса с графиками, но по запросу zabbix 3 в гуглокартинках находятся только скриншоты с таблицами, скриншоты с графиками старой версии либо интерфейс графаны прикрученный к заббикусу. Смотрел скриншоты из недавней статьи о выходе новой версии заббикса — та же проблема: маркетинговая картинка (а не скриншот), скриншоты с таблицами и один скриншот с одним графиком на весь экран что по-моему получается ещё менее показательно, чем скриншот от старой версии.
                                                          • 0
                                                            Update: удалось найти подходящий скриншот у них на сайте.
                                                        • +2
                                                          Спасибо за Netdata — любопытная система, очень многое действительно работает из коробки, кастомизируется судя по документации тоже неплохо — надо будет попробовать.
                                                          • 0

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


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

                                                            • 0
                                                              Sensu пытается быть таким решением. Я пытался его настроить в домашней сети, и оно даже заработало, но оказалось довольно тяжеловесным, т.к. потянуло ещё RabbitMQ и Redis. К тому же, это относительно новый продукт и он находится в активной разработке. Возможно, в будущем это будет довольно неплохое средство мониторинга.
                                                              • 0
                                                                Для Grafana есть обертки вокруг API, например https://github.com/utkarshcmu/wizzy
                                                                • Связка из Node Exporter + Prometheus + Grafana спокойно разворачивается через CloudInit конфиг (допустим тем же терраформом).

                                                                  Grafana позволяет один раз руками настроить все нужные датасорсы и дашборды, а потом автоматом делать их бэкап/рестор через curl
                                                                  • 0
                                                                    Я на zabbix делала. Конфиг агента erb/j2 темплейт, xml шаблоны на сервер тоже можно грузить puppet/ansible
                                                                  • +1
                                                                    По моему опыту в системах мониторинга все упирается в алерты. Ну т.е. можно сколько угодно любоваться красивыми графиками или динамичным дашбордом, но если алерты настроить сложно, если их много не по делу и т.п. — полезность системы резко падает. В этом плане в моем личном топе пока лидирует Zabbix, хотя веб-интерфейс там так себе, если честно.
                                                                    • 0
                                                                      Огромное спасибо автору за статью. Как раз работаем над стартапом и задумались над этим. У меня есть вопрос к читателям хабра. Сейчас наше ПО пишет логи в БД, мы их разбираем на стороне воркером и выводим, например, «статистику одного дня» и всякое разное. Проблема в том, что менять структуру лога — менять структуру бд — геморно. Какие решения есть и как можно загуглить это?
                                                                      • +2

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

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

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

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

                                                                          https://habrahabr.ru/company/pc-administrator/blog/304356/
                                                                          • 0
                                                                            Посмотрел первые 10 — все платные, это не мой кейс.
                                                                          • 0
                                                                            Лично у меня:

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

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

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

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

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

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

                                                                                    • 0
                                                                                      Я не рассматривал платные или закрытые продукты
                                                                                    • 0
                                                                                      Для простых проектов также могу посоветовать serverstate.ru
                                                                                      • 0
                                                                                        Тоже рассматривал его, но остановился на бесплатном аналоге.
                                                                                      • +1
                                                                                        Про shinken ни слова, в одну кучу свалены perfdata и мониторинг. Я даже не могу дать фитбэка на обзор, т.к. не понимаю как можно вместе сравнивать nagios и graphana. Всё равно, что сравнивать blender и gcc.
                                                                                        • 0
                                                                                          Я старался, чтобы в этот обзор попало только то, что популярно или перспективно (исходя из моей субъективной оценки). За основу я брал Comparison of network monitoring systems и топ гитхаба. Но если бы я взял от туда в статью весь список, то у меня бы год ушёл или я бы получил ещё одну статью Обзор 51 системы мониторинга. Но у меня не стояло такой задачи, мне нужно было выбирать систему мониторинга на замену munin. Именно по-этому в обзор попал ganglia, потому что я её рассматривал как альтернативу, хотя судя по результатам опроса её вообще никто не использует (считаю это моим самым большим промахом, все остальные ответы на опрос были достаточно предсказуемы).
                                                                                          В данном обзоре я не сравниваю nagios и graphana. Я специально написал "Отдельно хотелось бы упомянуть такой продукт, как grafana". Если этот текст путает, то предложите свой вариант и я внесу изменения в статью.
                                                                                          • +1
                                                                                            Википедия использовала ганглию https://ganglia.wikimedia.org/latest/
                                                                                            Вроде бы, мигрируют на прометей+графана.
                                                                                            • 0
                                                                                              Ганглия уныла. Graphana — няшка.
                                                                                            • 0
                                                                                              Давайте заменим «graphana» на collectd. Всё равно не понятно как вы сравниваете nagios и collectd. Они просто разные вещи делают. Они близки друг к другу по области применения, но совершенно не взаимозаменяемы. Скорее, дополняющие друг друга.
                                                                                          • 0
                                                                                            А что в принципе такого умеет collectd и не умеет nagios (давайте исключим разные плагины для сбора разных специфичных метрик)? Я бы разделил средства мониторинга на универсальные (zabbix, nagios со всеми ответвлениями, netxms и т.д. — они пытаются подгрести под себя все, включая инвентаризацию, чем собственно и хороши) и специализированные (а уж среди них сбор/визуализация метрик в духе collectd — кажется самое популярное направление, обработка логов наверное на втором месте). В этом смысле collectd никак не дополняет nagios, он представляет подмножество его возможностей, но при этом позволяет избежать избыточной сложности и снизить требования у ресурсам на мониторинг. Визуально результаты тоже, конечно, отличаются — но это уже по части «нефункциональных требований»
                                                                                            • 0
                                                                                              Пользую Prometheus + Grafana.

                                                                                              Prometheus хорош своей модульностью, можно включить только то что нужно и прикрутить модули для сборки нужных метрик. Ну и там всё предельно просто по настройке и транспорту метрик с клиентов на сервер.
                                                                                              • 0
                                                                                                Вот еще одно сравнение Open-Source TSDB.в Google Docs.
                                                                                                Чуть более проработанный, мне кажется, но систем меньше
                                                                                                • 0
                                                                                                  То что он более проработанный это к сожалению видимость. У него есть пара серьезных недостатковособенностей:
                                                                                                  1. Параметры типа Write Performance/Query Perfromance сравниваются по заверениям авторов без учета разного железа и методик тестирования — то есть по фатку это профанация.
                                                                                                  2. Для показателей bytes per point нет источника, например непонятно откуда у Dalmatiner'а 1, когда авторы базы об этом ничего не говорят, если из тестов то тогда см п. 1, цифры в этом блоке профанация так как еще и осознанно на разных сетах данных
                                                                                                  3. Оценки типа Complexity, Functionality, Usability тоже даны примерно от балды по какой-то внутренней логике авторов, которая не очень то афишируется
                                                                                                  4. Нет упоминаний ни в каком виде что у всего raik-based cross-dc кластеризация платная, что по мне, например важно.


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

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

                                                                                                      Фактически основная идея таблицы из Update2 в том чтобы собрать более честную и объективную информацию чем собрана в таблице из Update3 — то есть выкинуть по максимуму субъективные факторы, а взамен охватить большее количество систем.
                                                                                                      Наверное единственное чего не хватает это лицензии, чтобы цель можно было бы считать достигнутой.
                                                                                                • +1
                                                                                                  Не упомянута OpenNMS [demo]. У меня мониторится порядка 2500 нод (сетевая инфраструктура, сервера), интерфейсов… ммм… много. Стек: Java + PostgreSQL + на выбор time-series database — RRD, JRD, NewTS. Относительно легко разбивается на шарды. Конфигурирование может добавить седых волос, но после настройки работает безупречно.
                                                                                                  • 0
                                                                                                    А где check-mk? Комбайн, который имеет в себе всё. И не надо парится с какими-либо связками…
                                                                                                    • +1
                                                                                                      Большое спасибо за статью! Просто спасли кучу времени :)
                                                                                                      • 0
                                                                                                        У grafana нет готовых пакетов под i386 в отличии от influxdb и telegraf ;-(
                                                                                                        • +1
                                                                                                          А если не секрет, где в современной серверной жизни встречается i386? И главное — зачем оно там встречается?
                                                                                                          • 0
                                                                                                            На VPS-ках например и других виртуалках с небольшим объёмом памяти, старые сторейдж-серверы.
                                                                                                            • 0
                                                                                                              М… ну допустим, но зачем там Grafana или InfluxDB? По всей логике они должны стоять сбоку на несколько более жирном железе.
                                                                                                        • 0
                                                                                                          > graphite-web — интерфейс

                                                                                                          Это еще и API-интерфейс.
                                                                                                          • +1
                                                                                                            Притом одна из существующих реализаций API :)

                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.