Решение для мониторинга контейнеров в Azure Monitor

Статья
08/29/2022

Символ решения

В этой статье объясняется, как настроить и использовать решение для мониторинга контейнеров в Azure Monitor, чтобы централизованно просматривать узлы контейнеров Docker и Windows, а также управлять ими. Docker — это система виртуализации программного обеспечения, с помощью которой можно создавать контейнеры, автоматизирующие развертывание программного обеспечения в соответствующей ИТ-инфраструктуре.

Важно!

Решение для мониторинга контейнеров постепенно выводится из эксплуатации, и для мониторинга сред Kubernetes рекомендуется использовать аналитику контейнеров Azure Monitor.

Примечание

Сведения из данной статьи были недавно обновлены. Теперь вместо термина "Log Analytics" используется термин "журналы Azure Monitor". Данные журнала по-прежнему хранятся в рабочей области Log Analytics, собираются и анализируются той же службой Log Analytics. Целью обновления терминологии является лучшее отражение роли журналов в Azure Monitor. Дополнительные сведения см. в статье Изменения фирменной символики Azure Monitor.

Решение показывает, какие контейнеры запущены, какой образ контейнера запущен и где выполняются контейнеры. Также можно просматривать подробные сведения аудита, в том числе команды, используемые в контейнерах. Кроме того, вы можете устранять неполадки контейнеров, просматривая централизованные журналы и выполняя в них поиск, без необходимости удаленного просмотра узлов Docker или Windows. Решение позволяет находить контейнеры, содержащие ошибки и использующие слишком много ресурсов на узле. Также у вас есть возможность централизованно просматривать сведения об использовании и производительности ЦП, памяти, хранилища и сети по контейнерам. На компьютерах под управлением Windows можно централизовать и сравнивать журналы из Windows Server, Hyper-V и контейнеров Docker. Решение поддерживает следующие оркестраторы контейнеров:

Docker Swarm
DC/OS
Service Fabric

Мы рекомендуем использовать службу Azure Monitor Container Insights для мониторинга Kubernetes и Red Hat OpenShift:

AKS (настройка Container Insights для AKS)
Red Hat OpenShift (настройка Container Insights с помощью Azure Arc)

Если вы развернули контейнеры в Azure Service Fabric, для мониторинга событий кластера рекомендуется одновременно включить решение Service Fabric и это решение. Перед включением решения Service Fabric ознакомьтесь со статьей о его использовании, чтобы понять, какие возможности оно поддерживает и как с ним работать.

Если вы заинтересованы в мониторинге производительности рабочих нагрузок, развернутых в средах Kubernetes, которые размещены в Службе Azure Kubernetes (AKS), см. статью Обзор службы "Azure Monitor для контейнеров". Решение для мониторинга контейнеров не поддерживает мониторинг этой платформы.

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

Требования к системе и поддерживаемые платформы

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

Поддержка решений для мониторинга контейнеров: оркестратор Docker и платформа ОС

Ниже представлена таблица поддержки мониторинга операционных систем и оркестрации Docker с помощью Azure Monitor, где описана поддержка мониторинга списка контейнеров, производительности и журналов.

Оркестрации DOCKER	ACS	Linux	Windows	Контейнер Inventory (Товары)	Образ — Inventory (Товары)	Узел Inventory (Товары)	Контейнер Производительность	Контейнер Событие	Событие Журнал	Контейнер Журнал
Kubernetes	•	•	•	•	•	•	•	•	•	•
Mesosphere DC/OS	•	•		•	•	•	•	•	•	•
Docker Swarm	•	•	•	•	•	•	•	•		•
Служба Fabric		•	•	•	•	•	•	•	•	•
Red Hat Open Сдвиг		•		•	•	•	•	•		•
Windows Server (изолированный)			•	•	•	•	•	•		•
Linux Server (изолированный)		•		•	•	•	•	•		•

Версии Docker, поддерживаемые в Linux

Docker 1.11–1.13
Docker CE и EE v17.06

Дистрибутивы Linux x64, поддерживаемые в качестве узлов контейнера

