Skip to main content

BriefCamシステム管理者ガイド

メンテナンスとデータ保持

最終更新日: 17 分で読めます
バージョン2025r1
言語日本語

完全に最適化されたBriefCamシステムのパフォーマンスを維持するために、BriefCamは、データベースとストレージの両方からのデータも含めて、処理されたデータを定期的に自動的に消去します。

メンテナンスサービスは、複数のマシン間で負荷を分散するために複数のインスタンスにインストールできます。

自動メンテナンスをオフにするには、Maintenance.Enabled環境設定をfalseに設定します。ただし、ストレージがいっぱいになるため、これはお勧めできません。

Maintenance.ExecutionStrategy環境設定では、メンテナンスを毎日または継続的に実行するように設定できます。

  • 設定がデフォルトの Continuously(継続的)に設定されている場合、メンテナンスは 1時間ごとに実行されます。

  • Dailyに設定した場合、実行する時間はMaintenance.CleanHour環境設定で設定されます。値は時間ベース(hh:mm:ss)で、例えば23:00:00です。

To clear the data proactively, set the Maintenance.CleanHour environment setting to the current hour and set the Maintenance.ExecutionStrategy to Daily and then restart the Maintenance service. The maintenance will then run immediately. It is recommended to then change the settings back to their original value.

Maintenance clean setting.png

メンテナンスの実行に失敗した場合、プロセスが起動すると、システムは自動的に復旧を試みます。復旧の試みは、TaskRecovery.IntervalsMinutes設定で設定された時間間隔で行われます(下の画像を参照)。 デフォルトは10分、240分、1440分です。つまり、最初の復旧の試みは10分後、2回目の復旧の試みは4時間後、最後の復旧の試みは12時間後になります。

TaskRecover interval setting.png

Maintenance.ServiceInstancesRetentionMinutes環境設定は、オフラインになってからサービスがデータベースから削除されるまでの時間を決定します。この時間はBriefCam、次の時間です。デフォルト値は43,200分(30日)です。

以下のセクションでは、メンテナンスプロセスの動作を制御する追加の環境設定について説明します。

REVIEWモジュール

注記

自動メンテナンス中に削除されたくないREVIEWケースがある場合は、ケースの画面からedit (Edit icon white.png ) (編集)アイコンをクリックし、Do not delete during maintenance(メンテナンス中に削除しない)チェックボックスを選択します。これらの印付きケースとそのアーティファクトは、他のケースやアラートが削除されても、メンテナンスプロセスでは削除されません。

ベストプラクティスは、以下の2つの設定(CaseRetentionDaysとVideoArchiveExpirationDays)を同じ値に設定することです。

設定: Maintenance.CaseRetentionDays

デフォルト: 30日

ケースの更新日が30日(デフォルト)より古い場合、ケースのすべてのデータはデータベースとディスクから削除されます。この場合、ケースの更新日は30日より前にBriefCam設定されます。ケースの更新日は30日より古くなります。

ケースの名前や説明の編集、ケースの共有、ビデオの追加/削除、ビデオスケジュールの編集、プリセットの編集、ブックマークの追加/削除など、ケースの変更はケースの更新日に影響します。ただし、ケースのウォッチリストに顔やナンバープレートを追加したり、ブックマークの詳細を編集しても、ケースの更新日には影響しません。

同じデータが他のケースで使用されている場合でも、ケースはケース画面から削除され、データはデータベースとディスクに残ります。

ケースにスケジュールが有効化された参照元が含まれている場合、ケースは削除されません。この設定の値より古いスケジュールされた参照元からのリクエストは削除されますが、そのブックマークは、ケース全体が削除されたときにのみ削除されます。ケースにスケジュールが有効化されていない参照元やスケジュールが無効化された参照元が含まれている場合は、それらの参照元も削除されません。

ケースに含まれているのが通常の参照元またはスケジュールが無効化された参照元のみの場合、ケースは通常の参照元として扱われます。つまり、ケースの更新日が30日(デフォルト)より古い場合、30日(デフォルト)より古いケースのすべてのデータがデータベースとディスクから削除されBriefCamます。

