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

Мониторинг 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

По мере проникновения контейнеров в продуктовые среды у системных администраторов и разработчиков возникает необходимость мониторинга текущих рабочих показателей контейнеров и сбора метрик для анализа. В этой статье вы сможете узнать, какие механизмы для решения этой задачи могут быть использованы при использовании 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 . После очистки можно безопасно завершить процесс сбора статистики.

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

Мониторинг Docker контейнеров c помощью Zabbix на Ubuntu 20.04

Zabbix это система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования. С его помощью можно быстро реагировать на внештатные ситуации, ошибки оборудования и серверов и предупреждать возможные проблемы с нагрузкой.

Docker, в свою очередь, это пожалуй самый известный инструмент для работы с контейнерами. Он позволяет упаковать приложение или сервис, со всем его окружением и зависимостями, в контейнер, который может быть развернут на любой системе, на которой запускается Docker. Контейнеры в Docker это альтернатива аппаратной виртуализации, например такой как KVM, если Вы не планируете использовать различные ОС на виртуальных машинах. Docker позволяет запускать приложения в изолированном окружении с экономичным использованием ресурсов.

В данном руководстве мы настроим мониторинг состояния контейнеров через замечательную систему мониторинга Zabbix. Для этого нам потребуется два выделенных сервера с операционной системой Ubuntu 20.04 LTS. Первый сервер будет выступать в роли сервера Zabbix Server, который будет собирать метрики, строить графики и отправлять уведомления при наступлении каких-то внештатных ситуаций на серверах и контейнерах которые он будет отслеживать. Второй сервер у нас будет в роли сервера с установленным Docker и развернутыми контейнерами на нём. На этом сервере будет запущен сервис Zabbix Agent который будет собирать метрики и отправлять их на Zabbix Server, на нём мы тоже будем использовать Ubuntu 20.04 LTS.

Настройка сервера для запуска Zabbix Server с веб-интерфейсом

Откройте терминал и подключитесь к серверу на котором будет установлен Zabbix Server. Для начала обновим список пакетов операционной системы, введя команду:

sudo apt update

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

sudo apt upgrade

Теперь мы имеем обновлённую ОС со всем актуальным ПО и можем смело продолжать дальше.

Для запуска Zabbix Server нам понадобится установить на сервер стек LEMP, в него входят ОС Linux, веб-сервер Nginx, БД MySQL, и скриптовый язык PHP который применяется для разработки веб-приложений.

ОС Linux у нас уже установлена в лице Ubuntu 20.04, поэтому начнём с установки Nginx, для этого требуется ввести команду:

sudo apt install nginx

После завершения установки, Nginx автоматически запустится и мы сможем проверить его работу введя в адресной строке браузера http://IP_ВАШЕГО_СЕРВЕРА. Если всё прошло как надо, то вы увидите страницу «Welcome to nginx!».

По умолчанию в Ubuntu 20.04 выключен брандмауэр (фаервол), поэтому мы опускаем его настройку в этом руководстве, но если вы активировали брандмауэр то необходимо будет разрешить подключения по протоколу http/https к серверу.

Следующим шагом мы установим систему управления базами данных MySQL. MySQL — это распространенная система управления базами данных, часто используемая с языком PHP. Для её установки введем команду:

sudo apt install mysql-server

Для подтверждения нажмем Y и установка начнётся. По завершению установки сервер MySQL будет запущен и нам потребуется запустить специальный скрипт, этот скрипт удалит некоторые небезопасные настройки по умолчанию и заблокирует неавторизованный доступ к вашей системе баз данных. Для этого необходимо ввести в терминале команду:

sudo mysql_secure_installation

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

Следующим шагом нас просят установить пароль для пользователя root, подразумевается администратор именно MySQL, а не системный суперпользователь root. Введем необходимый пароль два раза. Рекомендуется использовать хороший стойкий пароль, с разными символами, цифрами и спец знаками.

Далее скрипт спросит нас, хотим ли мы удалить пользователя anonymous. По умолчанию, в начальной установке MySQL, есть так называемый анонимный пользователь, что позволяет любому пользователю войти в MySQL без наличия учетной записи. Это предназначено только для тестирования и мы должны деактивировать это перед началом использования MySQL. Вводим Y чтобы продолжить.

Далее скрипт предлагает выключить возможность доступа пользователя root с удалённого компьютера, соответственно доступ пользователю root будет разрешен только с локального хоста, что положительно скажется на безопасности, поскольку пароль MySQL пользователя root не будет передаваться по сети. Введите Y чтобы продолжить.

