こんにちは、kiwiです。
サーバーの監視ツールとしてZabbixを使い続けているチームがあり、そのZabbixを4系から最新の7.0へアップグレードする機会がありました。
Zabbixは（よほど古いバージョンでなければ）新しいバージョンのサーバーを起動することで、マイグレーション等が自動で実行され、アップグレードが完了します。ただ今回は数年越しで一気にアップグレードを行ったため、いくつかつまずきポイントがありました。このようなアップグレードを行う機会はあまりないと思うので、つまずいたポイントとその理由や対応を紹介します。
DBのマイグレーションに失敗する
早速ですが、新しいバージョンのサーバーを起動した際、マイグレーションが途中でストップしました。エラーログは以下の通りです。
[Z3005] query failed: [1832] Cannot change column 'scriptid': used in a foreign key constraint 'c_opcommand_2' [alter table opcommand modify `scriptid` bigint unsigned not null]このエラーについてはフォーラムで質問が出ており（https://www.zabbix.com/forum/zabbix-troubleshooting-and-problems/425115-zabbix-upgrade-5-0-lts-to-5-4-database-upgrade-error）、こちらに追加のSQLが記載されています。このSQLを実行後に再度マイグレーションを実施することで、次に進めるようになります。
ALTER TABLE zabbix.opcommand DROP FOREIGN KEY c_opcommand_2;
ALTER TABLE `opcommand` CHANGE `scriptid` `scriptid` BIGINT(20) UNSIGNED NOT NULL;
ALTER TABLE `opcommand` ADD CONSTRAINT `c_opcommand_2` FOREIGN KEY (`scriptid`) REFERENCES `scripts`(`scriptid`) ON DELETE RESTRICT ON UPDATE RESTRICT;しかし、今回の環境ではこのSQLの実行そのものが失敗してしまいました。
そもそもこの失敗したマイグレーションは、Zabbix 5.4のスクリプトの管理方法変更に対応するためのものです。エラーやDBの内容を確認したところ、アクションに「リモートコマンドを実行」が指定され、かつそのスクリプトが「カスタムスクリプト」としてアクション内に定義されている場合、外部キー参照の貼り直しに失敗してしまうことがわかりました。
今回の環境で設定されていたカスタムスクリプトはいずれも無効状態のアクションに設定されており、削除しても問題ありませんでした。そこで、アップデート前のバージョンにてアクションごと削除した上で、上記の追加SQLを実行することで、問題なくマイグレーションを終了できました。
DBの文字コード変更 & プライマリーキー利用手順の実行
今回の環境はDBとしてMySQLを使用していました。MySQL 8へ対応したZabbix 6.0より、データベースのcharacter setとしてutf8mb4が採用されるようになりました。この変更は自動で実行されないため、手動で実行する必要があります。手順はドキュメント Repairing Zabbix database character set and collation に記載されています。
また、同じくZabbix 6.0より、history系のテーブルにprimary keyが設定されるようになったほか、historyとtrendsテーブルで倍精度の小数が使われるようになるなどの変更が加わりました。こちらもドキュメント Database upgrade to primary keys and double precision data types に手動での適用手順が記載されています。ヒストリ系のテーブルを一度エクスポート→設定変更後にインポートする手順なのですが、データ量が多いと時間がかかりますのでご注意ください。
アップデート後にログインができない
さて、サーバーとWebフロントエンドのアップデートが完了し、サーバーが起動したは良いのですが、ユーザー名とパスワードを入力しても全くログインができません。データベースを確認すると、パスワードのハッシュが格納されているはずのカラムが全て空になっていました。
Zabbix 5.0でパスワードのハッシュ化方式がより安全なbcryptに変更されたのですが、しばらく「アップグレード後の初回ログインでbcryptにハッシュ化して保存し直す」という挙動となっていました。この移行処理はZabbix 6.0.xまで動いていましたが、Zabbix 6.2で削除されました。この際、従来のハッシュ化方式のパスワードは削除される挙動となったようで、結果何を入力してもログインできない状態となってしまいました。
一気にアップグレードを進めている限り、この事象に対する回避方法はありません。データベースに直接アクセスできる場合、力技でパスワードをリセットする方法が記載されていますので、そちらを特権管理者のユーザーに対して実行することで、ログインができるようになります。特権管理者でログインできれば、GUIからほかのユーザーのパスワードを再設定できるため、順次必要なユーザーのパスワードを設定すると良いでしょう。
Zabbix proxyを立てる
今回の環境には、ネットワーク設定を簡略化するため、Zabbix proxyが設定されています。以前はAmazon Linux 2を使っていたのですが、今回はより新しいOSで立てることにしました。
最初はAL2023を使って準備を進めていたのですが、そもそもZabbix proxyがAL2023に対応しておらず、無理やり導入するのも難しそうだったため、Ubuntu 24（Noble）を使うことにしました。
Ubuntu 24 (Noble) と CloudFormation
CloudFormationに指定していたcloud-initの内容をUbuntu用に書き換えて実行してみたのですが、インスタンスを立てたタイミングでは、CloudFormationヘルパースクリプトがPython 3.12（Nobleで標準利用できるPython）に対応しておらず、起動完了通知が送信されない（タイムアウトでインスタンスの作成に失敗）という事象が発生しました。
今回はヘルパースクリプトを使わず、AWS CLIから直接シグナルを送信する形で対応しました。シグナルを送信するためには、EC2のインスタンスIDが必要となるのですが、この値はリソースを作成するまで分からないため、cloud-initに書き込むことができません。
cloud-initを利用する場合、 bootcmd の中では $INSTANCE_ID という変数でインスタンスIDを取得できるため、この内容を一時ファイルなどに書き出しておき、起動後の実行コマンドの中でこれを読み込むことで、シグナルを送信することに成功しました。
Azure Entra ID（Azure AD）とのSSO設定
Zabbix 5.0よりSAML連携が、また6.4よりJITユーザープロビジョニングに対応したため、アップグレードの完了後に設定を行いました。
設定方法はマニュアル SAML setup with Microsoft Azure AD に記載があるので、基本的にこれに沿って進めれば設定できます。しかし、証明書に関してはどうしてもうまく接続ができず、エラーが表示されてしまっていました。
あれこれ探した結果、https://www.zabbix.com/forum/zabbix-help/402079-microsoft-adfs-saml-idp-and-zabbix-5-0-guidelineに記載されている方法で接続できました。
- 証明書ではなく、フェデレーション メタデータ XMLをダウンロードする
- XMLに含まれている
<X509Certificate>タグの内容を idp.crt としてファイルに保存する - このファイルを /etc/zabbix/web/certs/idp.crt として配置する（権限：644）
なお、今回はJITプロビジョニングとしたため、SCIMプロビジョニングは無効のままとしています。
さいごに
Zabbixのアップグレードで色々とつまずいたポイントがあったため、備忘録を兼ねて記載しました。頻繁に実施するようなものではありませんが、どなたか似たような境遇の方の参考になれば幸いです。
