Robotmk による Checkmk 合成監視

このエンドツーエンドの監視を実現するには、複数のコンポーネントが連携して動作しています。ここでは、その概要について簡単に説明します。

Robotmk スケジューラは、Setup > Agent rules > Robotmk scheduler (Windows) にあります。 ルールはかなり広範囲に及ぶため、ここでは空の設定を見てみましょう。

まず、スケジューラには、すべてのテストスイートが保存されているベースディレクトリが必要です。Base directory of suites に、任意の明確なファイルパスを入力してください。たとえば、C:\robots のように入力します。

現在表示されているParallel plan groups は、Checkmk固有の概念です。

これを説明するには、まず 1 階層下へ移動する必要があります。ここに、項目「Sequential plans 」があります。 このような連続したプランは、どのスイートをどのパラメータで実行するかを定義します。 ロボットフレームワークは、これらのスイートを順番に処理します。 その理由は簡単です。実際には、テストはデスクトップ上で実行される場合があり、複数のテストスイートが同時に実行されて互いに干渉する可能性があるからです（マウスカーソルの制御を奪い合うような状況です）。

プラングループは、順番に実行されるプランをカプセル化したものであり、それ自体は並行して実行されます。 ここでも、その理由は単純です。これにより、デスクトップに依存しないテストスイートを、遅延なく独自のプランで実行することができます。この記事で使用しているテストスイートは、このようなプロセスの良い例です。

ダイアログに戻ります。唯一の明示的な設定は、Group execution interval で設定する実行間隔です。

それでは、最初のプランを設定しましょう。Application name に任意の名前を入力できます。 この名前は一意である必要はありません。 ここでは、監視するアプリケーションの名前、たとえばOnlineShop 、またはこの例では単にMyApplication という名前を使用するのが適切です。 もちろん、このオンラインストアは、他のテストスイートによって、あるいは同じテストスイートによって異なるパラメータで、複数回テストされる場合もあります。 そのような場合、Variant フィールドを使用すると、名前が同じでも明確な結果を得ることができます。 たとえば、アプリケーションOnlineShop をドイツ語で1回、英語で1回（対応するパラメータを使用して）テストする場合、ここでは対応する略語を使用することができます。 監視は、My OnlineShop_en およびMy OnlineShop_de の結果を返します。

ただし、Relative path to test suite file or folder の指定は必要です。 パスは、上記で指定したベースディレクトリからの相対パスです。たとえば、C:\robots\ の場合はmybot\test.robot となります。 あるいは、ディレクトリ（複数のrobot ファイルを含む）をここで指定することもできます。その場合は、単にmybot と指定します。

Execution configuration. Limit per attempt で、テストスイートを実行できる最大経過時間（1回の試行あたり）を定義します。Robot Framework re-executions を使用して、テストが失敗した場合にテストスイートを完全にまたは段階的に繰り返すよう、ロボットフレームワークに指示することができます。 テストスイート内の個々のテストが互いに独立している場合は、時間を節約するには増分戦略が最適です。 一方、テストスイートが「ログイン → 製品ページを呼び出す → ショッピングカートに製品を入れる → チェックアウト」などの論理的なシーケンスをテストする場合は、テストスイートを完全に再処理する必要があります。 最終的には、結果は 1 つだけになります。

完全な再実行の場合、最終結果には、自己完結型のスイートの結果のみが考慮されます。最終的な再実行でテストが失敗した場合、そのテストスイートは失敗とみなされます。 増分再試行の場合、最終結果は最良の部分結果で構成されます。一部のテストが 3 回目の試行で初めて成功した場合、最終結果も成功としてカウントされます。 注意：プラングループ内のすべてのプランの試行回数と最大実行時間の組み合わせによって、そのプラングループの最小実行間隔が決まります。

デフォルトでは、Automated environment setup (via RCC) で RCC による実行が有効になっています。この設定では、2 つの値を入力する必要があります。 まず、RCC では、robot.yaml ファイルの場所を指定する必要があります。 このファイルの主な目的は、Python 環境の設定、つまり Python および依存関係のインストールを担当するconda.yaml ファイルを参照することです。 この指定は、Relative path to test suite file or folder で上記で設定したベースディレクトリを基準としています。 YAML ファイルはサブディレクトリに保存することもできますが、スイートのトップディレクトリに保存することをお勧めします。 上記のベースディレクトリC:\robot\ およびスイートディレクトリC:\robot\mybot に対して、それに応じてmybot\robot.yaml となります。

Python 環境の構築には、以下の時間制限があります。大量のデータをダウンロードして設定する必要がある場合があるため、ご注意ください。 特に、必要なブラウザの場合、数百メガバイトの容量がすぐに蓄積されますが、これは初回の実行時のみです。 RCC は、conda.yaml の内容に変更があった場合にのみ、環境を再構築します。