Ubuntu 14.04 LTS и 16.04 LTS
CoreOS (стабильный выпуск);
Amazon Linux 2016.09.0;
openSUSE 13.2
openSUSE LEAP 42.2
CentOS 7.2 и 7.3
SLES 12
RHEL 7.2 и 7.3
Платформа контейнеров Red Hat OpenShift (OCP) 3.4 и 3.5
ACS Mesosphere DC/OS 1.7.3–1.8.8
ACS Kubernetes 1.4.5–1.6
- События Kubernetes, список Kubernetes и процессы контейнера поддерживаются только в 1.4.1-45 и более поздних версиях агента Log Analytics для Linux.
ACS Docker Swarm

Примечание

В рамках текущего перехода с Microsoft Operations Management Suite на Azure Monitor агент Microsoft Operations Management Suite для операционных систем будет называться агентом Log Analytics для Windows и Log Analytics для Linux.

Поддерживаемая операционная система Windows

Windows Server 2016
Юбилейный выпуск Windows 10 (профессиональный или корпоративный)

Версии Docker, поддерживаемые в Windows

Docker 1.12 и 1.13
Docker 17.03.0 и более поздних версий

Установка и настройка решения

Для установки и настройки решений используйте указанные ниже данные.

Решение для мониторинга контейнеров необходимо добавить в рабочую область Log Analytics из Azure Мarketplace или в соответствии с инструкциями по добавлению решений для мониторинга из коллекции решений.
Установите и используйте Docker с агентом Log Analytics. В зависимости от операционной системы и оркестратора Docker можно использовать следующие методы настройки агента.
- Для автономных узлов:
  - В поддерживаемых операционных системах Linux установите и запустите Docker, а затем установите и настройте агент Log Analytics для Linux.
  - В CoreOS невозможно запустить агент Log Analytics для Linux. Вместо этого можно запустить контейнерную версию агента Log Analytics для Linux. Если вы работаете с контейнерами в облаке "Azure для государственных организаций", то см. раздел "Для всех узлов контейнера Linux, включая CoreOS" или "Для всех узлов контейнера Linux Azure для государственных организаций, включая CoreOS".
  - В Windows Server 2016 и Windows 10 установите модуль и клиент Docker, после чего подключите агент, чтобы собрать сведения и отправить их в Azure Monitor. Если вы используете среду Windows, см. сведения в разделе Установка и настройка узлов контейнера Windows.
- Для многоузловой оркестрации Docker:
  - Если вы используете среду Red Hat OpenShift, ознакомьтесь с разделом по настройке агента Log Analytics для Red Hat OpenShift.
  - Если вы используете кластер Kubernetes с помощью Службы контейнеров Azure (AKS), см. следующие разделы:
    - Ознакомьтесь с разделом Настройка агента Log Analytics в Linux для Kubernetes.
    - См. раздел Настройка агента Log Analytics в Windows для Kubernetes.
    - Ознакомьтесь с разделом "Использование Helm для развертывания агента Log Analytics в Kubernetes для Linux".
  - При наличии кластера DC/OS в службе контейнеров Azure дополнительные сведения см. в статье Мониторинг кластера DC/OS Службы контейнеров Azure с использованием Azure Monitor.
  - При наличии среды режима Docker Swarm ознакомьтесь с разделом "Настройка агента Log Analytics для Docker Swarm".
  - При наличии кластера Service Fabric см. дополнительные сведения в статье Мониторинг контейнеров с помощью Azure Monitor.

Дополнительные сведения о том, как установить и настроить модули Docker на компьютерах под управлением Windows, см. в этой статье.

Важно!

Docker необходимо запустить перед установкой агента Log Analytics для Linux на узлах контейнера. Если вы уже установили агент перед установкой Docker, то необходимо переустановить агент Log Analytics для Linux. Дополнительные сведения о Docker см. на веб-сайте Docker.

Установка и настройка узлов контейнера Linux

После установки Docker используйте приведенные ниже параметры узла контейнера, чтобы настроить агент для использования с Docker. Сначала необходимо получить идентификатор и ключ рабочей области Log Analytics, которые можно найти на портале Azure. В рабочей области щелкните Быстрый запуск>Компьютеры, чтобы просмотреть идентификатор рабочей области и первичный ключ. Скопируйте их и вставьте в любой удобный для вас редактор.

Для всех узлов контейнера Linux, за исключением CoreOS:

См. дополнительные сведения об установке агента Log Analytics для Linux.

Для всех узлов контейнера Linux, включая CoreOS:

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

