アラートログの可視化や複数の通知先設定
続いて、ぐるなびでは特定のログが出力された際にアラートを出したかったため、Elasticsearchで実現した。それまでオンプレでは、アプリケーションサーバーからsyslogをログ監視ツールswatchサーバーに送り、メールやSlackを通じてアラーティング（アラート発報）していた。
現在ではswatchではなく、ログをElasticsearchに送りアラーティングするような構成に変更した。ここで鍵となるのがKibana Rules。Elasticsearchに連携されたログをもとにアラートを設定できる。対象とするログの条件や、条件と合致するログ件数のしきい値、これらの条件を満たした時に実行されるアクションなどを設定することでアラーティングが可能となる。
単純なアラートの設定であれば管理画面上で記入できるが、やや複雑な条件であればクエリで設定することも可能だ。例えば正規表現を用いてホスト名を指定したり、ワイルドカードを用いてエラーコードを指定したりなどだ。アラート通知先はメール、Slack、Teams、PagerDuty、Webhook、ServiceNowなど、さまざまななかから選べる。
アラートの仕組みは導入できたものの、1つ課題があった。それはメンテナンスで稼働停止しているサーバーのアラートは抑止することだ。ぐるなびではアラート抑止のためのスクリプトを自動化しており、対象サーバーの監視をコマンドで停止できるようにしている。ここにKibana Rulesのアラートもスクリプトで抑止できるようにしたかった。
この監視停止の仕組みについては、Kibanaで提供されている設定変更を行えるAPIを使うことにした。まずKibana RulesのConfigファイルに監視除外用のフィルターを追加する。続いてそのConfigファイルを元にAPIを通じて、Kibana Rulesを変更する。なお特定のフィルターだけ追加することはできないため、ファイル丸ごと上書きする形となる。
佐々木氏は「APIキーの権限設定が複雑でなかなかうまくいかず、問い合わせをしながら実装しました。またConfigファイルの一部だけ変更できないため、差し替え用の設定ファイルを実行サーバー側で保持する必要がありました」と話す。
ログアラーティングを実装することで、アラートログをKibanaで確認できるようになり、リアルタイムで問題の特定が可能となった。佐々木氏は「これまでの古いアラートの仕組みをモダンな仕組みに切り替えることができてよかったです」と話す。また複数の通知方法を設定できるようになった。
今後Elasticsearchで実現したいこと
今後ぐるなびでは、ダッシュボードの拡張を予定している。佐々木氏は「活用できていない視覚化やグルーピング機能などを利用することで、より分かりやすいダッシュボードへと改善していきたいです」と話す。
また機械学習を用いることでアラートの自動化をより高度化していくことも計画している。AIOps機能を用いれば、ログデータ内の異常やパターン検出を自動化していくことが可能になる。さらにぐるなびではSREを進めているところなので、ElasticsearchのSLO機能からサービスのSLOを計測する予定だ。
最後に佐々木氏は「Elasticsearchを自社システムにうまく組み込むことで、アクセスログでは、リアルタイムなアクセス状況確認やグラフを用いた視覚的なデータ理解が可能になりました。またKibanaを用いたログアラーティングの仕組みを導入し、APIで監視抑止の自動化をすることで効果的なログ監視が可能となりました。これら2点により、ぐるなびのオブザーバビリティが向上したと考えています」と述べた。
