잊을만하면 쏟아지는 T-mobile용 AC1900 짜리 ASUS 공유기. 이쯤이면 'T-mobile 그거'나 'ASUS 그거'라고 불려도 되지 않을까? 대부분 제조사 리퍼제품이거나 open box이거나 그렇지만 성능에 비해 매우 저렴하게 나와서 많이들 주문하는 것 같다. 쳐다보고 있자니 그것들이 쏟아지기 전에 원모델 중 하나(AC68U)를 요즘보다는 비싼 가격으로 구매했던터라 아쉬운 마음 뿐이다.

아무튼 얼마전에 아는 형님이 '그런 공유기' 모니터링 방법을 공유해주셨는데 멀린 펌업 => metric 수집 script 실행 (cron) => influxdb에 저장 => grafana에 표시하는 내용으로 요약할 수 있을 것 같다. 나의 경우 Asus 공식 펌웨어를 쓰고 있기 때문에 멀린 펌웨어로 올리는 과정이 필요한터라 SNMP로 어떻게 해보기로 했다.

SNMP를 지원하나?​

많은 OS, 라우터 등의 장비들이 snmp를 지원하는 것으로 알려져있다. Asus 공유기라고 안될 이유는 없는데 관리 메뉴에는(있을법도 하지만) snmp on/off 라던가 설정에 대한 내용이 없다. 그럼 net-snmp 같은 패키지를 설치해서 돌려야 하는데 공유기가 많이 알려진 배포판 리눅스가 올라간게 아니라서 어떻게 설치할 수 있는지 패키지 이름은 뭔지 알 수가 없다.

Download master와 ipkg, 그리고 net-snmp의 설치​

찾아보니 asus 공유기에서는 debian의 dpkg와 비슷한 ipkg를 사용할 수 있다고 한다. 그런데 이것 역시 기본적으론 설치되어 있지 않고 꼼수를 써야 가능하다. 먼저 공유기 뒷면에 있는 usb 포트에 스틱이든 하드든 꽂아준다. (단, 리눅스이므로 filesystem이 ext4나 ntfs 같은 형태여야 인식 가능) 공유기에서 인식을하면 download master를 설치할 수 있게 되는데 설치를 끝내면 연결한 외부 장치에 ipkg가 설치된다. (mount된 경로에 설치가 되기 때문에 빼면 안된다) ipkg로 net-snmp 설치 후 활성화하면 끝.

ipkg update
ipkg install net-snmp
app_set_enabled.sh net-snmp yes

수집은 어떻게?​

SNMP를 통해 정상적으로 정보를 얻을 수 있는지는 간단하게 snmpwalk 등을 이용하면 확인할 수 있겠다.

지속적으로 정보를 수집해서 db에 쌓아야 하는데 별도로 스크립트를 만들어서 돌리기는 싫고 (이럼 처음부터 스크립트를 만들어 돌리지 굳이 snmp로 할 이유가 없다) 어차피 influxdb를 쓸 생각이었으니 같은 곳에서 만든 telegraf를 써보기로 했다. Telegraf는 docker container로 돌리고 output 설정은 이미 설치되어 있는 influxdb에 맞게, snmp input에 대해서는 아래처럼 해줬다.

[[inputs.snmp]]
   agents = [ "xxx.xxx.xx.1:161" ]
   version = 2
   community = "public"

   [[inputs.snmp.field]]
     name = "hostname"
     oid = "RFC1213-MIB::sysName.0"
     is_tag = true
     
   [[inputs.snmp.field]]
     name = "uptime"
     oid = "DISMAN-EXPRESSION-MIB::sysUpTimeInstance"
     
   [[inputs.snmp.table]]
     name = "interface"
     inherit_tags = [ "hostname" ]
     oid = "IF-MIB::ifTable"
     [[inputs.snmp.table.field]]
       name = "ifDescr"
       oid = "IF-MIB::ifDescr"
       is_tag = true
       
   [[inputs.snmp.table]]
     name = "interface"
     inherit_tags = [ "hostname" ]
     oid = "IF-MIB::ifXTable"
     [[inputs.snmp.table.field]]
       name = "ifDescr"
       oid = "IF-MIB::ifDescr"
       is_tag = true
        
   [[inputs.snmp.table]]
     name = "interface"
     inherit_tags = [ "hostname" ]
     oid = "EtherLike-MIB::dot3StatsTable"
     [[inputs.snmp.table.field]]
       name = "ifDescr"
       oid = "IF-MIB::ifDescr"
       is_tag = true