sudo docker run --privileged -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/containers:/var/lib/docker/containers -e WSID="your workspace id" -e KEY="your key" -h=`hostname` -p 127.0.0.1:25225:25225 --name="omsagent" --restart=always mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest

Для всех узлов контейнера Linux Azure для государственных организаций, включая CoreOS:

sudo docker run --privileged -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/log:/var/log -v /var/lib/docker/containers:/var/lib/docker/containers -e WSID="your workspace id" -e KEY="your key" -e DOMAIN="opinsights.azure.us" -p 127.0.0.1:25225:25225 -p 127.0.0.1:25224:25224/udp --name="omsagent" -h=`hostname` --restart=always mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest

Переход от использования установленного агента Linux к использованию агента в контейнере

Если ранее вы использовали установленный напрямую агент и теперь вместо него хотите использовать агент, работающий в контейнере, сначала необходимо удалить агент Log Analytics для Linux. Сведения об удалении агента Log Analytics для Linux см. в этой статье.

Настройка агента Log Analytics для Docker Swarm

Агент Log Analytics можно запускать в качестве глобальной службы в Docker Swarm. Используйте следующие сведения для создания службы агента Log Analytics. Необходимо будет предоставить идентификатор и первичный ключ рабочей области Log Analytics.

Выполните следующую команду на главном узле.

sudo docker service create  --name omsagent --mode global  --mount type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --mount type=bind,source=/var/lib/docker/containers,destination=/var/lib/docker/containers -e WSID="<WORKSPACE ID>" -e KEY="<PRIMARY KEY>" -p 25225:25225 -p 25224:25224/udp  --restart-condition=on-failure mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest

Защита секретов для Docker Swarm

Если вы используете Docker Swarm, после создания секрета для идентификатора рабочей области и первичного ключа создайте секретные данные, используя приведенные ниже сведения.

Выполните следующую команду на главном узле.

echo "WSID" | docker secret create WSID -
echo "KEY" | docker secret create KEY -

Убедитесь, что секретные данные созданы надлежащим образом.

keiko@swarmm-master-13957614-0:/run# sudo docker secret ls

ID                          NAME                CREATED             UPDATED
j2fj153zxy91j8zbcitnjxjiv   WSID                43 minutes ago      43 minutes ago
l9rh3n987g9c45zffuxdxetd9   KEY                 38 minutes ago      38 minutes ago

Запустите следующую команду, чтобы подключить секреты к контейнерному агенту Log Analytics.

sudo docker service create  --name omsagent --mode global  --mount type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --mount type=bind,source=/var/lib/docker/containers,destination=/var/lib/docker/containers --secret source=WSID,target=WSID --secret source=KEY,target=KEY  -p 25225:25225 -p 25224:25224/udp --restart-condition=on-failure mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest

Настройка агента Log Analytics для Red Hat OpenShift

Существует три способа добавления агента Log Analytics в Red Hat OpenShift, чтобы начать сбор данных мониторинга контейнера:

установить агент Log Analytics для Linux непосредственно на каждом узле OpenShift;
включить расширение виртуальной машины Log Analytics на каждом узле OpenShift, размещенном в Azure;
установить агент Log Analytics как набор daemon-set для OpenShift.

В этом разделе описаны действия, которые необходимо выполнить для установки агента Log Analytics как набора daemon-set для OpenShift.

Войдите на главный узел OpenShift и скопируйте YAML-файл ocp-omsagent.yaml с портала GitHub на свой главный узел. При этом замените значения идентификатора рабочей области Log Analytics и первичного ключа своими значениями.

Выполните следующие команды, чтобы создать проект для Azure Monitor и настроить учетную запись пользователя.

oc adm new-project omslogging --node-selector='zone=default'
oc project omslogging  
oc create serviceaccount omsagent  
oc adm policy add-cluster-role-to-user cluster-reader   system:serviceaccount:omslogging:omsagent  
oc adm policy add-scc-to-user privileged system:serviceaccount:omslogging:omsagent

Чтобы развернуть набор daemon-set, выполните следующую команду:

oc create -f ocp-omsagent.yaml

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

oc describe daemonset omsagent

Выходные данные должны выглядеть примерно так:

