従業員のリクエストに応じて、さまざまなITシステムを顧客のインフラストラクチャに統合することに関する一連の記事から新しい資料を提示します。 今回は、監視システムやITSMシステムなどの共生について詳しく説明します。
これらのシステムは個別に長い話になる場合があります。 適切に構成された稼働中の監視システムは、多くのトラブルを回避または防止するのに役立ち、ITSMシステムにより、ITプロセスを管理し、インフラストラクチャで発生するイベントを記録できます。 これらのシステムの複雑な動作を個別に掘り下げることはしませんが、顧客全体および特にITインフラストラクチャを提供するサービス会社の利益のためにこれらのシステムを組み合わせる方法を学習します。
監視統合の場合、監視システムに記録されたイベント、アラートがITSMシステムでインシデントの作成を開始するという事実に主に関心があります。
アラート -デバイスまたはサービスが設定されたしきい値に達したときに監視システムによって記録されたイベント。
インシデントとは、サービスの標準操作の一部ではないイベントであり、サービスの中断またはサービス品質の低下を引き起こすか引き起こす可能性があります。
市場で最も人気があり需要の高いシステムの1つであるServiceNowとMicrosoft System Center Operation Manager（SCOM）の例での統合を検討します。 ただし、このアプローチは他の同様のシステムに実装できます。
監視システムとITSMシステムを統合するには、主に2つの方法があります。
1.コネクタ、いわゆるMIDサーバーを使用します。 ServiceNowはクラウドプラットフォームであるため、中間リンクの使用は、このようなバンドルが正常に機能するための優先条件です。
2. REST API（REpresentational State Transfer Application Program Interface）を使用します。 ServiceNowも含まれる最新のWebアプリケーションは、ユーザーにそのようなインターフェイスを提供します。
REST APIは、分散されたスケーラブルなWebサービスを構築するためのソフトウェアアーキテクチャのスタイルです。
各実装パスには長所と短所があります。 前者の場合、MIDサーバーをインストールし、特定のポートを開くなどする必要があります。 また、2つのサポートチームの相互作用も必要であり、場合によっては困難です。 2番目のケースでは、ServiceNowで特定の権限を持つアカウントのみが必要であり、原則としてそれだけです。 他のすべての作業は、監視チームが行うことができます。
すべての長所と短所を比較検討し、経験を評価した後、2番目のパス、つまりREST APIを使用することにしました。
ベースライン分析
そのため、タスクは監視システムのイベントによるインシデントの発生を自動化することでした。 イベントのソースに応じて、インシデントに優先順位を付け、特定の責任あるチームに割り当てる必要があります。
まず、監視システムのイベントを分析しました。 統合を構築する際に考慮する必要がある規則性がいくつか特定されました。 たとえば、1つのアラートが複数のアラートまたは1つのロケーションを受信する場合があります。 通常、このようなイベントはグループ化され、グループごとに1つのインシデントのみが作成されます。
責任のあるチームのリストが定義され、優先順位のリストがイベントのタイプに応じてまとめられています。
実装
SCOM側で作業の大部分を実行するため、監視システム配布キットの一部であるOperationsManagerモジュールと組み合わせてPowerShellを使用する方が便利です。 特定のデータについてREST APIを使用してServiceNowに連絡し、直接インシデントを作成します。
ServiceNowにはかなり開発されたプログラミングインターフェイス（API）があり、システムをほぼ完全に制御できます。 Table APIメソッドのみが必要です。 このメソッドを使用すると、ServiceNowでレコードを作成、更新、読み取り、削除できます。 私たちの場合、これはTable API-GET / api / now / table /であり、これを使用してServiceNowからデータを読み取り、Table API-POST / api / now / table /で実際に新しいインシデントを追加します。
その他のメソッドについては、 docs.servicenow.com/bundle/geneva-servicenow-platform/page/integrate/inbound_rest/concept/c_TableAPI.htmlで説明しています 。 メソッドへのパラメーターとして、構造化ハッシュテーブルが必要なデータと共に渡されます。 以下のスクリプトの一部では、この場合に使用されるパラメーターを確認できます。
#Define Hash Table $HashTable = @{ 'u_snow_category' = 'Infrastructure'; 'u_affected_user' = 'scom'; 'caller_id' = 'scom'; 'assignment_group' = $record.ResolverGroup; 'cmdb_ci' = $record.CI.name; 'location' = $record.Location; 'short_description' = [System.Web.HttpUtility]::HtmlEncode($record.ShortDescription); 'description' = [System.Web.HttpUtility]::HtmlEncode($record.Description); 'impact' = $record.Impact; "contact_type" = "Own Observation"; #Posting new incident $RaisedIncident = Invoke-RestMethod -uri "$SNOW$SNOWtable`incident" -Headers $PostHeader -Method Post -Body ($HashTable | ConvertTo-Json);
上記の例では、行
$RaisedIncident = Invoke-RestMethod -uri "$SNOW$SNOWtable`incident" -Headers $PostHeader -Method Post -Body ($Body | ConvertTo-Json);
ServiceNowでインシデントを直接作成します。
「$ SNOW $ SNOWtable`incident」はプログラムインターフェイスのアドレスであり、通常は次のようになりますCustomDomain.service-now.com/api/now/table/incident
$ PostHeader-コンテンツタイプを渡す変数。
$ HashTable-必要なデータを含むハッシュテーブル。
簡略化されたスクリプトアルゴリズムは次のとおりです。
1.環境設定の読み取り
ミサゴ全体について読み取ったすべての変数を定義して、将来関数からアクセスできるようにします。
変数の読み取りの例：
New-Variable -Name ScriptConfiguraion -Value (Get-Content '.\Configuration.txt' -Raw -ErrorAction Stop | ConvertFrom-Json -ErrorAction Stop) -Option AllScope, ReadOnly -ErrorAction Stop;
構成設定を含むファイルに加えて、イベントが1つまたは別の優先度と1つまたは別の責任のあるチームに属するかどうかを判断するルールのリストが必要です。
New-Variable -Name DefaultRules -Value (Import-Csv $ScriptConfiguraion.Configuration.Rules.DefaultRules -ErrorAction Stop) -Option AllScope, ReadOnly -ErrorAction Stop;
この場合のルールファイルの例は次のとおりです。
{ "Parameters":"", "Properties":"Name", "Expression":"{0} -match \"http\\://www\\.domainname\\.com/\"", "ResolverGroup":"Application Team", "Priority":"2" },
ServiceNowに接続するための設定：
New-Variable -Name SNOW -Value $ScriptConfiguraion.Configuration.SNOW.APIURL -Option AllScope, ReadOnly -ErrorAction Stop; New-Variable -Name SNOWtable -Value $ScriptConfiguraion.Configuration.SNOW.APITables -Option AllScope, ReadOnly -ErrorAction Stop; New-Variable -Name GetHeader -Value (@{"Authorization" = "Basic " + [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($SNOWacc+":"+$SNOWaccPass))}) -Option AllScope, ReadOnly -ErrorAction Stop; New-Variable -Name PostHeader -Value (@{"Authorization" = "Basic " + [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($SNOWacc+":"+$SNOWaccPass));"Content-Type" = "application/json"}) -Option AllScope, ReadOnly -ErrorAction Stop;
気づいた場合、メインの構成ファイルからファイルパス、設定、サービスデータを取得し、最初から読み取り、その内容を$ ScriptConfiguraion変数に格納します。
次に、ServiceNowとSCOMを操作するためのモジュールをロードします。
Add-Type -AssemblyName System.Web -ErrorAction Stop; Import-Module OperationsManager -ErrorAction Stop;
2.監視システムからのデータの読み取り
SCOMからデータをアップロードするには、接続を確立する必要があります。
#Connecting to SCOM API if(-not(Get-SCOMManagementGroupConnection | ?{$_.IsActive})){ foreach($ManagementServer in $ScriptConfiguraion.Configuration.SCOM.ManagementServers){ New-SCManagementGroupConnection $ManagementServer; if(Get-SCOMManagementGroupConnection | ?{$_.IsActive}){ break; } } if(-not(Get-SCOMManagementGroupConnection | ?{$_.IsActive})){ Write-CustomLog "Script failed to connect to all SCOM management servers [$($ScriptConfiguraion.Configuration.SCOM.ManagementServers)] supplied in the configuration file. Please review debug log for more info."; exit; } }
そして、アラートに関するデータを読み取ります。
$AlertList = Get-SCOMAlert -Criteria "$($ScriptConfiguraion.Configuration.SCOM.AlertCriteria)";
$ AlertListへの出口には、$ ScriptConfiguraion.Configuration.SCOM.AlertCriteriaの基準を満たすSCOMからのすべてのアラートのリストがあります。 次の基準を設定します。
(CustomField2 IS NULL OR CustomField2 = '') AND Severity = 2 AND ResolutionState <> 255
インフラストラクチャのCustomField2に、インシデント番号データを保存します。 したがって、将来的には、インシデント番号で必要なアラートを簡単に見つけることができ、このフィールドを使用して、同じタイプのアラートのインシデントをグループ化します。
3. ITSMシステムからのデータの読み取り
インシデントデータを受信したら、ITSMシステムの構成単位であるCI（構成アイテム）の情報を読み取る必要があります。 これは、監視システムのデータとITSMシステムのデータを比較し、作成されたインシデントの優先度を設定するために必要です。
CIデータをアップロードするためのスクリプトの一部は次のとおりです。
$CI = (Invoke-RestMethod -uri "$SNOW$SNOWtable`cmdb_ci" -Headers $GetHeader -Method Get -Body @{sysparm_query="nameLIKE$SourceObject";sysparm_fields='name,location,u_environment,u_service_level,sys_updated_on,install_status'}).result;
4.場所によるアラートのグループ化
イベントをグループ化するために、SCOMのすべてのアラートを場所ごとにグループ化します。
$Alerts = $Alerts | group Location;
そして、ITSMシステム内の特定のグループにインシデントがあるかどうかを確認します。 SCOMデータベースにインシデントに関する情報を記録するため、SCOM側も確認します。
foreach($entry in ($OperationalData | ?{$_.GroupingType -eq 'LocationAndMonitorID'})){ if($entry.Location -eq $Location -and $entry.MonitorId -eq $MonitorId){ return(@{sysID=$entry.sysID;Number=$entry.Number}); } }
5.経時的なアラートのステータスの確認とインシデントの作成
インシデントを発生させる前の最後のチェックは、全員がチェックしている間にアラートが閉じられたかどうかを確認することです。
($record.Alert.ResolutionState -ne 255){}
さて、すべての情報が受信されると、上記で説明したように、インシデント自体が発生します。
#Define Hash Table $HashTable = @{ 'u_snow_category' = 'Infrastructure'; 'u_affected_user' = 'scom'; 'caller_id' = 'scom'; 'assignment_group' = $record.ResolverGroup; 'cmdb_ci' = $record.CI.name; 'location' = $record.Location; 'short_description' = [System.Web.HttpUtility]::HtmlEncode($record.ShortDescription); 'description' = [System.Web.HttpUtility]::HtmlEncode($record.Description); 'impact' = $record.Impact; "contact_type" = "Own Observation"; #Posting new incident $RaisedIncident = Invoke-RestMethod -uri "$SNOW$SNOWtable`incident" -Headers $PostHeader -Method Post -Body ($HashTable | ConvertTo-Json);
将来的にこの情報を取得するためにServiceNowにアクセスしないように、CustomField2を更新することを忘れないでください。
$AlertUpdateResult = $Alert | Update-Alert -ParamStr "-CustomField2 'Raised' -CustomField3 '$($result['IncidentNumber'])'
結論
ご覧のとおり、ServiceNowとの統合を簡単な方法で実装することはそれほど難しくありません。 詳細に入らない場合、すべての統合は、監視システムからデータをアップロードし、それに基づいてITSMシステムでインシデントを発生させるスケジュールでスクリプトを実行することに限定されます。 さらに、インシデントはサービスデスクによって処理されるか、担当チームに直接処理されます。
統合の導入により、システム内のイベントに対する全体的な反応時間が短縮されるため、時間内に発生する問題に対応し、それらをタイムリーに排除できます。 インシデントを提起する際の人為的エラーが削減されます（別のチームへの不適切な割り当て、インシデントの不適切な優先順位、初期診断に必要なデータの入力なし）。 総人件費が削減されます。