何かいい方法がないかと見ていたらstorcliがjsonでデータを出力できることに気がついたので、ZabbixのLLDと組み合わせていい感じにデータを監視する方法を作りました。先にテンプレートのJSONを置いておきます。
Template_LSI-storcli.json
storcliが動けばLinuxであっても情報を取得できるので、agentのsystem.run形式で作ったものも同梱しておきます。storcliの実行にroot権限が必要になるので、storcliにスティッキービットをつけたりsudoを許可したりagent自体をrootでうごかしたりしていい感じに対応してください。
system.runは悪だ!!!!!という方は、最終的にjsonが取れればいいので、userparameterにしたりrootのcronでstorcliを実行して結果をテキストデータとして出力してログ監視するなど、linuxであればやりようはいくつもあるのでいい感じに工夫してください。
まあ、linuxでエージェントが入っているようであれば/var/log/kernelなどをmegaraid_sasといったようなキーワードで監視していれば大体のイベントが取得できますが…。
ESXi用のテンプレートはSSHで接続してstorcliの実行結果を取得するので、Zabbix-agentが入っていないLinuxを監視したい場合にも使えます。
前提条件
利用するにあたり、以下の前提条件が必要になります。
Zabbixのバージョンが6系であること
監視対象上でstorcliが動かせること
作成したLDに対して名前がついていること
ssh接続が有効になっていること
ESXiホストの/etc/ssh/sshd_configのPasswordAuthentication が yesになっていること
注意点としては、LLDとJSONのクエリの関係で、作成した論理ディスクに対して名前が必要になります。デフォルトではついていないので、storcliで監視対象全てで被らない一意な名前をつけてあげてください
/opt/lsi/storcli/storcli /call/vall show all #一覧を確認
/opt/lsi/storcli/storcli /c0/v0 set name=myhost01-boot #/c0/v0に対して名前を付ける
ESXi側のSSHに関しては共通鍵認証でもいいですが、テンプレートの変更が必要なのでそのへんの設定は今回は省きます。デフォルトのkeyboard-interactiveになっていても動きそうな気がしますがテストしてません。
また、テンプレートの形式がZabbix6形式になっているので4系では入らない気がします。LLDのためにJSONpathとカスタムスクリプトでJSを使っているので、これを元に一から作る場合であっても、Zabbix側のカスタムスクリプトでJSの拡張がされていないと動かない気がします。
いずれにしても、4系の環境がもうないのでテストしてないですが、JSONpathは4系でも使えたはずなのでなにかのヒントにはなるかと思います。
利用方法
まず、Zabbixに監視するためのホストを作ります。ESXiの場合はSSHで接続するので、インターフェースは参照しないので127.0.0.1のままでOKです。ホスト名だけ入れてください。
次に、マクロに色々仕組みます。利用しているマクロは以下になります
{$IP} 接続先IP
{$PASS} SSHの接続パスワード
{$STORCLI} Storcliの配置先 ESXiデフォルトは/opt/lsi/storcli/storcliのはず
{$USER} SSHの接続ユーザ
今思うと{$IP}はホスト作るときにIPで作って{#HOST.IP}でも良かったのでは??という気がしますが、作ってしまったのでそのままにします。また、PASSについてはデバッグが終わったあとであればSecret textに変更可能ですが、最初はクリアテキストでデータが取れるかを見たほうがいいです。
作成したホストに今回のテンプレートをリンクさせ、
LD Data from StorcliをExecute nowで実行します。正しく設定されていれば、LLDが発動してアイテムが増えるはずです。LDが増えない場合、上記の制限事項にある手順のstorcli /cx/vx set name=uniquename で名前をつけたか確認してください。Latest dataでデータが取得できているのにLDが増えない場合おそらくこれが原因です。同じく
PD Data from Storcliを実行すると、刺さっている物理ディスクの一覧が取得できると思います。Latest dataが取れない場合、ZabbixからESXiにSSHが届くか、storcliのパスが合っているかなどを確認してください。
制限事項
物理ディスクの監視ですが、ディスク、HBAのファームウェアのバージョンによっては取得できない項目があります。
BBM Error countやShield State Countなどはある程度のクラスのディスクでないと値を持っていないので、ディスクによっては取得できないかもしれません。その場合は取得不可のマークが付きますが、影響がないのでそのままにするかLLDで作成されたアイテムから監視の無効化をしてください。
また、物理ディスクの監視のために実行している
storcli /call/eall/sall show all jで応答するJSONがかなり大きいため、搭載ディスク本数が24本などの巨大なマシンの場合はうまく取れないかもしれません。Zabbix6系ではTEXT型アイテムの場合、history_textテーブルに格納され、使っているDBがMariaDBであればmediumtext型で格納されるため1回のデータ取得で16MBまでは入りますが、使っているDBの種類によっては入り切らない可能性があります。参考までに、ディスクを8本搭載したマシンで
storcli /call/eall/sall show all jを実行すると22KBのJSONが出来上がります。調べた限り、Zabbixは1つのセッションで1GBくらいのデータを流せるようなので、おそらくSSHからのデータ取得で問題になることは少ないかと思いますが、場合によってはタイムアウトの時間を伸ばす必要があるかもしれません。
storcli /call/eall/sall show all jの結果については依存アイテムを分解するために実行しているだけなので、Zabbixが6系であればヒストリを「Do not keep history」にしてもLLD分解後のデータ取得は可能です。もともとデバッグのために1時間しか保持していませんが、コマンド実行に問題がなさそうであればstorcliの履歴については取得しない設定でも問題ないです。
→テンプレートの微調整の際にデフォルトではstorcliの実行結果を保存しないようにしました。storcliのコマンド実行結果を眺めたい場合は
PD Data from Storcli のアイテムヒストリをnoneから適宜変更してください技術的内容(うらみつらみ)
今回、JSONとLLDを使うにあたってかなり多くの問題にあたりました。まず1つめはstorcliの返すJSONの作りが悪すぎること、そして2つめはZabbix側のJSONの処理がイケてないことです。両方じゃねーか!!!
ZabbixのJSONの扱いが微妙
ZabbixでJSONを扱うときに2つの問題がおきます。まず1つ目は、LLDでJSONを扱う場合、見つかったキーが
["LLDNAME"]とダブルクオートとブラケットに囲まれた状態で取得します。中身だけ見つけてくれ…と、せめてどうにか値に対してtrimやiregsubなどが使えないか試したのですが、どうやらここをどうにかする方法はないようです。そのため、アイテム名を整形するために
Temperture of {{#MR_PD_NAME}.iregsub("\[\"(.*)\"\]", \1)}というような正規表現をところどころで書く必要がありイケてないです。LLDで見つかったアイテムのキーについても
mrstat.pd.temp.["[\"/c0/e252/s0:WDC WD1005FBYZ-01YCBB1:WD-WMC6M0F4M8WN\"]"]というような状態で入ってしまうのですが、どうせこれは他では使わないしもういいや…と諦めました。2つ目は、LLDを実行するときにJSONから複数の値が見つかった場合、それぞれ
[{"key": "value"},{"key": "value"}]で返答する必要があり、["value","value"]だとイテレータが動いてくれないという点です。https://www.zabbix.com/forum/zabbix-help/419391-utilizing-jsonpath-to-setup-an-lld-macros
これもハマりましたが、上記のスレッドのカスタムスクリプトに助けられました。なおしておいてくれ～～～～～
storcliのJSON構造がカス
storcliのJSONの構造で苦労したのは物理ディスクの応答内容がカスなことです。一例としては以下のようになります
{
"Controllers": [
{
"Response Data": {
"Drive /c0/e252/s0": [
{
"DG": 0,
"DID": 14,
"EID:Slt": "252:0",
"Intf": "SATA",
"Med": "HDD",
"Model": "WDC WD1005FBYZ-01YCBB2",
"PI": "N",
"SED": "N",
"SeSz": "512B",
"Size": "931.000 GB",
"Sp": "U",
"State": "Onln",
"Type": "-"
}
],
"Drive /c0/e252/s0 - Detailed Information": {
"Drive /c0/e252/s0 Device attributes": {
"Coerced size": "931.000 GB [0x74600000 Sectors]",
"Connector Name": "Port 0 - 7 x1",
"Device Speed": "6.0Gb/s",
"Firmware Revision": "RR07 ",
"Link Speed": "6.0Gb/s",
"Logical Sector Size": "512B",
"Manufacturer Id": "ATA ",
"Model Number": "WDC WD1005FBYZ-01YCBB2",
"NAND Vendor": "NA",
"NCQ setting": "Enabled",
"Non Coerced size": "931.012 GB [0x74606db0 Sectors]",
"Physical Sector Size": "512B",
"Raw size": "931.512 GB [0x74706db0 Sectors]",
"SN": "WD-WMC6M0J95THT",
"WWN": "50014EE0AF2FC003",
"Write Cache": "N/A"
},
"Drive /c0/e252/s0 Policies/Settings": {
"Certified": "No",
"Commissioned Spare": "No",
"Connected Port Number": "7(path0) ",
"Cryptographic Erase Capable": "No",
"Drive position": "DriveGroup:0, Span:0, Row:0",
"Emergency Spare": "No",
"Enclosure position": "1",
"FDE Type": "None",
"Last Predictive Failure Event Sequence Number": 0,
"Locked": "No",
"Multipath": "No",
"Needs EKM Attention": "No",
"PI Eligible": "No",
"Port Information": [
{
"Linkspeed": "6.0Gb/s",
"Port": 0,
"SAS address": "0x4433221107000000",
"Status": "Active"
}
],
"SED Capable": "No",
"SED Enabled": "No",
"Sanitize Support": "Not supported",
"Secured": "No",
"Sequence Number": 2,
"Successful diagnostics completion on": "N/A",
"Wide Port Capable": "No"
},
"Drive /c0/e252/s0 State": {
"BBM Error Count": 0,
"Drive Temperature": " 32C (89.60 F)",
"Media Error Count": 0,
"Other Error Count": 0,
"Predictive Failure Count": 0,
"S.M.A.R.T alert flagged by drive": "No",
"Shield Counter": 0
},
"Inquiry Data": "7a 42 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00 00 00 00 00 20 20 20 20 57 20 2d 44 4d 57 36 43 30 4d 39 4a 54 35 54 48 00 00 00 00 00 00 52 52 37 30 20 20 20 20 44 57 20 43 44 57 30 31 35 30 42 46 5a 59 30 2d 59 31 42 43 32 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 00 40 00 2f 01 40 00 00 00 00 07 00 ff 3f 10 00 3f 00 10 fc fb 00 00 5d ff ff ff 0f 00 00 07 00 "
}
}
}
]
}
各情報について、なぜ変動する値がキーになっているのか、微妙に違うキーに値を入れるのやめろ、と言いたくなります。例えば、ディスクの温度とシリアルを取りたい場合のデータの位置は以下になります。
json.Controllers[0]["Response Data"]["Drive /c0/e252/s0 - Detailed Information"]["Drive /c0/e252/s0 State"]["Drive Temperature"] = " 32C (89.60 F)";
json.Controllers[0]["Response Data"]["Drive /c0/e252/s0 - Detailed Information"]["Drive /c0/e252/s0 Device attributes"].SN = "WD-WMC6M0J95THT";
なぜ以下のようにしなかったのか…
json.Controllers[0]["Response Data"]["PhysDrive"][0]["Path"]= "/c0/e252/s0";
json.Controllers[0]["Response Data"]["PhysDrive"][0]["SN"] = "WD-WMC6M0J95THT";
json.Controllers[0]["Response Data"]["PhysDrive"][0]["Detailed Information"]["State"]["Drive Temperature Celsius"] = 32
もともとディスクのシリアルと型番を元にクエリを投げて温度を取ろうと思い、上記のような構造であればJSONだけでクエリが完結したのですが、このような構造のためLLDのキーに色々仕込む必要がありました。
内容としてはカスタムスクリプトに正規表現でパスを取り出すものを仕組み、LLDの名前として取得して、LLDのアイテムプロトタイプで正規表現で取り出す、という内容です。
LLDのカスタムスクリプト
var array = JSON.parse(value)
var drives = []
for (var a in array) {
for (var ar in array[a]){
if ( ar.indexOf("Detailed Information") != -1){
prefix=ar.replace(/(Drive\s\/[\w\/]+)\s.*/,"$1");
path=ar.replace(/Drive\s(\/[\w\/]+)\s.*/,"$1");
detail=prefix+" Device attributes";
drive=path+":"+array[a][ar][detail]["Model Number"].trim()+":"+array[a][ar][detail].SN
drives.push(drive)
}
}
}
var len = drives.length;
var x = 0
output = "{ \"data\" :["
for (; x < len - 1; x++){
output += "{\"Name\": \"" + drives[x] + "\"},"
}
output += "{\"Name\": \"" + drives[x] + "\"}"
output += "]}"
return output
上記のカスタムスクリプトでこのような名前が取れるので、これをLLDで見つかったディスクとして認識させます。
そして、LLDのアイテムプロトタイプにて、JSONpathでデータを取得する際に
.iregsub("\[\"([0-9a-z\/]+):.*\"\]", \1)}で一番最初のスロットナンバーの情報を切り出してJSONのキーに埋め込んでいます。$.Controllers..["Response Data"]..["Drive {{#MR_PD_NAME}.iregsub("\[\"([0-9a-z\/]+):.*\"\]", \1)} State"]["Drive Temperature"]
イケてねえ…。まあイケてないものをイケてない方法でどうにかしようとしているので汚くなるのは必然ですが…。
まとめ
Zabbixは仕事でもプライベートでも使うことが多く、いろいろな意味で一番柔軟性が高い監視方法だと感じています。特定のログを検知しても水曜日の6-7時だけは検知を除外する、というような要求でも、Zabbixであればそれなりに複雑なトリガーの条件式で対応できますが、他の監視方法だとかなりキツイ、もしくはそんな方法はない、という事なりがちで、良くも悪くも使い込めば使い込むほど他のものが使えなくなります。
Zabbixは以前の仕事でそれなりに使っていたつもりだったのですが、今回やった内容は全く知らず、「え、そんなことできたの…」という発見もかなりありました。Zabbixはパズルですが、どうにかする方法はあるのでみんなで沼に沈みましょう。
おそらく、今回の方法ももう少しスマートな方法がある気がしますが、とりあえず動いたので参考にはなるかと思います。
追記:
その後実際に役に立ってしまったので動作については問題ないと思います。また、storcliのデータについてはデフォルトではヒストリを取らない設定に変更し、ディスクのステータスの追加のデータを取るように変更しました。何が起きてるかを知りたいときには手動でヒストリの取得を有効にしてください。
また、コントローラーが複数存在する場合に、2台目以降のコントローラーのデータが上手くパースできていない問題も修正しました。
ツイート
コメントを書く
必要事項とコメントを入力して下さい。
自己紹介
、もしくはTwitterまでお願いします。
