Написать приложение, которое будет стоять перед базой и делать как надо и слать данные уже в бинарном виде?

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

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

Почему точно нет?

Почему точно нет?

Т.е часть метрик могла придти в 1 файле а часть в другом

Т.е часть метрик могла придти в 1 файле а часть в другом

А сейчас как вопрос решается?

Парсеры на c++ и Oracle, хотелось бы nifi+Java парсер+clickhouse

Парсеры на c++ и Oracle, хотелось бы nifi+Java парсер+clickhouse

А что мешает в Джава парсере конвертировать в бинарный формат

И вставлять в кх по нативному протоколу

С нуллами как есть

А что мешает в Джава парсере конвертировать в бинарный формат

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

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

Не вижу сильных отличий

От парсера сейчас

Вопрос лишь в том чтобы делать конвертацию в бинарный вид в парсере

Не вижу сильных отличий

Почему же? Так мы имеем парсер который надо дорабатывать каждый раз, а так мы имеем узкую таблицу в которую гарантировано придут метрики и надо поправить только запрос на вьюшку по созданию широкой таблицы

+ если изначально делать широкие таблицы - надо их часто делать alter с добавлением колонок...

Вопрос лишь в том чтобы делать конвертацию в бинарный вид в парсере

Ну и объём данных очень большой, 1 парсер с этим не справится, следовательно должны стоять несколько, а как обрабатывать события когда на парсер А пришла часть метрик а на парсер Б вторая?

кафка? :)

Ну и объём данных очень большой, 1 парсер с этим не справится, следовательно должны стоять несколько, а как обрабатывать события когда на парсер А пришла часть метрик а на парсер Б вторая?

Ещё раз, вопрос не в таблице, а атом чтоб вставлять не строки, а что уже прям надо

Инты там

Флоаты

Флоаты

В качестве значений могут быть: Число положительное - результат замера 0 - замер произведён но например трафика нет NULL - замер не произведён Массив из того что выше - когда внутри группа измеряемых объектов

Так то string :(

Так то string :(

Массив из нулабл интов

Или даже просто массив, по-моему он может быть пустым

Массив из нулабл интов

Типо всегда массив даже когда это не так и всегда приводить из массив в не массив?

Типо всегда массив даже когда это не так и всегда приводить из массив в не массив?

Да

Не надо в базу пихать строки

Не надо в базу пихать строки

А почему?

Когда ожидаются потом числа

Вот совсем не надр

А почему?

Ну потому что ты сложную логику пытаешься на базу переложить

Даже больше

Логику на которую база не рассчитана

Ну плюс тебя будет ждать расплата в виде очень медленных запросов на чтение

Ну относительно того же по интам

Возможно даже стоит уйти от массива в сторону колонки с Id измерения

Например

Возможно даже стоит уйти от массива в сторону колонки с Id измерения

У меня так и сделано: Дата измерения | название измерения | значение измерения

У меня так и сделано: Дата измерения | название измерения | значение измерения

А зачем тогда строки?

А зачем тогда строки?

Тк значения могут быть в том числе массив или int или null

Тк значения могут быть в том числе массив или int или null

Ок, делай как знаешь

Но это какая то ересь

Имхо

И так делать нельзя

Ок, делай как знаешь

Так ч не хочу как знаю :) за идею с массивами - спасибо - попробую, метрику генерирую не я себе сам, она такая какая приходит и изменить я её не могу

Так ч не хочу как знаю :) за идею с массивами - спасибо - попробую, метрику генерирую не я себе сам, она такая какая приходит и изменить я её не могу

Введи ещё одну колонку с subid

И уйди от массивов

И подумай ещё раз зачем тебе null и что будет с ними потом

И уйди от массивов

И что должно быть в subid?

И что должно быть в subid?

Номер элемента из массива

Тебе надо отталкиваться в выборе структуры от того какие запросы будут

А не от того какие данные на входе

И подумай ещё раз зачем тебе null и что будет с ними потом

Я знаю что с ним будет: например у нас есть счетчики: C1,c2,c3 Формула расчета KPI - C1^2+c2/c3 Но если хоть один счётчик пришёл как NULL - я не должен её расчитывать за полученное время, результат должен быть null что бы дальше при агрегации выкинуть неверный расчёт

Я знаю что с ним будет: например у нас есть счетчики: C1,c2,c3 Формула расчета KPI - C1^2+c2/c3 Но если хоть один счётчик пришёл как NULL - я не должен её расчитывать за полученное время, результат должен быть null что бы дальше при агрегации выкинуть неверный расчёт

Сложно будет логику реализовать как мне кажется

А что с массивами будет?

Вот выяснилось что все три - массивы ещё и разной длины

Сложно будет логику реализовать как мне кажется

