LMDXについて

この記事では、LM Dexda を ServiceNow インスタンスと統合する LogicMonitor Data Exchange (LMDX) アプリケーションの背後にある概念について説明します。 

LMDX を使用すると、ServiceNow で問題に関する通知を受け取ることができ、リンクを通じて LM Dexda の情報にアクセスして調査することができます。 インサイトの詳細を確認し、関連するアラートと問題の種類を確認し、それらが相関している理由を理解できます。 LM Dexda の問題を調査する方法については、次を参照してください。 データの探索.

LMDX は現在、ServiceNow の一般的に利用可能なすべてのバージョンで動作することが認定されており、またネイティブに動作します。 ドメイン分離インスタンス.

コア アプリケーションには、次の完全に機能する構成レコードが含まれています。

• インシデント (LMDXDefaultInc)— との同期を管理します。 事件 ServiceNow のテーブル。
• CMDB (LMDXデフォルトCmdb)— との同期を管理します。 cmdb_ci ServiceNow のテーブル (送信のみ。詳細については、を参照してください) CMDB).

関連するものすべて 構成アーティファクト アプリケーションにバンドルされています。 すべての構成レコードと関連アーティファクト (可能な場合) はデフォルトでは非アクティブになっており、使用するにはオンにする必要があります。 詳細については、「」を参照してください。 LMDXのインストール.

これらの設定は、LMDX をインストールしてすぐに起動して実行できる標準のデフォルト フィールドを利用するため、そのまま使用できます。 必要に応じて、デフォルトの構成を変更することもできます。

CMDB

LMDX は、ServiceNow CMDB (構成管理データベース) レコードの更新を処理し、処理と保存のためにそれらを LM Dexda に動的にエクスポートできます。 これにより、LM Dexda は CMDB 内に含まれる選択された情報の現在のコピーを維持できるようになり、受信イベントを強化するために使用されます。 

イベント エンリッチメントは、LM Dexda のイベント処理と機械学習に追加のビジネスおよび運用コンテキストを提供します。 これにより、ネイティブ ServiceNow レコード (参照フィールドや影響を受ける CI などの多対多 (m2m) テーブルなど) に正しいレコードの関連付けも提供されます。

LMDX には、ServiceNow と LM Dexda の間でコア標準 CMDB データを迅速に同期できるようにする、cmdb_ci テーブル用の事前構築された Config レコードが含まれています。 ただし、CMDB 内の子クラスでのみ使用できるより具体的なフィールドがある場合は、LMDX 経由でそのテーブルを同期するように設定できます。 詳細については、「」を参照してください。 新しいテーブルとアーティファクトの作成.

階層サポートと関係設定

LMDX は CMDB 階層を利用します。 子テーブルのレコードが CMDB の親テーブルの Config レコードに設定されたパラメータと一致する場合、そのレコードは親テーブルの構成をトリガーします。 ただし、レコードに適用できる異なる CMDB テーブルに関連付けられた複数の Config レコードがある場合、LMDX は CMDB 階層内で最も近い一致 (たとえば、最も低いもの) を使用します。

LMDX は、ドメイン分離インスタンスの CMDB 構成の場合にも、同様の方法でドメイン階層を利用します。 LMDX は、次に説明するように、単純な構成レコード設定のセットを使用して CI 間の関係を送信できます。

設定記録

A 構成 (x_lomo_dx_config) レコードは LMDX のメイン レコードです。 これは、ServiceNow テーブルが LMDX 経由で LM Dexda と同期しているとマークされていること、および更新を送信するタイミングを構成するための設定があることを示します。

本国行きの

「受信」タブには、LMDX が LM Dexda からの受信メッセージの処理を実行するために必要な主要レコードへのリンクがあります。 これらの記録は、 セット テーブルのインポート、と 変換マップ.

外国行きの

[アウトバウンド] タブには、いつ更新を LM Dexda に送信するかを構成するための設定と、LM Dexda へのアウトバウンド メッセージの処理を LMDX が実行するために必要なメイン レコードへのリンクが含まれています。

アウトバウンド設定には次のものが含まれます。

• 調子- 条件に一致するレコードのみが処理の対象となるように条件を設定できます。 トリガーフィールドと組み合わせて使用​​されます。
• トリガーフィールド- リストされたフィールドのいずれかの値が変更されると、LMDX が更新をトリガーして LM Dexda に送信するフィールドを示します。 条件と組み合わせて使用​​されます。
• 更新フィールドのインポート- リストされたフィールドのいずれかの値が変更された場合、LMDX が更新を既存の保留中の更新とマージせず、代わりにレコードの現在の状態で新しい更新を作成するフィールドを示します。 使用可能なフィールドのリストは、選択したトリガー フィールドに限定されます。 詳細については、「」を参照してください。 ペイロードのマージ.
• LMDX で作成されたレコードのみを送信する- LMDX によって作成されたレコードのみを同期する必要があることを指定できます。 これは、特定のユーザーによって作成または更新されるレコードに依存する条件を設定する必要がないことを意味します。 このフィールドは、「タスクのような」テーブルの構成レコードを対象としています。たとえば、 事件.
• レコードタイプ- これには、LM Dexda 管理者によって提供された特定の値が入力されます。