[ocpadmin@khm-0 ~]$ oc describe ds oms  
Name:           oms  
Image(s):       mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest  
Selector:       name=omsagent  
Node-Selector:  zone=default  
Labels:         agentVersion=1.4.0-12  
                dockerProviderVersion=10.0.0-25  
                name=omsagent  
Desired Number of Nodes Scheduled: 3  
Current Number of Nodes Scheduled: 3  
Number of Nodes Misscheduled: 0  
Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed  
No events.

Чтобы применить секреты для защиты идентификатора рабочей области Log Analytics и первичного ключа, когда используется YAML-файл набора daemon-set агента Log Analytics, выполните следующие действия.

Войдите на главный узел OpenShift и скопируйте YAML-файл ocp-ds-omsagent.yaml и сценарий создания секретов ocp secretgen.sh с портала GitHub. Этот сценарий создаст YAML-файл секретов для идентификатора рабочей области Log Analytics и первичного ключа, чтобы защитить ваши секретные сведения.
Выполните следующие команды, чтобы создать проект для Azure Monitor и настроить учетную запись пользователя. Сценарий создания секретов запросит ввести идентификатор рабочей области Log Analytics <WSID> и первичный ключ <KEY>, после чего создаст файл ocp-secret.yaml.
```
oc adm new-project omslogging --node-selector='zone=default'  
oc project omslogging  
oc create serviceaccount omsagent  
oc adm policy add-cluster-role-to-user cluster-reader   system:serviceaccount:omslogging:omsagent  
oc adm policy add-scc-to-user privileged system:serviceaccount:omslogging:omsagent  
```
Разверните файл секретов, выполнив следующую команду:

oc create -f ocp-secret.yaml

Проверьте развертывание, выполнив следующую команду:

oc describe secret omsagent-secret

Выходные данные должны выглядеть примерно так:

[ocpadmin@khocp-master-0 ~]$ oc describe secret omsagent-secret  
Name:           omsagent-secret  
Namespace:      omslogging  
Labels:         <none>  
Annotations:    <none>  
Type:   Opaque  
Data  
====  
KEY:    89 bytes  
WSID:   37 bytes

Разверните YAML-файл набора daemon-set агента Log Analytics, выполнив следующую команду:

oc create -f ocp-ds-omsagent.yaml

Проверьте развертывание, выполнив следующую команду:

oc describe ds oms

Выходные данные должны выглядеть примерно так:

[ocpadmin@khocp-master-0 ~]$ oc describe ds oms  
Name:           oms  
Image(s):       mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest  
Selector:       name=omsagent  
Node-Selector:  zone=default  
Labels:         agentVersion=1.4.0-12  
                dockerProviderVersion=10.0.0-25  
                name=omsagent  
Desired Number of Nodes Scheduled: 3  
Current Number of Nodes Scheduled: 3  
Number of Nodes Misscheduled: 0  
Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed  
No events.

Настройка агента Log Analytics в Linux для Kubernetes

Чтобы установить агент Log Analytics в Linux для Kubernetes, используйте сценарий, позволяющий создать YAML-файл секретов для идентификатора рабочей области и первичного ключа. На странице Log Analytics Docker Kubernetes в GitHub есть файлы, которые можно использовать с секретными данными или без них.

Стандартный файл DaemonSet агента Log Analytics для Linux не поддерживает секретные сведения (omsagent.yaml).
YAML-файл DaemonSet агента Log Analytics для Linux использует секретные сведения (omsagent-ds-secrets.yaml) со сценариями формирования секретов, чтобы создать YAML-файл секретов (omsagentsecret.yaml).

Вы можете создать DaemonSet агента OMS с секретными данными или без них.

Стандартный файл YAML DaemonSet агента OMS без секретов

Для стандартного файла YAML DaemonSet агента Log Analytics замените <WSID> и <KEY> на ваши WSID и ключ. Скопируйте файл на главный узел и выполните следующую команду:
```
sudo kubectl create -f omsagent.yaml
```

Стандартный файл YAML DaemonSet агента OMS с секретами

Чтобы использовать DaemonSet агента Log Analytics с секретными сведениями, сначала создайте секреты.
1. Скопируйте сценарий и файл шаблона секретов в один и тот же каталог.
  - Сценарий создания секретов — secret-gen.sh
  - Шаблон секретов — secret-template.yaml