이렇게 하고 나니 telegraf의 문제인 것 같은데 IF-MIB라는 OID를 인식못하는 문제가 발생. Community에서 찾은 글을 참고해 따로 snmp-mibs-downloader를 설치해줬다. (Docker image를 새로 만드는게 나을 것 같긴 한데 제대로 되는지만 보려고 container 내부에 들어가서 설치 후에 container를 restart 해줌. 설정된 persistent volume에 변경된 내용이 저장되는 것인지 restart 해줘도 문제없었다)

InfluxDB에서의 확인​

위와 같이 telegraf 설정을 한 경우 InfluxDB에서 확인을 해보면 (telegraf 기본 설정 중 inputs.cpu, inputs.disk 등을 제거하지 않은 경우) cpu, disk 등의 measurement 이외에 interface, snmp라는 measurement가 있는 것을 확인할 수 있다. 설정대로라면 snmp에는 host와 uptime 정보 정도, interface에는 network interface 별 정보들이 쌓이게 된다.

Grafana 연결과 dashboard 생성​

Grafana에서 data source로 influxdb를 설정하고 나서 쓸만한 dashboard를 찾아보니 마땅한게 없다. SNMP에 대한 것들은 있어도 보통은 cpu, storage 정보 정도라 공유기에서 큰 의미는 없을 것 같아서 직접 추가하기로 했다. SNMP의 OID들을 좀 더 확인해봐야 더 재미있는 것들을 볼 수 있을 것 같은데 일단은 throughput과 uptime만. (지금은 수집해서 쌓는 것도 uptime이랑 interface 별 in/out packet 수 정도뿐)

참고​

1. How to configure SNMP on Asus RT-AC68U

2. Using Telegraf, InfluxDB and Grafana to Monitor Network Statistics

ELK stack을 사용하는 것. 괜찮다고 생각하지만 여전히 쉽지는 않다. 난이도를 떠나서 번거로운 요소들이 있다고 생각되는데 개인적으로 가능한 logstash를 활용하려고 하는게 더 번거롭게 만드는게 아닌가 싶다. 사족이지만.

어찌되었든 Docker container의 로그를 ELK에서 수집하기 위해서는 몇가지 방법을 생각해 볼 수 있을 것 같다.

1. Autodiscovery 기능을 활용

비교적 최근에 만들어진 기능으로 보이는데 내용을 훑어봤을 때 감은 오지만 로그수집 보다는 메트릭 수집의 목적이 강한 것 아닌가 싶다. 결론적으로 잘 되지 않아서 다른 방법을 알아보기로 했다.

https://www.elastic.co/kr/webinars/elasticsearch-log-collection-with-kubernetes-docker-and-containers

2. Syslog log driver를 사용하는 방법

Docker에서 제공하는 log driver 중 syslog가 있는데 syslog를 log driver로 설정한 호스트에서는 container 로그들이 모두 syslog에 쌓이기 때문에 filebeat로 syslog만 수집하면 된다. 하지만 syslog의 다른 로그들과 혼재되면 그걸 골라내는 것도 일일 것 같다.

3. Fluentd를 통해 elasticsearch로 로그를 전송하는 방법

