ベストプラクティス

LogicMonitorを使用したMSPクライアントのオンボーディングの自動化

LogicMonitorを使用したMSPクライアントのオンボーディングの自動化

クライアントのオンボーディングを自動化すると、ダッシュボードのクローン作成、グループディレクトリ構造の作成、レポートの設定、アクセスロールの構成などの面倒な作業を省くことができます。 これらのタスクはすべて、ヒューマンエラーが発生しやすく、穏やかに言えば、実際に行うのは楽しいことではありません。 このブログでは、PowerShellスクリプトを使用して、これらのタスクの一部を自動化します。 具体的には、複数のNOCロケーション、ダッシュボードグループを含むクライアントグループ構造の作成、標準ダッシュボードの複製、および新しいクライアントがLogicMonitorポータルにアクセスするときの読み取り専用ユーザーロールの作成。    

私はという名前の関数を使用します  リクエストの送信 私の同僚であるジョナサン・アーノルドによって書かれました。 モニタリングレシピGithub。 この関数は、APIリクエストをXNUMX行に簡略化します Send-Request $ resourcePath $ httpVerb $ queryParams $ data

このブログのコードスニペットは、特定のタスクを実行するためのコードロジックとともにこれらの変数を定義します。  

リソースディレクトリ構造の作成

対処する必要がある最初の問題は、さまざまなNOCの場所です。 MSP■通常、形式のためにすべてのクライアントで使用される標準のフォルダ構造になります。 ただし、クライアントには、説明が必要な複数のNOCがあります。 これを解決するために、配列とdoループを使用しました。  

<# Client Info #>
$Client = 'Woeber Capital'
<# NOC Locations #>
$SitesArrray = @("Atlanta","DR","Florida","Home Routers","LA","NYC")

スクリプトのグループ作成部分では、最初にLogicMonitorを使用してルートクライアントフォルダーを作成します RESTAPI開発者ガイド.  

#Main Client Group 
$data = '{"name":"' + $Client + '","parentId":' + $clientDir + '}'
$resultsGrp = Send-Request $resourcePath $httpVerb $queryParams $data

* $ clientDirはメインクライアントグループのIDであり、オプションです

次に、foreachループを使用して、NOCの場所に基づいてグループを作成し、これらの各グループの下に、「システム| ネットワーク| NOCの下のDR」グループ。 $ resultsGrrp.idは、前の手順で作成したデバイスグループIDです。  

<# Static Groups creation Loop through Locations #>
foreach ($Site in $SitesArrray){
    #Main Location Group 
    $data = '{"name":"' + $Site + '","parentId":' + $resultsGrrp.id + '}'
    $resultsLocation = Send-Request $resourcePath $httpVerb $queryParams $data
    Write-host $data

    #System
    $data = '{"name":"System","parentId":'+ $resultsLocation.id + '}'
    $resultsSubdir = Send-Request $resourcePath $httpVerb $queryParams $data
    
    #Network
    $data = '{"name":"Network","parentId":'+ $resultsLocation.id + '}'
    $resultsSubdir = Send-Request $resourcePath $httpVerb $queryParams $data
    
    #DR
    $data = '{"name":"DR","parentId":'+ $resultsLocation.id + '}'
    $resultsSubdir = Send-Request $resourcePath $httpVerb $queryParams $data
}

ダッシュボード構造の作成とデフォルトダッシュボードの複製

次に、事前設定された## defaultResourceGroup ##トークンを使用してダッシュボードグループを作成します 

これは、先ほど作成したグループ構造を示しています。 このようにして、このダッシュボードグループに複製されたダッシュボードは、以前に作成されたクライアントグループ構造を指すように自動的に構成されます。  

# Add Dashboad Group with Widget Token
$resourcePath = "/dashboard/groups"
$queryParams = ""
$data = '{"name":"' + $Client + '","parentId":' + $dbGroup + ',"widgetTokens":[{"name":"defaultResourceGroup","value":"CLIENTS/' + $Client + '"}]}'
Write-Host $data
$resultsDashboards = Send-Request $resourcePath $httpVerb $queryParams $data