[アウトバウンド] タブには、LMDX が LM Dexda にメッセージを送信する処理を実行するために必要なメイン レコードへのリンクもあります。 これらの記録は、 ビジネスルール や アウトバウンド変換マップ.

CMDB 関係

CMDB 関係タブには、構成アイテムの関係を LM Dexda に転送するかどうかを決定する設定が含まれます。 このタブは、Config レコードでマークされたテーブルが CMDB 階層の一部として検出された場合にのみ表示されます。

最大高さと最大深さの設定は、各 CI レコードで処理するリレーションシップのレベルの数を定義します。 次の画像例では、高さ「4」と深さ「4」は、各 CI レコードについて、関係の各レベルが最大 XNUMX 回処理されることを意味します。

履歴レコードのロード

[履歴レコードのロード] ボタンを使用すると、LM Dexda に設定された条件に一致するすべての既存のレコードを簡単にエクスポートできます。 これらの記録は「歴史的」とみなされ、両方が使用されます。 insert や update 操作タイプ アウトバウンド フィールド マップ. 

これらのレコードは、アウトバウンド ペイロードをバッチ処理して LM Dexda に送信するときに、優先度が低いとみなされます。 また、送信ペイロードが送信される前にベース レコードで更新が発生した場合、レコードは常に更新されたペイロードとマージされます。 詳細については、「」を参照してください。 ペイロード表.

ドメインの分離

LMDX は、ドメイン分離が有効になっている ServiceNow インスタンスでネイティブに動作できます。 これにより、ServiceNow インスタンスを個別のドメインに論理的に分離でき、単一のインスタンスで複数の組織をサポートできます。 マネージド サービス プロバイダー (MSP) として、たとえばイベント、アラート、分析情報をテナントごとに分離できます。 詳細については、「」を参照してください。 テナントとドメインの分離によるグループ化.

LMDX 自体はドメイン分離されておらず、スコープ指定されたアプリケーション レコードはすべてグローバル ドメイン内にあります。 これはSNだからです 管理人 ユーザーが LMDX にアクセスして設定できるようにするには、(セキュリティ上の理由から) ロールが必要です。

アプリケーションが正しく動作することを保証するには、すべての LMDX アーティファクト (構成レコード、アウトバウンド変換マップ、およびアウトバウンド フィールド マップ) をグローバル ドメイン内に作成する必要があります。 唯一の例外はビジネス ルールです。これはインスタンスのプライマリ ドメインに存在する必要があります。 詳細については、「 ServiceNow のドキュメント.

有効なドメイン

LMDX のドメイン サポートを有効にすることができます。 これにより、LMDX で「有効」としてマークされた特定のドメインを設定できるようになり、有効になった各ドメインが独自の LM Dexda 資格情報を持つことができ、LM Dexda ポータル内でデータを分離できます。 詳細については、「」を参照してください。 ドメイン サポートの有効化.

ドメイン階層のサポート

LMDX はドメイン階層を利用します。 子ドメインのレコードが親ドメインの構成レコードに設定されたパラメーターと一致する場合、そのレコードによって親ドメインの構成がトリガーされます。 これにより、複数の子ドメイン (たとえば、異なる顧客) にわたる構成の標準化が可能になります。 XNUMX か所で変更を加えることができ、LMDX はその変更をすべての子ドメインに適用します。

ただし、XNUMX つのレコードに適用できる、異なる有効なドメインに関連付けられた複数の Config レコードがある場合、LMDX はドメイン階層内で最も近い一致 (たとえば、最も低いもの) を使用します。

LMDX はまた、 CMDB階層 同様の方法で。 ドメイン分離インスタンス内の CMDB 構成の場合、一致の順序は、ドメイン階層を上に移動する前に、同じドメイン内の CMDB 階層で最初に実行されます。

ペイロード表

LMDX は、すべての受信 (インバウンド) および送信 (アウトバウンド) データを次の形式でキャプチャします。 ペイロード レコード (x_lomo_dx_payload)。 これにより、インスタンスからどのような情報が送受信されるかを簡単に確認できます。 また、ペイロードの逐次処理やエラーからの回復も可能になります。

ペイロードの送信

LMDX は、送信ペイロードをバッチで定期的に送信します。 これは、という名前のスケジュールされたジョブによって実行されます。 LMDX – 送信ペイロードの処理、デフォルトでは 60 秒ごとに実行されるように設定されています。