역시 docker의 log driver로 fluentd를 지정해서 모든 container의 로그를 fluentd로 모은 후에 plugin을 이용해 elasticsearch에서 인덱싱하는 방법이 있을 수 있다. Container만 본다면 괜찮은 방법이라고 생각하는데 나의 경우엔 filebeat도 사용해야하는 상황이었기에 기존의 로그수집 방식을 fluentd로 변경해서 통합하거나 두가지를 혼용해야 할 것 같다.

4. Volume mount를 이용한 방법

Docker container 내부에서 로그를 파일로 쌓는 경우 해당 경로를 호스트의 특정 경로와 마운트하고 filebeat가 마운트 된 경로의 로그파일들을 수집하는 방식인데 application을 개발할 때 로그를 파일로 쌓도록 강제해야 하고 로그 경로가 공유되어야 한다는 문제가 있다. 개발 측면에서도 번거롭고 배포 과정에서도 volume 지정을 빼먹으면 안되니 비효율적이라고 생각한다.

5. Filebeat에서 add_docker_metadata processor를 사용하는 방법

마지막으로 검토해서 적용한 내용인데 filebeat에서 간단한 설정만으로 기존의 container나 시스템에 변경을 가하지 않고 로그를 수집할 수 있다. 문서(Enriching logs with Docker metadata using Filebeat)에 의하면 6.0.0 beta1 부터 새로 추가된 기능인 것 같다. Docker container의 stdout 로그들도 실제로는 호스트에 파일로 쌓이고 있기 때문에 해당 파일들을 전송하는 것 같은데 재미있는건 로그외의 container name, image 정보 등도 함께 날라가서 단순히 로그의 내용만 확인하는 데에는 큰 문제가 없다.

add_docker_metadata processor를 사용해보니​

위에 링크된 문서를 참고해서 기존에 동작중인 filebeat의 prospector에 몇 줄 추가하고 restart를 하니 언급한대로 로그수집은 간단하게 된다.

# Sample prospectors
filebeat.prospectors:

- input_type: log
  paths:
    - /var/log/syslog
  fields:
    document_type: syslog

- type: log
  paths:
    - '/var/lib/docker/containers/*/*.log'
  json.message_key: log
  json.keys_under_root: true
  processors:
    - add_docker_metadata: ~
  fields:
    document_type: docker

로그 구분을 위해 사용하던 document_type이 deprecated 된 field라 custom field에 넣어준 것을 제외하고는 위의 문서의 내용과 동일하다. 로그는 아래와 유사한 형태로 kibana에서 확인할 수 있다.

Container의 이름도 표시되니 container 이름이나 image로 조회해서 살펴볼 수 있을 것이다. log field에 넘어오는 전체 로그 메세지는 경우에 따라 다시 별도의 field 들로 분류할 필요가 생기겠지만 간단하다.

time field에서 발생한 conflict​

위의 이미지는 이미 문제를 해결하고 난 이후라 문제가 없어보인다. 원래 기본적으로는 time field가 넘어오게 되는데 나의 경우에는 다른 곳에서 filebeat가 보내고 있는 로그가 동일한 인덱스로 생성되고 있는 상황이었고 다른 로그의 time field와 type이 달라서 conflict이 발생하는 걸 볼 수 있었다.

(기존의 인덱스에 생성되어 있는 time field는 text, docker container 로부터 넘어오는 time field는 date) 이미 만들어진 index의 field type을 변경하는 것은 index 복제, field 변경, re-index 작업 등을 해야하니 무리라고 생각해서 container 로부터 넘어오는 field에만 조작을 가하기로 했다. (이런 경우에는 logstash가 있는게 불편하지만 편하다!?)

filter {
    if [fields][document_type] == "docker" {
        mutate {
            convert => { "time" => "string" }
            add_field => [ "received_at", "%{@timestamp}" ]
        }
        date {
            match => [ "time", "ISO8601" ]
            remove_field => "time"
        }
    }
}

