ジョブ: スケジュールと起動時
想定読者: エージェント起動直後にジョブを実行し、その後も固定間隔で実行し続けたい統合担当者。
スキャナーやレポーターでよくあるパターンです。起動時に一度すぐ実行してベースラインを得てから、スケジュールどおり継続します。ジョブ: スケジュールのみとの違いは、eventType: Startup の events エントリを追加する点です。両方のトリガーは独立しています。エージェントがジョブを読み込んだタイミングでStartupイベントが1回実行され、インターバルタイマーはStartup実行の完了を待たずにその時点から進みます。
本例はWindowsのパスを使います。LinuxおよびmacOSでは、ジョブ: 最小構成 (Linux) および ジョブ: 最小構成 (macOS) の例に示すとおり、パスと osFilter を置き換えてください。
ジョブのJSON
変更する箇所
id
本ジョブを一意に識別する文字列。ハイフンを使い、アンダースコアは使いません。ファイル名は id と一致させます (例: "id": "my-tool" のときは my-tool.json)。
name
ログや管理画面に表示する名称
schedule.intervalMinutes
起動後のスケジュール実行の間隔 (分)。Startupイベントがいつ実行されるかには影響しない
tasks[0].command
バイナリ名。パスや拡張子は含めません。
tasks[0].executablePath
エンドポイント上のバイナリのフルパス
tasks[0].arguments
バイナリが受け付けるフラグ。{KeeperApiBaseUrl} は残します。
tasks[0].timeoutSeconds
1回あたりの最大実行時間。Startup実行と各インターバル実行は、それぞれこの上限を独立して使う
動作の要点
スケジュールのみのパターンからの変更点は、"events": [{ "eventType": "Startup" }] を追加するだけです。それ以外は同じです。
エージェント起動時にジョブを読み込んだうえで、Startupを宣言したジョブではStartupイベントが実行されます。Startup実行とインターバルタイマーは独立しており、インターバルはStartup実行の完了を待ってから数え始めるわけではありません。そのため、ツールの実行時間がインターバル境界に近い場合、Startup実行がまだ進行中に最初のインターバル実行が始まることがあります。同時実行に耐えるようツールを設計するか、intervalMinutes を最悪実行時間より十分長く設定してください。
Startupイベントはエージェント起動ごとに1回だけです。ジョブの再読み込みやポリシー更新だけでは再実行されず、エージェントサービス自体が再起動した場合に限り再度実行されます。
KeeperLoggerはStartupジョブより前に準備が整います。ログ基盤の初期化が完了してからStartupイベントが送られるため、Startup実行の早い段階のログも失われません。
デプロイ前に
ジョブを登録する前に、エンドポイントの
executablePathにバイナリをデプロイする。環境でStartup実行が安全か検討する。大規模フリートでは、エージェント再起動のたびに全エンドポイントで同時実行が走ります。連携先でリソース競合が起きる場合は、ジョブ: スケジュールのみを使い、最初の実行までの遅延を受け入れる。
ファイル名は
idと一致させる。
デプロイ
保存前に検証します。
ジョブを作成します。
Startupの挙動を確認するには、エージェントサービスを再起動し、すぐに実行が記録されることを確認します。
最終更新