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

Мониторинг docker c помощью Prometheus

Jul 17, 2017 09:58 · 672 words · 4 minute read docker prometheus monitoring

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

В данной статье рассмотрим пример быстрой настройки мониторинга docker-хостов и запущенных на них docker-контейнеров с помощью уже известной нам системы мониторинга Prometheus — давайте разберемся!

Считаем, что у вас уже установлен Prometheus со всеми необходимыми компонентами ( node_exporter , alertmanager и Grafana).

Примечание. К слову, все эти компоненты можно устанавливать в docker-контейнерах и объединять весь стек с помощью docker-compose .

Если с мониторингом docker-хоста все просто и понятно — как и на любом другом физическом сервере метрики собирает node_exporter и передает их в Prometheus, то для мониторинга docker-контейнеров придется воспользоваться инструментом cAdvisor (Container Advisor) от google.

Для запуска cAdvisor воспользуемся файлом docker-compose.yml следующего содержания:

version: '2' services:  cadvisor-exporter:  container_name: "cadvisor-exporter"  image: google/cadvisor  ports:  - "9200:8080"  volumes:  - "/:/rootfs:ro"  - "/var/run:/var/run:rw"  - "/sys:/sys:ro"  - "/var/lib/docker/:/var/lib/docker:ro"  restart: unless-stopped 

Запускаем контейнер с помощью команды:

docker-compose up -d 

Далее в уже хорошо известный нам конфигурационный файл prometheus.yml (в debian-based дистрибутивах находится в каталоге /etc/prometheus ) нужно добавить следующие строки:

- job_name: 'cadvisor-exporter'  scrape_interval: 1s  target_groups:  - targets: ['cadvisor-exporter:9200'] 

и перезапустить Prometheus для применения изменений.

Следующим шагом нужно импортировать (или создать самостоятельно) в Grafana дашборд для отображения собираемых метрик по docker-контейнерам — взять готовые можно здесь. В некоторых случаях потребуется внести небольшие правки в зависимости от используемого вами docker storage driver — в готовых дашбордах используется aufs , если же у вас overlay/overlay2 , то некоторые графики будут пустыми.

Например, в моем случае используется overlay , поэтому правильная метрика для отображения используемого места на системном диске будет выглядеть так:

sum((node_filesystem_size - node_filesystem_free)) / sum(node_filesystem_size) * 100 

Далее следует настроить уведомления, по умолчанию данные настройки находятся в /etc/prometheus/alert.rules , но для удобства их можно разделить на несколько файлов в зависимости от типа оповещения.

Например, для оповещения о проблемах с контейнерами, можем использовать файл containers.rules , а для оповещений о проблемах с docker-хостом — файл docker.rules .

Содержимое файла правил containers.rules следующее:

# Контейнер не запущен более 30 секунд ALERT test_container_down IF absent(container_memory_usage_bytes) FOR 30s LABELS < severity = "critical" >ANNOTATIONS < summary= "test_container down", description= "test_container container is down for more than 30 seconds." ># Контейнер использует более 10% CPU более 30 секунд подряд ALERT test_container_high_cpu IF sum(rate(container_cpu_usage_seconds_total[1m])) / count(node_cpu) * 100 > 10 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary= "test_container high CPU usage", description= "test_container CPU usage is >%." > # Контейнер использует более 1,2GB RAM более 30 секунд подряд ALERT test_container_high_memory IF sum(container_memory_usage_bytes) > 1200000000 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary = "test_container high memory usage", description = "test_container memory consumption is at >.", > 

В конфигурационном файле docker.rules следующие строки:

# LA выше определенного лимита (1.5) более 30 секунд ALERT high_cpu_load IF node_load1 > 1.5 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary = "Server under high load", description = "Docker host is under high load, the LA 1m is at >.", > # Использование памяти превышает 85% ALERT high_memory_load IF (sum(node_memory_MemTotal) - sum(node_memory_MemFree + node_memory_Buffers + node_memory_Cached) ) / sum(node_memory_MemTotal) * 100 > 85 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary = "Server memory is almost full", description = "Docker host memory usage is >%.", > # Использование системного диска превышает 85% ALERT hight_storage_load IF (node_filesystem_size - node_filesystem_free) / node_filesystem_size * 100 > 85 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary = "Server storage is almost full", description = "Docker host storage usage is >%.", > 