Следующим шагом скрипт предлагает удалить тестовую базу данных с именем test, которая создана по умолчанию. Как правило она не используется — поэтому согласимся на её удаление. Введите Y чтобы продолжить.

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

Первичная настройка MySQL сервера завершена. Давайте теперь проверим его работу. Попробуем войти в консоль MySQL, для этого необходимо ввести в терминале команду:

sudo mysql

Чтобы вывести список существующих баз данных введем show databases; , не забудьте ввести точку с запятой после команды.

mysql> show databases;

Как вы можете видеть, в нашем сервере баз данных MySQL создано 4 базы данных на данный момент. То есть всё работает как надо и мы можем выйти из консоли MySQL. Для выхода введите exit;

mysql> exit;

Теперь ваш сервер баз данных MySQL установлен и защищен. Далее мы установим PHP, последний компонент в стеке LEMP.

LEMP подразумевает под собой отсутствие веб-сервера Apache на сервере. В качестве обработчика PHP, который будет генерировать динамическое содержимое страниц, мы будем использовать php-fpm, которому в свою очередь, веб-сервер Nginx будет передавать запросы для обработки файлов интерпретатором PHP.

Установим php-fpm и php-mysql, который обеспечит возможность работы PHP c базами данных MySQL. Для установки введем команду:

sudo apt install php-fpm php-mysql

Как и в предыдущих случаях вводим Y чтобы начать установку.

Установка Nginx, MySQL и PHP завершена. Приступаем к установке Zabbix Server. Zabbix сразу доступен в репозиториях Ubuntu, но в устаревшей версии, поэтому мы будем использовать официальный репозиторий Zabbix для установки последней стабильной версии. Скачайте и установите пакет конфигурации репозитория, введя команду:

wget https://repo.zabbix.com/zabbix/5.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.0-1+focal_all.deb

Теперь установим данный deb пакет для активации репозитория в нашей операционной системе:

sudo dpkg -i zabbix-release_5.0-1+focal_all.deb

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

sudo apt update

Следующим шагом установим Zabbix сервер, веб-интерфейс и агент на этот сервер:

sudo apt install zabbix-server-mysql zabbix-frontend-php zabbix-nginx-conf zabbix-agent

Далее мы создадим базу данных в сервере MySQL, которую Zabbix сервер будет использовать для хранения данных и метрик получаемых от своих агентов. Агентами в терминологии Zabbix называются сервера или другие устройства, которые подключены к мониторингу Zabbix.

Войдем в консоль MySQL, введя команду:

sudo mysql

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

mysql> create database zabbix character set utf8 collate utf8_bin; mysql> create user zabbix@localhost identified by 'password'; mysql> grant all privileges on zabbix.* to zabbix@localhost; mysql> quit;

Теперь у нас есть база данных для Zabbix Server, но на данный момент она пустая, без начальных таблиц и данных в ней, которые необходимы для начала работы Zabbix. Импортируем начальную схему и данные в неё, для этого необходимо ввести команду

zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix

Будет необходимо ввести пароль MySQL пользователя zabbix, который мы назначили выше, во время создания базы данных. Импорт может занять определенное время, которое зависит от производительности вашего сервера.

Следующим шагом нам необходимо настроить Zabbix сервер на использование этой базы данных, чтобы он сохранял и читал данные из неё. Для этого откроем конфигурационный файл /etc/zabbix/zabbix_server.conf.

sudo nano /etc/zabbix/zabbix_server.conf

Надо найти строчку начинающеюся с # DBPassword=

Убрать решетку (символ комментария) и ввести пароль для доступа к базе данных:

Сохраните файл и выйдите из редактора. Если вы использовали nano для редактирования файла, вы можете сделать это, нажав CTRL + X, Y, затем ENTER.

Мы настроили сервер Zabbix для подключения к нашей базе данных MySQL. Теперь необходимо настроить веб-сервер Nginx для обслуживания веб-интерфейса Zabbix. Откроем файл /etc/zabbix/nginx.conf который был создан после установки пакета zabbix-nginx-conf, в нём описывается так называемый виртуал-хост веб-интерфейса Zabbix.

sudo nano /etc/zabbix/nginx.conf

Необходимо убрать символ комментария перед директивой listen и прописать имя сервера в директиву server_name. Остальные директивы в данном файле оставляем как есть, благо создатели Zabbix уже настроили там всё как требуется.

Сохраняем файл /etc/zabbix/nginx.conf. В случае с nano для сохранения и выхода из редактора надо нажать CTRL + X, Y, затем ENTER.

