ConfigSourceの作成

概要

ConfigSourceは、GroovyまたはPowershellスクリプトに基づくテンプレートであり、LogicMonitorがデバイスの構成ファイルにアクセス、収集、およびアラートを送信する方法を定義します。

他のLogicModuleと同様に、LogicMonitorは、多くの一般的なシステムおよびアプリケーション用に事前構成されたConfigSourceを使用してインストールされます。 ただし、独自のカスタムConfigSourceを作成することもできます。

ご注意： ConfigSourceデータ収集がクラウドリソースに対して適切に機能するためには、最初にローカルコレクターを介した監視を有効にする必要があります。 ローカルコレクターによる監視の有効化.

ご注意： 監視対象の構成ファイルは、個々のファイルあたりのサイズが3MBを超えることはできません。

ご注意： .configファイルは、LMESデータビュー期間まで[リソース]ページで利用できます。 後で.configファイルを表示する場合は、APIトークンを使用して、LMESデータストレージ期間内に.configファイルをダウンロードする必要があります。 さらにサポートが必要な場合は、サポートチームにお問い合わせください。

ConfigSourceの作成

ご注意： 構成ファイルを監視および警告する機能が現在LogicMonitorプラットフォームで利用できない場合で、詳細を知りたい場合は、カスタマーサクセスマネージャーに連絡してください。

ConfigSourceを作成するには、に移動します 設定| LogicModules | ConfigSources | 追加| ConfigSource。 表示される[CreateNew ConfigSource]ダイアログから、構成する必要のある設定のXNUMXつのカテゴリがあります。

• 一般情報
• アクティブディスカバリー
• コレクター属性
• 構成チェック

一般情報

1. 名前：ConfigSourceの一意の名前。 ベストプラクティスとして、この名前はわかりやすいものにする必要があります。プラットフォームまたはアプリケーションの名前を指定し、必要に応じて、プラットフォームの特定のコンポーネントを指定します。  
2. として表示：ConfigSourceが[デバイス]ページに表示される名前。 この名前は一意である必要はありません。
3. 説明：このConfigSourceに関連付けられる説明。 ベストプラクティスとして、ConfigSource名がConfigSourceが収集しているものに関して明確でない場合、説明フィールドは、名前と説明を見た人がConfigSourceの機能を明確にするのに十分な情報を提供する必要があります。
4. 検索キーワード：ConfigSourceに、検索を容易にするキーワード（名前、目的、スコープなどに関連する）をタグ付けします。
5. テクニカルノート：このフィールドには、説明に含まれているもの以外に、ConfigSourceに関連するその他のテクニカルノートを含めることができます。
6. グループ：ConfigSourceが追加されるConfigSourceグループ。 このフィールドを空のままにすると、ConfigSourceはグループに追加されません。 既存のConfigSourceグループと一致しないテキストを入力すると、作成されます。

に適用されます

この に適用されます フィールドは、LogicMonitorのAppliesToスクリプトを入力として受け入れ、このConfigSourceに関連付けられるリソースを決定します。 このフィールドの使用に関する詳細情報（ウィザードおよびテスト機能を含む）、およびAppliesToスクリプト構文の概要については、を参照してください。 AppliesToスクリプティングの概要.

すべて収集

この すべて収集 フィールドは、データが収集される頻度（つまり、データ収集間隔）を定義します。

このフィールドは、チェックする構成に適した間隔に設定する必要があります。 たとえば、頻繁に変更されるアイテムや、エラーが発生した場合（スーパーバイザー/管理CPUが過負荷など）にすぐに対応する必要があるアイテムは、XNUMX時間などの短いポーリングサイクルにする必要があります。

ポーリングサイクルが長いほど、監視対象のサーバーとコレクターの両方にかかる負荷が少なくなることに注意してください。 

マルチインスタンス？

このオプションをオンにすると、ConfigSourceはマルチインスタンスになります。

マルチインスタンスとは、構成ファイルが複数回出現することを意味します。 マシン情報の記入> という構文でなければなりません。例えば、 for の試合に Fortigateファイアウォール上のネットワークインターフェース。それぞれに独自の設定ファイルが含まれています。

アクティブディスカバリー

アクティブディスカバリー ConfigSourceの監視対象インスタンスを管理するために使用されます。 これは、マルチインスタンスConfigSourceにのみ適用されます。 Active Discoveryが有効になっている場合、LogicMonitorはデバイス上のConfigsourceのインスタンスを自動的に検出し、それらの表示名またはエイリアスを判別して、それらを最新の状態に保ちます。

アクティブディスカバリーを有効にする

チェック アクティブディスカバリーを有効にする ConfigSourceのインスタンスを自動的に管理します。 このオプションは、 マルチインスタンス？ オプションがチェックされます。

計測パラメータ

この Active DiscoveryParametersスクリプト は、使用可能なデバイス構成ファイルを判別し、それらのConfigSourceインスタンスを作成する組み込みのGroovyまたはPowerShellスクリプトです。 スクリプトがインスタンスを検出する正確な方法は、デバイスの種類によって異なります。 例については、これを参照してください CiscoASAデバイス用のConfigSource検出スクリプト. 

