カスタム Low Level Discovery サンプル
ユーザ定義で、オリジナルの Low-level discovery を使う際の参考になれば‥。
自身のブログみたいなものを持っていないので、情報共有も兼ねて。
1.今回のサンプルでは、rubyを利用していますので、agent 側ホストに ruby が必要です
2.agent 側の zabbix_agentd.conf に、次のような UserParameter 定義を追加します
UserParameter=user.useraccount.discovery, /usr/local/ruby/bin/ruby /path/to/script/user.discovery.rb
3.添付の user.discovery.rb_.txt を、上記の agentd.conf で指定したパス・ファイル名で配置します
この時点で、agentd を再起動して、動作を確認します
shell # zabbix_get -s xx.xx.xx.xx -k user.useraccount.discovery
{"data":[{"{#UNAME}":"root",
"{#UID}":"0",
"{#GID}":"0",
"{#HOMEDIR}":"/root",
"{#SHELL}":"/bin/bash",
"{#GNAME}":"root"},
{"{#UNAME}":"bin",
"{#UID}":"1",
"{#GID}":"1",
"{#HOMEDIR}":"/bin",
"{#SHELL}":"/sbin/nologin",
"{#GNAME}":"bin"},
...中略...
{"{#UNAME}":"yamada",
"{#UID}":"500",
"{#GID}":"500",
"{#HOMEDIR}":"/home/yamada",
"{#SHELL}":"/bin/bash",
"{#GNAME}":"yamada"}]}
うまく動作していれば、json 形式の出力が得られるはずです
4.例えば、ログインシェルが /sbin/nologin 以外のユーザアカウントだけについてアイテムを定義したい場合には
相応の正規表現ルールを作成します
WebUI から、管理→一般設定→正規表現 の作成画面で
左側の「正規表現」枠内「名前」: valid shell for account discovery
右側の「条件式」枠内から「追加」
条件式:^\/sbin\/nologin$
条件式の形式:結果が真
大文字小文字の区別: true
5.いよいよ、ディスカバリルールを作成します
キー名: user.useraccount.discovery
タイプ: zabbixエージェント、もしくは zabbixエージェント(アクティブ)
フィルター マクロ:{#SHELL}
フィルター 正規表現:@valid shell for account discovery
6.あとはお好みのアイテム、トリガーを、ディスカバリの中で定義していきます
今回のサンプルスクリプトでは、以下のキーで、以下の値が返るように作ってあります
{#UNAME} : ユーザ名
{#UID} : UID値
{#GNAME} : プライマリグループ名
{#GID} : プライマリグループのGID値
{#HOMEDIR} : ホームディレクトリのパス
{#SHELL} : ログインシェルのパス
これらのキーワードを使って、アイテム・トリガーを作れば、正規表現に合致するユーザアカウントに対して
自動的にアイテム・トリガーが追加されるようになります
結局のところ、3.の段階で出力されているような json を、必要な項目毎に吐くようなディスカバリ用のカスタムアイテムを
UserParameter に追加すれば、なんでもできちゃうみたいです
ああ便利
- user.discovery.rb_.txt (1.58 KB)
fripper - 投稿数: 495
サンプルのディスカバリスクリプトでは、ユーザアカウントの列挙を行なっていますが、
他にも、「このアプリが存在していたら‥そのアプリ向けの監視項目を追加」みたいなことが可能です
自分でもハマったので、1つ追記
例)mysql 用の監視アイテム追加を自動化させる場合
カスタムディスカバリスクリプト側の json で
{#MYSQL.EXIST} true / false
を取得させるようにして、アイテムのプロトタイプで、mysql 用監視アイテムを入れるわけですが‥
アイテムプロトタイプのキーを、「user.mysql.status」 のようにしてしまうと、
ディスカバリ実行後の「自動アイテム生成」でエラーとなってしまいます
これは、Zabbix のDB内部で、実際に監視を行うアイテムのキーと、プロトタイプ用のアイテムキーが
同じように管理されてしまっていることが原因で、「キー重複」とみなされてしまうのが原因です
回避するには、プロトタイプに入れるアイテムのキーを
「user.mysql.status[{#MYSQL.EXIST}]」などのように、json から得られる {#XXXXX} の
文字列を含んだものにします。
実際の監視処理アイテム側の定義も、
UserParameter=user.mysql.status, hogehoge
とするのではなく、
UserParameter=user.mysql.status[*], hogehoge
などと定義してしまいます
アイテムプロトタイプのキー側には、実際の監視処理側で使う・使わないに関わらず、
ダミーでも構わないので「{#XXXX}」のような文字列を埋め込んでおけ、ってことみたいです
こうしておくことで、プロトタイプのアイテムキーは、「user.mysql.status[{#MYSQL.EXIST}]」となり、
プロトタイプから自動生成されたアイテムキーは、「「user.mysql.status[true]」などとなるため、
前述の「キー重複」によるエラーは発生せず、正しくアイテムを追加できます