Pull to refresh

Comments 111

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

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

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

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

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

Советую еще посмотреть в сторону Quest Software — Spotlight
Windows клиент для мониторинга серверов различного типа (Windows, Linux, Oracle и др.)
потратил минуту на сайте Quest Software не нашел даже раздел где брать на посмотреть.
Только маркетинговое бла-бла-бла, как круто они умеют всё мониторить.
то есть это SQL Server performance monitoring
Не только… Он мониторит различные системы.
Вот например мониторинг сервера под управлением CentOS
image

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

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

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

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

UFO just landed and posted this here
Древовидная структура серверов есть даже в munin.
А покажите. Ничего похожего на скриншотах и в документации не нашел, демо-сервер у них сдох
Спасибо за статью! Не рассматривали в качестве агента logstash (из ELK)?
Если не надо «рубить» данные, то сейчас в связке с ELK для многих применений хватает их же Beats.
Который хочет везде JRE и работает как черепаха? Нет, спасибо.

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


Плюсы:


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Это еще и API-интерфейс.
Притом одна из существующих реализаций API :)
Sign up to leave a comment.

Articles