위와 같이 logstash에 filter를 하나 추가해줬는데 이미 custom field로 document_type이 날라오고 있으니 구분해서 처리하고 time field를 string으로 변환해봤다. 처음엔 변환만 했는데도 동일한 문제가 생겨서 string으로 변환 후 timestamp로 찍히도록 date filter를 추가하고 time field는 날려버렸다. 차라리 time field를 다른 이름으로 rename 하는게 낫지 않을까도 생각해봤는데 timestamp가 있으니 의미는 없을 것 같다. Convert를 했는데 왜 동일한 문제가 생기는지는 좀 의문.

Bitbucket의 경우 저장소가 기본적으로 private이고 clone을 하려면 key를 통해 ssh로 진행하거나 http의 경우 password 입력 필요
이 때 사용할 수 있는게 prompt인데, playbook 실행시 prompt에 기술된 문자열이 뜨면서 입력을 받고 입력된 문자열은 name으로 지정한 변수로 저장됨
Built-in으로 보이는 vars_prompt와 함께 사용하고 private 항목을 yes로 하면 입력하는 문자열이 화면에 표시되지 않고 가려짐

- hosts: test_host
  vars:
    bitbucket_username: test_user
  vars_prompt:
    - name: bitbucket_password
      prompt: Password for bitbucket?
      private: yes
  tasks:
    - name: Clone the repository
      git:
        repo: 'http://{{ bitbucket_username }}:{{ bitbucket_password }}@bitbucket.org/test_group/test_repo.git'
        dest: '/tmp/test_repo'

http로 clone하면서 username과 password를 넘겨주려면 위의 예시처럼 username:password 형태로 colon으로 묶어주면 가능

Slack notification

Ansible에 slack module이 있는데 slack의 webhook을 사용하도록 되어있음
우선 Slack에서 incoming webhook을 하나 추가하거나 존재하는 webhook에 configuration을 추가해야 함
Configuration 추가시 메세지를 전송할 channel을 지정해야 하는데 slack module에도 channel key가 존재함
Slack module의 channel을 지정하면 Slackbot으로 메세지가 들어옴
Module에서 channel을 지정하지 않고 webhook 설정을 그대로 따라가게 두면 webhook 설정대로 지정한 channel에 메세지가 전달됨
이 때, channel 별로 token이 달라지므로 playbook에서는 해당 token만 교체하면서 사용

Docker for the node apps

Node 기반의 application을 dockerization 할 때 아래와 유사한 방식을 사용(Angular.js 환경에서 사용해 봄)

1. Base image 지정 (node official image)
2. package.json 복사
3. npm install
4. Copy source files (이 때 node_modules는 복사되지 않도록 .dockerignore 파일에 등록)
5. Expose ports and something...
6. Run application (CMD를 이용 npm start)

Docker container의 부하 분산과 auto scaling을 고민해야 하는 상황인데 부하 분산을 하기 위해서는 부하 테스트를 어떻게 할지부터 생각해봐야한다. 또 어느 정도의 stress에서 성능이 얼마나 떨어지는지 알아야 하기 때문에 모니터링도.

1. Environments​

며칠 고민하고 검토해서 현재는 아래와 같은 상태로 만들어둔 상태인데 서비스 오케스트레이션을 위해 Apache Mesos와 Marathon framework을 사용하다보니 편한 것도 있는데 고민해야할 요소들도 많아진 것 같다. 단지 부하를 가하고 모니터링이 되는지 정도만 확인할거라 테스트 대상이 되는 web container는 python으로 hello world만 뿌려주는 간단한 웹앱을 사용했고 container 자체에는 cpu 0.5 core, memory 256MB만 할당. Load balancer는 marathon에서 제공하는 marathon-lb인데 0.5 core / 128MB만 할당해 두었다.

2. Stress는 ngrinder로​