Alertmanager также умеет оправлять оповещения о проблемах с помощью e-mail, Pushover, Slack, HipChat. Пример интеграции alertmanager’а и slack подробно расписан здесь, поэтому воспользуемся данным примером.

Конфигурационный файл с настройками отправки уведомлений выглядит так:

route:  receiver: 'slack' receivers:  - name: 'slack'  slack_configs:  - send_resolved: true  username: 'Prometheus'  channel: '#random'  api_url: 'https://hooks.slack.com/services///' 

На этом все, а для быстрой настройки всего стека мониторинга «с нуля» могу порекомендовать готовый проект от Stefan Prodan.

Мониторинг docker при помощи контейнера zabbix агента

Есть виртуальная машина на ubuntu 22.04 с docker compose. На ней поднято несколько контейнеров. На ней я запустил контейнер с zabbix агентом 2 версии, он успешно отправляет метрики по состоянию хоста на сервер (стандартный шаблон Linux by Zabbix agent). Что же касается информации о docker (стандартный шаблон Docker by Zabbix agent 2), то данных нет совсем. Я пробовал запустить контейнер агента в привилегированном режиме и дать доступ к docker.sock, рерультат тот же.

 privileged: true volumes: - /var/run/docker.sock:/var/run/docker.sock 

В чем может быть причина?
Отслеживать
задан 27 сен 2022 в 8:25
1 1 1 бронзовый знак

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Достаточно было указать, чтобы контейнер запускался от рута:

user: root privileged: true volumes: - /var/run/docker.sock:/var/run/docker.sock 

Отслеживать
ответ дан 27 сен 2022 в 11:52
1 1 1 бронзовый знак

Абажди. а почему нельзя натравить на заббикс хостовый докер сокет? Тогда все контейнеры будут винды. Или я что-то не так понял?

Сбор метрик для мониторинга работы контейнеров в среде Docker

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

Данная статья является переводом англоязычной статьи из официальной документации Docker. В процессе перевода мы постарались упростить статью.

Отслеживание статистики с помощью docker stats

Для отслеживания метрик среды выполнения контейнера в режиме реального времени можно использовать команду docker stats . Команда отображает статистику использования ресурсов контейнерами и поддерживает такие метрики, как утилизация CPU, памяти, ограничения на использование памяти, а так же метрики для сети и блочного IO.

Ниже приведен пример вывода команды docker stats :

$ docker stats redis1 redis2 CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O redis1 0.07% 796 KB / 64 MB 1.21% 788 B / 648 B 3.568 MB / 512 KB redis2 0.07% 2.746 MB / 64 MB 4.29% 1.266 KB / 648 B 12.4 MB / 0 B 

Более подробно о команде вы сможете прочитать на странице docker stats

Контрольные группы

Контейнеры в Linux реализованы с использованием контрольных групп, которые не только позволяют задать ограничения для групп процессов, но также предоставляют метрики использования CPU, памяти, блочного ввода-вывода. Помимо этих метрик, можно также получить статистику использования сети. Все это относится как к контейнерам LXC, так и к контейнерам Docker.

Контрольные группы реализуются через специальную псевдофайловую систему. В последних версиях дистрибутивов вы можете найти данную файловую систему в каталоге /sys/fs/cgroup , для некоторых дистрибутивов может использоваться другой путь. В этой файловой системе вы увидите множество подкаталогов, которые называются devices , freezer , blkio и другие; каждый подкаталог соответствует отдельной иерархии контрольных групп.

Чтобы найти точку монтирования, к которой у вас подключены контрольные группы, воспользуйтесь командой:

$ grep cgroup /proc/mounts 

Перечисление cgroups

Чтобы определить известные системе подсистемы контрольных групп и статистику групп в них, просмотрите файл /proc/cgroups .

