Перфоманс Лаб

DevOps
20 марта, 2017

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

Время чтения: 10 мин.
20 марта, 2017
Автор:
Максим Рогожников

Введение в Docker мониторинг

В нашей компании мы часто используем докер, и поэтому решили перевести статью и пролить немного света на тему мониторинга ресурсов.

Мониторинг Docker окружения – непростая задача. Ведь каждый контейнер запускается в одном процессе, имеет свою собственную среду, использует виртуальные сети или имеет различные методы управления системами хранения. Традиционные решения для мониторинга контролируют метрики каждого сервера и приложения, на котором они запущены. Серверы и приложения, работающие на них, как правило, статичны, т.е. работают непрерывно. Docker формирует различные наборы контейнеров и может запускать множество приложений, совместно использующих ресурсы одного или нескольких хостов. Docker под силу запускать тысячи «временных» контейнеров (например, для пакетных заданий), параллельно осуществляя работу набора постоянных служб в штатном режиме.

Традиционные инструменты мониторинга не используются для динамических сред и не подходят для таких задач. С другой стороны, некоторые современные системы мониторинга (например, SPM от Sematex) были созданы для динамических систем и поддерживают средства для мониторинга и отчётов Docker «из коробки». Кроме того, совместное использование ресурсов контейнера предусматривает строгое соблюдение ограничений на использование ресурсов, которое необходимо контролировать.

Для того чтобы внести соответствующие изменения в квоты ресурсов, необходимо видеть каких ограничений достиг контейнер сейчас, и какие ошибки это вызывает (может вызвать). Мы рекомендуем использовать оповещения в соответствии с настроенными лимитами. Таким образом вы можете установить лимиты или настроить использование ресурсов ещё до того, как появятся ошибки.

Docker контейнеры ≠ VMs или серверы. Забудьте про старый «дедушкин мониторинг» — используйте мониторинг, предназначенный для Docker.

Мониторинг SPM

Все изображения в этой статье из инструмента мониторинга SPM производителя Sematext и его интеграции для мониторинга Docker 

Контролируйте ресурсы вашей Docker машины

Процессор

Информация об утилизации CPU хостов помогает оптимизировать использование ресурсов Docker машины. Использование CPU может быть уменьшено для того, чтобы избежать ситуации, когда один контейнер занимает все процессорное время, замедляя работу других контейнеров. Уменьшение процессорного времени является хорошим способом обеспечить минимум вычислительных мощностей для всех сервисов — это как старые добрые уровни в Unix/Linux.

Даже когда использование ресурсов оптимизировано, все же могут возникать ситуации, когда загрузка процессора близка к максимуму. Оповещения имеют смысл только в случае, когда утилизация процессора падает (происходит сбой в работе службы) или в течение длительного периода увеличивается до некоторого максимального предела (например, 85%).

Сверхутилизация Docker машины является признаком неисправности.

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

Память

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

Регулировка мощности новых узлов кластера в соответствии с утилизацией приложений Docker может помочь оптимизировать использование ресурсов.

Linux не перерасходует оперативную память. Однако когда буфер кэшируются, памяти не остается, а значит необходимо расширить кластер.

Дисковое пространство

Образы Docker и контейнеры потребляют дополнительное дисковое пространство. Например, образ приложения может включать в себя операционную систему Linux и иметь размер 150-700 Мб в зависимости от размера базового образа и установленных инструментов в контейнере. Постоянные Docker тома также потребляют дисковое пространство на хосте. По нашему опыту, наблюдение за дисковым пространством и применение инструментов очистки диска обязательно при постоянной эксплуатации Docker машины.

Хорошие дети убирают в комнате.

Хорошие Docker OPS убирают со своих дисков неиспользуемые контейнеры и образы.

Использование дискового пространства на Docker хосте

Использование дискового пространства на Docker хосте

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

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

Общее количество запущенных контейнеров

Текущее и накопленное количество контейнеров является интересной метрикой по многим причинам. Очень удобно во время развертывания и обновлений проверять, что все работает, как и раньше. Когда кластер-менеджеры, такие как Docker Swarm, Mesos, Kubernetes, CoreOS/Fleet, автоматически планируют запуск контейнера на разных компьютерах, используются разные политики планирования. Количество контейнеров, работающих на каждой машине может помочь проверить активированные политики планирования на ней. Гистограмма ниже показывает количество контейнеров на каждой машине и общее число контейнеров, демонстрируя как кластер-менеджер распределил контейнеры по доступным машинам.

Количество Docker контейнеров с течением времени

Количество контейнеров с течением времени

Контроль нештатного поведения, в отличие от оповещений на основе пороговых значений, позволит «поймать» внезапные миграции контейнера, что может являться предвестником серьёзного сбоя.

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

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

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

Метрики Docker контейнеров

Метрики контейнеров в основном те же показатели, что и доступные для каждого процесса Linux параметры, но они включают в себя ограничения, установленные с помощью контрольных групп в Docker, такие как ограничение для использования CPU или памяти. Обратите внимание, что сложные решения для мониторинга Docker, такие как SPM, способны агрегировать метрики контейнера на разных уровнях Docker хостов/узлов кластера, названиях или ID образов и название или ID контейнера.

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

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

Контейнер CPU — 100% утилизация CPU