Stress를 어떻게 줄까 고민하다가 Apache JMeter를 처음에 고려했는데 사용에 번거로운 요소들이 조금 있고 맥에서는 UI가 별로라 ngrinder를 시도해보게 되었다. 눈에 띄는 버그가 있긴 했지만 단순히 부하만 가하고 싶을 때 간편하게 할 수 있고 확장이 쉬워보이는게 장점인 것 같다.

(1) Agent, controller 사이의 통신 문제

ngrinder에서는 agent 하나에서 생성하는 process의 thread 하나를 가상 유저로 취급하는 것으로 보이는데 agent가 동작하는 환경을 고려했을 때 process와 thread의 수가 높으면 controller와의 통신에 문제가 생긴다. 찾아보니 이 문제는 이미 보고된 내용인 것 같고 현재는 적당히 수치를 조절하면서 사용해야 할 것 같다. 실제로 문제가 발생하는 process, thread 수보다 적게 설정해서 테스트를 해보니 agent가 돌아가는 vm의 cpu usage가 거의 full이었는데 agent가 돌아가는 환경에 대한 문제로 인식해야 할 것 같음.

(2) Agent 추가를 통한 stress 범위 확장과 클러스터링

더 많은 stress를 가하고 싶다면 agent를 확장하는 방법도 있는데, 비현실적이지만 단순히 부하만 가하기 위해서 처음에 vm 10대에서 agent를 돌리다가 현재는 5대로 줄여놓은 상태. 나중에 script를 추가하거나 변경하게 되었을 때 필요하면 다시 늘리면 된다. 아직 해보지는 않았지만 문서 상으로는 ngrinder controller의 경우 clustering이 가능한 것 같다.

(3) Test script로 다양한 시뮬레이션 가능

비현실적인 가상의 stress를 테스트하는 거지만 script 추가, 수정으로 조금 더 현실적인 테스트가 가능하게 되어있다. 예를 들어 가상 유저의 think time을 고려하고 싶다면 script에 sleep을 넣는 식으로 구현이 가능.

(4) Monitor의 한계

Target이 되는 시스템 모니터 용으로 사용할 수 있는 모듈이 controller에 들어있어서 다운로드 후에 target에 넣고 돌릴 수 있게 되어있는데 target의 ip와 port를 설정파일에 넣고 바인딩하도록 되어있다. 이 방식은 container에서 사용하기 어렵거나 가능하더라도 번거로워질 것 같다. Marathon framework에서는 container 별로 가상 ip를 부여하는 방식을 지원하려고 하는 것 같은데 아직 완전하지 않고 ip를 굳이 할당하고 싶다면 별도로 vip를 부여할 수 있도록 구성해줘야 한다.

3. 모니터링을 위해 cAdvisor를 사용해보자​

ngrinder의 monitor도 사용하기 어렵고 일반적인 모니터링 도구인 zabbix, cacti, nagios 등도 container에는 적합하지 않다는 생각을 했는데 이유는 아래와 같다.

(1) Target에 binding 되는 형태

모니터링 지표들을 agent 형태의 모듈들이 직접 중앙으로 쏴주는 형태라면 괜찮을거라고 생각하는데 거꾸로 중앙에서 각 container에 접근해야 하는 형태라면 혹은 그렇지 않더라도 위에서처럼 target 각각의 ip나 hostname으로 바인딩해야 한다면 번거로워질 것 같다.

(2) Host와 container를 함께 관리하기 어렵다

(1)의 문제를 갖고 있지 않더라도 일반적인 tool로는 container와 host 모두를 함께 확인하기 어렵다. 각각을 다른 모니터링 대상으로 보고 따로 관리하면 가능할텐데 한 host에 어떤 container들이 올라가 있고 각각의 container가 어떤 상태인지, 부하가 가해졌을 때 host는 어떻게 되는지를 함께 확인할 수 있어야 더 유용하다고 본다.

(3) Container 이중화의 문제