2. Выполните сценарий, как показано в следующем примере. Сценарий запрашивает идентификатор рабочей области Log Analytics и первичный ключ, а после их ввода создает YAML-файл секретов, который можно запустить.
```
#> sudo bash ./secret-gen.sh
```
3. Создайте pod секретов, выполнив следующую команду:
```
sudo kubectl create -f omsagentsecret.yaml
```
4. Чтобы проверить, выполните следующую команду:
```
keiko@ubuntu16-13db:~# sudo kubectl get secrets
```
  Выходные данные должны выглядеть примерно так:
```
NAME                  TYPE                                  DATA      AGE
default-token-gvl91   kubernetes.io/service-account-token   3         50d
omsagent-secret       Opaque                                2         1d
```
```
keiko@ubuntu16-13db:~# sudo kubectl describe secrets omsagent-secret
```
  Выходные данные должны выглядеть примерно так:
```
Name:           omsagent-secret
Namespace:      default
Labels:         <none>
Annotations:    <none>

Type:   Opaque

Data
====
WSID:   36 bytes
KEY:    88 bytes
```
5. Создание свой набор daemon-set omsagent, выполнив команду sudo kubectl create -f omsagent-ds-secrets.yaml

Проверьте, работает ли DaemonSet агента Log Analytics, что будет выглядеть примерно так:

keiko@ubuntu16-13db:~# sudo kubectl get ds omsagent

NAME       DESIRED   CURRENT   NODE-SELECTOR   AGE
omsagent   3         3         <none>          1h

Для агента Log Analytics в Linux для Kubernetes используйте сценарий, позволяющий создать YAML-файл секретов для идентификатора рабочей области и первичного ключа. Используйте сведения из следующего примера с файлом YAML omsagent, чтобы защитить свои секретные сведения.

keiko@ubuntu16-13db:~# sudo kubectl describe secrets omsagent-secret
Name:           omsagent-secret
Namespace:      default
Labels:         <none>
Annotations:    <none>

Type:   Opaque

Data
====
WSID:   36 bytes
KEY:    88 bytes

Настройка агента Log Analytics в Windows для Kubernetes

Чтобы установить агент Log Analytics в Windows для Kubernetes, используйте сценарий, позволяющий создать YAML-файл секретов для идентификатора рабочей области и первичного ключа. На странице Log Analytics Docker Kubernetes в GitHub есть файлы, которые можно использовать с секретными сведениями. Необходимо установить агент Log Analytics отдельно для главного узла и узла агента.

Чтобы использовать DaemonSet агента Log Analytics с секретными сведениями на главном узле, сначала выполните вход и создайте секреты.
1. Скопируйте сценарий и файл шаблона секретов в один и тот же каталог.
  - Сценарий создания секретов — secret-gen.sh
  - Шаблон секретов — secret-template.yaml
2. Выполните сценарий, как показано в следующем примере. Сценарий запрашивает идентификатор рабочей области Log Analytics и первичный ключ, а после их ввода создает YAML-файл секретов, который можно запустить.
```
#> sudo bash ./secret-gen.sh
```
3. Создание свой набор daemon-set omsagent, выполнив команду kubectl create -f omsagentsecret.yaml
4. Чтобы проверить, выполните следующую команду:
```
root@ubuntu16-13db:~# kubectl get secrets
```
  Выходные данные должны выглядеть примерно так:
```
NAME                  TYPE                                  DATA      AGE
default-token-gvl91   kubernetes.io/service-account-token   3         50d
omsagent-secret       Opaque                                2         1d
root@ubuntu16-13db:~# kubectl describe secrets omsagent-secret
Name:           omsagent-secret
Namespace:      default
Labels:         <none>
Annotations:    <none>

Type:   Opaque

Data
====
WSID:   36 bytes
KEY:    88 bytes
```
5. Создание свой набор daemon-set omsagent, выполнив команду kubectl create -f ws-omsagent-de-secrets.yaml

Проверьте, работает ли DaemonSet агента Log Analytics, что будет выглядеть примерно так:

root@ubuntu16-13db:~# kubectl get deployment omsagent
NAME       DESIRED   CURRENT   NODE-SELECTOR   AGE
omsagent   1         1         <none>          1h

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

Использование Helm для развертывания агента Log Analytics в Kubernetes для Linux

