4.0.9を導入した際のSELinux設定メモです。Serverを導入し、SELinux無効化状態であれば起動するところまで設定済みなところから始めます。Serverへの接続許可、Zabbixからのネットワーク接続を許可するbool値を設定します。httpd_can_network_connect_dbというのもありますが、今回ApacheからMySQLへの接続はUNIXドメインソケット経由となり、ネットワーク経由ではありませんので不要です。zabbix_can_network=onポリシー作成に必要なパッケージをインストールします。Serverを起動すると、/var/run/zabbix/配下に各種ソケットファイルが作成できないとのエラーが発生しますので、そちらを許可するポリシーを作成します。unlink;作成したポリシーファイルをビルドしてインストールします。MySQLを適用してMariaDBの状態を監視しようとするとエラーになります。UNIXドメインソケットに接続できない、my.cnfファイルが読み込めずにmysqlコマンドを実行できないため、これらを許可するポリシーを作成します。connectto;また、zabbixユーザーが使用する.my.cnfは/var/lib/zabbix/.my.cnfに配置しますので、こちらのファイルタイプがmysqld_home_tになるようにファイルコンテキストも作成します。unconfined_u:object_r:mysqld_home_t:s0teファイル、fcファイル両方揃ったところでビルドしインストールします。zabbix-agentd_local.ppこれでMySQL監視もおこなえるようになりました。導入したポリシーモジュールは以下のプライオリティ400のものになります。4.0のHA構成を試していていたら、ocf:heartbeat:apacheを使ったhttpdの起動がうまくいかなかった。クラスターリソースは以下で作成している。http://localhost/zabbix/の応答が</body>で終わってる)。2.4.4が起動しなくなりました。segfaltしている模様です。~]#以下の状況と同じようです。SUPPORTtrousersパッケージの削除かgnutlsのダウングレードで解決するようですが、trousersを削除するとpacemakerも削除されるので今回はgnutlsをダウングレード。~]#無事起動しました。6.4で、repo.zabbix.comからzabbix-server-mysqlとzabbix-web-mysqlをインストールして稼働している状態から、PacemakerとDRBDを使ったHA化をおこなってみます。Pacamakerの管理対象となるサービスを停止し、自動起動も無効化します。offdoneクラスターパッケージ群を導入します。resource-agentsDRBDはELrepoから導入します。cluster-recheck-interval=5mDRBDのリロース設定をおこないます。cfg-drbdDRBD領域をマウントするファイルシステムリソース設定をおこないます(fs-data)。cfg-fs1MySQLデータベースをDRBD領域配下に移動します。/var/lib/mysqlMYSQLデータベース領域をマウントするファイルシステムリソース設定をおこないます(fs-mysql)。timeout=40sfs-dataとfs-mysqlリソースが同一ノードで動作するようにgroup設定を施したうえで反映させます。cluster-recheck-interval=5mPacamakerの管理対象となるサービスを停止します。offdoneDRBDのリロース設定をおこないます。cfg-drbdDRBD領域をマウントするファイルシステムリソース設定をおこないます(fs-data)。cfg-fs1MySQLデータベースをDRBD領域配下に移動します。/var/lib/mysqlMYSQLデータベース領域をマウントするファイルシステムリソース設定をおこないます(fs-mysql)。timeout=40sfs-dataとfs-mysqlリソースが同一ノードで動作するようにgroup設定をおこないます。6.4にrepo.zabbix.comからパッケージを導入して。zabbix_serverプロセスは動いているし、10051ポートもLISTENしている。/etc/zabbix/web/zabbix.conf.phpも間違いない。httpd_can_network_connect=trueを実施する必要があった。EC2上で動かしているZabbixのテーブルサイズ推移を計測中です。pluginを使っています。Zabbixでの取得item数は110項目ほどで、9割方の項目がhistory=7/trends=365/delay=60の設定になっています。1週間経過してのデータ量推移は以下のようになりました。全テーブル分のデータを取得しているのでグラフが冗長ですが、Zabbixがデータを累積するのはhistory系とtrends系のテーブルですので、そちらに着目していただけるとわかりやすいかと思います。mysql_table_size推移file_sizes推移テーブルサイズ、ファイルサイズともにhistoryとhistory_uintが増加し続け、history保存期限の1週間を経過したところからほぼ横ばいになりました。10.10パッケージデフォルト)。言うと、レコード追加と削除の繰り返しでテーブルの断片化が進み、テーブルサイズは横ばいだがファイルサイズは増え続けるような状況を予想していたのですが、削除レコードの領域も上手に再利用されているようです。TYPE=InnoDBを実行して断片化解消しなきゃダメなのかな、と思っていたのですが、サイズ傾向だけで見る限りではそんな必要もなさそうです。😉EC2を1年以上継続利用する予定は今のところないのですが、気が向いたら1ヶ月後ぐらいに再度状況アップするかも知れません。252011Zabbixのhistoryとtrendsの違いに関して、Forumにトピックがあったのでメモ。Forumsなんとなくhistoryはitemで取得した生データ、trendsはhistoryを一定期間で丸めたデータ、と勝手に解釈していましたが、おおよそ間違いではなかったようです。trendsへのデータ保存はhistoryから削除するHouseKeepingのタイミングで実施しているのだろうと思っていたのですけれど、そこは勘違いしていました。zabbix_server/housekeeper/housekeeper.cのhousekeeping_history_and_trends()をみても、削除はhistoryもtrendsも同じようにおこなっていてhistoryからtrendsへの移送などはおこなっていません。グラフで表示する値は24時間以内であればhistoryを使い、それより長い期間の場合はtrendsを使うとのことです。pfreeの5項目あります。totalは別にして、容量不足だけを監視したいのならどれか1項目でもなんとかなるはずです。最低限取得するとしたら、Zabbixの負荷的にどれが一番効率がいいのか、ソースを見てみました。}ちなみにs構造体に入ってくる値はstatvfs()かstatfs()でまとめて取得するようになっています。計算の少なさでfreeの勝ち。次点はusedでした。閾値設定をファイルシステム毎にサイズ指定することになってしまうので、pfreeかpusedで値を取得、パーセンテージで監視するのが一番かもしれません。pfreeかpusedどちらかを取るならpfreeのほうが若干計算少ないです。コードの単純さだけを比較すれば、サイズとパーセンテージではサイズが有利、freeかusedではfreeが有利ということになります。252009ZABBIXでのデータ収集間隔はデフォルト5秒といったアイテムもあり、そのまま多数のノード監視に適用するとサーバー負荷が高くなりやすい。面倒なのでitemsテーブルのdelay値を一括変更した。これで300秒未満に設定されているデータ収集間隔は全て300秒に変更される。032009zabbix-server-mysqlパッケージのzabbix-serverがboot時に起動しない。ログをみるとmysqlに接続できずにエラーとなっている。(2)原因はrcスクリプトの起動順序指定。Sの時点ではmysqlは起動していない。INFOこちらをmysql前提に変更し(Required-Start/Required-Stop)、起動、停止するrunlevelもmysqlに合わせて解決。