オフライン監査アーカイブのクリーンアップ
監査が有効になっている場合、ディスク領域を監視して、監査サブシステムの AuditArchiveFileRepository をクリーンアップしなければならないかどうかを判断する必要があります。選択した実装に応じて、AuditArchiveFileRepository には次の 2 つのサブディレクトリのいずれかが含まれます。
• 直接永続 - AuditArchiveDirectPersistence
• データテーブル - AuditArchive
データテーブル実装を使用することを選択した後で直接永続実装に切り替えた場合、データテーブル実装での監査データは保持されます。ファイルリポジトリのディレクトリ構造は以下のようになります。
 | この逆も同様であり、直接永続からデータテーブルに切り替えた場合、直接永続のデータが保持されます。 |
リポジトリをクリーンアップする必要性について判断する際には以下の判定基準が役立ちます。
• AuditArchiveDiskSpaceUsed (MB で表示) - アーカイブリポジトリによって使用されているディスク領域の量。
• AuditArchiveFreeDiskSpace (MB で表示) - 空いているディスク領域の量。
CleanUpOfflineAudit サービスには次の 2 つの Scheduler Thing があります。
• AuditArchiveCleanupScheduler - デフォルトでは、毎月最終金曜日の午後 6 時にジョブをスケジュールします。ThingWorx Composer で AuditArchiveCleanupScheduler に移動し、そのコンフィギュレーションページで別の CRON 定義式を設定することによって、スケジュールを変更できます。
このジョブは CleanUpOfflineAudit サービスを呼び出します。現在アクティブな実装に応じて、CleanUpOfflineAudit は上記のいずれかのディレクトリからのみ、アーカイブされた監査データのサブディレクトリを削除します。データテーブル実装がアクティブな場合、AuditArchive からのみ、サブディレクトリが削除されます。同様に、直接永続がアクティブな場合、AuditArchiveDirectPersistence からのみ、サブディレクトリが削除されます。
このスケジューラの DaysToArchive プロパティの値より古いサブディレクトリが削除されます。このプロパティの値は ThingWorx Composer から設定できます。そのデフォルト値は 180 日です。
スケジューラを使用するだけでなく、CleanUpOfflineAudit サービスを手動で呼び出すこともできます。手動で呼び出した場合、サービスはこの日付を入力としてとり、現在アクティブな実装のサブディレクトリ (データテーブル実装の場合は AuditArchive、直接永続実装の場合は AuditArchiveDirectPersistence) からデータを除去します。
• AuditArchiveCleanupNotificationScheduler - クリーンアップサービスが実行されることをユーザーに通知します。デフォルトでは、この Scheduler Thing は毎月最終金曜日の午前 6 時にトリガーされ、クリーンアップサービスが午後 6 時 (AuditArchiveCleanupScheduler によってスケジュールされているジョブが実行されるデフォルト時刻) に実行されるというイベントを購読ユーザーに通知するイベントを発生させます。クリーンアップサービスのスケジュールと同様に、この通知サービスを実行する日や頻度を変更できます。イベントを購読し、そのイベントに基づいて実行するスクリプトに独自のロジックを追加することもできます。詳細については、以下のイベントの購読のセクションを参照してください。
クリーンアップサービス CleanUpOfflineAudit は入力として olderThanDate をとります。この引数は DateTime タイプであり、ロケールに基づいたフォーマットで指定します。このサービスは、指定されている日数より古い監査エントリをオフラインストレージから削除します。
 | CleanUpOfflineAudit サービスを手動で実行することもできます。 |
クリーンアップサービスは、出力として、正常に除去されたディレクトリと、該当する場合には、このサービスが除去に失敗したディレクトリについての情報を提供します。ファイルまたはディレクトリの除去に失敗してもクリーンアッププロセスは中止されません。このサービスは失敗したディレクトリをスキップして次のディレクトリに進みます。
クリーンアップサービスの動作を以下の例に示します。
例 4. CleanUpOfflineAudit サービスの使用
たとえば、日付 2020-03-07 を指定してこのサービスが呼び出され、直接永続実装のリポジトリサブディレクトリ AuditArchiveDirectPersistence に以下のサブディレクトリが含まれているとします。
クリーンアップサービスを実行すると、リポジトリには以下のサブディレクトリのみが含まれます。
2020-03-07 という名前のサブディレクトリは、olderThanDate として指定された日付のものであり、2020-03-08 という名前のサブディレクトリは olderThanDate よりも後のものです。この 2 つは維持されますが、ほかの 3 つのサブディレクトリは olderThanDate より古いので削除されます。
管理者だけがクリーンアップサービスを呼び出すアクセス許可を持ちます。非管理者ユーザーがこれを呼び出すには、管理者がサービスオーバーライドを使用してそのユーザーに適切なアクセス許可を付与する必要があります。サービスオーバーライドについては、このヘルプセンターのセキュリティのセクションにあるサービスのオーバーライドのトピックを参照してください。
何らかの理由でクリーンアップサービスが失敗した場合、エラーメッセージが失敗の理由とともに返されます。
オフライン保持期間の値を設定する際の最良事例
判定基準レポート機能が有効になっている場合、監査サブシステムとその監査アーカイブファイルリポジトリについての関連判定基準が ThingWorx Composer から提供されます。判定基準にアクセスするには、 > の順に選択します。判定基準の完全なリストが監査アクティビティの判定基準のトピックに記載されています。前述のように、以下の判定基準は、リポジトリ内にアーカイブされている監査データをクリーンアップしなければならないかどうかを判断する際に役立ちます。
• AuditArchiveDiskSpaceUsed (MB で表示) - AuditArchiveFileRepository にアーカイブされているデータによって使用されているディスク領域の量。
• AuditArchiveFreeDiskSpace (MB で表示) - 空いているディスク領域の量。
使用されているディスク領域が多く、空き領域が少ない場合、日付を指定してクリーンアップサービスを手動で呼び出すことでリポジトリをただちにクリーンアップすることをお勧めします。サービスは指定された日付を開始点としてそれよりも古いすべてのファイルとディレクトリを除去します。さらに、DaysToArchive を小さい値に設定して、環境で必要とされる空きディスク領域量を維持するようにしてください。
イベントの購読
AuditArchiveCleanupNotificationScheduler は AuditCleanupNotification という名前のイベントをトリガーして、予定されているファイルクリーンアップ操作について購読ユーザーに通知します。イベントを購読し、そのイベントに基づいて実行するスクリプトに独自のロジックを追加できます。
AuditArchiveCleanupScheduler に関連付けられているジョブには DaysToArchive という名前のプロパティがあります。デフォルトでは、このプロパティの値は 180 日 (6 カ月) です。この値は ThingWorx Composer から変更できます。スケジュールされたジョブは毎月実行され、指定した DaysToArchive よりも古いすべてのデータをクリーンアップします。自動サービス呼び出しの頻度を Composer で修正することもできます。