부하를 분산하기 위해, 또는 다른 이유로 하나의 container를 이중화 하거나 여러개로 분산하는 경우 분산된 container들 각각의 상태와 또 하나의 서비스 관점에서 통합된 지표를 확인할 필요가 있을 것 같다.

이 내용들을 정리하자면 일반적인 모니터링 도구들은 물리적인 서버나 vm에 초점을 맞추고 있다는 생각이고 그 위에서 동작하는 container의 모니터링은 조금 다른 관점에서 접근할 필요가 있다고 본다. 그래서 docker 모니터링 도구들이 있는지 확인해보게 되었는데 아래의 글을 보고 우선은 cAdvisor를 검토해보기로 했다.

http://rancher.com/comparing-monitoring-options-for-docker-deployments/

우선은 Marathon framework으로 mesos slave node 각각에 deploy를 했다. 아래의 json을 curl로 날리면 끝. 아니면 직접 marathon ui에서 생성해도 된다. 최근의 marathon은 constraints 설정으로 각 node에 container가 하나씩만 배포할 수 있는 기능을 제공하고 있다. 또, network을 HOST 모드로 지정하면 BRIDGE 모드에서처럼 container와 host의 port를 각각 매핑하지 않아도 되고 marathon의 service port가 임의로 붙지 않아서 편하다.

{
  "id": "cadvisor",
  "cmd": null,
  "cpus": 0.5,
  "mem": 256,
  "disk": 0,
  "instances": 4,
  "container": {
    "docker": {
      "image": "google/cadvisor",
      "network": "HOST",
      "privileged": true,
      "parameters": []
    },
    "type": "DOCKER",
    "volumes": [
      {
        "hostPath": "/",
        "containerPath": "/rootfs",
        "mode": "RO"
      },
      {
        "hostPath": "/var/run",
        "containerPath": "/var/run",
        "mode": "RW"
      },
      {
        "hostPath": "/sys",
        "containerPath": "/sys",
        "mode": "RO"
      },
      {
        "hostPath": "/var/lib/docker",
        "containerPath": "/var/lib/docker",
        "mode": "RO"
      }
    ]
  },
  "portDefinitions": [
    {
      "port": 8080,
      "protocol": "tcp",
      "name": null,
      "labels": null
    }
  ],
  "env": {},
  "labels": {},
  "healthChecks": [],
  "constraints": [
    [
      "hostname",
      "UNIQUE"
    ]
  ]
}

cAdvisor까지 배포된 후 ngrinder로 간단하게 부하를 발생시켜봤다. Script 등은 그대로 두고 agent는 하나만 사용하는 것으로 해서 테스트를 해보니 아래 그림처럼 cAdvisor의 그래프가 변화한다. 우선은 CPU만 확인해봤는데 container 내부에서는 대략 80% 이하로 cpu를 점유하는 것 같고 동작중인 host 전체에서는 50% 정도의 사용량을 찍었다. 여기서 host의 50% 점유율은 테스트 대상이 되는 container가 단독으로 만들어낸 사용량은 아니지만 (LB 등도 돌아가고 있으므로) container의 사용량이 올라갈수록 container가 동작중인 host에도 많은 부하가 걸림을 알 수 있다.

4. Container와 host에 걸리는 부하​

간단한 부하테스트와 모니터링이 가능한 것은 확인했는데 auto scaling을 구현하는게 어찌보면 최종 목표이기 때문에 단일 container가 감당하지 못할 정도의 부하를 줄 수 있는지 확인해보기로 했다. 그래서 ngrinder agent를 5개로 늘려 가상 사용자를 2500으로 만들어서 다시 테스트.

위 그림처럼 테스트 도중에 TPS가 0으로 떨어지고 이미지는 첨부하지 않았지만 그 시점부터 error가 발생한다. 이 때 container와 host의 상태는 어떨까? 아래 그림처럼 container는 본인에게 할당된 core 이상을 점유하는 경우가 발생하고, host (2core 짜리 VM)도 거의 100%에 가까운 사용량을 보이다가 줄어든다.