Robot Framework parameters では、ロボットフレームワークのコマンドラインパラメータの一部を使用することができます（これらのパラメータは、コマンドrobot --help でも表示されます）。 追加のパラメータを使用する場合は、Argument files オプションを使用してください。 ここで指定したファイルには、任意のロボットパラメータを記述することができます。 個々のパラメータの詳細については、インラインヘルプをご覧ください。

このサンプルプロジェクトでは、Variables オプションのみが有効になっており、値My Value の変数MYVAR が設定されています。 ファイルtests.robot の先頭にあるコマンドLog ${MYVAR} を覚えていますか？ これは、対応する参照です。

Secret environment variables オプションは、ロボットフレームワークのオリジナル機能ではないため、特に注意が必要です。 ここでは、ロボットフレームワークのライブラリ「CryptoLibrary」と組み合わせてパスワード用に、秘密の環境変数を設定することができます。 ここで設定した変数はログには表示されませんが、それぞれのテストホストの Checkmk 設定ファイルにプレーンテキストで書き込まれます。

スイート設定の最後に、3 つのほぼ自明のオプションがあります。

Execute plan as a specific user により、Robotmk を特定のユーザーアカウントのコンテキストで実行することができます。 背景：デフォルトでは、Robotmk は、デスクトップへのアクセス権限のない Checkmk エージェント（LocalSystem アカウント）のコンテキストで実行されます。 ここでは、デスクトップセッションに常にログインし、それに応じてグラフィカルデスクトップアプリケーションにアクセスできるユーザーを指定することができます。

Assign plan/test result to piggyback host を使用すると、プラン/テストの結果を別のホストに割り当てることができます。 たとえば、ロボットフレームワークがオンラインストアの注文プロセスをテストしている場合、その結果は対応する web サーバーに割り当てることができます。

各テスト実行では、C:\ProgramData\checkmk\agent\robotmk_output\working\suites\ にデータが保存されます。 デフォルトでは、過去 14 日間の結果が保持されますが、ここでは大量のデータがすぐに蓄積される可能性があることにご留意ください。 1 回の実行で少なくとも 500 キロバイトのデータが生成されます。たとえば、より複雑なテストスイートや埋め込みスクリーンショットを使用すると、すぐに数メガバイトのデータに膨れ上がる可能性があります。 実行間隔、レポートのサイズ、およびドキュメントの要件に応じて、このような状況では対応する必要があります。

ここで、このプラングループまたはさらに別のプラングループで、さらにプランを作成することができます。

最後に、Robotmk スケジューラの完全な設定に関連する 2 つのオプションがあります。

RCC profile configuration では、除外するプロキシサーバーおよびホストを指定できます。

Grace period before scheduler starts も非常に便利です。スケジューラは、デスクトップのログオン前に Checkmk エージェントとともに起動します。もちろん、これはデスクトップでのテストはすべて失敗することを意味します。 開始は、猶予期間を使用して手動で遅らせることができます。

これで設定は完了です。プラグインを使用して新しいエージェントをベイクし、手動または自動エージェントアップデートによって配備することができます。

監視では、個別のサービスルールを作成していない場合でも、Robotmk スケジューラの状態、および個々のプランとテストのステータスに関するサービスを確認できます。

原則として、標準ファイル (robot.yaml, conda.yaml, test.robot) を含むロボットディレクトリ全体を、Windows では ZIP 形式、Linux では tar.gz 形式でアーカイブするだけで済みます。

ただし、このようなテストは Git によって管理されることが多く、その結果、配布すべきではないファイルが定期的に発生します。これらのファイルは通常、gitignore ファイルによって管理されます。 アーカイブをクリーンに保つための補助として、無視するファイルを含まないアーカイブを作成する Windows および Linux 用の 2 つの小さなスクリプトを用意しています。 これらのスクリプトは補助としてのみ使用し、必ず事前にシステムで機能をテストしてください。

Windows:

Linux:

このバリエーションでは、テスト自体に変更を加える必要はありません。Robotmk KPI discovery ルールを開き、監視するキーワードを正規表現または非常に具体的な名前として入力してください。

注意：正規表現が同じテスト内の複数のキーワードと一致する場合、1 つのキーワードのみ認識され、そのサービス状態はUNKNOWNになります（Checkmk は、実際にどのキーワードが一致しているかを認識できないため）。

マーカーによるディスカバリーを行うには、以下の手順を実行する必要があります。

インストールするには、上記のconda.yaml にrobotframework-robotmklibrary を追加する必要があります。 上記のスイートとの変更点は、黄色で強調表示されています。

テストスイートtests.robot は、ライブラリ（Settings 領域）とマーカーで拡張する必要があります。 KPI は多くの場合、個々のユーザーキーワードを参照するため、キーワードFoobar がここに追加されます（これは、標準キーワードLog を呼び出すだけで、テストケースMy Test によって呼び出されます）。

