タグ別アーカイブ: Zabbix

Zabbixの設定のみをバックアップする (Zabbix 3.0)

OSSのサーバー監視ツール Zabbix はMySQL(やPostgreSQLなど)にデータを保存するのでDBのダンプ(とzabbix_server.conf)を取得しておけば概ねのバックアップが可能ですが、ログデータ(ヒストリ、トレンド)が巨大なデータになりがちです。おそらくログ系のテーブル以外をバックアップする事でコンパクトなバックアップにする事が出来る物と思われます。

ただ、Zabbix公式のドキュメントにはデータベースの中身の構造についての内容が見当たりません。

Database Schemas – Zabbix.org
https://www.zabbix.org/wiki/Database_Schemas

真偽不明な情報としては上記がZabbix 2.4のER図になります。これを参考にZabbix 3.0.10をインストールした状態のDBと見比べてみると、いくつかのテーブルで追加カラムが有る他、以下のテーブルが増えています。

  • application_discovery
  • application_prototype
  • item_application_prototype
  • opinventory
  • screen_user
  • screen_usrgrp
  • slideshow_user
  • slideshow_usrgrp
  • sysmap_user
  • sysmap_usrgrp

結構な数のテーブルが増えていますが、いずれも設定系のテーブルであり、ログ系のテーブルではないものと思われます。つまり以下のようなmysqldumpコマンドを投げれば設定のみをバックアップする事が出来る物と思われます

mysqldump -u [ユーザー名] -p –single-transaction –hex-blob \
–ignore-table=[DB名].alerts \
–ignore-table=[DB名].history \
–ignore-table=[DB名].history_uint \
–ignore-table=[DB名].history_str \
–ignore-table=[DB名].history_text \
–ignore-table=[DB名].history_log \
–ignore-table=[DB名].trends_uint \
–ignore-table=[DB名].trends \
–ignore-table=[DB名].auditlog \
–ignore-table=[DB名].auditlog_details \
–ignore-table=[DB名].events 
[DB名] | gzip > [ファイル名].gz

バイナリデータ(中身は画像)を含んだテーブルが有るので –hex-blob を付けておいてください。また、ファイル名は取得時刻が秒単位で分かるようにしておいた方がいいでしょう(後述)。

例: zabbix_configuration_only_backup_20170817_151515.sql.gz

復旧時の注意点

上記コマンドで取得したダンプデータですが、まっさらなZabbixに設定を投入するなら良いのですが、例えばZabbix画面上で設定変更を色々と行い、元に戻したいといった用途に使用しようとすると、ログに残ったアイテムIDなどでつじつまが合わなくなってくる可能性が有ります。安全を期すためには「itemid」カラムのあるテーブルに注意する必要が有ります。

データが欠けても良いのであれば、バックアップを取った時点以降のログデータを吹き飛ばすのが一番簡単だと思います。clockカラムにUNIXタイムの形式で日付が入っているので、それ以降のデータを飛ばします。

DELETE FROM alerts WHERE clock >= [UNIX時間];
DELETE FROM events WHERE clock >= [UNIX時間];
DELETE FROM history WHERE clock >= [UNIX時間];
DELETE FROM history_uint WHERE clock >= [UNIX時間];
DELETE FROM history_str WHERE clock >= [UNIX時間];
DELETE FROM history_text WHERE clock >= [UNIX時間];
DELETE FROM history_log WHERE clock >= [UNIX時間];
DELETE FROM trends_uint WHERE clock >= [UNIX時間];
DELETE FROM trends WHERE clock >= [UNIX時間];

DELETE audit_d FROM auditlog_details AS audit_d
LEFT JOIN auditlog USING(auditid)
WHERE auditlog.clock >= [UNIX時間];

DELETE FROM auditlog WHERE clock >= [UNIX時間]

auditlog_detailsはauditlogに関連しており、単体ではclockカラムを持っていないのでdetailsの方を先にDELETEする必要が有ります。これらDELETE分をzabbix-serverが停止した状態で実行し、その後バックアップのダンプデータをDBに流し込みます。

最後に

あくまでDBのテーブルのカラム名などから推測してバックアップをしているので、この方法には何かしら不具合が含まれる可能性が有ります。非公式なバックアップ方法なので、自己責任でのご利用の程お願いします。

また、あくまでZabbix 3.0.10時点でのテーブル内容を参考にしているので、3.2等ではそのまま動かない事も有るかと思います。