Теперь проверим, нет ли в нашей конфигурации Nginx ошибок, для этого в терминале введём:

sudo nginx -t

Система сообщит что ошибок нет и всё в порядке, после чего мы перезапустим веб-сервер Nginx для применения изменений которые мы внесли. Для этого необходимо ввести команду:

sudo systemctl restart nginx

После этого необходимо настроить правильный часовой пояс в конфигурации php-fpm пула для нашего Zabbix сервера. Для этого отредактируем файл /etc/zabbix/php-fpm.conf, требуется раскомментировать строку ; php_value[date.timezone] = Europe/Riga и указать свой часовой пояс. В нашем случае это Europe/Kiev.

sudo nano /etc/zabbix/php-fpm.conf

Сохраним файл и перезапустим php-fpm для применения изменений.

sudo systemctl restart php7.4-fpm

Следующим шагом нам необходимо добавить все необходимые службы в автозагрузку нашей операционной системы Ubuntu, для этого введём с терминале:

sudo systemctl enable zabbix-server zabbix-agent nginx php7.4-fpm

И теперь запустим все службы необходимые для работы Zabbix сервера:

sudo systemctl start zabbix-server zabbix-agent nginx php7.4-fpm

Сервер Zabbix настроен и подключен к базе данных MySQL. Приступаем к настройке веб-интерфейса Zabbix. Введите в стоку адреса вашего браузера http://ИМЯ_ВАШЕГО_СЕРВЕРА (то самое имя которые устанавливали в настройке Nginx в директиве server_name)

Веб-интерфейс Zabbix позволяет просматривать отчеты и добавлять узлы для мониторинга, но для его использования требуется начальная настройка. На первом экране вы увидите приветственное сообщение. Нажмите кнопку «Next step» для продолжения.

На следующей странице перечислены все необходимые условия для запуска Zabbix. Убедитесь что в последней колонке OK и можно продолжать нажав Next step.

На следующей странице необходимо ввести информацию для подключения к базе данных. Данные настройки нужны для работы веб-интерфейса Zabbix, поскольку конфигурацию Zabbix сервера мы уже провели ранее, введем пароль для доступа к базе данных MySQL и нажмем Next step.

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

И на завершающем экране предлагается проверить всё настройки, перед финальным шагом. Проверим и нажмем Next step.

Установка веб-интерфейса Zabbix завершена. Нажмите Finish и перейдите к окну входа. Имя пользователя и пароль по умолчанию Admin и zabbix.

Установка Docker

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

Как и со случаем сервера, где располагается Zabbix сервер, на сервере где у нас будут Docker контейнеры мы тоже для начала обновим список пакетов, а затем и сами пакеты, для этого требуется ввести две уже известные нам команды.

sudo apt update sudo apt upgrade

Docker есть в стандартных репозиториях Ubuntu 20.04 LTS Focal Fossa, но как и в случае с Zabbix сервером, в стандартных репозиториях не самые свежие версии. Установим Docker из его официальных репозиториев, где всегда доступна актуальная версия.

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

sudo apt install apt-transport-https ca-certificates curl software-properties-common gnupg lsb-release

После чего добавим GPG ключ официального репозитория Docker в нашу систему для этого вводим в терминале команду:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

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

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"

Теперь установим сам Docker. Это выполняется простой командой:

sudo apt install docker-ce

Соглашаемся на установку, введя Y на запрос в терминале.

Docker установлен. Для проверки, вводим в терминале команду sudo docker version, которая отобразит установленную версию Docker и другую системную информацию.

sudo docker version

Проверим запущена ли системная служба Docker, для этого введем в окне терминала команду:

sudo systemctl status docker

Вывод команды говорит нам о том что всё в порядке, сервис запущен и работает.

Установка Zabbix Agent на сервер с Docker

Zabbix Agent это небольшая программа которая запускается на сервере за которым необходимо осуществлять мониторинг. На данный момент существуют две версии, Zabbix Agent и Zabbix Agent 2. Мы будем рассматривать именно Zabbix Agent 2, поскольку именно в этой версии добавлена возможность мониторинга Docker и контейнеров в нём.

Для начала скачаем deb пакет который добавит официальный репозиторий в нашу систему, а затем установим этот пакет.

wget https://repo.zabbix.com/zabbix/5.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.0-1+focal_all.deb sudo dpkg -i zabbix-release_5.0-1+focal_all.deb

После добавления нового репозитория необходимо обновить базу пакетов, для этого введём команду sudo apt update:

sudo apt update

После чего мы можем установить сам Zabbix Agent 2.

sudo apt install zabbix-agent2

После установки агента нам необходимо внести изменения в файл конфигурации, чтобы обеспечить соединение между Zabbix Agent и Zabbix Server. Откроем для редактирования файл конфигурации агента:

sudo nano /etc/zabbix/zabbix_agent2.conf

По умолчанию Zabbix Agent настроен на работу с Zabbix Server, которые расположены на одном сервере. Но у нас Zabbix Server находится на отдельном сервере и нам надо изменить настройки Zabbix Agent, чтобы он работал с удалённым сервером Zabbix Server. Для этого в файле /etc/zabbix/zabbix_agent2.conf найдём строчку начинающеюся с Server и изменим значение с 127.0.0.1 на IP адрес или имя нашего Zabbix Server, в нашем примере это zabbix-server.dedicated.freehost.com.ua.

Обычно Zabbix Server сам подключается для сбора данных к Zabbix Agent, но в некоторым случаях и агент может подключаться к серверу, для этого необходимо ввести адрес сервера в директиву ServerActive.
Также необходимо ввести уникальное имя для агента, это имя будет отображаться в веб-интерфейсе. Для этого введите имя в директиву Hostname.

На этом редактирование файла конфигурации Zabbix Agent завершено, сохраним и выйдем из редактора.

Далее, для того чтобы Zabbix Agent мог осуществлять мониторинг Docker необходимо добавить системного пользователя zabbix в группу docker. Для этого введём команду:

sudo usermod -aG docker zabbix

Теперь мы можем запустить службу Zabbix Agent и добавить её в автозагрузку нашей ОС, а так же проверим запустилась ли служба Zabbix Agent. Для этого введём команды:

sudo systemctl start zabbix-agent2 sudo systemctl enable zabbix-agent2 sudo systemctl status zabbix-agent2

Вывод команды сообщает нам что сервис Zabbix Agent запущен и работает.

На этом установка и настройка Zabbix Agent закончена. Мы подготовили наш сервер с Docker к мониторингу через Zabbix Server. Далее нам потребуется подключить этот сервер с Docker к мониторингу, для этого мы войдем в веб-интерфейс нашего Zabbix Server, подключим сервер с Docker и активируем шаблон Docker.

Добавляем новый узел мониторинга в Zabbix Server

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

Войдем в веб-интерфейс Zabbix Server, используя адрес или имя, которые мы назначили ему ранее, во время его установки и настройки. В нашем случае, для примера, используется адрес http://zabbix-server.dedicated.freehost.com.ua/. Логин и пароль мы не меняли, поэтому используем установленные по умолчанию, логин Admin, пароль zabbix.

Для начала, давайте переключим веб-интерфейс Zabbix на русский язык. Для этого перейдём в раздел Administration — Users

И нажмём на пользователя Admin:

Но тут нас ожидает проблема, нет возможности выбрать любой язык кроме Английского, и сообщение об ошибке «You are not able to choose some of the languages, because locales for them are not installed on the web server». Давайте исправим это. Установим необходимые локализации на наш сервер Zabbix.

Первой командой мы посмотрим какие локали (языковые настройки) установлены на сервере.

sudo locale -a

Затем выведем список доступных локалей для русского и украинского языков.

cat /usr/share/i18n/SUPPORTED | grep ru_ cat /usr/share/i18n/SUPPORTED | grep uk_

Для установки необходимых локалей введем:

sudo locale-gen ru_RU sudo locale-gen ru_RU.UTF-8 sudo locale-gen uk_UA sudo locale-gen uk_UA.UTF-8

После чего вводим команду:

sudo dpkg-reconfigure locales

В открывшемся окне нажмём ОК

Далее, система спросит нас, какую из локалей необходимо установить в качестве системной — выберем en_US.UTF-8 и нажмем ОК.

Будут переконфигурирование локали на сервере, после чего мы сможем выбрать необходимый язык в настройках веб-интерфейса Zabbix. Перезапустим nginx и php-fpm чтобы эти демоны «увидели» новые локали.

sudo systemctl restart nginx sudo systemctl restart php7.4-fpm

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

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

Для добавления нового узла в мониторинг, в уже русифицированном веб-интерфейсе Zabbix, необходимо нажать «Настройка» — «Узлы сети» и выбрать в правом верхнем углу «Создать узел сети».

Ввести имя узла, добавить его в новую группу Docker Servers, и ввести DNS имя по которому Zabbix Server будет подключаться в агенту.