Robotmk キーワードMonitor Subsequent Keyword Runtime は、次のキーワード（Foobar ）を監視（Checkmk を起動）するためのマーカーです。より正確には、そのランタイムを監視します。 オプションのdiscover_as 引数を使用して、監視するサービスに個別の名前を指定することができます。そのため、キーワードFoobar は、My user keyword というサービス名として監視に表示されます。

パターンベースのディスカバリーと比較した大きな利点は、1 つのテスト内で同じキーワードを明示的に複数回監視できることです。

上記の例に、2 つのFoobar 呼び出しを追加した例です：

したがって、Foobar キーワードの 3 つの呼び出しは、監視にMy user keyword 、Foobar_2 、およびFoobar_3 として表示されます。

キーワードを監視するためにどちらのバリエーションを使用する場合でも、次のステップは常に評価の設定です。 サービスは、どのランタイムでWARN またはCRIT に移行するべきでしょうか？ これを行うには、Robotmk KPI monitoring ルールで対応するレベルを定義します。

キーワードサービスは、監視において次の 2 つのパターンのいずれかで表示されます。

したがって、違いはキーワードの直前に括弧で囲まれた出所の表示のみです。

2 つの Foobar キーワードサービスを含む上記のスクリーンショットに示すように、スイートを多少拡張する必要がありました。

2 つのキーワード「Foobar 」および「Barfoo 」は、監視では「Foobar 」という名前で表示されますが、括弧内の起源の表記によって区別することができます。

同じ名前でリストされている2 つの異なるキーワードの例は、主に起源情報を明確にするために使用されています。

前述のように、discover_as の実際の目的は、1 つのキーワードをテストで複数回呼び出すことができるようにしながら、それぞれの出現を個別に命名できるようにすることです。

この方法は、技術的な背景よりもはるかに簡単です。特に、ZIP アーカイブ（Linux では tar.gz アーカイブ）としてカタログを扱う場合はそうです。 基本的には、ROBOCORP_HOME 変数を指定してカタログを構築し、それをアーカイブとしてエクスポートしてから、手動で配布するだけです。 以下に、そのパスを詳しく示します。 以下の例のパスは Windows に限定されています。Linux で別のコマンドが必要な場合にのみ、そのコマンドを明示的に指定しています。

まず、RCCRemote はスタンドアロンのツールではなく、Robocorp/Sema4 からドキュメントや製品ページは提供されていません。 リモートサーバーは RCC の一部であり、RCC のコンパイル時に構築されます。 サーバーは通常、コンテナを介して動作します。 コンテナでの動作については、Robotmk プラグインの開発者である Elabit の GitHub ページに、RCCRemote-Dockerというプロジェクトがあります。ただし、RCCRemote および RCCRemote-Docker は Checkmk 合成監視の一部ではなく、Checkmk サポートの対象外です。

この配布パスのカタログは 2 つの方法で作成できます。ZIP ファイルとしてエクスポートされたカタログ（上記を参照）は、Windows と Linux の両方で使用できます。 Linux のみの場合、RCCRemote-Docker コンテナ内でカタログを直接構築することも可能で、手動での操作がまったく必要ありません。

RCCRemote-Docker の設定方法、証明書のハンドル方法、カタログのインポート方法については、プロジェクトページをご覧ください。

Checkmk 側の設定は、今回も（通常どおり）非常に簡単です。Environment dependency handling オプションは、今回はFetch from RCC remote server に設定し、サーバーのアドレスを指定します。

RCCRemote サーバーが自己署名証明書を使用するか、CA 署名証明書を使用するかによって、もう 1 つ設定が必要です。 どちらの場合も、通常、Robotmk scheduler (Windows|Linux) オプションのRCC profile configuration をCustom profile に設定する必要があります。

自己署名証明書の場合は、Validate TLS certificates ボックスをオフのままにしておけば十分です。

ただし、CA 署名付き証明書の場合は、このオプションを有効にし、署名機関からの証明書をRoot CA (PEM 形式) に保存する必要があります。

スケジューラがデータを受信しない場合は、環境の構築が正常に行われていない可能性があります。 この原因としてよくあるのは、ネットワークの問題により、特定の依存ファイルがロードできない場合です。 この場合は、C:\ProgramData\checkmk\agent\robotmk_output\working\environment_building にある対応するログファイルを確認してください。

これは、新しい Windows システムで発生しやすい、特に興味深いエラーです。conda.yaml には、依存関係のインストール後に実行すべき指示（たとえば、ロボットフレームワークブラウザの初期化）が含まれている場合もあります。 そのため、ここでは Python コマンドを実行する必要があります。 デフォルトでは、Windows 11 には、Microsoft Store を指すpython.exe およびpython3.exe のエイリアスがあります。 これらのエイリアスは、『設定/アプリ実行のエイリアス』で無効にする必要があります。

注意：Linux では、Robotmk スケジューラは独自のログファイル（Windows ではrobotmk_scheduler_rCURRENT.log ）を作成せず、エージェントおよび syslog 経由でログを記録します。 対応するコマンドは次のとおりです。