Zabbix Appliance 6.0でパッケージのアップデートを行ったらZabbix Serverのサービスが上がらなくなったので、復旧までの手順を記事にしたいと思います。
期待する目標
本手順期待する目標は以下の通りです。
- Zabbix Serverの起動不可原因が特定できる
- Zabbi Serverの起動不可を解消できる
期待する目標として、サービスの回復と言ったところがありますが、この手順はあくまで、原因が特定できた場合の手順です。
原因によっては、本手順で復旧しない場合があります。
なお、本手順を実行したことによるトラブル・損害・損失については、一切の責任は負いません。
前提条件
本手順で使用しているサーバは以下の通りです。
- CPU : 2vCPU
- MEM : 4GB
- DISK : 200GB
- OS : CentOS Stream 8
- Zabbix Version : zabbix_server (Zabbix) 6.0.12
なお、本環境のZabbixはZabbix Applianceとなっています。
そのため、インストールされているパッケージ等はZabbix Applianceで使用されてるものとなります。
障害発生の起因
これは、Zabbixだけの話ではないのですが、ITインフラ系の障害発生時には、当時何をやっていたか？どのような変更がなされたか？が非常に重要になってきます。
勿論、機器の物理障害により、障害発生があるので何とも言えませんが・・・
とはいえ、基本物理については、冗長化されているので片系が落ちてもある程度であれば問題ないようになっています。
どちらかというと、障害の契機となるのは変更作業で爆死するパターンが多いかと思います。
これについては、管理者側も適切に変更管理されていれば、障害発生の原因を簡単に切り分けできると思います。
本題に入っていきますが、今回の障害の契機はパッケージのアップデートでした。
皆さんが良くやる[apt update]や[yum update]といったコマンドですね。
これについても、本当に管理しているような環境であれば、事前にアップデート内容を精査して、問題ないようであればアップデートを適用する、怪しいものや大規模な変更で適用すると大きな障害を引き起こす可能性があるのであれば、見送ったり検証したりします。
今回yum updateを実行したことにより、障害が発生したようです。
そのため、大規模な変更やアップデートを行う際にはバックアップを取得しておきましょう。
障害原因の特定
起因はアップデートということが分かったので、原因の特定をしていきます。
VMwareであればログバンドルを取得してSRに送ってあげればVMwareの中の人がある程度解析してくれるので、良いのですが、Zabbixを無料で使わせていただいている身としては、サポートもないので、自身での原因究明が必要です。
ついでに、Zabbix Serverを手動で起動すると、エラーで起動ができませんでした。
[root@xxxxxx ~]# systemctl restart zabbix-server
Job for zabbix-server.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status zabbix-server.service" and "journalctl -xe" for details. Zabbixのログは、以下のパスに存在するので、ログファイルを読みます。
これもお客様によりますが、ログを読む際にオリジナルのログファイルに手をかけないようにします。
別の場所にコピーしたりしてから開きます。(これは、オリジナルのログを変更しないようにするため。)
/var/log/zabbix/zabbix_server.logログを確認すると、さっそくヒントがありました。
set new.name_upper=upper(new.name)]
1899069:20230120:105404.509 database upgrade failed
1899073:20230120:105416.744 Starting Zabbix Server. Zabbix 6.0.12 (revision 126aa2f53e9).
1899073:20230120:105416.744 ****** Enabled features ******
1899073:20230120:105416.744 SNMP monitoring: YES
1899073:20230120:105416.744 IPMI monitoring: YES
1899073:20230120:105416.744 Web monitoring: YES
1899073:20230120:105416.744 VMware monitoring: YES
1899073:20230120:105416.744 SMTP authentication: YES
1899073:20230120:105416.744 ODBC: YES
1899073:20230120:105416.744 SSH support: YES
1899073:20230120:105416.744 IPv6 support: YES
1899073:20230120:105416.744 TLS support: YES
1899073:20230120:105416.744 ******************************
1899073:20230120:105416.744 using configuration file: /etc/zabbix/zabbix_server.conf
1899073:20230120:105416.757 current database version (mandatory/optional): 06000000/06000010
1899073:20230120:105416.757 required mandatory version: 06000000
1899073:20230120:105416.757 optional patches were found
1899073:20230120:105416.757 starting automatic database upgrade
1899073:20230120:105416.758 [Z3005] query failed: [1419] You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) [create trigger hosts_name_upper_insert
before insert on hosts for each row 今回は、原因がログに書かれていたので、比較的簡単にログから原因特定ができました。
ポイントとなる部分は、以下の通りです。
- database upgrade failed : DBのアップグレードが失敗している。
- starting automatic database upgrade : DBの自動アップグレードのタスクが動いている。
- query failed : DBのクエリが失敗している
このことから、Zabbix Server自体に問題があるわけではなさそうと判断しました。
この時点で、DBのクエリが失敗しているため、以下のようなことが考えられます。
- Zabbix ServerとDBサーバの接続が物理的に失敗している
- Zabbix ServerとDBサーバの接続が論理的に失敗している
- DBサーバに障害が起こっている
1.については、Zabbix Appliance内部にDBを持っているので、あり得ません。
この時点で、2 or 3に切り分けができます。
3.のDBの障害である場合、データの復旧は困難になるので、とりあえずDBにログインして、クエリを実行し、正常にDBサーバが動いていることを確認します。
ここでもDBに問題が無かったので、Zabbix ServerとDBサーバ間で接続ができない or クエリが発行できないような権限問題が発生している。と判断しました。
ちょっとググって、以下のような記事を発見しました。
Zabbix 6.2.1: Mysql upgrade failed
Zabbixのユーザに権限を付けろ。と書いてあります。
(いや、ついてるやろあほ！)と思っていたのですが、さらにグーグル先生に聞いてみると・・・
Aurora MySQLのバージョンアップでハマった話
なんと、MySQLをバージョンアップすると一部の権限が外れてしまう場合があるとのこと。
ってことは、まず失われた権限を確認して、つけてあげればよいとプランニングしました。
Zabbix Serverの復旧
ちょっと原因が分かりかけたので、復旧を行っていきます。
まず、Zabbix ServerのDBにログインします。Zabbix Applianceについては、MySQLを採用しているため、以下のコマンドでログインすることができます。
[root@xxxxxx ~]# mysql -u root -p
mysql>
ついでに、MySQLのrootのパスワードが分からないといった場合、以下の設定を行うとパスワード無しで接続することができます。
[root@xxxxxx ~]# vi /etc/my.cnf
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]
#以下を追記
skip-grant-tables
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d設定変更後、MySQLサービスを再起動してから、rootユーザでMySQLに接続します。
DBに接続後、以下のクエリを実行して、[zabbix_srv]ユーザに対して権限を付与します。
なお、今回は[zabbix_srv]というユーザを使用していますが、Zabbixを手動でインストールした場合には別のユーザ名となっているので、確認してから権限を付与します。
mysql> grant all privileges on zabbix.* to zabbix_srv@'localhost';
Query OK, 0 rows affected, 1 warning (0.01 sec)もう1点注意事項なのですが、MySQLの8系から、GRANT ALLのクエリ構文が変更されているので、MySQLのバージョン合わせてクエリは確認してください。
Mysqlのgrant文でユーザ作成&権限付与しようとしてエラーが出たのでメモ
クエリが正常に実行できたら、[exit]を実行して、MySQLからログアウトします。
ログアウト後、以下のコマンドを実行して、Zabbix Serverを起動します。
[root@xxxxxx ~]# systemctl start zabbix-server
[root@xxxxxx ~]# systemctl status zabbix-server
● zabbix-server.service - Zabbix Server
Loaded: loaded (/usr/lib/systemd/system/zabbix-server.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2023-01-20 11:12:17 JST; 2 days ago
Process: 1238 ExecStart=/usr/sbin/zabbix_server -c $CONFFILE (code=exited, status=0/SUCCESS)
Main PID: 1246 (zabbix_server)
Tasks: 60 (limit: 24875)
Memory: 261.5MZabbix Serverが正常に起動したら、Zabbixのコンソールにアクセスして、正常性を確認していきます。
GUI上も問題ないようであれば、Zabbix Serverの復旧完了です。
まとめ
今回は、Zabbix Serverをアップデートして、database upgrade failedとエラーが出た場合の対応を切り分けから順を追って記事にしてみました。
ITインフラの運用を行う上で、必要な問題を解決する能力が問われる場所が障害対応になります。
とはいえ、ログをしっかり確認する。構成を正しく理解しておく。といった基礎的なことができれば、比較的簡単に障害を復旧させることは可能だと思います。(ただし、ネット上の記事として存在しない障害の方が多いため、解決するには広い視野が必要になると思います。)
おまけ
本ブログではVMwareやWindows、Linuxのインストール手順等も公開しております。
インフラエンジニアとして有益な記事や無益なコンテンツも作成しておりますので、通勤時間や休憩時間、休日のスキマ時間等に合わせて読んでいただけると幸いです。
また、Youtubeで解説動画も鋭意作成中です。本ブログで記事にしているものも動画にしようと思っておりますので、よろしくお願いいたします。
willserverのnoteも開設したのでフォローお願いします。
コメント