なお、Zabbixの有償サポートに入っているユーザーであれば、公式で(おそらくより高機能な)設定のみのバックアップと復元が可能なようです。整合性をチェックをするような記載も有るので、この方法のようにデータを飛ばす必要も無いのかもしれません。ミッションクリティカルな用途で使うなら、サポートの有るツールを使った方がいいでしょう。

Zabbix設定バックアップツール | Zabbix Enterprise
http://enterprise.zabbix.co.jp/solutions/3661


ZabbixのデフォルトMySQL監視UserParameterは修正が必要

以下はZabbix 3.0.xでの話です。

Zabbix AgentをZabbix SIAのyum Repositoryから導入すると、
/etc/zabbix/zabbix_agentd.d/userparameter_mysql.conf 内にデフォルトでMySQL監視用ユーザーパラメータが定義されますが、その中のZabbix Pingに関しては修正が必要です。以下がデフォルトの定義です。

UserParameter=mysql.ping,HOME=/var/lib/zabbix mysqladmin ping | grep -c alive

これをそのままコンソール上で実行すると、MySQL(MariaDB)が起動している状態で実行すると1を返しますが、停止時には0だけでなく標準エラー出力への文字出力が含まれ、データ型が数値ではなくなってしまいます。

$ HOME=/var/lib/zabbix mysqladmin ping | grep -c alive
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!
0

数値として受け取れなくなったアイテムは「不明」の状態となり、トリガーが検知しない状態となります。また、これはトリガーのnodata関数が有った場合でも検知されません。

UserParameter=mysql.ping,HOME=/var/lib/zabbix mysqladmin ping 2>/dev/null | grep -c alive

でエラー出力を捨ててみたり

UserParameter=mysql.ping,HOME=/var/lib/zabbix mysqladmin ping 2>&1 | grep -c alive

でエラー出力も標準出力に吐いてgrepに渡す事でMySQLのダウンを検知する事が出来ます。


Zabbix Proxyサービス起動時刻がおかしいと正常に動作しなくなる話

Zabbix Server、Zabbix Agentが導入されているサーバーを再起動することは問題ないが、Zabbix Proxyが導入されているサーバーのOSを再起動するとなぜかagent pingが飛ばなくなるという現象が有りました。以下のような状況でした。

  • OSはCentOS 7.2
  • Zabbix 3.0.2
  • zabbix-proxy.serviceは自動起動が有効。
  • キャッシュDBはSQLite3を利用。
  • systemctl restart zabbix-proxy を実行すると改善。
  • 稀にOS再起動後も問題なく動作する。

最初はProxyの設定ファイルを調査するも特に不審な点は無い状況でした。しかし、systemctl status zabbix-proxyで出てくるサービス起動時刻がおかしい事に気づきます。dateコマンドを叩いて表示される時刻はJSTとして正しいものであるものの、zabbix-proxyの起動時刻はJST + 7.x時間という中途半端な時刻になっています。9時間マイナスならともかく、JSTよりさらに先というのがよく分かりません。

  • dateコマンドで表示される時刻は正しい。
  • timedatectlで確認できるJST、UTCともに正しく、RTCはUTCと同じ値。
  • sshd等、他のサービスにもsystemctlで確認できる起動時刻がおかしいものがある。
  • psコマンドで表示される時刻は正常。
  • systemctl restart zabbix-proxyを行うとサービス起動時刻も正常なJSTになる。

時計回りの怪しさ満点ですが、結果としては「OSを起動している仮想環境のホストであるESXiの時計が狂っている」という物でした。OS上の時刻表示が正しいものだから結構気づくのに時間がかかりました。
では、なぜOS上の時刻が正しいのにサービスの起動時刻だけおかしくなるのかというと、OSの再起動時にESXiの機能が時刻同期をオフにしていてもホスト側に合わせてしまうというそんな事しなくていいのに……という処理が入るとの事。その後OS起動処理の中でchronyが動作し、ユーザーが触る頃には正しい時刻、という動きが再起動の度に挟まれていたようです。以下の記事がとても参考になりました。

―ESXi上のWindowsゲストの時刻がずれて詰みかけた話
http://qiita.com/ine1127/items/edb0a46b638265186650

なぜZabbix Proxyの起動時刻が正しくない状況にあると正常に動作しなくなるか、という点については不明ですが(まぁ正常な環境ではないのは確かですが)、とりあえず今のところは再起動後もagent pingが途切れなくなっています。