背景
自社のSaaSサービスをAWS上の主にEC2/RDS上で運用しており、監視にはZabbixを使用していた。
私がインフラ面を担当するようになった時には既にZabbixを使用していたが設定した人が退職されており、管理されてない＆監視できているかすらわからないという状態でした。
そこで、zabbixの整理及び監視ソフトの移行を上層部に提案しメインとなるサービスのMackerelへの移行及び既存システムのZabbix整理を実施する運びとなった。
実際にやったこと
既存Zabbix監視環境の整理編
- 監視対象/監視項目の調査（実際に監視されているかなど）
- 監視しきい値の見直し
- 自然復旧アラート削減
- Zabbixサーバへの負荷軽減の為の最適化
- 一部外形監視のGoogle StackDriverへの移行
- ドキュメント/マニュアル化
Mackerelへの移行編
- Mackerelサービスを利用するのにかかる予算の算出
- 移行する監視項目＆新たに追加する監視項目の計画
- 監視項目一覧をスプレッドシートで作成(他エンジニアと共有できるように)
- 監視項目をテキストエディタにコピーして正規表現で書き換え
- 実際の設定＆アラートしきい値の調整
- サーバスペックに応じて基本しきい値等を設定して運用しながら調整
- 自然復旧アラート削減＆自動復旧システムの構築
- アラートに応じてコマンドorスクリプトを実行するようにして自動復旧を構築
- ドキュメント/マニュアル化
総評
これまで誰も触れない魔窟とかしていたZabbixの設定を見直しマニュアル化することにより、緊急時にインフラ担当でなくてもある程度の問題解決が行える環境を作成した。
また、一部監視をMackerelやStackDriverに移行することによりZabbixサーバの負荷軽減や自動復旧システムなどそもそもアラートが起きにくい環境やメトリックの視認性を上げて障害発生時の状況を素早く確認できるようになった。