$ cat /proc/cgroup #subsys_name hierarchy num_cgroups enabled cpuset 2 1 1 cpu 3 122 1 cpuacct 3 122 1 blkio 10 122 1 memory 11 226 1 devices 8 123 1 freezer 6 2 1 net_cls 12 1 1 perf_event 7 1 1 net_prio 12 1 1 hugetlb 9 1 1 pids 4 134 1 rdma 5 1 1 

Вы можете просмотреть файл /proc//cgroup , чтобы определить, к каким контрольным группам принадлежит процесс. Контрольная группа отображается как путь от директории монтирования иерархии. / означает, что процесс не был назначен конкретной группе, а /lxc/pumpkin указывает на то, что процесс принадлежит контейнеру pumpkin .

Поиск контрольной группы конкретного контейнера

Для каждого контейнера в каждой иерархии создается одна cgroup . В ранних системах с более ранними версиями пользовательских утилит LXC, имя контейнера является именем контрольной группы. В более поздних версиях инструментов LXC, имя группы соответствует lxc/ .

Для контейнеров Docker, именем контейнера является полный ID контейнера. Если контейнер отображается в docker ps как ae836c95b4c3 , его полный ID может быть, например, таким: ae836c95b4c3c9e9179e0e91015512da89fdec91612f63cebae57df9a5444c79 . Его можно узнать с помощью docker inspect docker ps —no-trunc или docker ps —no-trunc .

Если обобщить все сказанное выше, то, к примеру, метрики памяти контейнера Docker находятся в каталоге /sys/fs/cgroup/memory/docker// .

Метрики из cgroup : память, CPU, блочный I/O

Для каждой подсистемы (память, CPU и блок ввода-вывода) есть один или несколько псевдофайлов со статистикой.

Метрики памяти

Метрики памяти находятся в контрольной группе “memory”. Эта группа создает дополнительную небольшую нагрузку на систему, потому что производит подробный учет использования памяти на вашем хосте. Таким образом, во многих дистрибутивах ее по умолчанию отключают. Как правило, чтобы ее включить, достаточно добавить параметры командной строки ядра: cgroup_enable=memory swapaccount=1 .

Метрики сохраняются в псевдофайл memory.stat и выглядят следующим образом:

cache 11492564992 rss 1930993664 mapped_file 306728960 pgpgin 406632648 pgpgout 403355412 swap 0 pgfault 728281223 pgmajfault 1724 inactive_anon 46608384 active_anon 1884520448 inactive_file 7003344896 active_file 4489052160 unevictable 32768 hierarchical_memory_limit 9223372036854775807 hierarchical_memsw_limit 9223372036854775807 total_cache 11492564992 total_rss 1930993664 total_mapped_file 306728960 total_pgpgin 406632648 total_pgpgout 403355412 total_swap 0 total_pgfault 728281223 total_pgmajfault 1724 total_inactive_anon 46608384 total_active_anon 1884520448 total_inactive_file 7003344896 total_active_file 4489052160 total_unevictable 32768 

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

Некоторые показатели отражают текущие значения, то есть могут увеличиваться или уменьшаться. Например, swap – размер файла подкачки, используемого участниками контрольной группы. Другие показатели являются “счетчиками”, то есть значениями, которые могут только увеличиваться и сбрасываться, потому что они подсчитывают некоторые события. Например, pgfault указывает количество промахов страниц виртуальной памяти, которые произошли с момента создания группы.

Метрики CPU

Метрики использования ресурсов процессора для каждого контейнера содержится в псевдофайле cpuacct.stat . Они аккумулируют использование процессора всеми процессами контейнера и разбиты по времени по нахождению процессов в пространстве пользователя и пространстве ядра:

• user – период времени, в течение которого процесс использует процессор для выполнения непривилегированного кода процесса;
• system – период времени, в течение которого ядро выполняет системные вызовы от имени процесса.

Время подсчитывается в единицах, равных 1/100 секунды, также известных как jiffies или тики. Количество тиков в секунду определяется переменной USER_HZ , и в системах x86 USER_HZ равен 100. Раньше это количество соответствовало количеству тиков планировщика в секунду, но с повышением частоты и появлением бестиковых ядер показатель стал полностью синтетическим.

