Всем добрый день. Пытаюсь уже несколько дней настроить алерт на down контейнера и все четно. Если использовать правило
absent(container_last_seen{container_label_com_docker_stack_namespace="prom-exp",container_label_com_docker_swarm_task_name=~"prom-exp.*"})
работает на ура, но нет информации о контейнере. Но если использовать (time() - container_last_seen{ container_label_com_docker_stack_namespace="prom-exp",container_label_com_docker_swarm_task_name=~"prom-exp_nginx-exp.*"}) > 20 правило не срабатывает или срабатывает 5 из 100 проверок. Просьба помочь или подсказать, как правильно настроить алерт.
Я выяснил что приложения можно мониторить, для мониторинга предполагается использовать Prometheus+правила (rules), где бы посмотреть promql запросы для полезных и выжных параметров приложения?
при этом эти значения около 13GB для сервера с 16GB RAM.
$ps эту память включает в RSS процесса, так же как $free этих свободных 13GB не видит, нет её ни в кэше, ни в буферах. В meminfo эта память числится в Inactive(anon).
Собственно вопрос, когда эта память станет реально доступной для ОС?
Всем доброго времени суток!
Как темплейтированном или вообще в alert rules Prometheus указать для какой они ноды или сервиса?
в доках не нашёл инфы по variables
К примеру у меня есть alert rules для бэкэнда,MongoDB,для «железа», контейнеров (Docker), как prometheus будет различать где и к чему применять эти правила алертинга?
Добрый день,
Я новичок в Prometheus. Настроил мониторинг, перешел к алертам и попал в тупик.
Есть 2 группы оборудования. 1 - роутеры, 2 - серверы. Есть 2 файла с правилами. В каждом файле присутстывет правило для алерта при привышени времени отклика.
- alert: host_response_time_is_high_via_icmp
expr: sum by (instance) (probe_icmp_duration_seconds) > 0.3
for: 10s
labels:
severity: warning
annotations:
description: "Host {{ $labels.instance }} response time via icmp-protocol is very high ( >300ms ) for more than 1 minutes."
summary: "Host {{ $labels.instance }} response time is {{ humanize $value}}s"
При тестировании, я меняю предел 300мс до значений чтоб алерт сработал. Когда я меняю для группы серверов, все равно обрабатывается группа с роутерами, соотвественно я получаю алерты для роутеров. Для группы серверов алерты (icmp) не приходят вообще.
Что я делаю не так? Где туплю?
Ubuntu 18. Zabbix 5.0 + Postgres. Разные экспортеры прометея. Период опроса 1 минута.
Проблема: периодически появляются «пропуски» в сборе метрик. Данные собираются, обрабатываются, но потом может быть пропуск в 3,5,7минут, срабатывает триггер nodata на отсутствие данных с экспортеров. Затем само собой снова восстанавливается. Сбор восстанавливается, значения появляются.
При этом порт экспортера доступен. Повесил доп.проверку http на код 200. Она не алармит, т.е. сам экспортер доступен. И в ручном режиме он отдает данные, а вот заббикс почему-то не собирает их.
В логах вижу по одному из серверов :
32180:20201207:151616.064 item «MYSERVER:apache_exporter.get» became not supported: Cannot perform request: Connection timed out after 3000 milliseconds
32174:20201207:152413.715 item «MYSERVER:apache_exporter.get» became supported
в 15:16 ошибка получения данных, в 15:24 успех. И на графиках появляются пропуски. Сетевая недоступность отклоняется. С этого сервера prometheus собирает метрики по хостам и через графану все отображается корректно. Связь с экспортерами не пропадает.
Сам сервер. 4 vCPU, 8GB RAM, 200Gb SSD. Очереди пусты. Самодиагноситка заббикса показывает, что он не перегружен. Запас по пулам есть.
Ссылка на скрины: https://yadi.sk/d/TVfg29DS95nc5A?w=1
Кто-нибудь сталкивался с подобным? В чем может быть дело?
Есть postgres_exporter ему заданы custom запросы которые долго выполняются.
В прометее для данного postgres_exporter стоит scrape_interval 60 минут, но прометей не может получить данные из postgres_exporter так как последний их долго отдает ( долго выполняются запросы, долго получаем ответ).
При этом если мы браузером идем напрямую в /metrics postgres_exporter данные формируются.
Получается что Prometheus просто не дожидается отдачи.
Какой параметр в сборе метрик прометея можно подкрутить чтоб он дожидался ответа postgres_exporter ?
Доброго дня!
Подскажите, пожалуйста, наблюдаю высокий рост дискового пространства на VM от Victoriametrics за 5 дней 17GB это норм, можно ли как-нибудь оптимизировать под неё место?
В postgresql статистика по commit суммируется в pg_stat_statement. Как в prometheus вычесть из текущего счетчика commit счетчик commit за предыдущую минуту?
оно показывает количество запущенных docker контейнеров в текущий момент. При перезапуске(деплое) контейнера, правило срабатывает и создает ложный алерт.
Есть мысль сделать правило таким образом, чтобы высчитывалась разница между количеством запущенных контейнеров N минут назад и количеством в данный момент. Вопрос: как получить количество запущенных docker контейнеров N минут назад?
Статистика в PostgreSQL в таблице pg_stat_statements кумулятивная.
То есть она накапливается и данные там суммируются.
pg_stat_statements сбрасываю раз в сутки.
topk(5, sum by (datname,queryid) (increase(pg_stat_statements_mean_time_seconds{datname!~"template.*", datname!~"postgres", instance=~"$instance", datname=~"$datname"}[1m])))
topk(5, sum by (datname) (increase(pg_stat_statements_mean_time_seconds{datname!~"template.*", datname!~"postgres", instance=~"$instance"}[1m]) > 10 ))
Продолжаем цикл тупых вопросов по гетто-мониторингу подкроватного сервера.
С мониторингом как таковым всё в принципе понятно. Вот есть, допустим, стек Prometheus/Alertmanager. Он понятно как работает: Prometheus агрегирует метрики, прогоняет их через правила, генерирует level-triggered алерты и пушит их в Alertmanager. При этом Alertmanager, по существу, делает ровно две вещи: конвертирует level-triggered алерты в edge-triggered события и роутит их.
Мне нужна похожая тулза, только для произвольных событий. У меня есть много периодических (и апериодических) задач, каждую из которых я отдельно заворачиваю в | mailx, но так жить нельзя. Я бы хотел уметь как-то обобщённо рассылать себе уведомления об их окончании, причём необязательно на почту.
Первым делом я попробовал присобачить тот же Alertmanager, потому что у него есть огромное количество интеграций во всё что можно. Но он принципиально не подходит под эту задачу. Он by design ожидает, что ему на вход поступают level-triggered алерты, а он их дедуплицирует и делает edge detection. А в моём случае входы уже edge-triggered, и на каждый вход нужно отправить ровно один выход, не больше и не меньше.
Есть ли в мире какой-нибудь «роутер событий», похожий на Alertmanager, но без этой семантики edge detection?
Добрый день!
Имеется сервер xx.xx.xx.xx привязанный к домену domen_name.
На сервере в докере крутится набор контейнеров grafana+prometheus+alertmanager+etc.
Соответственно сервисы доступны по адресам:
grafana:xx.xx.xx.xx:3000
prometheus:xx.xx.xx.xx:9090
Что я смог сделать:
Установить ssl через certbot на nginx, который привязан к домену domen_name.Но, как я выяснил ssl при обращении к domen_name:3000 / domen_name:9090 не прикручивается сам собой.
Вопрос:
Как мне прикрутить ssl к grafana,prometheus,alertmanager?Каждый сервис должен быть доступен в свою очередь по отдельному urlu.