REVIEWリクエストの一部がオンデマンド処理に基づき、一部はライブリクエストに基づいている場合(一部のリクエストがすでにアラートに対して処理されているため)、アーティファクトはメンテナンスの設定に従ってREVIEWモジュールとRESPONDモジュールから削除されます。ただし、リクエストは、オンデマンド処理またはライブ処理の2つのうち最後に発生した処理日に従って、インフラストラクチャ(データベースを含む)から完全に削除されます。

ウォッチリストに関しては、ケース内に作成された内部ウォッチリストは、ケースが削除されると(メンテナンスによって、またはユーザーによって)削除されます。

ブックマークに関しては、上記のようにケースが削除されると、ブックマークも削除されます。

設定: Maintenance.VideoArchiveExpirationDays

デフォルト: 30日

この設定は、VMSから取得したビデオファイルを削除する頻度を制御します。この設定は、通常は自動で持ち込まれない(アラートのサムネイルをクリックするときだけ)RESPONDアラートでフェッチされた元のビデオにも影響します。この設定は、アラートのサムネイルをクリックした場合にのみBriefCam適用されます。 例えば、RESPONDモジュールでは、各アラートの元の映像は、ユーザーが元の映像を要求するまで取得されません。ユーザーが元の映像を要求するとBriefCam、このパラメータで指定された日数の間、元の映像にすぐにアクセスできるように保持されます。

設定: Maintenance.LocalFilesRetentionInHours

デフォルト:24時間

この設定は、レンダリングされた一時ファイルがデータベースから削除される頻度(時間単位)を制御しBriefCamます。

レンダリングされた一時ファイルは次の場所にあります。..\BriefCam\ServerData\VideoStreamingGateway\VideoService 。

ここに保存されるファイルは、Webクライアントユーザーの操作によって作成されたレンダリングされたアーティファクトです。VIDEO SYNOPSIS、元のビデオなど。

設定: Maintenance.RenderingUploadedFilesRetentionDays

デフォルト: 0.5日

この設定は、アップロードされたファイルがデータベースから削除される頻度を制御しBriefCamます。

アップロードされたファイルは次の場所にあります。..\BriefCam\ServerData\VideoData\WebUpload 。

ここに保存されるファイルは、Webクライアントを介してエンドユーザーがREVIEW処理の目的でアップロードしたビデオファイルです。Investigator 、Investigator for Teams 、Protectおよび設定。

設定: clientMaintenanceCaseMessageInDays

デフォルト:7日

この設定は、ケースの削除通知の表示をいつ開始するかを制御します。ここで設定されている値は、メンテナンスプロセスによってケースが削除されるように設定される前の日数です。

注意

これらの設定はハブには適用されません。これは、サイトおよびスタンドアローンデプロイメントにのみ関連します。

RESPONDモジュール

設定:Maintenance.LiveRetentionDays

デフォルト: 7日

保存期間外のすべてのRESPONDアラートは削除されます(ブックマークが付いているアラートも削除されますが、ブックマーク自体は削除されません)。RESPONDモジュール内のブックマークは、メンテナンスプロセスによって削除されることはありません。

現在実行中のライブタスクのアラートは、保存期間外であれば削除されます。

RESEARCHモジュール

設定:Maintenance.BIAssetsRetentionDays

デフォルト:30日

この設定は、RESEARCHBIテーブル(メタデータETLから生成される)がストレージから削除される頻度を制御します。BriefCam メタデータは、BriefCamストレージから削除される前に削除されます。これは、Qlikがデータを取得できなかった場合のバックアップです。

設定: Maintenance.BIVisualLayersRetentionDays

デフォルト:3650日

この設定は、ダッシュボードタブで使用されるビジュアルレイヤーファイルを削除する頻度を制御します。これにより、データベースとBriefCam、画像が保存されているフォルダBriefCamーからファイルが削除されます(C:\BriefCam\ServerData\RenderData )。

これを1日未満に設定すると、ビジュアルレイヤーに影響する場合があります。