На оракле она есть, но он тормозной, с массивами будет то же самое, внутри них - счётчики которые надо как то обработать привести из array(2,3,43,2) к скажем 2+3-43/2

На оракле она есть, но он тормозной, с массивами будет то же самое, внутри них - счётчики которые надо как то обработать привести из array(2,3,43,2) к скажем 2+3-43/2

А для чего в этом месте делать сырые вставки, а не сразу вставлять с формулой?

А для чего в этом месте делать сырые вставки, а не сразу вставлять с формулой?

Не понял вопроса, ты имеешь ввиду почему сразу не считать значение массива?

Не понял вопроса, ты имеешь ввиду почему сразу не считать значение массива?

Да

Да

Сегодня формула такая, а завтра - другая + KPI нужен для отчетности а для мониторинга нужны отдельные значения и графики в графане по ним

Сегодня формула такая, а завтра - другая + KPI нужен для отчетности а для мониторинга нужны отдельные значения и графики в графане по ним

Складывайте сырые данные в хадуп и если что вытягивайте и переписывайте данные

Складывайте сырые данные в хадуп и если что вытягивайте и переписывайте данные

Слишком медленно, хотелось бы на лету, ресурсы позволяют, кластер на SSD 250gb ram+ на 60 серверов

250gb+ на каждом естественно

Слишком медленно, хотелось бы на лету, ресурсы позволяют, кластер на SSD 250gb ram+ на 60 серверов

Ну вставляй в массив или в плоскую структуру

про то, что в телеграфе можно использовать два индекса при опросе таблицы. [[inputs.snmp.table]] name ="cbQosCMStatsTable" oid = "CISCO-CLASS-BASED-QOS-MIB::cbQosCMStatsTable" [[inputs.snmp.table.field]] name = "cbQosConfigIndex" oid = "CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex" is_tag = true [[inputs.snmp.table.field]] name = "cbQosParentObjectsIndex" oid = "CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex" is_tag = true telegraf -config test.cfg -test * Plugin: inputs.snmp, Collection 1 * Internal: 5m0s > cbQosCMStatsTable,cbQosConfigIndex=1593,cbQosParentObjectsIndex=10248624,agent_host=10.1.2.3 cbQosCMPrePolicyPktOverflow=0i,cbQosCMPrePolicyBitRate=0i,cbQosCMDropByte=71674i,cbQosCMNoBufDropPkt=0i,cbQosCMFragmentByteOverflow=0i,cbQosCMFragmentByte=0i,cbQosCMPrePolicyByteOverflow=0i,cbQosCMPrePolicyByte=682036575i,cbQosCMPrePolicyByte64=682036575i,cbQosCMPostPolicyByteOverflow=0i,cbQosCMPostPolicyByte=681964901i,cbQosCMDropPktOverflow=0i,cbQosCMDropByteOverflow=0i,cbQosCMDropBitRate=0i,cbQosCMNoBufDropPkt64=0i,cbQosCMFragmentPktOverflow=0i,cbQosCMFragmentPkt=0i,cbQosCMPrePolicyPkt64=2233815i,cbQosCMPrePolicyPkt=2233815i,cbQosCMPostPolicyByte64=681964901i,cbQosCMPostPolicyBitRate=0i,cbQosCMDropPkt=49i,cbQosCMDropPkt64=49i,cbQosCMDropByte64=71674i,cbQosCMNoBufDropPktOverflow=0i 1505892809000000000

Ну вставляй в массив или в плоскую структуру

Тогда нужен не кликхаус - там update нет, а по скорости я не знаю что подойдёт если посоветуете буду счастлив

Тогда нужен не кликхаус - там update нет, а по скорости я не знаю что подойдёт если посоветуете буду счастлив

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

Тогда нужен не кликхаус - там update нет, а по скорости я не знаю что подойдёт если посоветуете буду счастлив

А апдейт тут как появился?

Плюс в кх есть replacingmerge tree

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

Массивы медленно для разработки, update - если делать широкую таблицу в место узкой. А реплейсинг мне не поможет - смотрел

Хотелось бы залить сложность разработки железом и мне кажется что CH для этого должен подойти

Массивы медленно для разработки, update - если делать широкую таблицу в место узкой. А реплейсинг мне не поможет - смотрел

Ну пыц

Хотелось бы залить сложность разработки железом и мне кажется что CH для этого должен подойти

Я сомневаюсь что тебе подойдёт что либо

В такой формулировке

Я сомневаюсь что тебе подойдёт что либо

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

Я к слову не понимаю почему массивы это сложно, если парсер из XML в нативный формат кх пишется в одно рыло за день

Про массивы я уже понял - попробую :) Чувствую что после реализации можно идти доклад для highload делать

