本文介绍如何在 Azure Monitor 中设置和使用容器监视解决方案,这有助于在单个位置查看和管理 Docker 和 Windows 容器主机。 Docker 是一种软件虚拟化系统,用于创建自动将软件部署到其 IT 基础结构的容器。
重要
正在逐步淘汰容器监视解决方案。若要监视 Kubernetes 环境,建议过渡到 Azure Monitor 容器见解。
注释
本文最近已更新,将术语“Log Analytics”更改为“Azure Monitor 日志”。 日志数据仍然存储在 Log Analytics 工作区中,并仍然由同一 Log Analytics 服务收集并分析。 我们正在更新术语,以便更好地反映 Azure Monitor 中的日志的角色。 有关详细信息,请参阅 Azure Monitor 术语更改。
该解决方案显示正在运行的容器、正在运行的容器映像以及容器的运行位置。 可以查看详细的审核信息,其中显示了用于容器的命令。 此外,可以通过查看和搜索集中式日志来排查容器问题,而无需远程查看 Docker 或 Windows 主机。 可以找到可能产生噪音并消耗主机上过多资源的容器。 还可以查看容器的集中式 CPU、内存、存储和网络使用情况和性能信息。 在运行 Windows 的计算机上,可以集中比较 Windows Server、Hyper-V 和 Docker 容器中的日志。 该解决方案支持以下容器业务流程协调程序:
- Docker Swarm
- DC/OS
- Service Fabric
建议使用 Azure Monitor 容器见解来监视 Kubernetes 和 Red Hat OpenShift:
- AKS (为 AKS 配置容器监控)
- Red Hat OpenShift (使用 Azure Arc 配置容器洞察)
如果在 Azure Service Fabric 中部署了容器,建议同时启用 Service Fabric 解决方案 和此解决方案以包括监视群集事件。 在启用 Service Fabric 解决方案之前,请查看 “使用 Service Fabric 解决方案 ”了解它提供的内容以及如何使用它。
如果有兴趣监视部署到 Azure Kubernetes 服务(AKS)上托管的 Kubernetes 环境工作负荷的性能,请参阅 监视 Azure Kubernetes 服务。 容器监视解决方案不支持监视该平台。
下图显示了各种容器主机与代理与 Azure Monitor 之间的关系。
系统要求和支持的平台
在开始之前,请查看以下详细信息,验证是否满足先决条件。
支持 Docker Orchestrator 和操作系统平台的容器监控解决方案
下表概述了通过 Azure Monitor 对容器清单、性能和日志进行监视的 Docker 编排和操作系统支持。
Docker 业务流程 | ACS | Linux | Windows操作系统 | 容器 库存 |
图片 库存 |
节点 库存 |
容器 性能 |
容器 事件 / 活动 |
事件 / 活动 日志 |
容器 日志 |
---|---|---|---|---|---|---|---|---|---|---|
Kubernetes | • | • | • | • | • | • | • | • | • | • |
中层 DC/OS |
• | • | • | • | • | • | • | • | • | |
Docker 蜂群 |
• | • | • | • | • | • | • | • | • | |
服务 织物 |
• | • | • | • | • | • | • | • | • | |
Red Hat Open 转变 |
• | • | • | • | • | • | • | |||
Windows Server (独立) |
• | • | • | • | • | • | • | |||
Linux Server (独立) |
• | • | • | • | • | • | • |
Linux 上支持的 Docker 版本
- Docker 1.11 到 1.13
- Docker CE 和 EE v17.06
支持作为容器主机的 x64 Linux 分发版
- 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
- 适用于 Linux 的 Log Analytics 代理版本 1.4.1-45 及更高版本仅支持 Kubernetes 事件、Kubernetes 清单和容器进程
- ACS Docker Swarm
注释
在从 Microsoft Operations Management Suite 向 Azure Monitor 正在进行的过渡过程中,Windows 或 Linux 的 Operations Management Suite 代理将更名为 Windows 和 Linux 的 Log Analytics 代理。
支持的 Windows 操作系统
- Windows Server 2016
- Windows 10 周年版(专业版或企业版)
Windows 上支持的 Docker 版本
- Docker 1.12 和 1.13
- Docker 17.03.0 及更高版本
安装和配置解决方案
使用以下信息安装和配置解决方案。
从 Azure 市场或按照 解决方案库中的“添加监视解决方案”描述的过程,将容器监视解决方案添加到 Log Analytics 工作区。
在 Log Analytics 代理中安装和使用 Docker。 根据您的操作系统和 Docker 编排器,您可以使用以下方法来配置代理程序。
- 对于独立主机:
- 在受支持的 Linux作系统上,安装和运行 Docker,然后安装和配置 适用于 Linux 的 Log Analytics 代理。
- 在 CoreOS 上,不能运行适用于 Linux 的 Log Analytics 代理。 而是运行适用于 Linux 的 Log Analytics 代理的容器化版本。 如果您在 Azure 政府云中使用容器,请查看包括 CoreOS 在内的 Linux 容器主机或 Azure 政府版包括 CoreOS 在内的 Linux 容器主机。
- 在 Windows Server 2016 和 Windows 10 上,安装 Docker 引擎和客户端,然后连接代理以收集信息并将其发送到 Azure Monitor。 如果有 Windows 环境,请查看 安装和配置 Windows 容器主机 。
- 对于 Docker 多主机编排:
- 如果有 Red Hat OpenShift 环境,请查看如何为 Red Hat OpenShift 配置 Log Analytics 代理。
- 如果有使用 Azure 容器服务的 Kubernetes 群集:
- 查看 配置适用于 Kubernetes 的 Log Analytics Linux 代理。
- 查看 配置适用于 Kubernetes 的 Log Analytics Windows 代理。
- 查看使用 Helm 在 Linux Kubernetes 上部署 Log Analytics 代理。
- 如果有 Azure 容器服务 DC/OS 群集,请在 使用 Azure Monitor 监视 Azure 容器服务 DC/OS 群集中了解详细信息。
- 如果有 Docker Swarm 模式环境,请在为 Docker Swarm 配置 Log Analytics 代理时了解详细信息。
- 如果您有 Service Fabric 群集,请访问 使用 Azure Monitor 监控容器以了解更多信息。
- 对于独立主机:
查看 Windows 上的 Docker 引擎 文章,了解有关如何在运行 Windows 的计算机上安装和配置 Docker 引擎的其他信息。
重要
在容器主机上安装适用于 Linux 的 Log Analytics 代理之前,Docker 必须正在运行。 如果在安装 Docker 之前已安装代理,则需要重新安装适用于 Linux 的 Log Analytics 代理。 有关 Docker 的详细信息,请参阅 Docker 网站。
安装和配置 Linux 容器主机
安装 Docker 后,请使用容器主机的以下设置来配置代理以用于 Docker。 首先,需要 Log Analytics 工作区 ID 和密钥,可以在 Azure 门户中找到该 ID。 在工作区中,单击“ 快速启动>计算机 ”以查看 工作区 ID 和 主密钥。 将这两者复制并粘贴到你喜欢的编辑器中。
对于除 CoreOS 之外的所有 Linux 容器主机:
- 有关如何安装适用于 Linux 的 Log Analytics 代理的详细信息和步骤,请参阅 Log Analytics 代理概述。
对于包括 CoreOS 在内的所有 Linux 容器主机:
启动要监视的容器。 修改并使用以下示例:
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
对于包括 CoreOS 在内的所有 Azure 政府 Linux 容器主机:
启动要监视的容器。 修改并使用以下示例:
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 代理切换到容器中的代理
如果以前使用了直接安装的代理,并且想要改用容器中运行的代理,则必须首先删除适用于 Linux 的 Log Analytics 代理。 请参阅 卸载适用于 Linux 的 Log Analytics 代理 ,了解如何成功卸载代理。
为 Docker Swarm 配置 Log Analytics 代理
可以在 Docker Swarm 上将 Log Analytics 代理作为全局服务运行。 使用以下信息创建 Log Analytics 代理服务。 需要提供 Log Analytics 工作区 ID 和主密钥。
在主节点上运行以下命令。
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,创建工作区 ID 和主密钥的机密后,请使用以下信息创建机密信息。
在主节点上运行以下命令。
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
为 Red Hat OpenShift 配置 Log Analytics 代理
可通过三种方法将 Log Analytics 代理添加到 Red Hat OpenShift,开始收集容器监视数据。
- 在每个 OpenShift 节点上直接安装适用于 Linux 的 Log Analytics 代理
- 在驻留在 Azure 中的每个 OpenShift 节点上启用 Log Analytics VM 扩展
- 在 OpenShift 上以 DaemonSet 形式安装 Log Analytics 代理
在本部分中,我们将介绍将 Log Analytics 代理安装为 OpenShift 守护程序集所需的步骤。
登录到 OpenShift 主节点,并将 yaml 文件 ocp-omsagent.yaml 从 GitHub 复制到主节点,并使用 Log Analytics 工作区 ID 和主密钥修改值。
运行以下命令,为 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
若要部署守护程序集,请运行以下命令:
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 文件时使用机密来保护 Log Analytics 工作区 ID 和主密钥,请执行以下步骤。
登录到 OpenShift 主节点,并从 GitHub 复制 yaml 文件 ocp-ds-omsagent.yaml 和机密生成脚本 ocp-secretgen.sh 。 此脚本将为 Log Analytics 工作区 ID 和主密钥生成机密 yaml 文件,以保护机密信息。
运行以下命令,为 Azure Monitor 创建项目并设置用户帐户。 机密生成脚本要求 Log Analytics 工作区 ID
<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
通过运行以下命令部署 Log Analytics 代理守护程序集 yaml 文件:
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.
为 Kubernetes 配置 Log Analytics Linux 代理
对于 Kubernetes,可以使用脚本为工作区 ID 和主密钥生成机密 yaml 文件,以安装适用于 Linux 的 Log Analytics 代理。 在 Log Analytics Docker Kubernetes GitHub 页中,有一些文件您可以根据需要选择使用或不使用机密信息。
- 适用于 Linux DaemonSet 的默认 Log Analytics 代理没有机密信息(omsagent.yaml)
- 适用于 Linux DaemonSet yaml 文件的 Log Analytics 代理使用机密信息(omsagent-ds-secrets.yaml)和机密生成脚本来生成机密 yaml (omsagentsecret.yaml) 文件。
可以选择使用或不使用机密创建 omsagent DaemonSet。
不带机密的默认 OMSagent DaemonSet yaml 文件
对于默认的 Log Analytics 代理 DaemonSet yaml 文件,请将
<WSID>
和<KEY>
替换为您的 WSID 和 KEY。 将文件复制到主节点并运行以下命令:sudo kubectl create -f omsagent.yaml
带机密的默认 OMSagent DaemonSet yaml 文件
要使用包含秘密信息的 Log Analytics 代理 DaemonSet,请先创建这些秘密。
复制脚本和机密模板文件,并确保它们位于同一目录中。
- 机密生成脚本 - secret-gen.sh
- 秘密模板 - secret-template.yaml
运行脚本,如以下示例所示。 该脚本会请求 Log Analytics 工作区 ID 和主密钥,并在输入它们后,该脚本会创建一个机密 yaml 文件,以便可以运行它。
#> sudo bash ./secret-gen.sh
通过运行以下命令来创建机密的Pod:
sudo kubectl create -f omsagentsecret.yaml
若要验证,请运行以下命令:
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
请通过运行
sudo kubectl create -f omsagent-ds-secrets.yaml
创建 omsagent 守护进程集
验证 Log Analytics 代理 DaemonSet 是否正在运行,如下所示:
keiko@ubuntu16-13db:~# sudo kubectl get ds omsagent
NAME DESIRED CURRENT NODE-SELECTOR AGE omsagent 3 3 <none> 1h
对于 Kubernetes,请使用脚本为 Log Analytics 代理(适用于 Linux)生成工作区 ID 和主密钥的机密 yaml 文件。 将以下示例信息与 omsagent yaml 文件 配合使用来保护机密信息。
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
为 Kubernetes 配置 Log Analytics Windows 代理
对于 Windows Kubernetes,可以使用脚本为工作区 ID 和主密钥生成机密 yaml 文件,以安装 Log Analytics 代理。 在 Log Analytics Docker Kubernetes GitHub 页面上,有可与您的机密信息一起使用的文件。 需要为主节点和代理节点单独安装 Log Analytics 代理。
若要使用主节点上的机密信息使用 Log Analytics 代理 DaemonSet,请先登录并创建机密。
复制脚本和机密模板文件,并确保它们位于同一目录中。
- 机密生成脚本 - secret-gen.sh
- 秘密模板 - secret-template.yaml
运行脚本,如以下示例所示。 该脚本会请求 Log Analytics 工作区 ID 和主密钥,并在输入它们后,该脚本会创建一个机密 yaml 文件,以便可以运行它。
#> sudo bash ./secret-gen.sh
请通过运行
kubectl create -f omsagentsecret.yaml
创建 omsagent 守护进程集若要检查,请运行以下命令:
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
请通过运行
kubectl create -f ws-omsagent-de-secrets.yaml
创建 omsagent 守护进程集
验证 Log Analytics 代理 DaemonSet 是否正在运行,如下所示:
root@ubuntu16-13db:~# kubectl get deployment omsagent NAME DESIRED CURRENT NODE-SELECTOR AGE omsagent 1 1 <none> 1h
若要在运行 Windows 的辅助角色节点上安装代理,请按照 安装并配置 Windows 容器主机部分中的步骤进行作。
使用 Helm 在 Linux Kubernetes 上部署 Log Analytics 代理
若要使用 helm 在 Linux Kubernetes 环境中部署 Log Analytics 代理,请执行以下步骤。
请通过运行
helm install --name omsagent --set omsagent.secret.wsid=<WSID>,omsagent.secret.key=<KEY> stable/msoms
创建 omsagent 守护进程集结果将如下所示:
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
有关详细信息,请访问 容器解决方案 Helm Chart。
安装和配置 Windows 容器主机
使用部分中的信息安装和配置 Windows 容器主机。
在安装 Windows 代理之前进行准备
在运行 Windows 的计算机上安装代理之前,需要配置 Docker 服务。 该配置允许 Windows 代理或 Azure Monitor 虚拟机扩展使用 Docker TCP 套接字,以便代理可以远程访问 Docker 守护程序并捕获用于监视的数据。
配置 Docker 服务
执行以下 PowerShell 命令,为 Windows Server 启用 TCP 管道和命名管道:
Stop-Service docker
dockerd --unregister-service
dockerd --register-service -H npipe:// -H 0.0.0.0:2375
Start-Service docker
有关用于 Windows 容器的 Docker 守护程序配置的详细信息,请参阅 Windows 上的 Docker 引擎。
安装 Windows 代理
若要启用 Windows 和 Hyper-V 容器监视,请在容器主机的 Windows 计算机上安装Microsoft监视代理(MMA)。 有关在本地环境中运行 Windows 的计算机,请参阅 将 Windows 计算机连接到 Azure Monitor。 对于在 Azure 中运行的虚拟机,请使用 虚拟机扩展将其连接到 Azure Monitor。
可以监视 Service Fabric 上运行的 Windows 容器。 但是,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 |
计算机,ObjectName,CounterName(%Processor 时间,磁盘读取 MB,磁盘写入 MB,内存使用 MB,网络接收字节,网络发送字节,处理器使用秒,网络),CounterValue,TimeGenerated,CounterPath,SourceSystem |
容器清单 | ContainerInventory |
TimeGenerated,Computer,容器名称,ContainerHostname,镜像,镜像标签,容器状态,退出码,环境变量,命令,创建时间,启动时间,结束时间,SourceSystem,ContainerID,ImageID |
容器映像清单 | ContainerImageInventory |
TimeGenerated, 计算机, 镜像, 镜像标签, 镜像大小, 虚拟大小, 运行中, 已暂停, 已停止, 失败, 源系统, 镜像ID, 总容器 |
容器日志 | ContainerLog |
TimeGenerated, 计算机, 映像 ID, 容器名称, 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 环境中使用。
- 容器 CPU 性能 - 显示计算机节点/主机随时间推移的平均 CPU 使用率的折线图。 此外,还根据平均 CPU 使用率列出计算机节点/主机。
- 容器内存性能 - 显示一段时间内内存使用量的折线图。 此外,还根据实例名称列出计算机内存利用率。
- 计算机性能 - 显示一段时间内 CPU 性能百分比的折线图、随时间推移的内存使用量百分比和数兆字节的可用磁盘空间。 可以将鼠标悬停在图表中的任何线条上以查看更多详细信息。
仪表板的每个区域都是收集数据搜索结果的可视化表示。
在 “容器状态 ”区域中,单击顶部区域,如下所示。
Log Analytics 随即打开,显示有关容器状态的信息。
在这里,可以编辑搜索查询以对其进行修改,以查找感兴趣的特定信息。 有关日志查询的详细信息,请参阅 Azure Monitor 中的日志查询。
通过查找失败的容器进行故障排除
如果容器已退出,则 Log Analytics 会将容器标记为 “失败 ”,并带有非零退出代码。 可以在 “失败的容器 ”区域中查看环境中的错误和故障的概述。
查找失败的容器
- 单击 “容器状态 ”区域。
- Log Analytics 将打开并显示容器的状态,如下所示。
- 展开“失败”行,然后单击“+”将其条件添加到查询。 然后注释掉查询中的“汇总”行。
- 运行查询,然后展开结果中的一行以查看图像 ID。
- 在日志查询中键入以下内容。
ContainerImageInventory | where ImageID == <ImageID>
查看有关图像的详细信息,例如图像大小以及已停止和失败的图像数。
容器数据的查询日志
在排查特定错误时,查看错误在您的环境中发生的位置是有帮助的。 以下日志类型将帮助你创建查询以返回所需的信息。
- ContainerImageInventory - 尝试查找按图像组织的信息并查看图像信息(如图像 ID 或大小)时,请使用此类型。
- 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。
后续步骤
查询日志 以查看详细的容器数据记录。