kolla-ansible with elasticsearch

elasticsearch/fluentd/kibana를 kolla-ansible 통해 배포하고 사용하는 방법에 대해 알아보도록 하자.

Build

먼저 아래와 같은 방식으로 elasticsearch/fluentd/kibana image를 build 하고 지정해놓은 docker registry에 push 한다.

(kolla-venv) root@deploy:/home/kolla/tools# ./build.py elasticsearch --base ubuntu --registry deploy001:5000 -t source --push
INFO:kolla.common.utils:Found the docker image folder at /home/kolla/docker
INFO:kolla.common.utils:Added image base to queue
INFO:kolla.common.utils:Attempt number: 1 to run task: BuildTask(base)
INFO:kolla.common.utils.base:Building started at 2021-02-23 21:42:03.717805
...

(kolla-venv) root@deploy:/home/kolla/tools# ./build.py kibana --base ubuntu --registry deploy001:5000 -t source --push
INFO:kolla.common.utils:Found the docker image folder at /home/kolla/docker
...

(kolla-venv) root@deploy:/home/kolla/tools# ./build.py fluentd --base ubuntu --registry deploy001:5000 -t source --push
INFO:kolla.common.utils:Found the docker image folder at /home/kolla/docker
INFO:kolla.common.utils:Added image base to queue
...

위와 같이 수행하게 되면 아래와 같은 이미지가 생성되게 된다.

(kolla-venv) root@deploy:~# docker images | grep -E "fluentd|elastic|kibana"
deploy001:5000/kolla/ubuntu-source-fluentd                             11.0.0    4347cf611252   4 minutes ago   496MB
deploy001:5000/kolla/ubuntu-source-kibana                              11.0.0    501995ed4e79   12 hours ago    507MB
deploy001:5000/kolla/ubuntu-source-elasticsearch                       11.0.0    e2e5b6c78b47   12 hours ago    581MB
deploy001:5000/kolla/ubuntu-source-elasticsearch-curator               11.0.0    f38643f17b4a   12 hours ago    323MB
deploy001:5000/kolla/ubuntu-source-prometheus-elasticsearch-exporter   11.0.0    96426168c584   12 hours ago    269MB

deploy

이제 배포를 진행해보자.
배포를 위해서는 globals.yml 내에 central_logging 및 fluentd에 대한 enable이 필요하다.

## logging

enable_central_logging: "yes"
enable_fluentd: "yes"
enable_elasticsearch_curator: "yes"

참고로 curator는 일정기간이 지난후 indice들을 제거하는 정책을 수행하는 것이다.

• https://docs.openstack.org/kolla-ansible/latest/reference/logging-and-monitoring/central-logging-guide.html

이제 kolla-ansible 을 통해 배포해보자.

배포하게 되면 kibana 및 elasticsearch는 kolla_external_vip_address로 binding 되게 되고 해당 IP에 5601 포트로 접속하게 되면 아래와 같이 kibana dashboard가 출력되게 된다.

위 그림에서 볼수 있듯이 flog라는 prefix를 가지는 indices가 생성되어 있음을 알수 있다.

아래와 같이 flog-*에 @timestamp를 time filter로 하는 index pattern을 생성하게 되면

discover 를 통해 log 정보를 확인 및 분석할수 있다.

참고

• docs.openstack.org/kolla-ansible/latest/reference/logging-and-monitoring/central-logging-guide.html

Configuration 확인

실제 controller나 compute node에 /etc/kolla/fluentd/td-agent.conf 내에 아래와 같은 output filter가 생성되어있음을 확인할 수 있다.

<match *.**>
    @type copy
    <store>
       @type elasticsearch
       host xx.xx.xx.100
       port 9200
       scheme http



       logstash_format true
       logstash_prefix flog
       flush_interval 15s
       reconnect_on_error true
       buffer_type file
       buffer_path /var/lib/fluentd/data/elasticsearch.buffer/openstack.*
    </store>
</match>

또한 elasticsearch에 수집되는 데이터를 아래와 같이 조회해볼수 있다.

root@control001:~# curl -XGET '[kolla_vip_internal_address:9200]/_cat/indices?pretty'
green open flog-2021.02.24 DEFa_xCvQqqVjneEw8JUdg 5 1 96505 0 94.3mb 48.4mb
green open .kibana_1       PHZKdPTTRZCp1oFLIJ-_2A 1 1     4 0   41kb 20.5kb

실제 kibana는 kolla_vip_external_addres:5601 및 kolla_vip_internal_address:5601로 binding 되고
elasticsearch는 kolla_vip_internal_address:9200으로 binding 된다.

root@control001:~# netstat -tnlp | grep -E '9200|5601'
tcp        0      0 kolla_vip_internal_address:9200       0.0.0.0:*               LISTEN      4329/haproxy
tcp        0      0 control001_ip_addres:5601        0.0.0.0:*               LISTEN      1809/node
tcp        0      0 kolla_vip_internal_address:5601       0.0.0.0:*               LISTEN      4329/haproxy
tcp        0      0 kolla_vip_external_address:5601       0.0.0.0:*               LISTEN      4329/haproxy
tcp6       0      0 control001_ip_addres:9200        :::*                    LISTEN      1788/java

참고로 elasticsearch node는 별도로 구성하는 것을 추천한다.
만약 controller내에 같이 동작시킬경우 memory를 좀더 넉넉히 사용할것을 추천한다.
(memory가 적을 경우 docker ps로 확인시 지속적인 restart와 함께 error 137가 나올수 있다. 이는 OOM-killber에 의해 kill되어 다시 시작됨을 의미한다.)