ダッシュボードのクローン作成には、いくつかの注意が必要な部分があります。 XNUMXつ目は、ウィジェットのサイズがダッシュボード自体ではなくウィジェットに保存されることです。 元のダッシュボードからウィジェット構成を取得し、複製されたダッシュボードに正しいウィジェットサイズ情報をパッチすることで、これを回避することができます。 これを行う方法の詳細は、 ダッシュボード開発者APIガイド。 以下のコードはこれを実現します。  

    # Loop through the widgets to build WidgeConf JSON
    $i = 0
    DO
    {
        $widId = $orgDashboard.items[$i].id
        $widgetCof = $orgWidSize.widgetsConfig.$widId
        $WidConf = $WidConf + '"' + $clonedDashboard.items[$i].id + '" :' + '{"col":' + $WidgetCof.col + ',"sizex":' + $WidgetCof.sizex + ',"row":' + $WidgetCof.row + ',"sizey":' + $WidgetCof.sizey + "}"
        if ($i -lt ($clonedDashboard.total -1)){$widConf = $WidConf + ","}     
        $i++

    } While ($i -lt $clonedDashboard.total)

    write $data

    # Patch Dashboard with WidgeConfig JSON
    $httpVerb = "PATCH"
    $resourcePath = "/dashboard/dashboards/" + $cDashboard.id 
    $queryParams = ''
    $data = '{"widgetsConfig":{' + $widConf + '}}' #| ConvertTo-Json -depth 3
    $resizeDashboard = Send-Request $resourcePath $httpVerb $queryParams $data

複製するダッシュボードを指定し、複雑なディレクトリ構造に対応するために、配列を使用することができます。 以下の例では、3つのダッシュボードグループを表す配列を確認できます。 7つはルートクライアントレベル用で、7つはサブグループ(MicrosoftとVMware)用です。 配列には、複製される元のダッシュボードIDが含まれています。 これは、以前のNOCグループ化構造で使用されていたのと同じ手法です。 ダッシュボードIDを見つける最も簡単な方法は、URLで、例「/santaba/uivXNUMX/dashboard/index.jsp#dashboard=XNUMX」、ダッシュボードIDはXNUMXです。     

#Root level Dashboarrds
$DBToCloneArrray =  @(7,54,62,42,73)

# Microsoft Dashbaords
$msDashboards = @(295,354,122)

# VMWare Dashboards
$vmDashboards = @(294,165,456)

ダッシュボードセクション全体は、オンボーディングスクリプトの最も複雑な部分です。 以下はこのセクションの完全なコードであり、上記のルートレベルのダッシュボード配列を使用しています。  