コレクター属性

ここでは、構成ファイルの取得に使用するGroovyまたはPowerShellスクリプトを埋め込む必要があります。 GroovyまたはPowershell以外のスクリプト言語を使用する場合は、スクリプトファイルをアップロードするオプションもあります。 可能な場合は、 ベストプラクティスは、埋め込まれたGroovyスクリプトを使用することです したがって、EXPECT構文を利用できます。

ConfigSourceスクリプトの構文は、大部分が標準化されています。 独自のConfigSourceスクリプトを作成する場合、LogicMonitorのベストプラクティスでは、既存のConfigSourceテンプレートをLogicMonitorリポジトリからコピーして貼り付け、環境に合わせて必要な構文上の変更を加えることをお勧めします。 たとえば、Juniperデバイスを使用している場合は、 期待する（「＃」） 以下のスクリーンショットで使用されるコマンドは、Ciscoの設定を識別します。 期待する（“ <“）

スクリプトを実行する前に、 SSH認証資格情報をプロパティとして設定する 構成監視を実装するデバイス上。 これらのプロパティは、次の形式をとる必要があります ssh.user / ssh.pass 適用されたデバイスがSSHを許可する場合、または config.user / config.pass 非SSHデバイス（つまり、telnet / FTP）の場合。 スクリプトは、これらのプロパティをプルインし、それらを使用してデバイスにSSHで接続するように設計されています。 SSH認証権限が自動的に有効になっていないデバイス（Cisco ASAなど）では、XNUMX番目の資格情報をプロパティとして保存する必要がある場合があります。 ssh.enable.pass.

ConfigSourceスクリプトの構造を理解するために、Groovyで記述されたサンプルスクリプトの内訳を次に示します。

1. デバイスのプロパティで設定されたSSH認証資格情報を取得します。
2. デバイスにSSHで接続します。 「＃」は接続が成功したことを示し、デバイスはコマンドを受信する準備ができていることを期待してください。
3. デバイスの構成ファイルのページ付けを無効にします。 これにより、ファイルが単一の中断のないビューで確実に取得されます。
4. 構成ファイルを要求します。
5. デバイスとのSSHセッションからログアウトします。
6. 取得した設定ファイルからNTPクロック周期値を取り除きます。 この値は常に変化し、これらの変化は通常問題になりません。 この値を削除すると、ConfigCheckが不要なアラートを生成するのを防ぎます。
7. SSH接続を閉じ、スクリプトの出力（構成ファイル）をLogicMonitorアカウントにインポートします。

この特定のスクリプトは、提供されたSSH認証資格情報が実行中の構成を表示するのに十分であることを前提としていることに注意してください。 Cisco ASAなどの一部のデバイスでは、これらの昇格されたアクセス許可を有効にするために追加の手順が必要になります。

このような場合、「ssh.enable.pass」と呼ばれる追加のデバイスプロパティが定義されていると、スクリプトはそれを使用して特権をエスカレートしようとします。 「ssh.enable.pass」プロパティが存在しない場合、スクリプトは標準の「ssh.pass」プロパティを使用して特権をエスカレートしようとします。

try
{
    pass = hostProps.get("ssh.pass")
}
catch (all)
{
    println "(debug::fatal) Could not retrieve the config.pass device property.  This is required for authentication.  Exiting."
    return 1
}
try
{
    enable_pass = hostProps.get("ssh.enable.pass")
}
catch (all)

構成チェック

ConfigSourcesは、構成チェックに基づいてアラートを生成します。 データソースのデータポイントとしきい値と同様に、構成チェックは構成ファイルの可用性、またはファイルの特定のコンテンツを監視し、定義された基準が満たされたときにアラートをトリガーします。 構成チェックにはXNUMXつのタイプがあり、それぞれが構成ファイルを監視するための特定の方法を提供します。

各タイプの構成チェックで使用できるオプションは、ConfigSource定義で選択されたファイル形式によって異なります。 監視している構成ファイルに最も適したファイル形式を選択すると、構成チェックを定義するプロセスが簡単になり、エラーが発生しにくくなります。

ファイル形式

任意のテキスト、java-properties、およびUnixのXNUMXつのファイル形式を使用できます。 java-propertiesまたはUnixファイル形式を使用すると、ConfigSourceの設定を容易にする暗黙的なチェックがいくつか提供されます。 デフォルトのファイル形式は任意のテキストです。

注意：ファイル形式は、ConfigSourceの作成時に選択する必要があり、ConfigSourceの保存後に変更することはできません。

ファイル形式の説明

Unix。 改行文字（\ r \ n）を使用して行を区切るDOS形式とは対照的に、行は改行文字（\ n）で区切られます。 「＃」で始まる行はコメントとして扱われます。

java-properties。 「.properties」とも呼ばれます。 「＃」または「！」で始まる行コメントとして扱われます。 「=」の前のテキストはキー（フィールド）として扱われ、「=」の後に続くテキストは値として扱われます。 以下は、java-properties形式のテキストのサンプルです。

