障害状態をシミュレートして動作確認
それでは障害状態をシミュレートして、動作確認を行ってみましょう。今回は、空きメモリが1024MBを切ったらトリガが作動するようにしたので、適当なアプリケーションを起動し、メモリを圧迫してみてください。もしくは、トリガの閾値を上げてみてもよいと思います。
ここまでで設定したことで、以下のような手順で連携が実現されることになります。
-
Zabbixのトリガが、
vm.memory.size[available]値が規定値（1024MB）より小さくなったのを検知する -
Zabbixのアクションが指定したトリガの値が
PROBLEMになり、アクションが実行される - アクションに指定されている Commands (＝作成したPythonスクリプト) が実行される
-
宛先RedmineのREST APIに起票内容が
POSTされる
イメージとしては以下の図のようになります。
いかがでしたか。うまく連携できたでしょうか。
実際の運用では、監視対象および閾値の精査が必要ですし、Redmine上にチケット起票されたものに対して、根本的な問題解決を行うことが求められます。しかし、監視から発される異常状態を漏れなく記録をすることで、アプリケーションの不具合のみならず、サーバサイジングの適正化や運用体制自体の見直しに活用することもできると思います。
その他のアイデア
チケットの一括登録
スプレッドシートや CSV 管理している案件リストから、一括取り込みを行うこともできます。
Jenkinsとの連携
自動ビルドシステム Jenkinsと連携して、ジョブ開始時にチケット起票し、ジョブ終了時にチケットのステータスを更新するような仕組みも考えられます(チケットIDの管理に工夫が必要そうですね)。
まとめ
RedmineやZabbixなどのWebアプリケーションは、単独で利用してももちろん便利ですが、今回はREST APIなどを組み合わせて連携させてみました。ネットワークを利用したWebアプリケーションの醍醐味とも言えるのでないかと思います。
今回紹介した単独サーバでのアプリケーションから、パブリッククラウドの操作インタフェースに至るまで、RESTやSOAPを利用してWeb経由で操作できるAPIは数多く提供されています。コマンドラインやスクリプトから様々なAPIを操作することで、手放しでシステムを使いこなすことも夢ではないと思います。ちょっとしたコードを書いてみることで、普段のツールが何倍にも効果的になることを、体感いただけたなら幸いです。
第1回、第2回と本連載をお読みいただき、ありがとうございました。皆さんの業務が、少しでもスムーズになれば幸いです。
【参考サイト】Zabbixの設定については、日本語のマニュアルが公開されています。
