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

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

Работать с xml, вопреки ожиданиям, больно даже в джаве. Да, множество джава-легаси юзает xml, но новый код всё-таки перекладывает json'ы.

P.S. Ну и недекларативный IaC considered harmful, если начать описывать конфиги зуббикса на ЯП, который ходит в API, то очень быстро появится желание переплетать состояние мониторинга и поведение конфигуратора, что сильно понизит читаемость и понимаемость "конфига"

ты просто xml хейтер )

С XML проблем больше, чем пользы

та и про докир многие так грят )

готовить нужно уметь

Я и json не особо люблю. Просто лучше json'а пока ничего особо не придумали, а лучше xml'я придумали json

все ясно , ты ничего не любишь ))) ты не xml хейтер, а просто )

Да что вы говорити... А MessagePack?

Жену свою люблю, а так да, ты попал в точку

О великий здравый смысл

если вкратце (вчера уже поздновато было писать подробно) то там ничего не изменилось.
В зависимости от стека у тебя есть:
1. Скейлинг на ручном приводе методом подпирания костылями. Но хорошая производительность на чтение и почти линейное масштабирование по записи. Это если гошный стек. Но не будет поддержки тэгов и будет жрать место как ни в себя (хотя там букинговцы пилят сжатый виспер ща)
2. Скейлпинг как у кликхауса, ибо бэкэндов является кликхаус. Стек от ломика довольно шустрый и жирные запросы обрабатывает неплохо, но кучи мелких запросов ему тяжло даются (хуже виспера). Зато по месту все не так плохо, ну и кликхаус чуток повеселее в управлении. Но тулинг весь заточен под (1). И можно юзать как graphite-web так и carbonapi. Если в моем варианте последний - то будут тэги, возможно с багами, но будут. Если в варианте от букинга - то тэгов не будет и много бэкэндов там делать сложновато будет, лучше брать 1 carbonapi на один бэкэнд сервер. Или лишние костыли в виде haproxy/envoy между carbonapi и clickhouse'ом.
3. Есть еще всякие варианты на кассандре, которые просты в управлении, но медленные и на чтение и на запись.
4. У графановцев есть metrictank, который довольно шустрый и вроде масштабируется, хоть и поверх кассандры, но я его кроме как у графаны не видел

супер!

если вкратце то все через задницу

ну плюс надо понимать, что у меня продакшена на графите больше нет и я хоть и пилю свой carbonapi, но тестировать толком мне его негде

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

но при этом у них есть мониторинг графита прометеем

+

George Gaál (2.98) увеличил репутацию Vladimir Smirnov (3.01) (+1.01)

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