LMDX は、挿入および更新ペイロード (たとえば、レコードの挿入または更新によって生成されたペイロード) の送信を優先します。 歴史的記録。 バッチ内に十分なスペースがない場合、残りのペイロードは、スケジュールされたジョブが再度実行されるまで保留状態のままになります。

ペイロードのマージ

ペイロードのマージは、送信を待機している送信ペイロードがあるが、そのペイロードが送信される前に、そのペイロードに関連付けられた基本レコードが更新される場合に発生します。 これは、ほとんどの更新では、レコードごとに XNUMX つのペイロードのみが送信され、ペイロードには最新の値が反映されることを意味します。

ただし、マージは行われません。 重要な更新フィールド 更新中に値が変更されました。 代わりに、新しい送信ペイロード レコードが生成され、送信される挿入および更新ペイロードのキューの最後に追加されます。

自動再試行ポリシー

外国行きの エラーが発生した場合、ペイロードは常に自動的に再試行されます。 これは、スケジュールされたジョブが再度実行されて送信ペイロードを LM Dexda に送信するときに発生します。

本国行きの ペイロードには自動再試行ポリシーがありません。 これは、受信ペイロードのエラーや警告は ServiceNow 管理者が手動で解決する必要があるためです。 したがって、受信ペイロードには、以下で説明する順次処理機能があります。

手動再試行ポリシー

外国行きの ペイロードは常に自動的に再試行されるため、手動で再試行するメカニズムはありません。

本国行きの ペイロードでは手動での再試行が可能で、ペイロードのステータスが次の場合は [再処理] ボタンが表示されます。 エラー or 完了 (警告あり). 手動の再試行では、該当する場合、インバウンド ペイロードの順次処理が実行されます。

インバウンド・ペイロードの順次処理

LMDX には、受信ペイロードに対する順次処理機能があります。 受信ペイロードの処理中にエラーまたは警告が発生した場合、後続の新しい受信ペイロード レコードは同じものになります。 外部参照 (external_reference) 値は、同じ警告またはエラーに自動的に続きます。

警告またはエラーの根本原因が解決されると、同じペイロードで任意のペイロードを使用できるようになります。 外部参照 すべての既存のペイロードを順番に再処理する値。 これは、 作成日 (sys_created_on) 各ペイロードの値。 これにより、ServiceNow が LM Dexda から受信したのと同じ順序ですべてのペイロードが処理されます。

ペイロード レコードの削除

ペイロード レコードは、ServiceNow に組み込まれている Table Cleaner 機能を使用して自動的に削除されます。 詳細については、「 ServiceNow のドキュメント.

ステータスのあるペイロードは自動削除されません。 エラー、またはステータス付きの受信ペイロード 完了 (警告あり)。 これは、エラーまたは警告から回復できるようにするためです。

アウトバウンド変換マップとフィールド マップ

送信変換マップは、ServiceNow 変換マップと同じように機能します。 これらを使用すると、特定のレコードのどのフィールドを ServiceNow から LogicMonitor に送信するかを構成できます。 フィールドは、ServiceNow フィールド マップと同様のアウトバウンド フィールド マップを使用して指定されます。

アウトバウンド フィールド マップ

アウトバウンド フィールド マップの次の機能は、LogicMonitor 統合に固有です。

• 値型- ユーザー インターフェイスに表示される値とともに基礎となる値を持つフィールドで使用できます。 これは、フィールドが「実際の」値 (参照フィールドの sys_id など)、「表示値」 (参照フィールドに表示される値)、または両方の値を送信する必要があるかどうかを示します。
  
  「両方」を選択すると、「実際の」値を含む「_fv」の接尾辞を持つフィールドとともに、「表示」値がフィールドの値に設定されます。

{
    "state": "New",
    "state_fv": "1",
}
{
    "state": "New",
    "state_fv": "1",
}

• 操作タイプ- フィールドが特定のレコード操作タイプに対して送信されるかどうかを示します。 たとえば、フィールドは、レコードが挿入、更新、またはその両方が行われた場合にのみ送信される必要があります。

アウトバウンド フィールド マップでのスクリプト作成

ServiceNow のフィールド マップと同様に、アウトバウンド フィールド マップは変換プロセス中にスクリプトを実行できます。 [アウトバウンド フィールド マップ] フォームで、次を選択します。 スクリプトを使用 をクリックして、スクリプト フィールドと関連するフィールド名を表示します。

「スクリプト」フィールドにスクリプトを追加する場合、次の変数を使用できます。

• 現在- アウトバウンド変換によって処理されているレコードの GlideRecord。 ビジネス ルールと同じ現在のオブジェクト。
• 無視する- フィールドを無視するかどうかを示すブール値。 この値を返す必要はありません。

スクリプト フィールドを使用するには、次の例に示すように値を返す必要があります。 または、「無視」を「true」に設定することもできます。