＃「。properties」エントリを読んでいます。 ！ 感嘆符は、テキストをコメントとしてマークすることもできます。 website = https://en.wikipedia.org/ language = English＃以下のバックスラッシュは、アプリケーションに＃値を次の行に読み続けるように指示します。 メッセージ= \ウィキペディアへようこそ！ ＃キーにスペースを追加しますkey \ with \ space =これは、キー「keywithspaces」で検索できる値です。 ＃Unicodeタブ：\ u0009

ファイル形式による暗黙のチェック

構成チェックタイプ

構成チェックにはXNUMXつのタイプがあり、それぞれが構成ファイルを監視するための特定の方法を提供します。

チェックタイプ：構成を取得できません

説明: 収集スクリプトが正常に完了しなかった場合にアラートを生成します。

オプション： 生成されるアラートの重大度を選択できます。

コメント： アラートは、収集スクリプトが正常に完了するまでアクティブのままになります。

例

この構成チェックは、構成ファイルを取得できない場合にエラーアラートを生成します。

チェックタイプ：変更（差分チェック）

説明: 構成ファイルの内容に変更が検出された場合にアラートを生成します。

オプション： フィルタを追加して、タイムスタンプや空白行の追加または削除などの特定の変更を無視できます。 ファイル形式がUnixまたはjava-propertiesの場合、一部のフィルターはデフォルトで含まれますが、必要に応じて削除できます。 確認応答時、設定された期間が経過した後、またはそのいずれか（つまり、最初に発生したイベント）のいずれかでクリアするようにアラートを構成できます。 生成されるアラートの重大度を選択できます。

コメント： アラートクリアオプションのどちらも有効になっていない場合、収集された構成ファイルが現在のバージョンと同一であるときにアラートがクリアされます。

例

この構成チェックは、構成で変更が検出された場合に警告アラートを生成します。デフォルトでは、UNIXファイル形式のフィルターは無視されます。 確認応答時にアラートをクリアするオプションが有効になっています。

チェックタイプ：フィールドがありません

説明: 指定されたフィールドが構成ファイルに存在しない場合にアラートを生成します。

オプション： 生成されるアラートの重大度を選択できます。

コメント： ファイル形式が任意またはUNIXに設定されている場合、このチェックはファイルの内容で指定された文字列を検索するだけです。 問題のフィールドを明確に識別するために、正規表現が必要になる場合があります。 ファイル形式がjava-propertiesの場合、チェックは指定された文字列をファイル内のフィールド（キー）名のリストと比較します。 指定されたフィールドが構成ファイルで見つかると、アラートがクリアされます。

例

この構成チェックでは、「Ubuntu17-9ab76122-」というテキストが構成ファイルに存在しない場合、警告アラートが生成されます。

チェックタイプ：値

説明: フィールドの値が指定された基準を満たさない場合にアラートを生成します。

オプション： 値の比較演算子を選択するか、値が構成ファイルのあるバージョンから次のバージョンに変更された場合に単にアラートを出すことができます。 値の変更によってアラートが生成された場合は、確認時に、設定された期間が経過した後、またはそのいずれか（つまり、最初に発生したイベント）をクリアするようにアラートを構成できます。 生成されるアラートの重大度を選択できます。

コメント： ファイル形式が任意またはUnixに設定されている場合、このチェックはファイルの内容で指定された文字列を検索するだけです。 フィールド値を抽出するには、キャプチャグループを含む正規表現が必要になります。 ファイル形式がjava-propertiesの場合、チェックは指定された文字列をファイル内のキー値のリストと比較します。 確認時にクリアするか、設定した期間オプションが有効になった後にクリアするかのどちらでもない場合、値が指定された基準を満たしたときにアラートがクリアされます。

例

この構成チェックは、コミュニティ文字列の値が変更された場合にクリティカルアラートを生成します。 キャプチャグループとして指定されたコミュニティ文字列の値を持つ正規表現の使用に注意してください。

チェックタイプ：Groovyスクリプト

説明: Groovyスクリプトが1を返した場合にアラートを生成します。構成ファイルの内容は、組み込みのテキスト変数「config」を介して構成チェックで使用できるようになります。 標準のGroovy文字列メソッド など contains, matches, size。 Groovyスクリプトの構成チェックには、Collectorバージョン25.200以降が必要であることに注意してください。

オプション： 生成されるアラートの重大度を選択できます。

コメント： アラートを生成するかどうかを決定するためのすべてのロジックは、スクリプトに含まれています。 チェック自体は、スクリプトによって返される値を確認するだけです。1はアラートをトリガーし、0はトリガーしません。 スクリプトが0を返すと、アラートがクリアされます。

例

この構成チェックでは、Groovyスクリプトを使用してsystem.hostnameデバイスプロパティの値を取得し、この値が構成ファイルに存在するかどうかを確認します。 そうでない場合は、エラーアラートが生成されます。