TWSNMP FCのログ自動削除で悩む　その２

今朝は５時半から開発開始です。
最近noteに書いているTWSNMP FCのログ自動削除の問題について心配していただいた方からTwitterでご連絡いただきました。
ありがとうございます。
本業の環境と書いたので停止したりデータ破損したりする障害が発生すると、いろんな人から怒らるシステムで使っているように思えたかもしれませんが、そうではありません。誤解を与えてすみません。
TWSNMP FCの限界を知るために、あえて過酷な環境で使用しているものです。syslogとNetFlowのログが毎分１万以上記録されるような環境です。
実務に役立っていますが止めたり、DBが破損しても、誰にも怒られません。
以前に何度もDBのサイズがディスクの８TBを超える問題が発生しました。DBを消してバックアップから開始すれば、ログは全部消えますがノードの監視はちゃんとできるようになるので問題ありません。

さて、昨日、いろいろと試行錯誤してログの削除処理がログの記録処理よりも速くできました。今朝の段階では、問題の環境でもDBのサイズは増えていません。
この問題の調査をしていて、使っているbbolt

の特性がいろいろ見えてきました。
データの追加、更新、検索はかなり高速にできます。削除はちょっと苦手な感じです。削除したもディスクの使用量は減らないですし、大量に削除するとディスクに反映させるために処理が遅くなるようです。特にハードディスクに保存していると顕著です。SSDなら大丈夫なようです。

Twitterで連絡いただいた方のアイデアにインスパイアーされて、よい改善策を思いつきました。ログのDBのテーブルを月別などに分けるというアイデアですが、ログのDBファイル(bboltのファイル）を分離して一定期間（月単位など）でファイルを切り替えるという方法です。３月は、３月のログDBファイルに書き込み、４月になったら４月のDBファイルに切り替えるということです。ディスクの空きが足りなくなったら古いログDBファイルを削除すればよいです。今やっているログの削除処理がいらなくなります。
昔からあるsyslogのローテーションのようなものです。
ここで助手の猫が一言
「先人の知恵をあなどるなかれ」
とのことです。

大掛かりな改造になりそうなので、すぐにはできませんが、今後の楽しみにしようと思います。

今のバージョンは、もう少し様子をみてリリースしようと思います。（月曜からログが増えると思うので）

明日に続く