はじめに
こんにちは。インフラチームの高畑です。
今回、 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 を利用してみることをオススメします！
