前回まででインストールは完了しましたが、ギリギリの性能であるため、放っておくと問題が発生します。
ここではチューニング方法を記載します。

1. Swap領域の有効化

t2.mediumはメモリ4GBです。T-Potの要求スペックを満たしているものの、実は推奨スペックは8GBです。しばらく運用を続けて、elasticsearchにデータが積みあがってくるとメモリ不足になります。ちなみに、インストール直後がこの状態です。

[root@massshoemaker:/home/honey]# htop

f:id:graneed:20180610170236p:plain よって、Swap領域を作成してメモリ使用量の増加に備えます。

# Swap領域の作成
[root@massshoemaker:/home/honey]# mkdir /var/swap
[root@massshoemaker:/home/honey]# dd if=/dev/zero of=/var/swap/swap0 bs=1M count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 27.3182 s, 78.6 MB/s
[root@massshoemaker:/home/honey]# chmod 600 /var/swap/swap0
[root@massshoemaker:/home/honey]# mkswap /var/swap/swap0
Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
no label, UUID=20e34a6e-7f6e-4cca-ab52-674475bcd45a

# Swap領域の有効化
[root@massshoemaker:/home/honey]# swapon /var/swap/swap0

# Swap領域の自動マウント
[root@massshoemaker:/home/honey]# echo '/var/swap/swap0 swap swap defaults 0 0' >> /etc/fstab

# Swap領域の確認
[root@massshoemaker:/home/honey]# swapon -s
Filename                                Type            Size    Used    Priority
/var/swap/swap0                         file            2097148 0       -1

これでSwap領域を2GB確保しました。

2. ログ保存期間短縮によるディスク使用量の節約

攻撃状況にもよりますが、AWSの無料利用枠の範囲内であるSSD 30GBで構築すると、1か月経たずにディスクがいっぱいになりました。 T-Potは、各ハニーポットのログを/data領域に保存しており、デフォルトは30日間保存しています。その保存期間を変更して、ディスク使用量を節約します。

# 設定ファイルのバックアップ
[root@massshoemaker:/home/honey]# cp -p /opt/tpot/etc/logrotate/logrotate.conf /opt/tpot/etc/logrotate/logrotate.conf.org

# 設定ファイルの編集。rotateを30から15に変更。
[root@massshoemaker:/home/honey]# vi /opt/tpot/etc/logrotate/logrotate.conf

# 変更内容を確認
[root@massshoemaker:/home/honey]# diff -u /opt/tpot/etc/logrotate/logrotate.conf.org /opt/tpot/etc/logrotate/logrotate.conf
--- /opt/tpot/etc/logrotate/logrotate.conf.org  2018-06-10 01:30:22.830235993 +0900
+++ /opt/tpot/etc/logrotate/logrotate.conf      2018-06-10 12:24:06.095311754 +0900
@@ -33,6 +33,6 @@
        daily
         missingok
         notifempty
-       rotate 30
+       rotate 15
        compress
 }

これで保存期間を15日間に変更できました。

3. elasticsearch保存期間の短縮によるCPUバースト抑制

運用を始めて2か月を過ぎたあたりのある日、Kibanaでダッシュボードを表示すると、しばらく表示を待たされた結果、タイムアウトが発生してまともに使用できない状態になりました。

glances等のモニタリングツールで調べていると、stealが発生しており、各プロセスにCPUが割り当たっていない状態になっていることがわかりました。どうやら、elasticsearhのCPU使用率が徐々に高くなっており、AWSのCPUのバーストが発生しCPUクレジットを消費し尽くしていました。
t2.mediumの場合、CPU使用率が20%を超えると、CPUクレジットを消費していきます。

参考：CPU クレジットおよびベースラインパフォーマンス - Amazon Elastic Compute Cloud

elasticsearhはデータ量に比例してCPU使用率が高くなっていくようです。 elasticserchのデータは、デフォルトで90日間保存されています。その保存期間を変更して、CPU使用率を抑えます。

# 設定ファイルのバックアップ
[root@massshoemaker:/home/honey]# cp -p /opt/tpot/etc/curator/actions.yml /opt/tpot/etc/curator/actions.yml.org

# 設定ファイルの編集。unit_countを90から45に変更。
[root@massshoemaker:/home/honey]# vi /opt/tpot/etc/curator/actions.yml

# 変更内容を確認
[root@massshoemaker:/home/honey]# diff -u /opt/tpot/etc/curator/actions.yml.org /opt/tpot/etc/curator/actions.yml
--- /opt/tpot/etc/curator/actions.yml.org       2018-06-10 01:30:22.830235993 +0900
+++ /opt/tpot/etc/curator/actions.yml   2018-06-10 16:33:48.623398098 +0900
@@ -23,4 +23,4 @@
       direction: older
       timestring: '%Y.%m.%d'
       unit: days
-      unit_count: 90
+      unit_count: 45

これで保存期間を45日間に変更できました。