вы вставляете напрямую в Replicated таблицы?

нет, через distributed

replicatiion - internal

вы проверьте что столбец везде есть (на всех шардах) и что тип везде именно String
и в Replicated и в Distributed

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

это тестовый пул, я могу и таблицы пересоздать, просто хочется понять - почему, вдруг в проде поймаю

а в проде пересоздавать таблицы - это боль

Ребят, помогите плз.

Какие типы данных у этих колонок (endtime, time)

А, ну как минимум вижу что у time приделывается timezone Moscow.

Что если такую же таймзону приделать к конвертации endtime

попробуйте на тесте 20.8.15

timezone это не то что вам кажется, то что текстовое отображение отображает Московское время это ничего не меняет.

SELECT
    toTimeZone(now(), 'Europe/Moscow') AS a,
    now() AS b,
    a - b AS x

┌───────────────────a─┬───────────────────b─┬─x─┐
│ 2021-03-04 02:18:29 │ 2021-03-03 23:18:29 │ 0 │
└─────────────────────┴─────────────────────┴───┘

Да docker образы планируется собирать
еще в планах сделать кастомизированные настройки metric name conversion
чтобы  было можно совместимость подкрутить с clickhouse-operator metrics-exporter и с prometheus embedded endpoint
и добавить custom queries в конфиг с кешированием чтобы кастомные метрики собирать
еще хотим
добавить rest server совместимый с metrics-exporter чтобы один clickhouse_exporter мог скрейпить метрики с нескольких серверов  и их можно было добавлять динамически

но это все хотелки и на это нужно время
со всем этим можно помочь
начать надо наверное с правил name conversion

никто ничего не забирал если что
Егор давно проект забросил
Перконе этот экспортер нужен для PMM2

ну, проблемка в том что exporter это сторонний софт и он ест отдельные ресурсы, если есть встроенные средства мониторинга, то IMHO лучше их использовать

https://github.com/ClickHouse/clickhouse_exporter/blob/master/exporter/exporter.go

select metric, value from system.metrics
select metric, value from system.asynchronous_metrics
select event, value from system.events
select database, table, sum(bytes) as bytes, count() as parts, sum(rows) as rows from system.parts where active = 1 group by database, table

вроде как это всё что он экспортит

родной экспортит со всех тех же таблиц, кроме system.parts

Господа, такой вопрос:

Допустим, у нас есть таблица requests, у которой есть поле status. Список статусов относительно часто меняется. Пересобирать агреггированные таблицы в таких случаях не охота (т.е. держать поля requests_ok_count, requests_failed_count, requests_blabla_count не вариант). Но и оставлять status в order by тоже не хочется, т.к. вкупе с другими это очень резко толстит таблицу.

Хотелось бы хранить это одним полем с какой-нибудь хитрым суммированием.

Я сначала расчитывал, что SummingMergeTree успешно переварит вот такие конструкции в поле, скажем, status_count_map

[(1,3),(2,1)]
[(1,4),(2,7)]

просуммирует их после в одну

[(1,7),(2,8)]

после чего я выберу их через sumMap

Но нет, он их не переваривает и не суммирует, схлопывает до первой строчки. Короче говоря, я неправильно понял документацию. Запутался, реально ли вообще это сделать и как.

https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/summingmergetree/#vlozhennye-struktury
таблицы заканчивается на Map

должны быть поля типа sMap.key sMap.value

https://gist.github.com/den-crane/1de5aa4a1e1a7460b03af86e56184301

status_count_map неправильно