【Monitoring】 ZabbixからESXiホストに刺さってるMegaRAIDの状態をLLDで動的に取得して監視する 
 個人でESXiを動かしていると、何かとLSIのRAID情報を取得したいと思うことがありますが、LSAではなくて既存のZabbixからデータを取得したいと思うことがあります。ありますよね(同調圧力)。
 何かいい方法がないかと見ていたら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 StorcliExecute 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 countShield 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台目以降のコントローラーのデータが上手くパースできていない問題も修正しました。




[ コメントを書く ] ( 405 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 427 )  |  
【その他】ごみスクリプト置き場 
 某所にいたときに不毛な作業を少しでも楽にしようと足掻いた時に作ったゴミを置いておきます。たまにこれをベースに何かを作ったりするので主に自分のためのメモですが。
 内容としては、Expectで複数サーバに対して同一コマンドをsuして実行するだけのゴミと複数のサーバから一か所にファイルをSCPで集めるか送るだけのゴミです。

もっと読む...

[ コメントを書く ] ( 2342 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1938 )  |  
【Storage】VMware 5.1からSRPなデータストアを使う 
前回までのあらすじ

 無事にSRPターゲットの起動に成功したら、どんな人でもおそらくVMwareからこれを使いたいと考えるでだろう。VMware 4.xにはSRPイニシエータがあり、これからSRPなデータストアに繋ぐことが出来たので、Supported DeviceにあるConnectX2を買えばSRPが使える!と思っていた。
 しかし、去年の後半くらいからIBを触っていき、色々調べているうちに5系になってからVMware用SRPイニシエータが配布さていないことを知り、IBを使うには10GとしてiSCSIで繋ぐしかないことを知って絶望する。SRPの良さを知ってからこの事に気がついたので、知ったときはときはマジかよ…と結構落ち込んだ。
 一応、iSCSI over IPoIBがどの程度のパフォーマンスが出るのか調べてみると、ConnectedMode(MTU 65520)が使えないので10GbEなIBのMPIOx2(20Gbリンク)でさえ5GB/s(4-5Gbps)程度しか出ないらしい。Oh…
http://communities.vmware.com/thread/39 ... p;tstart=0

if anyone in Mellanox wants IB to get market acceptance then they should support this crap! (Mellanoxの中にIBのシェアを上げたいやつがるいならこのクズをどうにかしろ!)


 全くです…

 はっきり言って、全く使い物にならないといってもいいレベルのサポート状況にうちひしがれていた中、ある情報が届く。



 キター!ConnectX2が来たら本気出す!
 そして、ようやくConnectX2が来たので試してみたのであった…


 ConnectX2はもっと前からあったのですが、 前回 無事にSRPターゲットが使えるようになったので、VMwareから接続し、どの程度パフォーマンスが出るのか試してみました。

もっと読む...

[ 3 コメント ] ( 5383 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 449 )  |  
DebianにSCSTをいれてWindows7とLinuxからSRPで接続してみる 
 SRP転送そのものはもっと前に出来ていたのですが、力尽きて書く気力がありませんでした。ですが、気が向いたので自分用の備忘録と情報共有としてメモします。どこかでSubnetManagerが動いている前提で進みます。貼り付けが多いので長いです。
もっと読む...

[ コメントを書く ] ( 495 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 381 )  |  
【HW】DDR InfinibandHCAにおけるIPoIBのパフォーマンス 
 前回にIPoIBが通るようになったので色々テストしてみました。機材は前回のままです。
もっと読む...

[ 2 コメント ] ( 2194 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 2293 )  |  

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 進む> 最後へ>>