最近はゲームでも小説でもなんでも、タイトルが長いものが流行ですよね。
はじめに
はじめまして。
オークファン入社歴二年目、インフラエンジニア歴二年目の @aucfan-0540 です。
業務では主に AWS を用いたインフラ環境の構築等に携わっています。
アドベントカレンダーを書くのは二回目です。
昨年度はこんな記事を書きました。
https://qiita.com/aucfan-0540/items/01e33583fe76318fb3b1
今回はZabbix のバージョンアップ時にメンテナンス期間の設定を間違え、大量のアラートを発生させると同時に関係各所をざわつかせてしまった時の話を自分への戒めとして記事に残そうと思います。
よろしくお願いします。
やりたかったこと
弊社では一部サーバーの監視に AWS の EC2 インスタンス上に構築したZabbix 4.4を使用していました。
ある日の定例で「Zabbix 4.4はサポートが終了しているからそろそろバージョンを上げたいよね」という話が持ち上がり、その作業を私が担当することになりました。
特にバージョンの指定などなかったので、当時最新だったZabbix 6.0にしたいなあと思い調べてみたところ、現在使用しているAmazonLinux 2のインスタンスではRHEL8系のみ対応のZabbix 6.0は動かせない！ ということがわかったので、AWS のマーケットプレイスから代替の OS を探し、紆余曲折の末にAlmaLinuxを使うことにしました。更にZabbix 6.0はMySQL 8.0のみ対応だったため、インスタンスに接続したRDSのMySQLのバージョンもあげることになりました。
徒然なるままに書き連ねましたが、最終的な変更点が下記です。
【現行】
| OS | zabbix | zabbix-agent | mysql |
|---|---|---|---|
| AmazonLinux2 | 4.4.10 | 4.4.10 | 5.7.27 |
【バージョンアップ後】
| OS | zabbix | zabbix-agent | mysql |
|---|---|---|---|
| AlmaLinux | 6.0.9 | 6.0.9 | 8.0.30 |
なにをしたのか？
アップグレートを行うにあたり、既存の外部スクリプトがきちんと動くか等諸々の検証が必要になったので、まずは検証用のリソースから作ることにしました。
隙のない検証手順
いま見返すと隙だらけですが、当時はそう信じて疑いませんでした。
-
RDSのスナップショットを作成する - スナップショットから
RDSを複製する -
AMIを用いて現行のZabbixサーバーの複製を作成する - 複製した
RDSに同じく複製したZabbixを接続し、もろもろZabbix 6.0用の検証 - 一通りうまくいったら本番反映だ！
アラーム大騒ぎ（第一回目）
必要なリソースを作成し、インスタンスへ SSH 接続後に以下を実行しました。
systemctl start zabbix-server
コマンドを実行したのとほとんど同じタイミングでZabbixのアラートと連携している Slackチャンネル が騒ぎはじめました。詳細を見てみると、Web 監視をしていた数多のサービスが失敗（test.fail）を返しているようです。
その時は自分のせいだとは思っていなかったので「なにか障害が起きているのかな…？」とZabbixのアップデート作業を一時中断し、アラートの上がっているサーバーへ接続して様子を探ることにしました。
作業を中断するためにsystemctl stop zabbix-serverを実行してしばらく後にアラームが鳴りやんだので、偶然だなあと思いつつも、その時はあまり深く考えませんでした。自分が関与している可能性をあまり考えたくなかったというのもあります。
アラーム大騒ぎ（第二回目）
翌日、再び検証用のインスタンスでZabbixを起動しました。案の定またアラームが鳴り響きました。内容は前回とまったく同じです。
こんなことが二回続くとさすがに偶然とは思えなかったので、頻発するアラームに戸惑っている slack チャンネルで自供をしました。
文面からわかる通り、この期に及んでまだ自分のせいだという確信を得ていません。このときZabbixを使って作業をしていたのは一人だけなんだから確実にアンタやで…という感じなんですが、本当にこの時までは自分のせいだと思っていませんでした。
何が原因だったのか？
ものすごく初歩的なことでお恥ずかしい限りですが、複製したZabbixをメンテナンスモードにしていませんでした。
自分の中に「本番環境から複製して切り離したリソースなんだから、本番の設定は関係ない」という巨大な思い込みがあったためです。
複製したZabbixサーバーは、起動と同時に各サービスへアクセスしようとしますが、検証用のインスタンスには当然アクセス許可が設定されていないため、Web 監視に失敗します。
加えて本番環境から複製したデータベースを使っていたので、通知の設定などもまるまる引き継がれており「サービスには何の問題もないが、Zabbixがアクセスを拒否され 4xx エラーになり Web 監視が失敗、 Slack の通知が止まらなかった」という状態になっていました。
どうすればよかったのか？
以下のような手順で実行すれば、アラームはならなかったと思います。
- 起動時にアラートが上がらないよう、現行の
Zabbixにメンテナンス期間を設定する - その状態で
RDSのスナップショットを作成する - スナップショットから
RDSを複製する -
AMIを用いて現行のZabbixサーバーの複製を作成する - 複製した
RDSに同じく複製したZabbixを接続し、もろもろZabbix 6.0の検証 - 一通りうまくいったら本番反映だ！
というわけで、メンテナンス期間を設定してRDSを複製、今度こそは大丈夫だろうと椅子に深く腰をかけながらZabbixを起動しました。
アラーム大騒ぎ（第三回目）
だめでした…………。
Slack で各所へ謝罪しながら、設定したのに何がダメなんですか…と打ちひしがれていたところ、どうやらメンテナンスの設定をデータ収集ありではなくデータ取集なしにしないと、メンテナンス期間であれZabbixは値を取ってこようとしてしまうみたいです。
（下記はZabbix 6.0のコンソールです。）
メンテナンス設定とデータ収集の有無はsqlを用いても確認することができます。
maintenance_typeが1なら「データ収集なし」です。
mysql> SELECT * FROM zabbix.maintenances;
+---------------+-----------------------------------------+------------------+----------------------+--------------+-------------+---------------+
| maintenanceid | name | maintenance_type | description | active_since | active_till | tags_evaltype |
+---------------+-----------------------------------------+------------------+----------------------+--------------+-------------+---------------+
| 10 | zabbix-versionup-2022 | 1 | for zabbix versionup | xxxxx | xxxxx | 0 |
+---------------+-----------------------------------------+------------------+----------------------+--------------+-------------+---------------+
上記を基にメンテナンスの設定を更新し、満を持してZabbix起動したところ、今度は何もアラートがなりませんでした。やった！
まとめ
今回のことで得た知見です。
- 本番環境から切り離した = 本番環境へ影響を及ぼさない ではない
- バージョンアップは慎重に行う
- 現在起こっている障害に対し、心当たりがあったらすぐに言う
- 常に自分を疑う
- Zabbix は難しい
最後に
株式会社オークファンではエンジニアを募集しております。
ご興味持っていただけた方はぜひ！