이 문서에서는 단일 위치에서 Docker 및 Windows 컨테이너 호스트를 보고 관리하는 데 도움이 되는 Azure Monitor에서 컨테이너 모니터링 솔루션을 설정하고 사용하는 방법을 설명합니다. Docker는 IT 인프라에 대한 소프트웨어 배포를 자동화하는 컨테이너를 만드는 데 사용되는 소프트웨어 가상화 시스템입니다.
중요합니다
컨테이너 모니터링 솔루션은 단계적으로 폐지되고 있습니다. Kubernetes 환경을 모니터링하려면 Azure Monitor Container Insights로 전환하는 것이 좋습니다.
비고
이 문서는 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
Kubernetes 및 Red Hat OpenShift를 모니터링하기 위해 Azure Monitor 컨테이너 인사이트를 사용하는 것이 좋습니다.
- AKS(AKS에 대한 컨테이너 인사이트 구성)
- Red Hat OpenShift(Azure Arc를 사용하여 컨테이너 인사이트 구성)
Azure Service Fabric에 컨테이너가 배포된 경우 클러스터 이벤트 모니터링을 포함하도록 Service Fabric 솔루션과 이 솔루션을 모두 사용하도록 설정하는 것이 좋습니다. Service Fabric 솔루션을 사용하도록 설정하기 전에 Service Fabric 솔루션 사용을 검토하여 제공하는 내용과 사용 방법을 이해합니다.
AKS(Azure Kubernetes Service)에서 호스트되는 Kubernetes 환경에 배포된 워크로드의 성능을 모니터링하려면 Azure Kubernetes Service 모니터링을 참조하세요. 컨테이너 모니터링 솔루션은 해당 플랫폼 모니터링을 지원하지 않습니다.
다음 다이어그램에서는 Azure Monitor를 사용하여 다양한 컨테이너 호스트와 에이전트 간의 관계를 보여 줍니다.
시스템 요구 사항 및 지원되는 플랫폼
시작하기 전에 다음 세부 정보를 검토하여 필수 구성 요소를 충족하는지 확인합니다.
Docker Orchestrator 및 OS 플랫폼에 대한 컨테이너 모니터링 솔루션 지원
다음 표에서는 Azure Monitor를 사용하여 컨테이너 인벤토리, 성능 및 로그의 Docker 오케스트레이션 및 운영 체제 모니터링 지원을 간략하게 설명합니다.
| Docker 오케스트레이션 | 전미 화학 협회 (ACS) | Linux | 윈도우즈 | 컨테이너 재고품 |
이미지 재고품 |
노드 재고품 |
컨테이너 성능 |
컨테이너 이벤트 |
이벤트 로그 |
컨테이너 로그 |
|---|---|---|---|---|---|---|---|---|---|---|
| Kubernetes | • | • | • | • | • | • | • | • | • | • |
| Mesosphere DC/OS |
• | • | • | • | • | • | • | • | • | |
| 도커 떼 |
• | • | • | • | • | • | • | • | • | |
| 서비스 직물 |
• | • | • | • | • | • | • | • | • | |
| Red Hat Open 변화 |
• | • | • | • | • | • | • | |||
| Windows Server (윈도우 서버) (독립 실행형) |
• | • | • | • | • | • | • | |||
| Linux 서버 (독립 실행형) |
• | • | • | • | • | • | • |
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 OCP(OpenShift Container Platform) 3.4 및 3.5
- ACS Mesosphere DC/OS 1.7.3 ~ 1.8.8
- ACS Kubernetes 1.4.5 ~ 1.6
- Kubernetes 이벤트, Kubernetes 인벤토리 및 컨테이너 프로세스는 Linux용 Log Analytics 에이전트 버전 1.4.1-45 이상에서만 지원됩니다.
- ACS 도커 스웜
비고
Microsoft Operations Management Suite에서 Azure Monitor로 진행 중인 전환의 일부로 Windows 또는 Linux용 Operations Management Suite 에이전트는 Windows용 Log Analytics 에이전트 및 Linux용 Log Analytics 에이전트로 참조됩니다.
지원되는 Windows 운영 체제
- Windows Server 2016
- Windows 10 Anniversary Edition(Professional 또는 Enterprise)
Windows에서 지원되는 Docker 버전
- Docker 1.12 및 1.13
- Docker 17.03.0 이상
솔루션 설치 및 구성
다음 정보를 사용하여 솔루션을 설치하고 구성합니다.
Azure Marketplace에서 또는 솔루션 갤러리에서 모니터링 솔루션 추가에 설명된 프로세스를 사용하여 Log Analytics 작업 영역에 컨테이너 모니터링 솔루션을 추가합니다.
Log Analytics 에이전트와 함께 Docker를 설치하고 사용합니다. 운영 체제 및 Docker 오케스트레이터에 따라 다음 메서드를 사용하여 에이전트를 구성할 수 있습니다.
- 독립 실행형 호스트의 경우:
- 지원되는 Linux 운영 체제에서 Docker를 설치 및 실행한 다음 Linux용 Log Analytics 에이전트를 설치하고 구성합니다.
- CoreOS에서는 Linux용 Log Analytics 에이전트를 실행할 수 없습니다. 대신 Linux용 Log Analytics 에이전트의 컨테이너화된 버전을 실행합니다. Azure Government 클라우드에서 컨테이너 작업을 하는 경우 CoreOS를 비롯한 Linux 컨테이너 호스트와 Azure Government Linux 컨테이너 호스트를 검토하세요.
- Windows Server 2016 및 Windows 10에서 Docker 엔진 및 클라이언트를 설치한 다음 에이전트를 연결하여 정보를 수집하고 Azure Monitor로 보냅니다. Windows 환경이 있는 경우 설치를 검토하고 Windows 컨테이너 호스트를 구성합니다 .
- Docker 다중 호스트 오케스트레이션의 경우:
- Red Hat OpenShift 환경이 있는 경우 Red Hat OpenShift에 대한 Log Analytics 에이전트 구성을 검토합니다.
- Azure Container Service를 사용하는 Kubernetes 클러스터가 있는 경우:
- Kubernetes에 대한 Log Analytics Linux 에이전트 구성을 검토합니다.
- Kubernetes에 대한 Log Analytics Windows 에이전트 구성을 검토합니다.
- Helm을 사용하여 Linux Kubernetes에 Log Analytics 에이전트를 배포합니다.
- Azure Container Service DC/OS 클러스터가 있는 경우 Azure Monitor를 사용하여 Azure Container Service DC/OS 클러스터 모니터링에서 자세히 알아보세요.
- Docker Swarm 모드 환경이 있는 경우 Docker Swarm에 대한 Log Analytics 에이전트 구성에서 자세히 알아보세요.
- Service Fabric 클러스터가 있는 경우 Azure Monitor를 사용하여 Monitor 컨테이너에서 자세히 알아보세요.
- 독립 실행형 호스트의 경우:
Windows를 실행하는 컴퓨터 에서 Docker 엔진 을 설치하고 구성하는 방법에 대한 자세한 내용은 Windows의 Docker 엔진 문서를 검토하세요.
중요합니다
컨테이너 호스트에 Linux용 Log Analytics 에이전트를 설치하기 전에 Docker를 실행해야 합니다. Docker를 설치하기 전에 에이전트를 이미 설치한 경우 Linux용 Log Analytics 에이전트를 다시 설치해야 합니다. Docker에 대한 자세한 내용은 Docker 웹 사이트를 참조하세요.
Linux 컨테이너 호스트 설치 및 구성
Docker를 설치한 후 컨테이너 호스트에 대해 다음 설정을 사용하여 Docker에서 사용할 에이전트를 구성합니다. 먼저 Azure Portal에서 찾을 수 있는 Log Analytics 작업 영역 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 Government 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 lsID 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 에이전트 구성
Red Hat OpenShift에 Log Analytics 에이전트를 추가하여 컨테이너 모니터링 데이터 수집을 시작하는 세 가지 방법이 있습니다.
- 각 OpenShift 노드에 직접 Linux용 Log Analytics 에이전트 설치
- Azure에 있는 각 OpenShift 노드에서 Log Analytics VM 확장 사용
- OpenShift 데몬셋으로 Log Analytics 에이전트 설치
이 섹션에서는 OpenShift 디먼 집합으로 Log Analytics 에이전트를 설치하는 데 필요한 단계를 설명합니다.
OpenShift 마스터 노드에 로그온하고 GitHub에서 마스터 노드로 yaml 파일 ocp-omsagent.yaml 을 복사하고 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에서 ocp-secretgen.sh yaml 파일 ocp-ds-omsagent.yaml 및 비밀 생성 스크립트를 복사합니다. 이 스크립트는 비밀 정보를 보호하기 위해 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 DaemonSets를 만들도록 선택할 수 있습니다.
비밀이 없는 기본 OMSagent DaemonSet yaml 파일
기본 Log Analytics 에이전트 DaemonSet yaml 파일의
<WSID>경우 WSID 및<KEY>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 1dkeiko@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 bytesomsagent 데몬셋을 생성하려면
sudo kubectl create -f omsagent-ds-secrets.yaml을 실행하십시오
Log Analytics 에이전트 DaemonSet이 다음과 같이 실행되고 있는지 확인합니다.
keiko@ubuntu16-13db:~# sudo kubectl get ds omsagentNAME DESIRED CURRENT NODE-SELECTOR AGE omsagent 3 3 <none> 1h
Kubernetes의 경우 스크립트를 사용하여 Linux용 Log Analytics 에이전트에 대한 작업 영역 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.shkubectl 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 bytesomsagent 데몬 집합을 만들려면
kubectl create -f ws-omsagent-de-secrets.yaml을 실행하십시오.
Log Analytics 에이전트 DaemonSet이 다음과 같이 실행되고 있는지 확인합니다.
root@ubuntu16-13db:~# kubectl get deployment omsagent NAME DESIRED CURRENT NODE-SELECTOR AGE omsagent 1 1 <none> 1hWindows를 실행하는 작업자 노드에 에이전트를 설치하려면 Windows 컨테이너 호스트 설치 및 구성 섹션의 단계를 따릅니다.
Helm을 사용하여 Linux Kubernetes에 Log Analytics 에이전트 배포
Helm을 사용하여 Linux Kubernetes 환경에 Log Analytics 에이전트를 배포하려면 다음 단계를 수행합니다.
"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다음을 실행
helm status "omsagent"하여 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 차트를 참조하세요.
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 컴퓨터에 MMA(Microsoft Monitoring Agent)를 설치합니다. 온-프레미스 환경에서 Windows를 실행하는 컴퓨터의 경우 Azure Monitor에 Windows 컴퓨터 연결을 참조하세요. Azure에서 실행되는 가상 머신의 경우 가상 머신 확장을 사용하여 Azure Monitor에 연결합니다.
Service Fabric에서 실행되는 Windows 컨테이너를 모니터링할 수 있습니다. 그러나 Azure에서 실행되는 가상 머신 과 온-프레미스 환경에서 Windows를 실행하는 컴퓨터 만 현재 Service Fabric에서 지원됩니다.
Windows에 대해 컨테이너 모니터링 솔루션이 올바르게 설정되었는지 확인할 수 있습니다. 관리 팩이 제대로 다운로드되었는지 확인하려면 ContainerManagement.xxx 찾습니다. 파일은 C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs 폴더에 있어야 합니다.
솔루션 구성 요소
Azure Portal에서 솔루션 갤러리 로 이동하여 컨테이너 모니터링 솔루션을 추가합니다. Windows 에이전트를 사용하는 경우 이 솔루션을 추가할 때 에이전트가 있는 각 컴퓨터에 다음 관리 팩이 설치됩니다. 관리 팩에는 구성 또는 유지 관리가 필요하지 않습니다.
- ContainerManagement.xxx이(가) C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs에 설치되었습니다.
컨테이너 데이터 수집 세부 정보
컨테이너 모니터링 솔루션은 사용하도록 설정한 에이전트를 사용하여 컨테이너 호스트 및 컨테이너에서 다양한 성능 메트릭 및 로그 데이터를 수집합니다.
데이터는 다음 에이전트 유형에 의해 3분마다 수집됩니다.
용기 기록
다음 표에서는 컨테이너 모니터링 솔루션에서 수집한 레코드 및 로그 검색 결과에 표시되는 데이터 형식의 예를 보여 줍니다.
| 데이터 형식 | 로그 검색의 데이터 형식 | 분야 |
|---|---|---|
| 호스트 및 컨테이너에 대한 성능 | 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, 컴퓨터, 컨테이너 이름, 컨테이너 호스트 이름, 이미지, 이미지 태그, 컨테이너 상태, 종료 코드, 환경 변수, 명령어, 생성 시간, 시작 시간, 완료 시간, 소스 시스템, 컨테이너 ID, 이미지 ID |
| 컨테이너 이미지 인벤토리 | ContainerImageInventory |
TimeGenerated, 컴퓨터, 이미지, 이미지 태그, 이미지 크기, 가상 크기, 실행 중, 일시 중지됨, 중지됨, 실패, 소스 시스템, 이미지 ID, 총 컨테이너 |
| 컨테이너 로그 | ContainerLog |
생성시간, 컴퓨터, 이미지 ID, 컨테이너 이름, 로그 엔트리 소스, 로그 엔트리, 소스 시스템, 컨테이너 ID |
| 컨테이너 서비스 로그 | ContainerServiceLog |
TimeGenerated, 컴퓨터, TimeOfCommand, 이미지, 명령, 소스 시스템, 컨테이너 ID |
| 컨테이너 노드 인벤토리 | 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, 컴퓨터, 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 Portal에서 솔루션을 사용하도록 설정하면 컨테이너 타일에 컨테이너 호스트 및 호스트에서 실행되는 컨테이너에 대한 요약 정보가 표시됩니다.
이 타일은 환경에 있는 컨테이너 수와 실패한 컨테이너, 실행 중 또는 중지되었는지에 대한 개요를 보여 줍니다.
컨테이너 대시보드 사용
컨테이너 타일 을 클릭합니다. 여기에서 다음으로 구성된 보기를 볼 수 있습니다.
- 컨테이너 이벤트 - 컨테이너 상태 및 실패한 컨테이너가 있는 컴퓨터를 표시합니다.
- 컨테이너 로그 - 시간에 따라 생성된 컨테이너 로그 파일의 차트와 로그 파일 수가 가장 많은 컴퓨터 목록을 표시합니다.
- Kubernetes 이벤트 - 시간에 따라 생성된 Kubernetes 이벤트 차트와 Pod가 이벤트를 생성한 이유 목록을 보여 줍니다. 이 데이터 집합은 Linux 환경에서만 사용됩니다.
- Kubernetes 네임스페이스 인벤토리 - 네임스페이스 및 Pod 수를 표시하고 해당 계층 구조를 표시합니다. 이 데이터 집합은 Linux 환경에서만 사용됩니다.
- 컨테이너 노드 인벤토리 - 컨테이너 노드/호스트에서 사용되는 오케스트레이션 형식의 수를 표시합니다. 컴퓨터 노드/호스트도 컨테이너 수로 나열됩니다. 이 데이터 집합은 Linux 환경에서만 사용됩니다.
- 컨테이너 이미지 인벤토리 - 사용된 컨테이너 이미지의 총 수와 이미지 유형 수를 표시합니다. 이미지 수도 이미지 태그로 나열됩니다.
- 컨테이너 상태 - 컨테이너를 실행하는 컨테이너 노드/호스트 컴퓨터의 총 수를 표시합니다. 컴퓨터는 실행 중인 호스트 수로도 나열됩니다.
- 컨테이너 프로세스 - 시간이 지남에 따라 실행되는 컨테이너 프로세스의 꺾은선형 차트를 표시합니다. 컨테이너 내에서 명령/프로세스를 실행하여 컨테이너도 나열됩니다. 이 데이터 집합은 Linux 환경에서만 사용됩니다.
- 컨테이너 CPU 성능 - 컴퓨터 노드/호스트에 대한 시간에 따른 평균 CPU 사용률의 꺾은선형 차트를 표시합니다. 또한 평균 CPU 사용률에 따라 컴퓨터 노드/호스트를 나열합니다.
- 컨테이너 메모리 성능 - 시간에 따른 메모리 사용량의 꺾은선형 차트를 표시합니다. 또한 인스턴스 이름에 따라 컴퓨터 메모리 사용률을 나열합니다.
- 컴퓨터 성능 - 시간 경과에 따른 CPU 성능 백분율, 시간 경과에 따른 메모리 사용률 및 시간 경과에 따른 사용 가능한 디스크 공간의 메가바이트 선형 차트를 표시합니다. 차트의 모든 줄을 마우스로 가리키면 자세한 내용을 볼 수 있습니다.
대시보드의 각 영역은 수집된 데이터에서 실행되는 검색의 시각적 표현입니다.
컨테이너 상태 영역에서 아래와 같이 위쪽 영역을 클릭합니다.
컨테이너 상태에 대한 정보를 표시하는 Log Analytics가 열립니다.
여기에서 검색 쿼리를 편집하여 수정하여 관심 있는 특정 정보를 찾을 수 있습니다. 로그 쿼리에 대한 자세한 내용은 Azure Monitor의 로그 쿼리 개요를 참조하세요.
실패한 컨테이너를 찾아서 문제 해결
Log Analytics는 컨테이너가 0이 아닌 종료 코드로 종료된 경우 실패 로 표시합니다. 실패한 컨테이너 영역에서 환경의 오류 및 실패에 대한 개요를 볼 수 있습니다.
실패한 컨테이너를 찾으려면
-
컨테이너 상태 영역을 클릭합니다.
- 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 쿼리 영역을 실험하여 고급 쿼리를 빌드할 수 있습니다.
로그 쿼리 저장
쿼리 저장은 Azure Monitor의 표준 기능입니다. 저장하면 유용하게 사용할 수 있는 항목들이 앞으로 쉽게 접근할 수 있게 됩니다.
유용한 쿼리를 만든 후 로그 검색 페이지의 맨 위에 있는 즐겨찾 기를 클릭하여 저장합니다. 그런 다음 나중에 내 대시보드 페이지에서 쉽게 액세스할 수 있습니다.
작업 영역에서 솔루션 제거
컨테이너 모니터링 솔루션을 제거하려면 Azure Portal, PowerShell 또는 Azure CLI 중 하나를 사용하여 솔루션을 제거하는 지침을 따릅니다.
다음 단계
자세한 컨테이너 데이터 레코드를 보려면 로그를 쿼리합니다.