Источник: Технологический институт CreditEase.

На рынке существует множество типов технологий виртуализации, таких как moby (docker), LXC, RKT и так далее. Принося преимущества удобного развертывания приложений и полного использования ресурсов, мониторинг соответствующего контейнера и его внутреннего процесса приложения стал новой ситуацией, с которой неизбежно сталкивается эксплуатационный и обслуживающий персонал. Исходя из основных принципов технологии виртуализации и характеристик ядра операционной системы Linux, UAV.Container получает данные мониторинга контейнеров-контейнеров и внутренних процессов в различных измерениях, так что будь то виртуальная машина или персонал, обслуживающий и обслуживающий машину, или производственный и обслуживающий персонал, могут быть получены соответствующие размеры мониторинга.

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

Ниже мы возьмем в качестве примера технологию docker, другие технологии виртуализации аналогичны.

1. Container ID

ID контейнера — это уникальный идентификатор контейнера. С точки зрения мониторинга контейнеров нам нужно иметь возможность получить, в каком контейнере запущен процесс. На уровне операционной системы может быть отражено состояние монтирования cgroup процесса. Как показано на рисунке, мы запускаем процесс Tomcat внутри контейнера с идентификатором 3411554ff684.

Поскольку пространство имен pid контейнера является подпространством имен пространства имен pid операционной системы, процесс также должен иметь соответствующий pid на уровне операционной системы.Используйте команду docker top для проверки:

Номер процесса в контейнере на узле — 1848. Затем перейдите в /proc/1848/cgroup, чтобы увидеть монтирование cgroup процесса.

Файл cgroup четко показывает технологию виртуализации, которая реализует контейнер, идентификатор контейнера и путь подключения ресурсов контейнера. Сравните отображаемый здесь идентификатор контейнера, который точно совпадает с идентификатором при создании контейнера. Это также подтверждает, что идентификатор контейнера может быть получен путем сканирования информации cgroup хост-процесса. Это связывает pid с идентификатором контейнера.

2. CPU

Хотя CGRoup контролирует использование ЦП всеми процессами в этой CGROUP, с точки зрения операционной системы, независимо от того, связан ли процесс с подгруппой, он по-прежнему является ЦП хоста-совместителя. Поэтому следите за индикатором мониторинга ЦП процесса в процессе процесса.

Часто используемая команда мониторинга ЦП в Linux — это top. Принцип верхнего мониторинга ЦП состоит в том, чтобы получить кумулятивное общее время countAll1 и общее время занятости countBusy1 ЦП в момент времени1 в момент времени1, а затем получить общее время ЦП countAll2 и общее время занятости countBusy2 в момент времени2 и, наконец, вычесть разница времени от значения занятости.Разница общего времени определяет использование ЦП машины в период времени от time1 до time2. То есть:

Использование ЦП (%) = (countBusy2 - countBusy1)/(countAll2 - countAll1) * 100

Аналогично для процесса общее время занятости countProcBusy1 и countProcBusy2 каждого процесса получается дважды, а также получается использование ЦП процессом:

Использование ЦП процессом (%) = (countProcBusy2 - countProcBusy1)/(countProcAll2 - countProcAll1)*100

Общий квант процессорного времени хоста с момента запуска можно получить из /proc/stat:

Первая строка — это общее использование ЦП, значение конкретных параметров:

Итак, выберите текущее время1, через 3 секунды время2, countAll = user + nice + system + idle + iowait + irq + softirq +stealstolean + guest + guest_nice. countBusy — это countAll за вычетом значения простоя, так что все требуемые значения первой формулы выше все на месте и могут быть вычислены напрямую.

Вторая и третья строки — это использование каждого логического ЦП.Обратите внимание, что здесь два логических ЦП.Количество логических ядер ЦП связано с режимами отображения ЦП irix и solaris.

Далее следует расчет countProcBusy.Квант процессорного времени процесса находится в /proc/$pid/stat, как показано на рисунке:

Этот файл содержит много информации о процессе. 14-й, 15-й, 16-й и 17-й параметры относятся к процессору.

Итак, countProcBusy = utime + stime + cutime + cstime, это значение включает в себя процессорное время всех его потоков. И countProcAll2-countProcAll1=3s, через countProcBusy и countProcAll в два момента можно получить использование ЦП процессом.

Следует отметить два момента:

1).jiffies на самом деле относится к общему количеству ударов, используемых часами ядра, поэтому здесь jiffies необходимо преобразовать в секунды, чтобы применить приведенную выше формулу деления.

2) Мы только что говорили о режимах отображения ЦП irix и solaris.Проще говоря, режим irix означает, что машина имеет N логических ЦП, а верхний предел отображения ЦП равен N*100%.Режим Solaris означает, что независимо от сколько логических ЦП имеет машина, верхний предел отображения ЦП составляет 100%, а /proc/$pid/stat показывает, что вычисляется все логическое время ЦП, поэтому два метода отображения означают, что метод расчета немного отличается, а Результат режима Solaris должен быть основан на приведенной выше формуле использования ЦП процесса Разделить на количество логических ядер.

3. Память

Мониторинг памяти процесса имеет два измерения данных: одно — это размер физической памяти, а другое — размер процента использования памяти процессом.

Использование памяти процесса (%) = использование физической памяти процесса / общая память хоста * 100

Как и в случае с ЦП, файл /proc/$pid/status записывает использование физической памяти процессом, где VmRSS — это фактический размер физической памяти, занимаемой процессом в данный момент.

Использование памяти машины записывается в файл /proc/meminfo.Этот файл очень длинный.Перехватите его часть и покажите.MemTotal — это общий объем памяти хоста:

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

4. Дисковый ввод-вывод

Сбор операций ввода-вывода на диск также очень прост. /proc/$pid/io помог нам записать ситуацию с вводом-выводом этого процесса, но, как и в случае с ЦП, файл ввода-вывода хранит общее количество операций ввода-вывода процесса с момента запуска до настоящего времени, а затем :

Дисковый ввод/вывод (байт/сек) = (ввод/вывод в момент времени2 – ввод/вывод в момент времени1) / (время2 – время1)

Среди них read_bytes и write_bytes — количество прочитанных байтов и количество записанных байтов с момента запуска процесса, соответственно, и принимают значения 2 раза соответственно.Согласно приведенной выше формуле, дисковый ввод-вывод процесса равен полученный.

5. Номер порта и количество соединений

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

/Proc/$PID/NET/TCP (TCP6, UDP, UDP6) сделал соответствующую историю номера порта и соединений. Эти форматы файлов похожи, и используется TCP6.

Объясните несколько ключевых ключей:

Поскольку st = 0A представляет прослушивание, из него выбираются данные st = 0A и извлекается соответствующий номер инода, где номер инода — это номер сокета, и вопрос преобразуется в вопрос о том, существует ли еще процесс, представленный сокетом. по номеру розетки. В /proc/$pid/fd есть все fd (файловый дескриптор) процесса, для примера возьмем секцию.

Мягкая цепочка за каждым файловым дескриптором на самом деле является открытым файлом.Начинающийся с сокета — это сокет, открытый процессом, а часть в середине скобок — это номер сокета. Возьмите этот номер сокета и сопоставьте его с номером инода, полученным в tcp6 выше, если он соответствует, то порт st = 0A в tcp6 контролируется этим процессом. Что касается маппинга портов внутри и снаружи контейнера, то его нужно получить согласно методу маппинга применяемой технологии виртуализации. Подсчет количества подключений такой же, как и при сканировании портов, с той лишь разницей, что счетчик сканирований нужно накапливать для st = 01 (установить).

Суммировать:

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

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

Справочная документация:

elixir.free-electrons.com/Linux/V3.10…