Чтобы использовать Helm для развертывания агента Log Analytics в Kubernetes в среде Linux, сделайте следующее.

Создание свой набор daemon-set omsagent, выполнив команду helm install --name omsagent --set omsagent.secret.wsid=<WSID>,omsagent.secret.key=<KEY> stable/msoms

Результаты будут выглядеть следующим образом.

NAME:   omsagent
LAST DEPLOYED: Tue Sep 19 20:37:46 2017
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Secret
NAME            TYPE    DATA  AGE
omsagent-msoms  Opaque  3     3s

==> v1beta1/DaemonSet
NAME            DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE-SELECTOR  AGE
omsagent-msoms  3        3        3      3           3          <none>         3s

Вы можете проверить состояние omsagent, запустив helm status "omsagent". Выходные данные будут выглядеть, как показано ниже:

keiko@k8s-master-3814F33-0:~$ helm status omsagent
LAST DEPLOYED: Tue Sep 19 20:37:46 2017
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Secret
NAME            TYPE    DATA  AGE
omsagent-msoms  Opaque  3     17m

==> v1beta1/DaemonSet
NAME            DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE-SELECTOR  AGE
omsagent-msoms  3        3        3      3           3          <none>         17m

Дополнительные сведения см. на странице KubeApps.

Установка и настройка узлов контейнера Windows

Сведения в этом разделе помогут вам установить и настроить узлы контейнера Windows.

Подготовка к установке агентов Windows

Настройте службу Docker, прежде чем устанавливать агенты на компьютерах под управлением Windows. Конфигурация позволяет агенту Windows или расширению виртуальной машины Azure Monitor использовать TCP-сокет Docker, чтобы агенты могли получить удаленный доступ к управляющей программе Docker и возможность получать данные мониторинга.

Настройка службы Docker.

Чтобы включить TCP-канал и именованный канал для Windows Server, выполните следующие команды PowerShell:

Stop-Service docker
dockerd --unregister-service
dockerd --register-service -H npipe:// -H 0.0.0.0:2375  
Start-Service docker

Дополнительные сведения о настройке управляющей программы Docker, используемой в контейнерах Windows, см. в статье Подсистема Docker в Windows.

Установка агентов Windows

Чтобы включить мониторинг контейнеров Windows и Hyper-V, установите Microsoft Monitoring Agent (MMA) на компьютерах Windows, которые являются узлами контейнера. Сведения для компьютеров под управлением Windows в локальной среде см. в статье Подключение компьютеров Windows к Azure Monitor. Виртуальные машины, запущенные в Azure, нужно подключать к Azure Monitor с помощью расширения виртуальной машины.

Вы можете отслеживать контейнеры Windows, запущенные в Service Fabric. Однако сейчас для Service Fabric поддерживаются только виртуальные машины, работающие в Azure, и компьютеры под управлением Windows в локальной среде.

Убедитесь, что решение для мониторинга контейнеров правильно установлено в Windows. Чтобы проверить, был ли пакет управления скачан должным образом, найдите файл ContainerManagement.xxx. Файлы должны находиться в папке, расположенной по адресу C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs.

Компоненты решения

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

ContainerManagement.xxx устанавливается в папке, расположенной по адресу C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs.

Сведения о сборе данных из контейнеров

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

Данные собираются каждые три минуты следующими типами агентов.

Записи контейнеров

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