Одним из самых основных метрик является информация о том, сколько CPU потребляется всеми контейнерами вместе, образами, или отдельными контейнерами. Большим преимуществом использования Docker является возможность ограничить загрузку процессора по контейнерам. Конечно, вы не можете настроить и оптимизировать что-то, если вы не измеряете это, поэтому мониторинг таких ограничений является необходимым условием. Наблюдая за общими метриками загрузки CPU контейнерами, стало понятно, что CPU был утилизирован почти на 100%, поэтому необходимо настроить параметры для совместного использования процессоров в Docker.

Обратите внимание, что CPU имеет высокую утилизацию только тогда, когда использование хост-процессора максимизировано. До тех пор, пока у хоста есть запасные мощности CPU, доступные для Docker, он не уменьшит использование процессора для контейнера. Таким образом, повышенная утилизация CPU или нулевая является пиком этой метрики, и как правило, это является хорошим показателем одного или нескольких контейнеров, требующих большей мощности процессора, чем хост может обеспечить.

Использование CPU, контейнер использовал все процессорное время

Использование CPU, контейнер использовал все процессорное время

На следующем снимке показаны контейнеры с квотой 5% CPU, запущенные с помощью команды docker run -cpu-quota=5000 nginx. Отчётливо видно, как утилизация CPU растет, пока не достигнет порога примерно в 5%.

Использование Docker CPU контейнером

Использование CPU контейнером, и утилизация процессорного времени CPU при квоте 5%

Контейнер памяти — счетчик сбоев

Установка лимитов памяти для контейнеров — хорошая практика. Лимиты памяти помогают избежать проблем, когда контейнер, которому не хватает памяти, забирает всю доступную память из системы, обрекая «голодать» все другие контейнеры на этом сервере. Ограничения на ресурсы могут быть определены в команде запуска Docker. Например, -m 300M устанавливает верхний предел памяти для контейнера на уровне 300 МБ. Docker устанавливает метрику контейнера — счетчик сбоев памяти.

Этот счетчик увеличивается каждый раз, когда не удаётся выполнить распределение памяти — то есть, каждый раз, когда заранее установленное ограничение памяти достигает предела. Таким образом, пики в этой метрике указывают на один или несколько контейнеров, которым требуется больше памяти, чем было выделено изначально. Если процесс в контейнере завершается из-за этой ошибки, мы также можем увидеть событие нехватки памяти в Docker.

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

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

Использование памяти контейнером

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

Оптимальный подход в данном случае — настройка памяти в несколько итераций:

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

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

Использование памяти контейнером

Использование памяти контейнером

Swap в контейнерах

Как и в памяти любого другого процесса, память какого-либо контейнера может быть выгружена на диск. Для приложений, таких как Elasticsearch или Solr, часто приходилось находить инструкции, чтобы отключить swap на Linux машине, но при запуске таких приложений на Docker это может быть сделано достаточно просто, необходимо добавить в команду запуска -memory-swap=-1.

Как быстро отключить Swapping в Docker – контейнере?
Используйте команду -memory-swap=-1

Контейнер swap, страницы памяти, и скорость подкачки

Контейнер swap, страницы памяти, и скорость подкачки

Контейнер дискового ввода/вывода

В Docker несколько приложений одновременно могут использовать одни и те же ресурсы. Таким образом, наблюдения за дисковой системой ввода/вывода помогают определить пределы для конкретных приложений и обеспечивают более высокую пропускную способность для критически важных приложений, таких как хранилища данных или веб-серверы. Например, утилизация дисковых операций ввода/вывода для пакетных операций достигает 100%, и в этом случае команда docker run -it -device-write-bps /dev/sda:1mb mybatchjob будет актуальна: она ограничит максимальную скорость записи на диск до 1 МБ/с.

Контейнер дискового ввода/вывода

Контейнер дискового ввода/вывода

Чтобы ограничить контейнер Docker от потребления всего вашего диска необходимо использовать команду -device-write-bps /dev/sda:1mb

Сетевые метрики контейнера

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

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

Мониторинг сетевого трафика

Мониторинг сетевого трафика

Заключение

Теперь у вас есть главные показатели работы контейнеров Docker, на которых стоит сфокусировать внимание. Также не стоит забывать, что проведенный должным образом анализ поможет избежать многих трудностей при внедрении Docker на таких платформах как Docker Swarm, Docker Cloud, Docker Datacenter или любой другой платформе, поддерживающей контейнеры Docker.

Комментарии переводчика

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

  • Процент свободного дискового пространства — обратите внимание на то, что если его значение упало ниже 15 процентов, то возникает опасность нехватки свободного места для хранения важных файлов операционной системы. Одно из очевидных решений в этом случае состоит в добавлении места на диске.
  • Процент использования памяти — если это значение превышает 80 процентов, это указывает на недостаточный объем памяти. Очевидным решением в этом случае является добавление памяти.
  • Процент загруженности процессора — если загруженность превышает 85 процентов, процессор перегружен, и серверу, возможно, требуется более быстрый процессор и пора задуматься о масштабировании или оптимизации производительности.
  • Загрузка сетевого интерфейса — сеть перегружена, если выясняется, что используется более 70 процентов скорости сетевого канала. В случае сетевой карты со скоростью обмена 100 Мбит/с потребляемый траффик составляет 8,7 МБ/с (100 Мбит/с = 100 000 кбит/с = 12,5 МБ/с* 70 процентов). В подобной ситуации, возможно, придется установить более быструю сетевую карту или провести сегментирование сети.

Оригинал статьи http://govit.sys-con.com/node/3880796.

Чтобы узнать подробнее о наших услугах