どういう LogicMonitorプロフェッショナルサービス 行う？ 最も複雑な統合の課題のいくつかを解決しながら、LogicMonitorの完全な展開を通じてお客様をガイドします。 LogicMonitorを活用することがよくあります REST API 顧客のワークフローとタスクを自動化するための独自のソリューションを開発する。
この投稿では、主要なエンタープライズ顧客のXNUMXつである、有名な多国籍CADソフトウェアメーカーの特定のユースケースを紹介し、ニーズに合わせたカスタムソリューションを考案するために行ったプロセスを説明します。
同期する2,000CI？ 汗かいていない。
Fortune 1000のお客様のXNUMX人から、ServiceNowを活用しているとの連絡がありました。 構成管理 データベース（CMDB）を使用して、デバイスのインベントリを追跡します。 LogicMonitorには、との統合が組み込まれています。 ServiceNow 双方向のインシデントエスカレーションと配信用ですが、構成管理用ではありません。 これは、監視インフラストラクチャのメンテナンスを自動化する機会であると認識しました。 この場合、ServiceNowで構成アイテム（CI）が作成、更新、または削除されるたびに、ユーザーの介入を必要とせずに、これがLogicMonitorポータルに反映されることを意味します。
LogicMonitorには非常に堅牢なRESTAPIがあり、ほとんどすべてのプログラミング言語を使用して、ポータルでデバイスを作成、読み取り、更新、削除（CRUD）するプロセスを自動化できます。 同様に、ServiceNowCMDBにはCIのクエリに使用できる独自のRESTAPIがあることを確認しました。
ニッティ・グリティ
このタイプのカスタム作業で達成する最も重要なことのXNUMXつは、最初に必要なすべての要件を収集することです。 以下に、この特定のエンゲージメントのためにまとめた要件の質問のリストと、それぞれの回答を示します。
- どのタイプのデバイス（ストレージ、ESX、Linuxなど）を同期しようとしていますか？
- デバイスを作成、更新、および削除するための基準は何ですか？
- これらのCMDBCIはどのようにLogicMonitorデバイスにマッピングされますか？
- 検出されたデバイスをコレクターに自動的に割り当てるにはどうすればよいですか？
- 複数のコレクターから選択できますか？
- コレクターのサブセット間で負荷分散したいですか？
- カスタムアラート統合に渡す必要のある情報は何ですか？
- スクリプトをいつどこから実行しますか？
＃1と＃2複数の作業セッションに基づいて、LogicMonitorデバイスとグループ化構造を作成するために必要なすべてのデータがCMDBCIオブジェクト自体から利用可能であると推定することができました。 以下に、同期することを選択した特定のServiceNowCMDBクラスをリストしました。 このリストは、将来、任意の数のクラスタイプに拡張できます。
＃cmdbからLogicMonitorに同期されるクラスCMDB_SYNC_CLASSES = ['cmdb_ci_linux_server'、 'cmdb_ci_msd'、 'cmdb_ci_esx_server'、 'cmdb_ci_solaris_server']
さらに、CIの動作ステータスを使用して、デバイスを作成、更新、または削除するタイミングを決定しました。
＃3 ServiceNow CMDB REST APIによって返されるCIをマッピングするには、ServiceNowCIからLogicMonitorデバイスにプロパティをマッピングするマッピングテーブルを作成する必要がありました。 また、値が必要かどうかを指定する機能も追加しました。
＃ServiceNowプロパティ名からLogicMonitorプロパティ名へのマッピングと＃およびそれらが必須プロパティであるかどうか。 DIRECT_PROPERTIES = [['name'、 'displayName'、True]、['ip_address'、 'name'、True]]
＃4デバイスを割り当てるコレクターを決定するために、CIの名前、場所、およびタイプに基づいてコレクターのサブセットから選択するマッピングテーブル（CSVファイル）を作成しました。 追加のボーナスとして、負荷分散も組み込まれているため、監視対象のデバイスの数が最も少ないサブセットから、デバイスがコレクターに自動的に割り当てられます。 CSVの例を参照してください。
＃5カスタムアラート統合でチケットを作成するために、顧客はCIのオブジェクトに存在する特定のメタデータを必要としていました。 アイテム1から4に使用したのと同じプロセスでカスタムプロパティを作成することで、このニーズにすばやく対応できました。その後、チケットシステムは、追跡目的でLogicMonitorデバイスをCMDBのCIと正常に関連付けることができました。
＃ServiceNowプロパティ名からLogicMonitorカスタムプロパティ名へのマッピング＃およびそれらが必須プロパティであるかどうか。 CUSTOM_PROPERTIES = [['sys_class_name'、 'sn.sys_class_name'、True]、['manufacturer'、 'sn.manufacturer'、False]、['u_support_tier'、 'sn.u_support_tier'、True]、['u_used_for'、 'sn.u_used_for'、True]、['support_group'、 'sn.support_group'、True]、['operational_status'、 'sn.operational_status'、True]、['sys_id'、 'sn.sys_id'、True] 、['os'、 'sn.os'、False]、['location'、 'location'、False]]
以下に、高レベルの鳥瞰図からコードを示します。 含まれているのは、リファレンスドキュメントで使用したLogicMonitorのリソースとアクションです。
def execute（）：logging.log（ 'ServiceNowCMDBとLogicMonitorPortalの同期が開始されました。'）＃資格情報、マッピング、負荷分散などの構成設定を読み込みます。configure_incremental_sync（）configure_clients（）＃ServiceNowCMDBからデバイスを取得します。 cmdb_devices = get_cmdb_devices（）＃CMDB CIが作成、更新、または削除された場合、LogicMonitorにこれを反映させます。 if len（cmdb_devices）> 0：＃構成基準に基づいてLogicMonitorデバイスオブジェクトを作成または更新します。 lm_devices = map_cmdb_to_lm_devices（cmdb_devices）＃LogicMonitorデバイスオブジェクトをLogicMonitorポータルにプッシュします。 create_or_update_lm_devices（lm_devices）logging.log（ 'ServiceNowCMDBとLogicMonitorポータルの同期が完了しました。'）
＃6コードの実行については、枠の外で少し考えたかったのです。 明らかな答えは、CMDB同期スクリプトをオンプレミスで設定されたスケジュールで実行することですが、さらに一歩進んでみたかったのです。 お客様との以前の話し合いで、彼らはLogicMonitorを使用していると述べました AWSモニタリング、およびインフラストラクチャでいくつかのAWSサービスを活用していました。 これにより、サーバーのプロビジョニングについて心配することなくコードを実行できるAWSLambdaが思い浮かびました。
サーバーまたはサーバーレス？
スクリプトはオンプレミスで実行するように作成されていましたが、AWS Lambda関数は、スクリプトが作成された言語を含む幅広い言語をサポートしています。Lambda関数は、関数の作成時に構成されたトリガーイベントに基づいて実行されます。 ラムダカナリアトリガーを使用して、設定されたスケジュールでCMDB同期コードを実行することができました。 また、スクリプトが完全同期または増分同期を実行できるように、いくつかの構成フラグを追加しました。 完全同期では、CMDBからすべてのCIが取り込まれますが、増分同期では、最後の同期以降に変更されたCIのみが取り込まれます。
最終的に、「サーバーレス」コード（AWS Lambda）を使用して、お客様のCMDBからLogicMonitorポータルにデバイスを移行するプロセスを正常に自動化することができました。 デバイスのプロビジョニングまたは廃止のためにCMDBに変更が加えられると、スクリプトが実行されると、これはLogicMonitorポータルに自動的に反映されます。 これは、新しく追加されたCIのダウンタイムとパフォーマンスの問題を特定するのに役立ち、廃止されたデバイスの誤ったアラートを最小限に抑えます。 設定して忘れてください。