Далее перейдем на вкладку «Шаблоны» на этой странице, в пункте «Присоединение новых шаблонов» впишем «Template App Docker» и «Template OS Linux by Zabbix agent», таким образом мы применим к данному узлу мониторинга два шаблона, шаблон Docker и общий шаблон ОС Linux, которые будут включать в себя метрики, триггеры и графики необходимые для мониторинга Docker и системы в целом на этом выделенном сервере.

Далее нажмём кнопку «Добавить» для добавления этого узла в наш мониторинг. После добавления нового узла в Zabbix необходимо подождать несколько минут, для того чтобы Zabbix Server подключился к агенту на удалённом сервере и получил все метрики узла.

Затем, в меню слева перейдём в раздел «Мониторинг» — «Узлы сети», где мы увидим наш только что добавленный сервер с зеленой иконкой ZBX, это значит что узел добавлен успешно и Zabbix Server подключился и получает данные от агента на этом узле.

Замечательно! Теперь Zabbix Server следит за вашим сервером с Docker. На следующем этапе мы запустим тестовый контейнер и посмотрим какие метрики может собирать Zabbix с этого контейнера.

Получение метрик и данных из Docker контейнера

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

В консоли сервера с Docker введите команду:

sudo docker run --name freehost_alpine_container -it alpine ash

Данная команда скачает образ Alpine Linux из Docker Hub и моментально запустит его, присвоив ему имя freehost_alpine_container, после чего запустит нам терминал той системы, которая запущена в контейнере.

Оставим пока этот контейнер работающим и перейдём в веб-интерфейс Zabbix сервера. Буквально через несколько минут после запуска контейнера, Zabbix автоматически найдет новый контейнер на сервере и добавит соответствующие метрики для него.

Кликнем на меню слева и перейдём в раздел «Мониторинг» — «Узлы сети» и выберем Графики в строке с нашим Docker сервером.

Мы увидим, что Zabbix уже «подхватил» наш контейнер с именем freehost_alpine_container, и собирает данные из него. На скриншоте два графика — использование процессора и памяти в данном контейнере.

Если пролистать страницу ниже, то можно наблюдать огромное количество графиков и метрик. На следующем скриншоте графики использования сети для нашего контейнера с именем freehost_alpine_container.

Для того, чтобы увидеть список всех метрик получаемых Zabbix из контейнера в Docker снова перейдём в раздел «Мониторинг» — «Узлы сети» и выберем «Последние данные» в строке с нашим Docker сервером.

Перелистнем на страницу 2 данного листинга и увидим 37 метрик которые Zabbix получает о контейнере. Чтобы просмотреть историю изменений для конкретной метрики, нажмите График (для числовых значений) или История (для текстовых значений).

Итак, мы запустили тестовый контейнер в Docker и просмотрели его метрики в веб-интерфейсе Zabbix.

Триггеры и уведомления в Zabbix

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

Для симуляции сбоя контейнера откройте терминал Docker сервера, где запущен наш контейнер freehost_alpine_container и введите в терминале контейнера команду:

exit 1

С помощью этой команды мы завершим работу контейнера с кодом ошибки 1, который передастся в Docker и запишется в метаданные нашего контейнера.

Чтобы увидеть оповещение, нажмите «Мониторинг», а затем «Проблемы» в левой навигационной панели веб-интерфейса Zabbix. Через несколько секунд отобразится уведомление «Container has been stopped with error code»

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

Теперь вы можете запустить контейнер снова и уведомление в Zabbix исчезнет автоматически. Чтобы запустить контейнер повторно выполните команду на сервере c Docker:

sudo docker start freehost_alpine_container

Zabbix определит что контейнер снова в строю, и состояние триггера изменится на «Решено»

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

Заключение

В данной статье мы с вами настроили два сервера, один с Zabbix Server и веб-интерфейсом, и второй сервер с Docker и Zabbix Agent, для мониторинга состояния контейнеров в системе мониторинга Zabbix. Мониторинг предназначен предупреждать вас о проблемах, и вы сможете анализировать процессы и проблемы происходящие в вашем Docker контейнере. Zabbix это очень мощный инструмент, с помощью которого вы можете контролировать не только контейнеры, но и серверы в целом, базы данных, веб-приложения и многое другое.

Вероятно Вас заинтересует статья “Как мониторить сервер с помощью Zabbix”
Подписывайтесь на наш телеграмм — канал t.me/freehostua, чтобы быть в курсе новых полезных материалов. Смотрите наш Youtube канал на youtube.com/freehostua.

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

Я искал 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