company_banner

Как мы Zabbix обновляли

    image


    За что мы любим Prometheus? У него есть конфиг — взглянул и всё понятно, программа делает то, что ей сказали. Можно автоматизировать настройку мониторинга, хранить в VCS, ревьюить командой. Смержили твой MR, отработал пайплайн, новый конфиг применился к прометею. В общем, IaC во всей красе.


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


    Как и многие, кто мониторит давно и у кого есть «голое» железо, мы используем Zabbix, который, кстати, на том железе и располагается. Увы, на данный момент заббикс и IaC — вещи не связанные. Настраивать заббикс можно или вручную, или через API.


    Предыстория


    В октябре 2018-го вышел Zabbix-4.0 — новая LTS ветка. И в середине марта мы начали планировать обновление на него нашей инсталляции версии 3.4.


    Особых проблем с 3.4 почти не было:


    • Иногда где-то не срабатывал какой-то LLD и случалось Невозможное, которое неясно как отлаживать на неподдерживаемой разработчиком версии
    • Постоянно текла память HTTP-пуллеров — в результате чего заботливо настроенный systemd прибивал мониторинг и запускал его заново. Проблема маскировалась приличным объёмом памяти сервера. Проблема известная, задокументированная.

    А в 4.0 появились интересные фичи вроде родных HTTP-итемов и периодов обслуживания не на весь хост целиком.


    Да и где же это видано, на неактуальной версии мониторинга сидеть, даже не на LTS? Надо идти в ногу со временем.


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


    Обновление «в лоб»


    Ничего особо сложного в обновлении заббикса сейчас нет. Закажи сервер, проведи его настройку, слей копию базы. Поставь пакеты мониторинга и укажи им базу, запусти заббикс — и он тебе сам всё обновит, накатит все миграции. Ну да, наверное, вы знаете, каким лёгким стал апгрейд заббикса.


    В сумме миграции БД заняли около 15-ти минут и даже без особой ругани. И вроде бы всё хорошо. Да? Как бы не так! Несмотря на то, что IP нового сервера не прописан в белых листах агентов, и он собирает данные лишь с нескольких тестовых хостов, на нём по прежнему стабильно происходит Невозможное.


    К чести разработчиков заббикса надо сказать, они своё слово держат — версия 4.2 на тот момент поддерживается. После общения в трекере проекта мы выясняем, что причина невозможного в том что не совпадает с ожидаемой структура одной из таблиц БД.


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


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


    • другая стоимость хранения метрик
    • другая точность цифр
    • другая скорость выборки/записи метрик

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


    И этот тип данных колонок можно, но сложно и долго менять. И невозможно без долгого простоя мониторинга. Без гарантий успеха, без поддержки со стороны разработчика в будущем. Нужен другой путь.


    И его есть у заббикса. Потому что в апреле 2019-го выходит zabbix-4.2


    Второй подход к снаряду


    Основная фича 4.2 для нас — поддержка секционирования «из коробки» посредством TimescaleDB. Пообщавшись с представителями заббикса и ознакомившись с результатами тестирования его техподдержкой этой возможности (перевод на хабре), мы решаем протестировать инсталляцию с timescaledb и по результатам принять решение о переходе. Более конкретно: некоторое время у нас все данные мониторинга параллельно будут писаться и в старую, и в новую версии. А потом мы просто переключим запись в DNS.


    Конечно, такой подход не позволяет сохранить данные истории и трендов — новая БД наполняется с нуля. Но так ли уж они нужны? История имеет значение только здесь и сейчас, она довольно быстро накопится заново (посмотрите на тот же прометей). Остаётся только несомненная полезность трендов для планирования мощностей. В любом случае, архив с уже собранными данными у нас остаётся (забегая вперёд — некоторым клиентам он пригодился). Ещё одна особенность поддержки timescaledb в заббиксе — перестают действовать индивидуальные периоды хранения истории/трендов.


    У нас есть клиенты, которые настаивают на «вечном» хранений всех собранных данных любой ценой. Им мы можем предложить рассмотреть установку/поддержку отдельной инсталляции мониторинга со специфическими настройками. Наша основная задача — обеспечивать стабильную работу проектов/серверов клиентов при сохранений приемлемой стоимости услуг, в которую входит в том числе и мониторинг.


    Итого, для миграции потребуется выполнить следующие шаги:


    1. Установить и настроить вторую инсталляцию мониторинга
    2. Завести в ней всё то же самое, что и в первой инсталляции
    3. Переключиться!

    Звучит просто, не так ли? Действительно, первое не очень сложно, ведь во время предыдущего подхода мы написали роль для установки заббикс-сервера, достаточно просто налить конфигурацию. Третий пункт тоже выглядит просто — переключаем DNS и все заббикс-агенты, прокси, клиенты API и живые люди попадают на новую версию. Но как сделать второй пункт?


    Поначалу мы попробовали наивный подход. Импортировали из текущего мониторинга пару-тройку самых часто используемых шаблонов. Посредством уже написанных скриптов для работы с API завели в новом мониторинге те же самые проекты, что и в текущем, через системы SCM разлили по машинам правки, добавляющие IP новой машины в пакетный фильтр и в директивы Server/ServerActive агентов. Это даже сработало — множество хостов стали регистрироваться в двух мониторингах сразу, новый назначил им шаблоны и начал собирать данные параллельно с текущим.


    Увы, это именно наивный подход к миграции, годный разве что для теста. Получившаяся нагрузка (в nvps-ах) не шла ни в какое сравнение с текущей инсталляцией, будучи ниже на порядки. Оно и понятно. В нашем случае мониторинг — это буквально годы работы множества людей и скриптов, квинтэссенция опыта эксплуатации разнородных проектов.


    Например, что насчёт вручную заведённых пользователей и их паролей, которые при создании проектов генерируются случайными, навешанных на хосты шаблонов мониторинга (со своими кастомными значениями макросов), вручную созданных итемов, комплексных экранов, графиков, дэшбордов, периодов обслуживания, прокси-серверов? Это всё и многое другое нужно переносить для плавной миграции.


    На счастье, у заббикса есть встроенный функционал по экспорту/импорту объектов — доступный в том числе и через API. Увы, он покрывает не более половины всех существующих объектов. И код для его использования ещё и написать нужно. В общем, нельзя просто взять и импортировать конфигурацию одного заббикса в другой.


    Или можно?


    Тут мозг услужливо вспоминает задачу из бэклога о том, что неплохо было бы организовать хранение истории конфигурации мониторинга внешними средствами. Увы, это больное место заббикса. Со ссылкой на статью на хабре и репозиторий с кодом. Но есть нюансы:


    • код экспортирует в человекочитаемые YAML-файлы не все объекты мониторинга (в частности, не все нужным нам)
    • код не поддерживает импорта объектов

    На удачу, есть люди немного знающие язык проекта (python) и имеющие опыт работы с заббикс API. Всего делов-то — сделать импорт объектов из готовых YAML-дампов. Долго ли, коротко ли, но после трёх недель работы и полутора сотен коммитов получился вполне годный для наших целей форк. Собственно, ради чьего представления и пишется вся статья:


    https://github.com/centosadmin/zabbix-review-export-import


    Что сделано:


    • Добавлена поддержка множества новых объектов
    • Изменён формат YAML-экспорта большей части существующих объектов так, чтобы их можно было импортировать
    • Добавлена возможность импорта большей части экспортированных объектов
    • Добавлена ограниченная функциональность по конвертации объектов между разными версиями заббикса (как в нашем случае)

    Импорт поддерживается почти исключительно созданием новых объектов. Если объект существует, он не будет изменён. Это позволило удержать сложность кода хоть в каких-то рамках, сэкономить время и здорово увеличить скорость работы — при импорте тысяч объектов. Использовать импорт очень просто:


    ./zabbix-import.py /path/to/file.yaml

    (предполагается, что параметры целевого мониторинга указаны в переменных среды, подробнее в выводе --help)


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


    Таким образом, в нашем гитлабе появились два репозитория с периодически обновляемыми YAML-дампами двух версий мониторинга, текущей и новой. И, конечно же, возможность восстановить почти любой объект мониторинга на любой момент времени.


    Continuous monitoring deployment и сама миграция


    В итоге мы пришли к тому, что гитлаб по расписанию запускает пайплайн на репозитории нового мониторинга, который шаг за шагом иерархически импортирует из старого мониторинга один тип объектов за другим. Это позволило импортировать подавляющее большинство объектов и дать нашим командам администраторов время спокойно починить вылезшие проблемы — а их не так уж мало накопилось за годы. «Лишние» объекты не удалялись.


    Вопрос с паролями пользователей — они тоже экспортируются/импортируются, но при создании назначается случайный пароль — удалось решить преобразованием SQL-дампа таблицы с учётными данными текущего мониторинга в SQL-операторы для установки правильных паролей в новом мониторинге.


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


    Таким образом, переключение прошло довольно легко и свелось к следующим пунктам:


    • удалить все хосты в новом мониторинге (для этого написаны пара скриптов над API)
    • дёрнуть SCM-ы чтобы обновили версию zabbix-proxy и переключили прокси на новый сервер
    • дождаться импорта хостов из дампа старого мониторинга
    • переключить DNS-записи

    (план сокращён в целях упрощения)


    Что дальше?


    Конечно, код не идеален и не особо красив. Он импортирует не всё, в частности, есть проблемы с некоторыми шаблонами — ищите FIXME в коде. Но для нас этого хватило. Возможно, этот форк пригодится кому-то ещё. Логичным продолжением видится развитие в сторону подобную работе утилиты Terraform, когда целевой мониторинг полностью приводится к виду, заданному, например, каталогом с YAML-дампами. В том числе и с приведением существующих объектов к нужному виду.


    Это позволит спокойно дождаться «родной» поддержки HA в zabbix, имея два сервера, синхронизация настроек между которыми происходит автоматически. Сейчас приходится держать реплику, прокси и писать скрипты.


    Камо грядеши?


    После изучения материалов конференций и митапов, официального роадмапа, трекера ошибок и (скромного) опыта личного общения с разработчиками заббикса складывается впечатление, что они отлично понимают ситуацию, в которой сейчас оказались. Когда начинался заббикс, ни о каком IaC авторы не думали, решая свои задачи. Спустя десятилетие продукт возмужал и расцвёл. Оборотной стороной успеха стала набранная масса клиентов компании, у которых мониторинг решает их задачи. И которым не очень-то симпатичны революции. В современных условиях они, с одной стороны, против того, чтобы всё ломать и начинать с нуля. С другой стороны, они же местами испытывают недостаток возможностей мониторинга и смотрят «на сторону», не забывая озвучивать хотелки разработчикам заббикса. Рисковать ими компания не собирается, несмотря на любые симпатии к новому, удобному, модному, молодёжному.


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


    Использованные источники:


    1. https://gitlab.com/devopshq/zabbix-review-export
    2. https://habr.com/ru/company/pt/blog/433126/
    3. https://habr.com/ru/company/zabbix/blog/458530/
    Southbridge
    612,96
    Обеспечиваем стабильную работу серверов
    Поделиться публикацией

    Похожие публикации

    Комментарии 27

      +1
      Кроме IaC для Zabbix можно было бы добавить поддержку ClickHouse

      Вот ZBXNEXT для добавления ClickHouse:
      Add support for the preservation of historical data in Clickhouse

      Так же:
      В рамках проекта Glaber создан форк системы мониторинга Zabbix
        +2

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

          +1
          хочется верить, что нет

          ИМХО:
          в zabbix сами не знают, что им нужно, комьюнити для обкатки версий и баг репортов
          фиче голосование? — есть… как сусли, есть и ок, голосвали — молодцы, а мы там посмотрим, что нам нужно для клиентов заносить…
            +1
            Этот проект возник из-за того что товарищи из zabbix не очень любят принимать патчи снаружи
          +3

          Насчёт IaС — в ansible есть пачка модулей для zabbix: https://docs.ansible.com/ansible/latest/modules/list_of_monitoring_modules.html#zabbix


          Там нет работы с пользователями, media и actions, но хосты, шаблоны, скрины — пожалуйста.

            +1

            Надо честно признать, что ансибль это просто баш на YAML-е. Т.е. императивный язык по сути. Нам не надо работать с "ОБЪЕКТ", хотя мы и применяем эти модули, нам надо было "Загрузить всё из бэкапа".

              +3

              Да ну, какая императивность? — что мешает описать все ваши шаблоны и объекты мониторинга в виде нескольких yaml-файлов? Применять их можно в любом порядке, с ними легко работать, их можно версионировать, хранить в vcs, следить за изменениями и работать с ними в разных окружениях.
              Что не так-то?

                +1

                Сейчас только храним объекты мониторинга в YAML-е. И это на данный момент 5к объектов (файлов). Можно конечно коммитить туда и импортировать объекты, но пока оказывается что проще скриптами через API создать полтора десятка объектов мониторинга для среднего клиента, чем писать это в ямле. Плюс с большой частью объектов модули ансибля не работают.


                Оказывается, применять ямлы можно только в определённом порядке. Объекты — сложные, между ними много взаимозависимостей. Это сейчас не учитывается. Поэтому и смотрим на терраформ (как на образец для вдохновения) — разруливалку отношений между объектами.

                0

                Ансибл как раз-таки декоративный: "добейся такого-то состояния".

                  –1

                  Да, именно. Декоративный.


                  Увы, мы его много используем и там всё далеко не безоблачно.

              +2
              Про то что мы не увидим нового забикса это вы поспешили, буквально вчера вышла версия 4.4
              www.zabbix.com/whats_new_4_4
                +1
                Нового, правильного прометея из заббикса мы в ближайшее время не увидим.

                Не надо вырывать из контекста. Статья чуть припозднилась, да.

                0

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

                  +2
                  Zabbix хорош своей гибкостью и подходом все данные. То что там можно просто в интерфейсе неспешно настроить за час попивая кофе, в других системах вам потребуется день. Плюс он два в одном. Он не только про мониторинг, но еще и про метрики. Из минусов он весь завязан на базу.
                    0

                    Как будто прометеус — не про метрики.


                    Zabbix хорош своей гибкостью и подходом все данные.

                    звучит, как рекламные материалы. Давайте будем честны. Плюсы заббикса:


                    1. это коробочное решение. Якобы ты его поставил, быстренько настроил и можешь работать. Хороший набор интеграций из коробки.
                    2. из п.1 следует, что у разработчика можно купить поддержку. Хорошо для энтерпрайза.
                    3. многие УЖЕ привыкли к заббиксу и его заебиксам.

                    Все. Остальное — это минусы. И прожорливость базы. И невозможность декларативно его настроить. И необходимость подпиливать его, а потом таскать свои доработки и проверять на совместимость с новыми версиями и т.п.

                      +1
                      Как будто прометеус — не про метрики.

                      Да он про метрики. Но он про другие метрики. Простой пример у меня есть коммутатор у него 96 портов. У каждого порта есть три метрики
                      входящий трафик
                      исходящий трафик
                      состояние порта

                      Устройство тупое и умеет отдавать эти данные только по snmp. Как разложите?

                      звучит, как рекламные материалы.

                      Нет в том то и дело. Я много разных мониторингов видел еще когда прометеуса в проекте не было.

                      это коробочное решение. Якобы ты его поставил, быстренько настроил и можешь работать. Хороший набор интеграций из коробки.

                      Глубоко ошибочное мнение :) Zabbix требует чтения мануалов и вдумчивого подхода к настройке.

                      многие УЖЕ привыкли к заббиксу и его заебиксам.

                      Потому что долгое время ничего лучше вообще не было.

                      И невозможность декларативно его настроить.

                      Экспорт и импорт там внезапно есть и там где его используют декларативная настройка не нужна.

                      И необходимость подпиливать его, а потом таскать свои доработки и проверять на совместимость с новыми версиями и т.п.

                      Если вам такое требуется при работе с zabbix он вам не нужен.

                      Вы просто заходите не с той стороны. Если вы планируете мониторить какие-то контейнеры и микросервисы, то да можно использовать zabbix. Но это будет не очень удобно.

                      Зато когда у вас 100500 коммутаторов и 100500 однотипных серверов, тогда да zabbix хорошо и удобно. Zabbix это больше про телеком и инфраструктуру. К примеру там парой кликов можно добавить 100500 коммутаторов. Более того сейчас имеется большой наработанный каталог шаблонов для них. И больше про тупые устройства которые надо опрашивать.

                        0
                        Зато когда у вас 100500 коммутаторов и 100500 однотипных серверов, тогда да zabbix хорошо и удобно. Zabbix это больше про телеком и инфраструктуру. К примеру там парой кликов можно добавить 100500 коммутаторов. Более того сейчас имеется большой наработанный каталог шаблонов для них. И больше про тупые устройства которые надо опрашивать.

                        Тогда — icinga2 & nagios. Ну, и, да, я согласен, что есть сервисный мониторинг (прометеус именно про мониторинг сервисов в первую очередь, иначе приходится костылить экспортеры на все подряд), и есть инфраструктурный — но все равно без агентов или проб не обойтись (тем более, если инфра распределенная). А раз так, то разницы между агентом и экспортером по сути и нет (неожиданно, да?)


                        Экспорт и импорт там внезапно есть и там где его используют декларативная настройка не нужна.

                        Давайте еще бекапами базы кидаться друг в друга?


                        Потому что долгое время ничего лучше вообще не было.

                        ну, да


                        Глубоко ошибочное мнение :) Zabbix требует чтения мануалов и вдумчивого подхода к настройке.

                        Не так. Быстрый старт — да, возможен. Автодискавери и встроенные шаблоны помогают. Но вот продуктивная работа с Z и подгонка его под особенности конкретного предприятия — да, требуют чтения мануалов. Но так, вероятно, с любым продуктом. Автомагически ничего не работает :-/


                        Устройство тупое и умеет отдавать эти данные только по snmp. Как разложите?

                        Очевидно, что прометеуса одного будет недостаточно. Придется где-то snmp exporter поставить и настроить его. Но я об этом выше и писал.

                          +1
                          Тогда — icinga2 & nagios. Ну, и, да, я согласен, что есть сервисный мониторинг (прометеус именно про мониторинг сервисов в первую очередь, иначе приходится костылить экспортеры на все подряд), и есть инфраструктурный — но все равно без агентов или проб не обойтись (тем более, если инфра распределенная). А раз так, то разницы между агентом и экспортером по сути и нет (неожиданно, да?)

                          У них подход получаем алярмы, а метрики это так сбоку. В случае zabbix метрики первичны их обработка внутри него. Этим он ближе как раз к прометеусу. Плюс там не важно что за метрика, можно строить какие угодно выражения для генерации событий.

                          Давайте еще бекапами базы кидаться друг в друга?

                          Там экспорт импорт шаблонов. Чего вполне достаточно на самом деле.

                          Очевидно, что прометеуса одного будет недостаточно. Придется где-то snmp exporter поставить и настроить его. Но я об этом выше и писал.

                          Который туповат и валит все подряд, дальше надо будет еще на сервере правила записи расшивать. Да это декларативно, но это еще надо будет написать.

                          Как итог возвращаемся к тому, что делается в zabbix неторопливо за час, потребует день писанины в прометеусе. При этом и там и там придется читать документацию.
                            +1
                            Ну и да zabbix позволяет быстро набрать данных, но вот когда уже нужно настроить события и тревоги, тут ой. Без чтения документации там делать нечего.
                            +1
                            Устройство тупое и умеет отдавать эти данные только по snmp. Как разложите?

                            github.com/prometheus/snmp_exporter

                            Но проблема prometheus-a или же юзверов — они в метриках, метрики как бы если верить приходу «церкви_метрик» — это цифры, а string/char — это не метрика, потому prometheus оптимизирован на данные в виде цифр, а zabbix/icinga/nagios/sensu — уже на значение, которое ты хочешь записать в базу.
                              +1
                              Эту штуку я видел, она судя по описанию валит весь mib из устройства. Как минимум не быстро. Потому что snmp ну не особо быстро.

                              zabbix/icinga/nagios/sensu — уже на значение, которое ты хочешь записать в базу.

                              За sensu не скажу, но у icinga/nagios первичны события, а не метрики. А в zabbix первична метрика. На долгом забеге и большом количестве устройств это реально стреляет.
                            +1
                            Все. Остальное — это минусы. И прожорливость базы. И невозможность декларативно его настроить. И необходимость подпиливать его, а потом таскать свои доработки и проверять на совместимость с новыми версиями и т.п.


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

                            Хотя, стоит отметить, что неподдержка из коробки TSDB — это серьезная недоработка Zabbix-a. Все же метрики завязаны на времени.
                            Это все равно, что выпускать машину с тороидальными многогранниками, вместо колёс, при этом понимая что это для этого не совсем предназначено.
                            Ехать можно, но не очень.
                          +2
                          нет мониторинга, кроме заббикса, и графана — дэшборд его.
                            +2

                            Вы предлагаете отказаться от Zabbix в пользу:


                            • Graphite — это система для хранения и работы с метриками. Никаким мониторнгом тут не пахнет.
                            • Prometheus — сам по себе (без Alertmanager) только собирает, хранит и предоставляет инструменты для работы с метриками. Ну и с долговременным хранением метрик не всё гладко. Но сейчас Zabbix поддерживает работу с его экспортерами. Так что можно настроить работу этих двух систем чтобы они дополнли друг друга.
                            • Icinga — это вообще каменный век )) Форк Nagios, который имеет несколько полезностей, но в основном, по многим парметрам уступает предшественнику. Ну и сам подход к мониторнгу у этих систем уже устарел.

                            Я не пытаюсь сказать, что Zabbix — это наше всё, а другие системы — отстой. Всё ситуативно.
                            Zabbix хорош своей универсальностью и современным "metric-based" подходом.
                            Но иногда для мониторнга классической инфраструктуры вполне хватает того-же Nagios или Check_MK.

                              0

                              Вы только что взяли и перечеркнули все, что мы делали. Вот чем Вам графит не нравится как центральная часть системы мониторинга? Тем более, если его снабдить дополнительными компонентами — moira, alerta? Просто тот же заббикс сам по себе тоже не покрывает полностью все кейсы. Я когда говорю "графит" подразумеваю именно его не как отдельный продукт, а как экосистему — а там много чего навернуто на базе него и сбоку от него.
                              Ну, или давайте разбираться, что в Вашем понимании "система мониторинга" и как она может работать без "сбора и хранения метрик".


                              По прометеусу — согласен. Там есть нюансы именно с долговременным хранением. И мы сами думаем, как их решить. То ли графит рядом поставить, то ли писать в Timescaledb. Или может M3 от убера попробовать. Федерации — шмедерации посмотрели — но это тоже не про долговременное хранение. А! VictoriaMetrics еще в шорт-листе, но до нее руки не дошли

                                0
                                зачем дублировать функционал?
                                В заббиксе алертинг родной, из коробки, и гарантированно работает.
                                Что случится, когда вы начнете обновлять дополнительные компоненты?

                                Какие кейсы не покрывает заббикс?
                            +1
                            Да лучше всего поставить опенсорсный NetXMS — и карта сети будет автоматически и мониторинг с метриками. Да, надо немного подолбаться с интерфейсом но оно того стоит

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

                            Самое читаемое