есть метрика в promethus с label=hostname
как вытащить кол-во уникальных hostname
для которых метрика > 0 ?

Галочка даже не нужна - достаточно просто экранировать символы, которые не могут встречаться в прометеусовских именах метрик, с помощью бэкслеша. Это никак не поломает обратной совместимости с прометеусом, т.к. в нем по определению нет имен метрик с неподдерживаемыми символами.

вот это смотрели - https://github.com/flant/loghouse ?

Ну посмотрят в графана на этот юзкейс и скажут wtf я думаю.
Можно начать наверное с ишью на гитхабе

Он разве для докера подойдёт?

нет, это для kubernetes решение

Логи это тут немного оффтопик, лучше про них на отдельном канале

Имеется ввиду официальный дашборд для кластерной версии? Вот отсюда? https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/README.md#monitoring
Можно больше делалей, что конкретно там не заработало?

@hagen1778 , можешь посмотреть, что там не так с дашбордом.

сингл или кластерная версия? можно в личку чтобы не офф-топить

RSS - это память, к которой недавно обращалась программа aka процесс (без разницы - на чтение или запись). Сюда входят следующие типы памяти:

* Локальная память программы aka anonymous memory. К этой памяти имеет доступ только эта программа.
* Память, общая для нескольких программ aka shared memory. Например, код из shared libs или вся readonly память после fork'а процесса либо какая-нибудь shm память.
* Память, отображенная в адресное пространство программы из файлов aka file-based memory map (mmap). Наиболее распространенный пример - код запущенной программы.

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

Virtual - это адресное пространство программы. В теории всем программам на 64-битных операционках доступно до 2^64 байт адресного пространства. На практике это число немного меньше, но все равно превышает терабайт. Размер доступной виртуальной памяти для каждой программы не зависит от реального объема памяти на компе и спокойно может превышать доступную память на компе в тысячи или миллионы раз. Советую вообще не обращать внимания на колонку Virtual, т.к. по ней сложно понять, как обстоят дела с реальным потреблением памяти у программы.

Code - это память с кодом программы. Обычно этот код за`mmap'ливается напрямую из файлов в память программы, как это было сказано в описании RSS. Обычно его размер не превышает размер файла с программой. Может превышать, если программа запакована с помощью какого-нибудь upx.

DataAndStack - это объем локальной (ака анонимной) памяти, про которую уже рассказано в RSS. Тут тоже важно понимать, что RSS может не учитывать всю эту память, если к ней давно не было обращений. Например, если в программе есть "медленная" утечка памяти, через которую медленно выделяется, но не освобождается память, то с течением времени такая выделенная память перестанет считаться в RSS, хотя будет продолжать учитываться в DataAndStack. Т.е. при такой утечке памяти RSS может оставаться на месте, а DataAndStack будет расти.

;) Александр спасибо за объяснения, мне надо было именно URL
который я в grafana dashboard воткну как ссылку на документацию ;)
https://elinux.org/Runtime_Memory_Measurement
вполне подошел

Написал в личку

Коллеги, добрый день.

Подскажите, как можно понять в чем проблема с правилом в alertmanager?  
Я отслеживаю состояние одной из служб. Создал правило:
groups:
- name: service.rules
 rules:
 - alert: service_down
   expr: win_services_state{service_name="MSExchangeUM"}==4
   for: 1m

Добавил его в prometheus.yml. Тест правила прошёл и в :9090/alerts оно появилось. Но почему то оно не срабатывает, хотя если писать запрос в Prometheus "win_services_state{service_name="MSExchangeUM"}", в нём сейчас Value 1

!=4 ?

Сейчас попробую. Но в дефолтном правиле вот так и всё работает:
groups:
- name: alert.rules
 rules:
 - alert: InstanceDown
   expr: up == 0
   for: 1m

А, хотя все правильно. Это же знак равенства

ребят, есть крон, который шлет в statsd следующие метрики:

25 May 09:28:00 - cron-run.start:1|g
25 May 09:28:16 - cron-run.stop:1|g
25 May 09:28:16 - cron-run.success:1|g
25 May 09:28:16 - cron-run.duration:16883|ms|@0.1

statsd репитит метрики в statsd-exporter. в экспортер каждые 15 секунд приходит прометеус и забирает их.
как заставить statsd/statsd-exporter сбрасывать метрику в ноль после того, как крон закончился?
а то получается, что в графике каждые 15 секунд и старт и стоп и саксесс идут как 1, хотя крон завершил свою работу

deleteIdleStats:true
deleteGauges: true не помогает

А вот ещё такой вопрос. Если я хочу в alertmanager.yml в routes привязать два алерта к одному ресиверу, как это можно сделать?
Вариант:
 routes:
   - receiver: send_email
     match:
       alertname:['service_down',' InstanceDown']

не работает.

В интернете не нашёл таких примеров. Так вообще делают?

Сделал так, но не уверен что это лучший вариант:
 routes:
   - receiver: send_email
     match:
       alertname: service_down

   - receiver: send_email
     match:
       alertname: InstanceDown