はじめに
こんにちは。インフラチームの高畑です。
今回、 curator を利用して AWS Elasticsearch Service に登録されているインデックスを削除するようにしてみたのでご紹介します！
curator とは
Elastic 社が提供する Elasticsearch の運用管理ツールで、インデックスのリスト表示や削除などが手軽に行えます。
curl を使用した場合のインデックスリスト表示
[user@hostname ~]# curl -XGET https://vpc-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxap-northeast-1.es.amazonaws.com/_cat/indices?v health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open api-nginx-access-2018.11.10 NtPFJq7gQ06fDZ8xtqarOA 5 1 35248 0 2.9mb 2.9mb yellow open api-nginx-access-2018.11.08 2zAfE-neQ0-2ghTfZQkxsA 5 1 40706 0 4.1mb 4.1mb yellow open api-nginx-access-2018.11.07 uxd-OGsbQq-k4qoteAPaGw 5 1 40406 0 4.1mb 4.1mb yellow open api-nginx-error-2018.11.03 9bAwxr8lSJSe1J3UE5AUfg 5 1 521 0 222.6kb 222.6kb yellow open ap-nginx-access-2018.11.05 VowpBW7SStmPm94xbG044A 5 1 168 0 223.3kb 223.3kb yellow open api-nginx-error-2018.11.04 rgKkhzhcR06eFnerLx54aw 5 1 1 0 8kb 8kb yellow open ap-nginx-access-2018.10.31 2LznB-GoTBm5fjb_T4bN9w 5 1 175 0 310.4kb 310.4kb yellow open api-nginx-access-2018.11.09 ysINQk6vRUO8FLGOiRcmnA 5 1 38718 0 3.8mb 3.8mb yellow open ap-nginx-access-2018.11.09 mU3ABP35Ste0VsJU64jpHQ 5 1 214 0 412.6kb 412.6kb yellow open ap-nginx-error-2018.11.08 wJIVXbnpSUGlpRr4KwcmwQ 5 1 8 0 61.2kb 61.2kb yellow open ap-nginx-access-2018.11.08 9aE7-pCTQtWbauq_7aI7xg 5 1 230 0 378.2kb 378.2kb yellow open api-nginx-error-2018.11.10 ZchNOQfCS4GKZ3FKWW1cfg 5 1 6 0 35.9kb 35.9kb yellow open api-nginx-access-2018.11.04 7D0J_NXVT6Wkmaf83B-kQw 5 1 35703 0 3.1mb 3.1mb yellow open api-nginx-error-2018.10.31 gnFgi1UGQbKHqCS1-m6eRg 5 1 883 0 320.6kb 320.6kb yellow open ap-nginx-access-2018.11.13 5VaWNCv9SNauh_1FCWSLrw 5 1 7 0 49.7kb 49.7kb yellow open api-nginx-access-2018.11.03 CBYDBAniRHiY-KzKiz8eiA 5 1 36741 0 3.2mb 3.2mb yellow open api-nginx-access-2018.11.02 RvdI42J0TrmC-lycFNWHjg 5 1 38100 0 3.6mb 3.6mb yellow open api-nginx-error-2018.11.09 qHjKeVtMTyOcbePYSVF5sA 5 1 538 0 220.2kb 220.2kb yellow open api-nginx-error-2018.11.05 _3PJCIgMT9mlbVh9jGzJNg 5 1 2 0 14.9kb 14.9kb yellow open ap-nginx-access-2018.11.01 IzjvuxKxRomqQdElicP10Q 5 1 157 0 260.2kb 260.2kb yellow open api-nginx-error-2018.11.01 oJnvclQkQtmr-btW9WkcIA 5 1 8 0 55.7kb 55.7kb yellow open ap-nginx-access-2018.11.03 kjFlEFifQEKXkVmfeomniw 5 1 96 0 227.8kb 227.8kb yellow open ap-nginx-access-2018.11.07 q4GQX8pORZS1slQSzJlsbQ 5 1 131 0 252.5kb 252.5kb yellow open ap-nginx-access-2018.10.30 Et4smDEyQuSLawlLOdnkHQ 5 1 144 0 294.3kb 294.3kb yellow open ap-nginx-access-2018.11.11 Owe3aa4gQ7aCs5mkkIA3kw 5 1 19 0 133.4kb 133.4kb yellow open api-nginx-access-2018.11.12 9n4sfrfFT4yCa7Kp5IFZNg 5 1 40121 0 4mb 4mb yellow open api-nginx-access-2018.10.31 6YxRk1kkRuWDAGDrndXApA 5 1 40941 0 4mb 4mb yellow open api-nginx-access-2018.10.30 bRZ_7_YeT0SZSyC0j1i7mg 5 1 38288 0 3.6mb 3.6mb yellow open api-nginx-access-2018.11.11 VfaS5hVKTDyFXLdjHVSecQ 5 1 35786 0 3.1mb 3.1mb yellow open api-nginx-error-2018.11.06 vC_QtLPmTRugJZsR7du4_w 5 1 289 0 278.6kb 278.6kb yellow open ap-nginx-access-2018.11.12 c97C6639SNatlNJpsVKFeA 5 1 355 0 364.2kb 364.2kb yellow open ap-nginx-access-2018.11.06 tV7vbxDXR_aEXwbKhWp0Sw 5 1 183 0 298.4kb 298.4kb yellow open api-nginx-access-2018.11.01 4UHB-q-hSCWnTaQgoDmizQ 5 1 40240 0 3.9mb 3.9mb yellow open api-nginx-access-2018.11.05 2Jhq-KLEQLm3HtJNrf6j6w 5 1 38685 0 3.7mb 3.7mb yellow open api-nginx-error-2018.11.07 99-0rOfVS42rH1vm-9CDnw 5 1 312 0 161.4kb 161.4kb yellow open api-nginx-error-2018.11.02 KHLZjLKRTK-wDnCLcD7Fdw 5 1 550 0 302.8kb 302.8kb yellow open ap-nginx-access-2018.11.02 7iB_pIGEQlygM7OQrs2CVA 5 1 136 0 230.7kb 230.7kb yellow open api-nginx-error-2018.11.12 Sg7P8WneQz2H_gTzwAKxfw 5 1 277 0 145.2kb 145.2kb yellow open api-nginx-access-2018.11.06 zwYwZHYZQcKVY90MgI3jgA 5 1 41895 0 4.2mb 4.2mb yellow open api-nginx-error-2018.11.08 qhH5k3cqRb-Lu9qvPh_FNw 5 1 537 0 220.4kb 220.4kb yellow open api-nginx-error-2018.10.30 HhB_3KPJRZe6lJBOpz9cEQ 5 1 41 0 255kb 255kb green open .kibana -mBnXlR2QQGCuTDFEScqng 1 0 11 1 30.3kb 30.3kb yellow open ap-nginx-access-2018.11.04 Zh-SgjiITye2tW1krPgT0g 5 1 96 0 264.7kb 264.7kb yellow open api-nginx-access-2018.11.13 Ztu6V_jsTfqAx7HVcFuRNw 5 1 709 0 209.6kb 209.6kb yellow open api-nginx-error-2018.11.11 W44PXSWTQ9aTdE2TtMN2LQ 5 1 266 0 122.6kb 122.6kb
curator を使用した場合のインデックスリスト表示
[user@hostname ~]# curator_cli show_indices .kibana ap-nginx-access-2018.10.30 ap-nginx-access-2018.10.31 ap-nginx-access-2018.11.01 ap-nginx-access-2018.11.02 ap-nginx-access-2018.11.03 ap-nginx-access-2018.11.04 ap-nginx-access-2018.11.05 ap-nginx-access-2018.11.06 ap-nginx-access-2018.11.07 ap-nginx-access-2018.11.08 ap-nginx-access-2018.11.09 ap-nginx-access-2018.11.11 ap-nginx-access-2018.11.12 ap-nginx-access-2018.11.13 ap-nginx-error-2018.11.08 api-nginx-access-2018.10.30 api-nginx-access-2018.10.31 api-nginx-access-2018.11.01 api-nginx-access-2018.11.02 api-nginx-access-2018.11.03 api-nginx-access-2018.11.04 api-nginx-access-2018.11.05 api-nginx-access-2018.11.06 api-nginx-access-2018.11.07 api-nginx-access-2018.11.08 api-nginx-access-2018.11.09 api-nginx-access-2018.11.10 api-nginx-access-2018.11.11 api-nginx-access-2018.11.12 api-nginx-access-2018.11.13 api-nginx-error-2018.10.30 api-nginx-error-2018.10.31 api-nginx-error-2018.11.01 api-nginx-error-2018.11.02 api-nginx-error-2018.11.03 api-nginx-error-2018.11.04 api-nginx-error-2018.11.05 api-nginx-error-2018.11.06 api-nginx-error-2018.11.07 api-nginx-error-2018.11.08 api-nginx-error-2018.11.09 api-nginx-error-2018.11.10 api-nginx-error-2018.11.11 api-nginx-error-2018.11.12
curator を導入するに至った背景
ウィルゲート ではログ基盤として EFK ( Elasticsearch + Fluentd + Kibana ) を構築しています。
EFK を運用するにあたり、ログを絶え間なく Elasticsearch に蓄積していくためデータ量が膨大になっていき、結果的に Kibana のレスポンスが悪くなったり最悪表示ができなくなってしまうという問題がありました。
curator を導入する以前は、 古いインデックスに対して curl -XDELETE をひたすら投げるシェルスクリプトを実行して削除を行っていたのですが、古いインデックスが綺麗に削除されなかったり、 curl プロセスが大量に生成され負荷が上昇したりと運用において大きな課題となっていました。
そこで、前述した Elasticsearch の運用管理ツールである curator を利用して古いインデックスの削除を試みてみました。
導入方法
curator のインストールおよび設定には 構成管理ツールである Ansible を利用しています。
AWS の Elasticsearch へ接続する際に IAM Role を使用するため、最初に必要なモジュールである「requests_aws4auth」をインストールしてから elasticsearch-curator をインストールします。
また、curator の設定ファイルは Jinja2 テンプレートとして作成しています。
最後に 毎日 3 時に実行するように cron を設定すれば完了です。
Ansible Playbook
---
- name: install requests_aws4auth
pip:
name: requests_aws4auth
state: latest
- name: install elasticsearch-curator
pip:
name: elasticsearch-curator
state: latest
- name: mkdir .curator
file: path=/root/.curator state=directory owner=root group=root mode=0755
- name: configure curator
template: src={{ item.src }} dest={{ item.dest }} owner=root group=root mode={{ item.mode }}
with_items:
- { src: 'curator.yml.j2', dest: '/root/.curator/curator.yml', mode: 644 }
- { src: 'delete_old_index.j2', dest: '/root/.curator/delete_old_index', mode: 644 }
- name: set cron curator
cron: name={{ item.cron_name }} minute={{ item.cron_minute }} hour={{ item.cron_hour }} day={{ item.cron_day }} month={{ item.cron_month }} weekday={{ item.cron_weekday }} job={{ item.cron_job }} user={{ item.cron_user }}
with_items: "{{ cron_list }}"
vars
cron_list:
- cron_name: Run curator
cron_minute: '0'
cron_hour: '3'
cron_day: '*'
cron_month: '*'
cron_weekday: '*'
cron_job: 'curator /root/.curator/delete_old_index'
cron_user: root
curator.yml.j2
client:
hosts:
- AWS ESのエンドポイント（例： vpc-kibana-xxxxxxxxxxx.ap-northeast-1.es.amazonaws.com）
port: 443
url_prefix:
use_ssl: True
certificate:
client_cert:
client_key:
ssl_no_validate: False
http_auth:
timeout: 30
master_only: False
logging:
loglevel: INFO
logfile:
logformat: default
blacklist: ['elasticsearch', 'urllib3']
delete_old_index.j2
actions:
1:
action: delete_indices
description: >-
このアクションの説明
options:
ignore_empty_list: True
timeout_override:
continue_if_exception: False
disable_action: False
filters:
- filtertype: pattern
kind: prefix
value: 対象インデックスの接頭語（例：web-error-log-）
exclude:
- filtertype: age
source: name
direction: older
timestring: '%Y.%m.%d'
unit: days
unit_count: 何日以上経過したら消すか（例：10）
exclude:
2:
action: delete_indices
:
: 以下、対象のインデックス分追記していく
:
導入してみて
前述したように、これまで curator ではなくシェルスクリプトから curl を投げ続けるという方法でインデックスを削除していたため、サーバの負荷が上昇してしまったり、綺麗に古いインデックスが消せずに蓄積し続けてしまうなど課題が山積みとなっていました。
今回 curator を導入してからというもの、綺麗に古いインデックスを削除しつつ全くと言っても良いほど負荷もかからないので、素晴らしくサーバ（と心の）の平穏が保たれています。
また、 curator のインストールや設定を Ansible によりコード化しているので、同様に EFK を運用している別サービスにも手軽に適用できるようになりました。
おわりに
curator を利用することにより、 AWS Elasticsearch Service に登録されている古いインデックスを綺麗に削除でき平穏が訪れてきました！
同じような悩みをお持ちの方は curator を利用してみることをオススメします！