<# Clone Root Level Dashboards #> 
foreach ($DB in $DBToCloneArrray){
    #Get Dashboard Name
    $httpVerb = “GET”
    $resourcePath = “/dashboard/dashboards/" + $DB
    $queryParams = '?fields=name'
    $data = $null
    $orgDbName = Send-Request $resourcePath $httpVerb $queryParams $data
    write $resourcePath
    write "testing = " + $orgDbName

    # Clone the dashboard
    $httpVerb = "POST"
    $resourcePath = "/dashboard/dashboards/" + $DB + "/clone"
    $queryParams = ''
    $data = '{"name":"' + $orgDbName.name + '","sharable":true, "groupId":' + $resultsDashboards.id + '}'
    $cDashboard = Send-Request $resourcePath $httpVerb $queryParams $data
    write $data

    # Original dashboard Widget Size, Sort by name to ensure array in same order as Cloned Dashboard
    $httpVerb = “GET”
    $resourcePath = “/dashboard/dashboards/" + $DB
    $queryParams = ‘?fields=widgetsConfig’
    $data = $null
    $orgWidSize = Send-Request $resourcePath $httpVerb $queryParams $data
    $orgWidSize | ConvertTo-Json -Depth 6


    # Original Dashboard Widget List, Sort by name to ensure array in same order as original Dashboard
    write "Orriginal Widget List"
    $httpVerb = “GET”
    $resourcePath = “/dashboard/dashboards/" + $DB + "/widgets”
    $queryParams = '?fields=id,name&sort=+name'
    $data = $null
    $orgDashboard = Send-Request $resourcePath $httpVerb $queryParams $data
    $orgDashboard | ConvertTo-Json

    # Cloned Dashboard Widget List
    write "Cloned Widget List"
    $httpVerb = “GET”
    $resourcePath = “/dashboard/dashboards/" + $cDashboard.id + "/widgets”
    $queryParams = ‘?fields=id,name&sort=+name'
    $data = $null
    $clonedDashboard = Send-Request $resourcePath $httpVerb $queryParams $data
    $clonedDashboard | ConvertTo-Json

    # Build the WidgeConfig JSON
    $WidConf = ''

    # Loop through the widgets to build WidgeConf JSON
    $i = 0
    DO
    {
        $widId = $orgDashboard.items[$i].id
        $widgetCof = $orgWidSize.widgetsConfig.$widId
        $WidConf = $WidConf + '"' + $clonedDashboard.items[$i].id + '" :' + '{"col":' + $WidgetCof.col + ',"sizex":' + $WidgetCof.sizex + ',"row":' + $WidgetCof.row + ',"sizey":' + $WidgetCof.sizey + "}"
        if ($i -lt ($clonedDashboard.total -1)){$widConf = $WidConf + ","}     
        $i++

    } While ($i -lt $clonedDashboard.total)

    write $data
    # Patch Dashboard with WidgeConfig JSON

    $httpVerb = "PATCH"
    $resourcePath = "/dashboard/dashboards/" + $cDashboard.id 
    $queryParams = ''
    $data = '{"widgetsConfig":{' + $widConf + '}}' #| ConvertTo-Json -depth 3
    $resizeDashboard = Send-Request $resourcePath $httpVerb $queryParams $data

クライアントユーザーアクセスロールの作成

すべてが作成され、必要な情報がすべて揃ったので、新しいクライアントに読み取り専用アクセスを許可するユーザーセキュリティロールを作成できます。 これは単に新しい役割を作成することです 「操作」:「読み取り」  スクリプトで作成されたクライアントグループ用。 ユーザーアクセスロールの作成の詳細は、 役割セクション API開発者ガイドの  

# Add the Company Role  
$resourcePath = "/setting/roles"
$queryParams = ""
$data = '{"name":"' + $Client + '","privileges":[{"objectType":"dashboard_group","objectId":' + $resultsDashboards.id + ',"objectName":"' + $Client + '","operation":"read"}, {"objectType":"host_group","objectId":' + $results.id + ',"objectName":"' + $Client + '","operation":"read"}, {"objectType":"report_group","objectId":' + $resultsReport.id + ',"objectName":"' + $Client + '","operation" : "read"},{"objectType":"help","objectId" : "feedback","objectName":"help","operation":"read"},{"objectType":"help","objectId" : "document","objectName":"help","operation":"read"},{"objectType":"help","objectId":"training","objectName":"help","operation":"read"}]}'
Write-Host $data
$resultsRole = Send-Request $resourcePath $httpVerb $queryParams $data

MSPオンボーディングスクリプトの作成に関するさまざまなセクションと、それらのコーディング方法の例について説明しました。 概説されたツールは、カスタムMSPオンボーディングのニーズに十分柔軟なオンボーディングスクリプトを開発し、かなり退屈なプロセスを自動化することを可能にするはずです。 詳細およびプロフェッショナルサービスオプションについては、カスタムサクセスマネージャーにお問い合わせください。  

著者
LogicMonitorチーム
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

私たちのブログを購読する

このような記事をあなたの受信箱に直接お届けします