Тип данных	Тип данных, используемый для поиска в журналах	Поля
Производительность узлов и контейнеров	`Perf`	Computer, ObjectName, CounterName (%Processor Time, Disk Reads MB, Disk Writes MB, Memory Usage MB, Network Receive Bytes, Network Send Bytes, Processor Usage sec, Network), CounterValue, TimeGenerated, CounterPath, SourceSystem
Список контейнеров	`ContainerInventory`	TimeGenerated, Computer, container name, ContainerHostname, Image, ImageTag, ContainerState, ExitCode, EnvironmentVar, Command, CreatedTime, StartedTime, FinishedTime, SourceSystem, ContainerID, ImageID
Список образов контейнеров	`ContainerImageInventory`	TimeGenerated, Computer, Image, ImageTag, ImageSize, VirtualSize, Running, Paused, Stopped, Failed, SourceSystem, ImageID, TotalContainer
Журнал контейнеров	`ContainerLog`	TimeGenerated, Computer, image ID, container name, LogEntrySource, LogEntry, SourceSystem, ContainerID
Журнал службы контейнеров	`ContainerServiceLog`	TimeGenerated, Computer, TimeOfCommand, Image, Command, SourceSystem, ContainerID
Список узлов контейнеров	`ContainerNodeInventory_CL`	TimeGenerated, Computer, ClassName_s, DockerVersion_s, OperatingSystem_s, Volume_s, Network_s, NodeRole_s, OrchestratorType_s, InstanceID_g, SourceSystem
Список Kubernetes	`KubePodInventory_CL`	TimeGenerated, Computer, PodLabel_deployment_s, PodLabel_deploymentconfig_s, PodLabel_docker_registry_s, Name_s, Namespace_s, PodStatus_s, PodIp_s, PodUid_g, PodCreationTimeStamp_t, SourceSystem
Процесс контейнера	`ContainerProcess_CL`	TimeGenerated, Computer, Pod_s, Namespace_s, ClassName_s, InstanceID_s, Uid_s, PID_s, PPID_s, C_s, STIME_s, Tty_s, TIME_s, Cmd_s, Id_s, Name_s, SourceSystem
События Kubernetes	`KubeEvents_CL`	TimeGenerated, Computer, Name_s, ObjectKind_s, Namespace_s, Reason_s, Type_s, SourceComponent_s, SourceSystem, Message

Метки, добавленные в типы данных PodLabel — это ваши метки. Например, приведенные в таблице метки PodLabel. Таким образом, PodLabel_deployment_s, PodLabel_deploymentconfig_s, PodLabel_docker_registry_s будут отличаться в наборе данных вашей среды и должны выглядеть примерно так: PodLabel_yourlabel_s.

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

Включив решение на портале Azure, вы увидите плитку Контейнеры, на которой отображаются сводные сведения об узлах контейнеров и контейнерах, запущенных на узлах.

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

Использование панели мониторинга "Контейнеры"

Щелкните плитку Контейнеры. Отсюда можно открыть представления, упорядоченные по:

Событиям контейнера. Здесь отображается состояние контейнера и компьютеры, содержащие контейнеры со сбоями.
Журналам контейнера. Здесь отображается диаграмма файлов журналов контейнеров, созданных за определенный период, и список компьютеров с наибольшим количеством файлов журналов.
Событиям Kubernetes. Здесь отображается диаграмма событий Kubernetes, созданных за определенный период, и список причин, по которым модули pod создали события. Этот набор данных используется только в средах Linux.
Списку пространств имен Kubernetes. Здесь отображается количество пространств имен и модулей pod, а также их иерархия. Этот набор данных используется только в средах Linux.
Списку узлов контейнеров. Здесь отображается количество типов оркестрации, которые используются на узлах контейнеров. Узлы компьютеров также перечислены по количеству контейнеров. Этот набор данных используется только в средах Linux.
Списку образов контейнеров. Здесь отображается общее количество используемых образов контейнеров и количество типов образов. Количество образов также указано по тегам образов.
Состоянию контейнеров. Здесь отображается общее количество компьютеров узлов контейнера с запущенными контейнерами. Компьютеры также перечислены по количеству запущенных узлов.
Процессу контейнера. Здесь отображается график процессов контейнера, выполняемых за период времени. Контейнеры также перечислены по выполняемым в них командам или процессам. Этот набор данных используется только в средах Linux.
Производительности ЦП контейнера. Здесь отображается график среднего использования ЦП по времени для узлов компьютеров. В нем также перечисляются узлы компьютеров по среднему использованию ЦП.
Производительности памяти контейнера. Здесь отображается график использования памяти по времени, а также использование памяти компьютера по имени экземпляра.
Производительности компьютера. Здесь отображаются графики с процентами производительности ЦП, использования памяти и свободным дисковым пространством в мегабайтах по времени. Наведите указатель на любую линию в диаграмме, чтобы просмотреть дополнительные сведения.

Каждая область на панели мониторинга — это визуальное представление поиска по собранным данным.

Перейдите в область Container Status (Состояния контейнера) и щелкните верхнюю область, как показано ниже.

Откроется Log Analytics со сведениями о состоянии контейнеров.

Здесь можно изменить поисковый запрос таким образом, чтобы найти нужную вам информацию. Дополнительные сведения о запросах журналов см. в статье о запросах журналов в Azure Monitor.