Метрики блочного I/O

Метрики блочного ввода/вывода учитываются в подсистеме blkio . В разных файлах сохраняются разные метрики. Подробнее о них можно узнать из документации ядра. Ниже представлен краткий список наиболее часто используемых метрик:

Метрика	Описание
blkio.sectors	Содержит количество 512-байтовых секторов, считанных и записанных процессами контрольной группы для каждого устройства. Операции чтения и записи учитываются в одном показателе.
blkio.io_service_bytes	Определяет количество байт, считанных и записанных контрольной группой. Имеет 4 счетчика для каждого устройства, поскольку для каждого устройства отдельно учитываются синхронные и асинхронные операции ввода/вывода, а также операции чтения и записи.
blkio.io_serviced	Число произведенных операций ввода/вывода, вне зависимости от их размера. Также имеет 4 счетчика для каждого устройства.
blkio.io_queued	Определяет количество запросов ввода/вывода, инициированных контрольной группой, которые на данный момент поставлены в очередь.

Метрики сети

Метрики сети напрямую не учитываются контрольными группами. Этому есть хорошее объяснение: сетевые интерфейсы существуют в контексте сетевых пространств имен. Ядро могло бы собирать метрики о количестве пакетов и байтов, отправленных и полученных группой процессов, но эти показатели были бы бесполезны. Пользователю обычно нужны метрики по каждому интерфейсу. Но так как процессы в отдельной контрольной группе могут относиться к множеству сетевых пространств имен, эти показатели будет сложно интерпретировать – множество сетевых пространств имен означает множество интерфейсов lo , множество интерфейсов eth0 и так далее; поэтому собрать показатели сети с контрольных групп нелегко.

Вместо этого можно собирать метрики сети из других источников.

IPtables

Достаточно подробный учет могут делать IPtables (или фреймворк netfilter , для которого iptables является просто интерфейсом).

Например, можно задать правило учета исходящего HTTP-трафика на веб-сервере:

$ iptables -I OUTPUT -p tcp --sport 80 

Здесь нет флага -j или -g , поэтому правило считает только соответствующие пакеты и переходит к следующему правилу.

Затем, можно проверить значения счетчиков с помощью:

$ iptables -nxvL OUTPUT 

Счетчики учитывают пакеты и байты. Если необходимо задать такие метрики для трафика контейнера, можно выполнить цикл for , чтобы добавить две цепочки iptables для каждого IP-адреса контейнера в цепочке FORWARD .

Затем нужно периодически проверять эти счетчики. Если вы используете collectd , есть хороший плагин для автоматизации сбора учетных данных с IPtables.

Счетчики на уровне интерфейса

Так как каждый контейнер имеет виртуальный интерфейс Ethernet, возможно, вам захочется проверить напрямую счетчики TX и RX этого интерфейса. Каждый контейнер в вашем хосте связан с виртуальным интерфейсом Ethernet с именем, например, vethKk8Zqi . К сожалению, сложно определить, какой интерфейс к какому контейнеру относится.

На сегодня лучше всего проверять метрики из контейнеров. Для этого вы можете запустить исполнительный файл из среды хоста в сетевом пространстве имен контейнера, используя ip-netns .

Команда ip-netns exec позволяет выполнить программу в любом сетевом пространстве имен, доступном текущему процессу. Это значит, что ваш хост может войти в сетевое пространство имен контейнера.

Формат команды следующий:

$ ip netns exec

$ ip netns exec mycontainer netstat -i 

ip-netns находит контейнер mycontainer с помощью псевдофайлов пространств имен. Каждый процесс относится к одному сетевому пространству имен, одному пространству имен PID, одному пространству имен mnt и так далее. Эти пространства имен описываются в /proc//ns/* . Например, сетевое пространство имен PID 42 отображается в псевдофайл /proc/42/ns/net .

При запуске ip netns exec mycontainer . ожидается, что /var/run/netns/mycontainer будет одним из таких псевдофайлов. (Допускаются ссылки).

Иными словами, для выполнения команды внутри сетевого пространства имен контейнера необходимо:

