第2回：IoT端末や管理サーバーがあるオンプレミスのIoT環境をVistaraで監視し、APIを使いつつアラートの状況に応じてインシデント化（サービスデスクのチケット化）または自動化ツールなどと連携
今回と最終回はIoTに関わる各種端末や管理サーバーをVistaraで監視し、アラートの状況に応じてインシデント化（サービスデスクのチケット化）を実施する一連の挙動を示しつつ、さまざまなシステムと連携する上でうまくAPIを活用する様子を見たいと思います。
第２回目は「オンプレミス」上の環境に着目します。
まずは監視・運用する物理環境を以下に図示します。
「オンプレミス」環境には、各種センサーにつながったIoT端末があります。RaspbianあるいはWindows 10 IoT CoreなどのOSを含むデバイスもあれば、OSが存在しないデバイスもあります。ただしIoTですのですべてネットワークに接続できます。多くの場合これら端末を統括するプラットフォーム管理サーバ、例えば風力タービン管理システム、植物工場管理システム、牛舎の管理システムなど、何らかの集中管理サーバが存在します。データは端末からが管理サーバに送られ、管理サーバ上で一括で処理・保管されます。かつ「パブリッククラウド」であるMicrosoft Azure上のリソース（Azure上のリソースもOSがある場合とない場合がありますが）とオンプレミスの管理サーバがデータを同期し、Azure上で外部からデータ閲覧するウェブを提供したり外部サービスを使ったデータ解析サービスに役立てることが考えられます。ここでVistaraとはパブリッククラウドに存在する、ITオペレーションのライフサイクル管理システムです。各種デバイスのインベントリ状況の把握と監視、障害時のアラート発報や通知、サービスデスクのチケット処理など、ITオペレーションのPDCAサイクルを、一つの画面からエンドツーエンドまで対応できるツールです。また既存のIoTプラットフォームや、Zabbix・ServiceNowといった監視やサービスデスクなど特定機能に特化したツールとも連携・共存可能であるので、既存システムを配下にぶらさげる傘のような「ITオペレーションコマンドセンター」と見ることもできます。
VistaraのITオペレーションの処理の流れは以下です。
Vistaraでは「Vistaraゲートウェイ」という外形監視システムでPing、HTTP URL、ポート監視、SNMP、WMI等を通じてインベントリ情報やアラートトリガーとなる監視情報を取得します。外形で見れないOS内部の情報は、端末にインストールするタイプの「Vistaraエージェント」を通じて実施します。
一方で、IoT環境では、すでにお使いのIoT管理サーバーがVistaraゲートウェイまたはVistaraエージェントを介してこれらの情報を渡すことが可能であったり、pingのみの死活監視でよければ、一般的なIT環境と変わりありません。しかしながら大抵いくつかの相違点が見込まれます。
例えば
- IoT管理サーバというものが存在せず、その場合IoT端末から直接Vistaraに情報を渡さざるを得ない。
- IoT管理サーバは存在するが、汎用的なIAサーバーでなく、通常の監視が実施できない（シェルは利用可能）。
- IoT端末にOSがないため通常のSNMPあるいはWMI経由で情報が取れない（限定的なSNMPやSMTPなどは動作可能）。
- IoT端末にOSがあるが、組み込み系OSで機能が限定的であるため（シェルは使用可能）、上記同様に通常のSNMPあるいはWMIで情報が取れない。
- その他。
VistaraにオンボーディングされたIoT端末。Pingの死活監視中。
この場合Vistaraでは、インベントリの可視化は限定的となりますが（上記UIの通り端末の詳細情報が自動的に取得できません；手動での記載は可能）、HTTPまたはSMTPさえサポートできれば、Vistaraが提供する「Rest API」「Email API」を活用して、アラートの発報、サービスデスクのインシデント化等を実施しITオペレーションに乗せることができます。以下のような組み合わせによる実現方法があります。
IoT端末がセンサーを通じて何らかの警告を発するためにVistara上にアラートを発報したい場合に、IoT端末がシェルをサポートできCurlが使えれば（JSONフォーマットでデータが送れれば）以下のような書き方でVistaraにHTTP POSTでトリガーを送ることが可能です。例として温度センサーが検知した温度に応じて、Critical/Warning/OKの３つの状態を区別するアラートを発報するとします。
例（Raspberry PiでRaspbian OSを使用）：
#!/bin/sh
if [<温度が著しく上がったとき>]; then
curl -k https://app.vistanet.jp/api/basic/tenants/<クライアントID>/alerts
-H "Authorization:Basic <基本認証用文字列>"
-H "Authorization:Token <トークン文字列>"
-H "Content-Type:application/json"
-H "Accept: application/json"
-d '[{"device":{"hostName":"ホスト名”,
"ipAddress":"IPアドレス",
"macAddress":"MACアドレス"},
"alertTime":"アラート時刻",
"currentState":"CRITICAL",
"serviceName":"IoT-Temperature”,
"subject":"Temperature alert!",
"description":"Very high temperature persists! Requires immediate attention.",
"app":"VISTARA",
"alertType":"WebAPI",
"monitorName":"Temperature"}]'
-X POST
elif [<温度が多少上がったとき>]; then
curl -k https://app.vistanet.jp/api/basic/tenants/<クライアントID>/alerts
-H "Authorization:Basic <基本認証用文字列>"
-H "Authorization:Token <トークン文字列>"
-H "Content-Type:application/json"
-H "Accept: application/json"
-d '[{"device":{"hostName":"ホスト名”,
"ipAddress":"IPアドレス",
"macAddress":"MACアドレス"},
"alertTime":"アラート時刻",
"currentState":"WARNING",
"serviceName":"IoT-Temperature”,
"subject":"Temperature alert!",
"description":"High temperature detected! Please investigate.",
"app":"VISTARA",
"alertType":"WebAPI",
"monitorName":"Temperature"}]'
-X POST
else ##通常温度のとき
curl -k https://app.vistanet.jp/api/basic/tenants/<クライアントID>/alerts
-H "Authorization:Basic <基本認証用文字列>"
-H "Authorization:Token <トークン文字列>"
-H "Content-Type:application/json"
-d '[{"device":{"hostName":"ホスト名”,
"ipAddress":"IPアドレス",
"macAddress":"MACアドレス"},
"alertTime":"アラート時刻",
"currentState":"OK",
"serviceName":"IoT-Temperature”,
"subject":"Temperature alert!",
"description":"Temperature is normal. ",
"app":"VISTARA",
"alertType":"WebAPI",
"monitorName":"Temperature"}]'
-X POST
このHTTP POSTをIoT端末から直接実行しても動作も可能ですが、理想的にはIoTプラットフォーム管理サーバにて全IoT端末を統括し、管理サーバから集中的にVistaraと通信を行うのが理想的です。
次にインシデント化となります。Vistaraゲートウェイ、Vistaraエージェント、あるいはVistara Rest APIを利用していったんアラートが上がった後で、それをトリガーに「自動的に」インシデントを作成するという機能がVistaraに存在します。下記UI図では、「Criticalという状態のアラートが発生して、かつデバイスのリソース名に”IoT”という文言が含まれる」条件の場合、アクションとしてインシデントの表題とメッセージをカスタマイズし、ある担当チームに割り振って自動的にインシデントを起票するというアクションの設定をしています。
自動インシデント化ポリシーでチケットを起票
インシデントチケットのサンプル
またアラート発報を受けて外部システムにHTTP POSTで情報を送信することができるので、アラート通知を外部のコールセンターシステムに任せたり、ジョブフローのシステムと連携して自動修復作業を実施するなど可能です。下記は自動インシデント化ポリシーと同じ画面ですが、アクションとしてHTTP POSTを外部システムに発信する設定にしています。ここでは外部のJenkinsにVistaraのアラートの状態をパラメーターとして渡し、Jenkins側で分岐処理を定義し、必要に応じて修復処理を行います。JenkinsからIoTプラットフォーム管理サーバ上にSSHログインして特定のスクリプトを実行したり、複数のジョブ（Jenkinsではプロジェクトと呼ばれる）を連携させてジョブフロー化したりできます。Vistaraのパラメータを引き継ぎながら、JenkinsからさらにHTTP POSTで別のシステムと連携させることもできます。
外部システムにHTTP POSTでVistaraのパラメータを渡す。
VistaraからHTTP POSTを受け取るJenkinsの管理画面
Jenkinsのパラメータ設定画面
JenkinsにてVistaraから渡るパラメータの値に応じて処理
また、前述のRaspbian OSのシェルスクリプトでのアラート発報と同様に、インシデント化するプログラムを記述し、VistaraのUIを経由せずにRest API/Email APIだけでインシデント化することもできます。
例（Raspberry PiでRaspbian OSを使用）：
#!/bin/sh
if [<アラートがCriticalのとき>]; then
curl –k https://app.vistanet.jp/api/basic/tenants/<クライアントID>/incidents
-H "Authorization: Basic <基本認証用文字列>"
-H "Authorization:vtoken <トークン文字列>"
-H "Content-Type:application/json"
-H "Accept: application/json"
-d '{"subject":"Too high temperature!",
"description":"Temperature is too high. Please resolve it.",
"priority":"High"}'
-X POST
elif [<アラートがWarningのとき>]; then
curl –k https://app.vistanet.jp/api/basic/tenants/<クライアントID>/incidents
-H "Authorization: Basic <基本認証用文字列>"
-H "Authorization:vtoken <トークン文字列>"
-H "Content-Type:application/json"
-H "Accept: application/json"
-d '{"subject":"Moderately high temperature!",
"description":"Temperature is high. Please check it.",
"priority":"Normal"}'
-X POST
else ##通常温度のとき
## 特に何も実行しない
このようにVistaraはそれ自体がITオペレーションコマンドセンターとしてITライフサイクルに渡る機能を一気通貫で持ちながらも、APIを活用しつつIoTをはじめ外部のシステムとも柔軟に連携できるようになっています。
次回最終回は、VistaraによるMicrosoft Azure上のリソース監視について触れたいと思います。
どうぞお楽しみに！
Vistara の詳細については下記をご覧ください！
https://sios.jp/products/oss-integration/service/oss_on_cloud/vistara.html
