Основная проблема - парсинг имён метрик, метрика + тэги. Я оптимизировал протокол немного, добавив возможность передать набор возможных имён метрик один раз и потом ссылаться на них. Стало на 60% быстрее.

а, увидел линк. А поддержку этой моды будешь куда то добавлять?

Evgeny А вот такой Array режим https://akumuli.gitbook.io/docs/writing-data#array-of-values зачем? вижу из плюсов только атомарность записи связанных метрик.

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

Intel snap так работает

ну вот он только очень энтерпрайзный

ну вот он только очень энтерпрайзный

Почему?

Гошечка, грпц всякий там - не шибко и

Но на вин платформе фактически безальтернативный, что печалит

http://leapfrogonline.io/articles/2018-05-11-exporting-windows-and-sql-server-metrics-to-prometheus-with-sonar/

Evgeny А вот такой Array режим https://akumuli.gitbook.io/docs/writing-data#array-of-values зачем? вижу из плюсов только атомарность записи связанных метрик.

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

http://leapfrogonline.io/articles/2018-05-11-exporting-windows-and-sql-server-metrics-to-prometheus-with-sonar/

Я сам не пробовал, если что.

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

ну в других dbms я видел это делают через begin commit и и т.п.

ну в других dbms я видел это делают через begin commit и и т.п.

Тут смысл не в этом, а в том, чтобы добиться компактного представления. Это же формат сериализации, а не язык запросов. Меньше ресурсов CPU на парсинг, меньше трафик между клиентом и бд.

Гляну сонару

Спс

господа, подскажите хорошо масштабируемое TSDB с сжатием данньіх и триггерами которьіе не очень медленньіе (опционально). требований к IOps не много, но ожидается хранить много ТБ данньіх

вариантов на рьінке масса - все руками пробовать непродуктивно

Триггеры в тсдб?

хорошо если будут, не будет - ну и фиг с ними

timescaledb, clickhouse

задача предполагает timestamp - value1-value2-.....- valuex

А ктото тестил кусаное яблоко?

Оно правда не тс

Какой те нестандартный тайм сериес, пакетированный

А есть где-нибудь нормальное описание синтаксиса prometheus alert expressions? Нашёл такой пример: expr: instance:node_filesystem_avail:ratio{fstype=~"(ext.|xfs)",job="node"} * 100 <= 10 - непонятно, откуда взяли instance: и :ratio? В доках prometheus не вижу такого

сделали record rule с таким названием

https://prometheus.io/docs/practices/rules/

Понял, tnx

@korservick подскажи pcp коллектор идёт одним бинарём как в telegraf или под разные плагины отдельные как в проме?

Разные под разное

А ктото тестил кусаное яблоко?

?

Название забыл

Яблочники заопенсорсили

@Civiloid м?

FoundationDB

Да

https://github.com/prometheus/prometheus/issues/4254 багоделы

Проблема этих всех баз что под них нет готовых писашек

ба https://github.com/prometheus/prometheus/issues/4241 го https://github.com/prometheus/prometheus/issues/4246 де https://github.com/prometheus/prometheus/issues/4253 лы

@Civiloid м?

А?

вспоминали название яблочной тсдб

А я ее и не знал :)

коллеги, а кто-нибудь алертманагером алертит в слак?

у меня какая-то странная штука с подавлением

никак не могу добиться картинки вроде такой:

то есть как только случается [FIRING:>1], то заголовок просто пропадает и всё

не понял в чём разница

описания нет

на первом скриншоте [FIRING:2] PodsAreRestarting

так это в шаблоне надо же

а у меня [FIRING:1] DescriptionHere, но [FIRING:7] ЁбаноеНичего

правила подавления вот такие:

inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['alertname', 'cluster', 'component', 'service'] - source_match: severity: 'warning' target_match: severity: 'info' equal: ['alertname', 'cluster', 'component', 'service']

то есть критикал подавляет ворнинг, ворнинг подавляет инфо

без этого [FIRING:7] развернулся бы в семь алертов отдельных

сюда глянь https://github.com/prometheus/alertmanager/blob/master/template

{{ define "__subject" }}[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .GroupLabels.SortedPairs.Values | join " " }} {{ if gt (len .CommonLabels) (len .GroupLabels) }}({{ with .CommonLabels.Remove .GroupLabels.Names }}{{ .Values | join " " }}{{ end }}){{ end }}{{ end }}

похоже?

есть app'ы которые по определенным смс начинают орать пока не остановишь

А можно названия программ?

логика в шаблонах, чо

чота я об условие сломался

if gt (len .CommonLabels) (len .GroupLabels)

вот чота тоже

ну ты всегда можешь тайтл переопределить

то есть если самих алертов больше, чем групп, то удаляем лейблы с алертов, оставляем только групповые ( with .CommonLabels.Remove .GroupLabels.Names ) и джойним, что осталось

видимо ага

ERROR: S client not available

странная логика кажется

и походу на выходе у меня не остаётся примерно ничего

то есть я где-то проскипал имена/лейблы для групп чтоли?

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

а какие у тебя алерты щас горят?

прямо сейчас никакие, но это работает абсолютно со всеми

ща покажу пример

groups: - name: disk-space-ends-soon rules: - alert: disk_space_ends_soon expr: 100 - predict_linear(disk_used_percent{fstype!="overlay",path!="/tmp"}[1h], 4 * 3600) < 0 for: 5m labels: cluster: amplifr component: node service: disk_space severity: warning annotations: description: Check partition info at https://grafana.amplifr.com/dashboard/db/host-stats?var-host={{ $labels.host }}&panelId=5&fullscreen and try to move or remove something summary: Attention! Mountpoint {{ $labels.path }} on node {{ $labels.host }} predicted to be overflowed in next 4 hours - alert: disk_space_ends_soon expr: 100 - predict_linear(disk_used_percent{fstype!="overlay",path!="/tmp"}[1h], 3600) < 0 for: 5m labels: cluster: amplifr component: node service: disk_space severity: critical annotations: description: Free some space ASAP and remember to check partition info at https://grafana.amplifr.com/dashboard/db/host-stats?var-host={{ $labels.host }}&panelId=5&fullscreen after freeing space. summary: Attention! Mountpoint {{ $labels.path }} on node {{ $labels.host }} predicted to be overflowed in hour!

я думаю что речь идёт про группировку в алертменеджере, а не про группы алертов в прометее

и вот если на двух дисках сразу будет кончаться место, то в слаке будет просто FIRING:2

убери группировку по имени хоста

(или наоборот добавь)

не соображу

в алертманагере вообще никаких группировок не описано

только inhibition

как же он тогда у тебя группирует в 7 штук?

слакоконфиг выглядит так: slack_configs: - api_url: 'https://hooks.slack.com/services/xxx channel: '#info-alerts' username: 'amplifr-prometheus' title: '[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .CommonAnnotations.summary }}' text: '{{ .CommonAnnotations.description }}' send_resolved: true

title: '[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .CommonAnnotations.summary }}'

это ты щас добавил?

не, это "всегда" было

а закомментируй и посмотри какой заголовок упадёт

у меня вот например всё ок с дефолтным шаблоном

[FIRING:10] HighMemoryUsage (default eu-west-1 info)

ок, спасибо

ну то есть говно конечно, но не техническая проблема с заголовком

теперь бы вспомнить, зачем я тут кастомный сочинял...

аннотацию хотел в заголовок сунуть

а под группировками ты что имел в виду?

ну то есть оно у меня как-то само эти [FIRING:10] собирает

я ничего для этого не делал

ну алертменеджер умеет группировать алерты перед посылкой

group_interval