• Определить PID любого процесса в контейнере, данные которого мы хотим получить;
• Создать ссылку из /var/run/netns/ к /proc//ns/net ;
• Выполнить ip netns exec . .

Заново просмотрите раздел «Перечисление групп» для того чтобы понять, как найти контрольную группу, для которой вы хотите хотите измерить статистику сети. Затем вы можете просмотреть псевдофайл с именем «tasks» в контрольной группе, который содержит все PID в группе (и, следовательно, в контейнере). Выберите любой из PID.

В общем, если “короткий ID” контейнера содержится в переменной окружения $CID , то можно сделать следующее:

$ TASKS=/sys/fs/cgroup/devices/docker/$CID*/tasks $ PID=$(head -n 1 $TASKS) $ mkdir -p /var/run/netns $ ln -sf /proc/$PID/ns/net /var/run/netns/$CID $ ip netns exec $CID netstat -i 

Советы для более эффективного сбора статистики

Запускать новый процесс каждый раз, когда нужно обновить показатели, может быть довольно затратно. Если вы хотите собирать показатели с большой частотой и/или с большого количества контейнеров (например, 1000 контейнеров на одном хосте), не следует каждый раз создавать новый процесс.

Вы можете собирать метрики с помощью одного процесса, написав обработчик для сбора метрик на С или любом другом языке, который дает возможность выполнять низкоуровневые системные вызовы. Необходимо использовать специальный системный вызов, setns() , который позволит текущему процессу попасть в пространство имен. Для данного системного вызова необходимо наличие открытого файлового дескриптора для псевдофайла пространства имен (речь идет о псевдофайле в /proc//ns/net ).

Не оставляйте дескриптор открытым после сбора метрик, поскольку пока существует последний процесс контрольной группы, будут существовать и пространство имен, а его сетевые ресурсы (например, виртуальный интерфейс контейнера) не будут освобождены.

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

Сбор метрик после завершения контейнера

Иногда нет необходимости отслеживать метрики в режиме реального времени, но когда контейнер уже остановлен, требуется понять сколько CPU, памяти и других ресурсов он использовал.

Для Docker это довольно сложно реализовать, что связано с использованием lxc-start , которая тщательно удаляет все, относящееся к контейнеру после вызова. Обычно проще собирать метрики через равные промежутки времени. Именно так работает LXC-плагин collectd . Но если все же необходимо собрать статистику после остановки контейнера, то это можно сделать так:

Для каждого контейнера запустите процесс сбора статистики, и переместите его в те контрольные группы, которые вы хотите отслеживать, записав PID процесса в файл tasks контрольной группы. Процесс сбора метрик должен периодически перечитывать файл tasks , чтобы проверить, является ли данный процесс последним в контрольной группе. Если нужно также собрать статистику сети, как описано в предыдущем разделе, то необходимо перенести процесс в соответствующее сетевое пространство имен.

Когда контейнер будет остановлен, lxc-start попытается удалить контрольные группы. У нее это не получится это сделать, так как контрольные группы еще используются нашим процессом сбора метрик. Теперь ваш процесс должен определить, что он является единственным процессом, оставшимся в группе, и собрать метрики для контейнера.

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

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

Мониторинг докер-хостов, контейнеров и контейнерных служб

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

Почему выбор пал на Prometheus

• Весь стек можно развернуть с использованием контейнеров.
• Он создан для распределенных систем и инфраструктур.
• Масштабируемый сбор данных, не зависящий от распределенного хранилища.
• Гибкая система обнаружения сервисов (встроенная поддержка для Kubernetes, Consul, EC2, Azure).
• Целевой экспортер для таких сервисов, как HAProxy, MySQL, PostgreSQL, Memcached, Redis и др.

Экосистема Prometheus огромна. Это означает, что можно найти метрические экспортеры для целого ряда систем, начиная от базы данных, MQ, HTTP-серверов до систем, связанных с аппаратными средствами, таких как IoT или IPMI. Тестирование по методу белого ящика также имеет отличное покрытие. Существуют клиентские библиотеки Prometheus для Go, Java, Python, Ruby, .NET, PHP и других языков программирования.

Начало работы с Prometheus и докером

Если вы хотите попробовать стек Prometheus, обратите внимание на репозиторий dockprom на GitHub. Можно использовать dockprom в качестве начальной точки мониторингового решения. Это позволит с помощью одной команды управлять целым стеком: Prometheus, Grafana, cAdvisor, NodeExporter и AlertManager.

Установка

Скопируйте репозиторий dockprom на докер-хост, перейдите в директорию dockprom и запустите compose up:

$ git clone https://github.com/stefanprodan/dockprom $ cd dockprom $ docker-compose up -d

• Prometheus (метрическая база данных) http://:9090
• AlertManager (управление оповещениями) http://:9093
• Grafana (визуализация метрик) http://:3000
• NodeExporter (сборщик хостовых метрик);
• cAdvisor (сборщик метрик контейнеров).

Если Gafana поддерживает аутентификацию, то сервисы Prometheus и AlertManager не имеют такой функции. При наличии базовой аутентификации для Prometheus и AlertManager вы можете удалить отображение портов из файла docker-compose и использовать NGINX как обратный прокси-сервер.

Установка Grafana

Перейдите на http://:3000 и авторизуйтесь, используя логин admin и пароль changeme. Вы можете изменить пароль с помощью Grafana UI или изменив файл user.config.

Из меню Grafana выберите пункт «Источники данных» (Data Sources) и кликните «Добавить источник данных» (Add Data Source). Чтобы добавить контейнеры Prometheus как источник данных, используйте следующие значения:

• Имя: Prometheus
• Тип: Prometheus
• Url: http://prometheus:9090
• Доступ: proxy

Теперь вы можете импортировать шаблоны панели управления из директории Grafana. Из меню Grafana выберите «Панель управления» и нажмите «Импорт».

Панель управления докера

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

• Время работоспособности сервера, процент простоя ЦПУ, количество ядер ЦПУ, доступная память, swap и хранилище.
• График средней нагрузки системы, график выполненных и заблокированных IO-процессов, график прерываний.
• График использования ЦПУ в режимах guest, idle, iowait, irq, nice, softirq, steal, system, user.
• График использования памяти по распределению (использовано, свободно, буферы, кэшировано).
• График использования IO (read Bps, read Bps and IO time).
• График использования сети устройствами (входящий Bps, исходящий Bps).
• Использование Swap и графики активности.

Панель управления контейнеров докера

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

• Общая нагрузка контейнеров ЦПУ, использование памяти и хранилища.
• График используемых контейнеров, график нагрузки системы, график использования IO.
• График использования контейнера ЦПУ.
• График использования памяти контейнера.
• График использования кэшированной памяти.
• График входящего использования сети контейнеров.
• График исходящего использования сети контейнеров.

На панели не представлены контейнеры, являющиеся частью стека мониторинга.

Панель управления мониторинговыми сервисами

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

• Время работы контейнера Prometheus, общее использование памяти мониторингового стека, фрагменты и серии памяти локального хранилища Prometheus.
• График использования контейнера ЦПУ.
• График использования памяти контейнера.
• Графики сохраняемых фрагментов Prometheus и срочности сохранения.
• Графики операций фрагментов Prometheus и продолжительности установления контрольных точек.
• Графики процента использованных шаблонов Prometheus, целевых считываний и продолжительности считывания.
• График запросов Prometheus HTTP.
• График уведомлений Prometheus.

Контролировать использование памяти Prometheus можно присоединением фрагментов памяти локального хранилища. Можно изменять максимальное значение фрагментов в docker-compose.yml. Я настроил значение storage.local.memory-chunks до 100 000. Если вы мониторите 10 контейнеров, то Prometheus будет использовать около 2 Гб RAM.

Определение уведомлений

Я установил три файла конфигурации уведомлений:

• Уведомления сервисов мониторинга targets.rules;
• Уведомления хоста докера hosts.rules;
• Уведомления контейнеров докера containers.rules.

Вы можете изменять правила уведомления и перезагружать их с помощью запроса HTTP POST:

curl -X POST http://:9090/-/reload

Уведомления сервисов мониторинга

Если один из целевых объектов (node-exporter и cAdvisor) не отвечает более 30 секунд, включите уведомление:

ALERT monitor_service_down IF up == 0 FOR 30s LABELS < severity = "critical" >ANNOTATIONS < summary = "Monitor service non-operational", description = "> service is down.", >

Уведомление хоста докера

Если ЦПУ хоста докера находится под высокой нагрузкой более 30 секунд, включите уведомление:

ALERT high_cpu_load IF node_load1 > 1.5 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary = "Server under high load", description = "Docker host is under high load, the avg load 1m is at >. Reported by instance > of job >.", >

Измените пороговое значение нагрузки в соответствии с количеством ядер ЦПУ.

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

ALERT high_memory_load IF (sum(node_memory_MemTotal) - sum(node_memory_MemFree + node_memory_Buffers + node_memory_Cached) ) / sum(node_memory_MemTotal) * 100 > 85 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary = "Server memory is almost full", description = "Docker host memory usage is >%. Reported by instance > of job >.", >

Если хранилище хоста докера заполнено, включите уведомление:

ALERT hight_storage_load IF (node_filesystem_size - node_filesystem_free) / node_filesystem_size * 100 > 85 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary = "Server storage is almost full", description = "Docker host storage usage is >%. Reported by instance > of job >.", >

Уведомления контейнеров докера

Если контейнер не отвечает в течение 30 секунд, включите уведомление

ALERT jenkins_down IF absent(container_memory_usage_bytes) FOR 30s LABELS < severity = "critical" >ANNOTATIONS

Если контейнер использует более 10 % ядер ЦПУ более 30 секунд, включите уведомление:

 ALERT jenkins_high_cpu IF sum(rate(container_cpu_usage_seconds_total[1m])) / count(node_cpu) * 100 > 10 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary= "Jenkins high CPU usage", description= "Jenkins CPU usage is >%." >

Если контейнер использует более 1,2 Гб RAM в течение 30 секунд, включите уведомление:

ALERT jenkins_high_memory IF sum(container_memory_usage_bytes) > 1200000000 FOR 30s LABELS < severity = "warning" >ANNOTATIONS < summary = "Jenkins high memory usage", description = "Jenkins memory consumption is at >.", >

Настройка уведомлений

Сервис AlertManager отвечает за передачу уведомлений сервера Prometheus. AlertManager может посылать уведомления с помощью электронной почты, Pushover, Slack, HipChat и других систем, использующих интерфейс webhook.

Здесь вы можете просмотреть или выключить уведомления: http://:9093 .

Получение уведомлений можно настроить в файле alertmanager/config.yml.

Чтобы получать уведомления через Slack, необходимо настроить интеграцию, выбрав «Исходящие сетевые привязки» на странице приложения.

Скопируйте Slack Webhook URL в поле api_url и определите канал Slack.

route: receiver: 'slack' receivers: - name: 'slack' slack_configs: - send_resolved: true text: ">" username: 'Prometheus' channel: '#' api_url: 'https://hooks.slack.com/services/'

Расширение системы мониторинга

Чтобы покрыть больше одного хоста докера, панель управления Grafana Dockprom можно расширить.. Для контроля большего количества хостов нужно разместить нод-экспортер и контейнер cAdvisor на каждом хосте и указать сервер Prometheus для считывания.

Необходимо активировать стек Prometheus через дата-центр/зону и использовать характеристику интеграции, чтобы объединить все метрики в определенной копии программы Prometheus, которая будет представлять собой общий обзор инфраструктуры. Таким образом, если зона или копия программы Prometheus, задействованная в объединении зон, выйдет из строя, мониторинговая система будет доступна в оставшихся зонах.

Вы также можете сделать Prometheus более отказоустойчивым, запустив два идентичных сервера в каждой зоне. Если несколько серверов будут направлять уведомления в Alertmanager, это не приведет к появлению избыточных данных, так как Alertmanager выполняет дедупликацию.

• Блог компании Слёрм
• Системное администрирование
• Серверное администрирование
• DevOps