про то, что в телеграфе можно использовать два индекса при опросе таблицы. [[inputs.snmp.table]] name ="cbQosCMStatsTable" oid = "CISCO-CLASS-BASED-QOS-MIB::cbQosCMStatsTable" [[inputs.snmp.table.field]] name = "cbQosConfigIndex" oid = "CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex" is_tag = true [[inputs.snmp.table.field]] name = "cbQosParentObjectsIndex" oid = "CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex" is_tag = true telegraf -config test.cfg -test * Plugin: inputs.snmp, Collection 1 * Internal: 5m0s > cbQosCMStatsTable,cbQosConfigIndex=1593,cbQosParentObjectsIndex=10248624,agent_host=10.1.2.3 cbQosCMPrePolicyPktOverflow=0i,cbQosCMPrePolicyBitRate=0i,cbQosCMDropByte=71674i,cbQosCMNoBufDropPkt=0i,cbQosCMFragmentByteOverflow=0i,cbQosCMFragmentByte=0i,cbQosCMPrePolicyByteOverflow=0i,cbQosCMPrePolicyByte=682036575i,cbQosCMPrePolicyByte64=682036575i,cbQosCMPostPolicyByteOverflow=0i,cbQosCMPostPolicyByte=681964901i,cbQosCMDropPktOverflow=0i,cbQosCMDropByteOverflow=0i,cbQosCMDropBitRate=0i,cbQosCMNoBufDropPkt64=0i,cbQosCMFragmentPktOverflow=0i,cbQosCMFragmentPkt=0i,cbQosCMPrePolicyPkt64=2233815i,cbQosCMPrePolicyPkt=2233815i,cbQosCMPostPolicyByte64=681964901i,cbQosCMPostPolicyBitRate=0i,cbQosCMDropPkt=49i,cbQosCMDropPkt64=49i,cbQosCMDropByte64=71674i,cbQosCMNoBufDropPktOverflow=0i 1505892809000000000

И что потом с этими абстрактными индексами в тегах делать? Их же ещё надо как-то в человеческие названия policy-map, классов и т.п. превратить. А если они ещё и вложенные, то веселее вдвойне.

имя политик не нужны. нужны только счетчики в классах. уже не имеет значения вложенность.

cbqos-show.sh | grep VIDEO 10.1.2.3|Gi0/2|15259361|VIDEO|10371104|LAN-C2 10.1.2.3|Gi0/2|15259361|VIDEO|1837680|LAN-C5 10.1.2.3|Gi0/2|15259361|VIDEO|9545408|LAN-C4 10.1.2.3|Gi0/2|15259361|VIDEO|12302432|LAN-C1 тут 15259361 - cbQosConfigIndex для класса VIDEO. Т.о. можно рисовать счетчики cbQosCMDropPkt для этого класса и группировать по уникальным cbQosParentObjectsIndex (5 столбец)

как бы для примера, на одном интерфейсе 4 политики и в каждой есть класс VIDEO

посмотреть какие видосы идут в каких классах

имя политик не нужны. нужны только счетчики в классах. уже не имеет значения вложенность.

Ну это не дженерик решение тогда, а только для определённой структуры cbqos конфига. Ну и о persistency индексов надо не забыть.

да, есть ограничения.

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

В общем случае cbqos таблица описывает дерево. И логично бы тогда в качестве тега использовать путь по дереву: имя_интерфейса.имя_политики.имя_класса и т.д. Ну или отдельно меппинг индексов на имена держать.

Геморройный этот МИБ у киски.

я решил что мне будет достаточно вот этой таблицы cbQosCMStatsTable. тут все счетчики по всем классам. мне нужны дропы и полосу нарисовать.

CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt64.370.5074529 = Counter64: 1781

" а только для определённой структуры cbqos конфига. " для любой, но будет удобнее, если классы в политиках будут использоваться одни и те же, чтобы использовать минимум cbQosConfigIndex

интересно что cbQosConfigIndex для class-default равен 1593. у всех так?

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

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

группировать по хостам и cbQosParentObjectsIndex капаситор умеет

Про массивы я уже понял - попробую :) Чувствую что после реализации можно идти доклад для highload делать

уровень хайлоада в последние годы не впечатляет :) практически ничего нового

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

Вот на это закладываться стрёмно. Думаю, что именатут не причём, скорее определяется порядком инициализации и обхода дерева. Это никак не документировано и не оговорено в мибе и точно зависит как от имплементации в конкретной версии IOS, так и от динамики - попробуйте в "чистом" конфиге в другом порядке политики и классы создать и применить на интерфейсах. Или просто удалитьполитику и пересоздать.Скорее всего индексы поплывут.

посмотрите cbQosConfigIndex для class-default равен 1593?