Устранение неполадок с помощью поиска контейнера со сбоем

Log Analytics добавляет к контейнеру пометку Сбой, если такой контейнер завершил работу с ненулевым кодом выхода. Обзор ошибок и сбоев в среде можно просмотреть в области Failed Containers (Контейнеры со сбоями).

Поиск контейнеров со сбоями

Щелкните область Container Status (Состояние контейнера).
Откроется Log Analytics со сведениями о состоянии контейнеров, как показано ниже.
Разверните строку Failed (Ошибка) и нажмите кнопку +, чтобы добавить критерии в запрос. Затем закомментируйте в запросе строку Summarize (Сводка).
Выполните запрос, а затем разверните строку в результатах, чтобы просмотреть идентификатор образа.
Введите следующий запрос в поле запроса: ContainerImageInventory | where ImageID == <ImageID> для просмотра сведений об образе, таких как размер образа, количество остановленных образов, а также образы со сбоями.

Запрос данных контейнера в журналах

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

ContainerImageInventory — этот тип используется для поиска сведений, упорядоченных по образам, и для просмотра информации об образах, включая идентификаторы или размеры образов.
ContainerInventory — этот тип используется для получения сведений о расположении контейнеров, их именах и образах, которые в них выполняются.
ContainerLog — этот тип используется, если требуется найти определенные сведения или записи в журнале ошибок.
ContainerNodeInventory_CL — этот тип используется для получения сведений об узле, где находятся контейнеры. С его помощью можно получить сведения о версии Docker, типе оркестрации, хранилище и сведения о сети.
ContainerProcess_CL — этот тип используется для быстрого просмотра процессов, запущенных в контейнере.
ContainerServiceLog — этот тип используется для поиска в журнале аудита данных об управляющей программе Docker, включая команды для запуска, остановки и извлечения.
KubeEvents_CL — этот тип используется для просмотра событий Kubernetes.
KubePodInventory_CL — этот тип используется, если необходимо получить сведения об иерархии кластера.

Запрос данных контейнера в журналах

Выберите образ, в котором недавно произошел сбой, и найдите журнал ошибок для этого образа. Сначала найдите имя контейнера, в котором выполняется этот образ, выполнив поиск в журнале ContainerInventory. Например, выполните поиск по запросу ContainerInventory | where Image == "ubuntu" and ContainerState == "Failed"

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

Пример запросов журнала

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

Сохранение запросов журнала

Сохранение запросов — это стандартная функция в Azure Monitor. Она позволяет сохранять полезные запросы для использования в будущем.

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

Удаление решения из рабочей области

Чтобы удалить решение для мониторинга контейнеров, воспользуйтесь инструкциями по удалению решений с помощью одного из следующих средств: портал Azure, PowerShellили Azure CLI.

Следующие шаги

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

Решение для мониторинга контейнеров в Azure Monitor

Требования к системе и поддерживаемые платформы

Поддержка решений для мониторинга контейнеров: оркестратор Docker и платформа ОС

Версии Docker, поддерживаемые в Linux

Дистрибутивы Linux x64, поддерживаемые в качестве узлов контейнера

Поддерживаемая операционная система Windows

Версии Docker, поддерживаемые в Windows

Установка и настройка решения

Установка и настройка узлов контейнера Linux

Настройка агента Log Analytics для Docker Swarm

Защита секретов для Docker Swarm

Настройка агента Log Analytics для Red Hat OpenShift

Настройка агента Log Analytics в Linux для Kubernetes

Настройка агента Log Analytics в Windows для Kubernetes

Использование Helm для развертывания агента Log Analytics в Kubernetes для Linux

Установка и настройка узлов контейнера Windows

Подготовка к установке агентов Windows

Настройка службы Docker.

Установка агентов Windows

Компоненты решения

Сведения о сборе данных из контейнеров

Записи контейнеров

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

Использование панели мониторинга "Контейнеры"

Устранение неполадок с помощью поиска контейнера со сбоем

Поиск контейнеров со сбоями

Запрос данных контейнера в журналах

Запрос данных контейнера в журналах

Пример запросов журнала

Сохранение запросов журнала

Удаление решения из рабочей области

Следующие шаги

Дополнительные ресурсы