테스트 후에 웹앱에 접근해보니 안되길래 container 내부의 로그를 확인해보니 아래 이미지처럼 SocketServer에서 오류가 발생해서 더 이상 서비스가 안된다. 오류 발생 이후에 접근이 안되는데도 200이 찍히는건 이해가 안되지만 일단 서비스가 죽을 정도의 부하를 발생시킬 수 있다는 걸 알았고 그걸 모니터링 할 수 있으니 성공.

5. Load balancing​

부하를 걸어서 서비스를 죽여는 봤으니 load balancing을 하면 어떻게 될지 궁금해졌다. 당연히 개선되겠지만 auto scaling을 구현했을 때 그 기능이 유효할지는 알아야 하니까. 부하는 동일하게, 테스트 대상인 웹앱의 instance를 2개로 늘려서 다시 테스트. 이 때 ngrinder가 가리키는 url은 LB가 된다. (instance가 하나일때도 동일했음) LB가 request를 2개의 container에 적당히 알아서 분배해야할테니 죽더라도 어느 정도 개선된 지표가 확인되어야만 한다.

위 그림처럼 ngrinder에서 테스트 오류가 발생하지 않았고 TPS는 container가 하나일 때에는 최대 1400 정도였던 것이 1860까지 올라갔다. 이 때 부하를 받은 2개의 container와 VM의 cpu 사용량 상태는 아래와 같았다. (container는 각각 다른 VM에 올라가도록하고 해당 VM에는 테스트용 container, cAdvisor 이외에는 아무것도 없는 상태)

두개의 container 모두 할당된 core 이상의 점유율을 보이긴 했지만 서비스가 죽지는 않았고 그 상태에서 VM의 cpu 사용량은 50%를 넘지는 않았다. 추가로 LB가 올라가있는 VM의 점유율이 상당히 높아진 것도 확인.

6. cAdvisor의 장단점​

(1) 장점

위에 링크된 비교 페이지에서처럼 cAdvisor는 구축이 무척 간단하다. 또 VM과 container의 상태 확인이 가능하다는 것도 도움이 된다.

(2) 단점

특정 시점의 상태를 다시 확인할 수가 없고 정확한 결과값이 아니라 그래프로만 표시되어서 정확한 분석이 어렵다. REST API를 제공하는 것으로 봐서는 내부에서는 data를 쌓을 것 같기도 한데 UI로는 확인할 수가 없었다. REST API를 호출해야봐야 알겠지만 API로 제공하는 data도 그 순간의 data 뿐일수도 있다. 또, host와 container의 상태를 확인할 수는 있지만 한 화면에서 보는 것은 불가능해서 상당히 불편했는데 측정된 지표들이 시간에 따라 계속 흘러가기 때문에 동시에 확인하는 것이 힘들고 각 host에 설치되어야 하지만 클러스터링이 지원되지 않아 host 별로 따로 접속해서 확인해야 한다. Mesos, marathon과 엮어서 생각해봤을 때에는 mesos 내부에서 관리하는 container의 id와 marathon에서의 application 이름(예를 들면 simple-webapp 같은 사람이 인지할 수 있는 이름)이 매칭이 어려운데 cAdvisor에서 표시하는 container는 marathon에서의 application 이름이 아닌 것도 문제.

7. 더 고민할 것들​

Auto scaling을 위해서는 scaling 시점을 결정해야 하기 때문에 container와 VM의 상태에 대한 data를 얻을 수 있어야만 한다. 더 확인해봐야 하겠지만 cAdvisor의 data를 InfluxDB나 Redis 등에 전송한 후에 그 곳에서 쌓이는 data를 가지고 처리하는 방법도 있을 것 같고 아예 다른 모니터링 도구를 활용하는 방법도 생각해봐야겠다.