設定: Maintenance.BITaskRetentionDays

デフォルト:3日

この設定は、RESEARCH処理タスクからのメタデータとビジュアルアセットがストレージから削除される頻度を制御しBriefCamます。メタデータは、RESEARCH処理中(継続的またはオンデマンド)に作成されるすべてのアセット/ファイル/レコードです。 これは、BIルールエンジンサービスのデータを保存する期間BriefCamです。

設定: RESEARCH.QVDRetentionDays

デフォルト:30日

この設定は、分割されたQVDを使用するデプロイメントの詳細テーブルを保持する日数を決定します。

設定:RESEARCH.DetailedLoadDays

デフォルト:30日(v6.4より前からアップデートされた環境では、デフォルトは730 日)

この設定は、RESEARCHアプリから読み込まれるデータを制御します(VMS時間ではなくタイムスタンプフィールドに基づきます)。この設定は、詳細なアプリの読み込みに必要なRAMに影響し、完全なデータモデルに読み込まれるデータの量を減らします。

集計ダッシュボードはこの設定の影響を受けません。

ウォッチリストのタブ

外部ウォッチリスト(ウォッチリストタブで管理)はメンテナンスプロセスによって削除されません。ただし、前述の通り、ケース内に作成された内部ウォッチリストは、ケースが削除されると(メンテナンスまたはユーザーによって)削除されます。

注意

この機能はハブには適用されません。これは、サイトおよびスタンドアローンデプロイメントにのみ関連します。

メンテナンスの除外

以下のアイテムはメンテナンス中は削除されません。

  • カメラの背景画像フォルダー – テスト接続を使用する場合、カメラからの画像はそのフォルダーの下に保存されます。このフォルダーにはCamera Background Images、以下の情報が含まれます。各カメラは1つの画像を保持し、接続が再テストされるたびに更新されます。このフォルダーとその内容はメンテナンスの影響を受けません。

  • ブックマーク - RESPONDまたはREVIEWモジュールで作成されたブックマークは、元のアラートまたはオブジェクトが削除されてもシステムに残ります。ユーザーが明示的に削除した場合にのみ削除されます。

  • Do not delete during maintenance - REVIEWモジュールでは、ケースを編集し、Do not delete during maintenance(メンテナンス中に削除しない) チェックボックスを選択できます。これらのケースとそれに関連するアーティファクトは、メンテナンスサイクルを通じて持続します。

  • QVDファイル(RESEARCHモジュール)- QVDファイルはメンテナンスプロセスの一部ではなく、必要に応じて手動で削除する必要があります。

メンテナンス監視

メンテナンスを監視および追跡できます。

メンテナンスは、次のような別のサービスによって実行されます。 メンテナンスサービスと独自のログがあります。Event(イベント)画面で、サービスが実行中であるかどうかを確認できます。

Events Maintenance service.png

メンテナンスに失敗した場合、メンテナンスイベントのしきい値に達すると、メンテナンスイベントがEvents(上記)画面に表示されます。デフォルトでは、メンテナンスの実行が少なくとも1回失敗した場合はWarning(警告)イベントが表示され、直近3回失敗した場合はCritical(重大)イベントが表示されます。

Events Threshold maintenance.png

PostgreSQL手動メンテナンス

PostgreSQLデータベースでは、パフォーマンスの問題やテーブルの肥大化を防ぐために手動メンテナンスが不可欠です。VACUUM FULLおよびREINDEX操作を定期的に実行することで、データベースのパフォーマンスと安定性を維持できます。データベースの可用性への影響を回避するには、これらのタスクを、使用率が低い期間または計画されたメンテナンス期間中(理想的には数か月または半年ごと)にスケジュールします。これにより、スムーズで効率的なデータベース操作が保証されます。

最大200GBのPostgreSQL_Dataフォルダサイズのデータベースの場合、6か月に1回、最大6時間のメンテナンスウィンドウが必要です。アクティビティの多いシステムでは、それに応じてメンテナンスの時間枠と間隔が長くなります。