Data Collector はコード解析/テスト ツールからのレポートを受け取るコンポーネントです。Data Collector のストレージとアップロード制限の閾値は、組織の要件に合わせてユーザーが設定できます。

このセクションの内容:

Data Collector レポート ストレージ閾値の設定

Data Collector がアナライザーからファイルを受信して処理する際、処理されたレポート ファイルは <DTP_DATA_DIR>/data/_DEFAULT_/dc/stored フォルダーに置かれます。このフォルダーには、YEAR/MONTH/DAY/XXX/YYY という書式のサブフォルダーがあります 。XXX と YYY は整数です。この値はファイル名に基づいて計算されます。

保存するフォルダーの最大サイズを指定すると、古いエントリが自動的に削除されます。この設定は、ビルド詳細の保持設定ではなく、DTP に保存されている XML レポートにのみ適用されます (「ビルド詳細の保持設定」を参照)。 

1. <DTP_DATA_DIR>/grs/config/ ディレクトリの DCConfig.xml ファイルを開き、次のエントリを探します。

   <stored-folder>
   	<max-size>20</max-size>
   	<size-to-clean>5</size-to-clean>
   </stored-folder>

2. <max-size> プロパティの値 (単位: GB) を許される最大のストレージ容量に変更します。デフォルトは 50 GB です。
3. <size-to-clean> プロパティの値 (単位: GB) を最大容量に達した時に削除するデータの量に変更します。デフォルトは 5 GB です。
   
4. ファイルを保存します。

DCConfig.xml ファイルにエントリがない場合、デフォルト値が使用されます。

レポート アップロードの最大サイズの設定

デフォルトでは、Data Collector が受け取ることができる XML レポートの最大サイズは 512MB です。<DTP_INSTALL>/bin/variables ファイルで JAVA_DC_CONFIG_ARGS パラメーターを変更することにより、制限値を変更することができます。例:

JAVA_DC_CONFIG_ARGS=" -Dcom.parasoft.sdm.api.rawstorage.datacollector.uploadMaxSize=1024"

DTP リクエストとレスポンスと共にユーザー情報をログに記録するための Data Collector の設定

DTP 2022.2 以前からアップグレードする場合は、各リクエストとレスポンスと共にユーザー情報をログに記録するように Tomcat を設定できます。これは、一部のユーザーが特定の規制に準拠するために必要です。DTP 2023.1 以降の新規インストールでは、この設定は不要です。

DTP からこの情報をログに記録するように Data Collector を設定するには、<DTP_DATA_DIR>/conf/ にある DCServerConfig.xml ファイルを変更して、要素 <access-log-pattern> を挿入する必要があります。この要素はデフォルトでは存在しません例:

<access-log-pattern>%t %s %m %U %H %u %sid %{local}a:%{local}p %{remote}a:%{remote}p %{ms}T %{X-Forwarded-For}i %{User-Agent}i %{Referer}i -</access-log-pattern>

標準の Jetty リクエスト ログ フォーマット コードがサポートされています。詳細については https://www.eclipse.org/jetty/javadoc/jetty-9/org/eclipse/jetty/server/CustomRequestLog.html を参照してください。Data Collector は、セッション ID を表すためにカスタム フォーマット コード %sid を追加します。

これらのログは、<DTP_DATA_DIR>/logs/ ディレクトリにある dc_jetty_request.log ファイルにあります。

ビルド詳細の保持設定

デフォルトでは、Data Collector は 10 ビルド分のメトリクス データと 2 ビルド分のテスト結果およびテスト カバレッジデータをデータベースに保存します (「デフォルトのデータ保存期間の設定」を参照)。これらのプラクティスに関連するデータは「ビルド詳細」と呼ばれ、それぞれエクスプローラー ビューに表示するために使用されます。新しいレポートが DTP に送信された際にビルド詳細の上限を超えている場合、最も古い関連ビルドの詳細が削除されます。ただし、各ビルド詳細タイプは個別に保存されるため、あるビルド詳細タイプの制限を超えても、同じビルドの他のビルド詳細には影響しません。静的解析の詳細は常にデータベースに保存されます。保存についてユーザーが設定することはできません。

次の例では、2 ビルド分のテスト データが保存されており、[テストの傾向] ウィジェットの詳細レポートから利用できます。

プラクティスごとに、保持されるデータをビルド数で設定できます (「設定」を参照)。新しいレポートが DTP に送信されるときに Data Collector が保持するビルド詳細データを増やしたい場合、上限を引き上げます。ビルド詳細は大量のディスク容量を消費する可能性があるため、ディスク容量が問題になる場合は、上限を下げることを検討してください。DTP が意味のある情報を表示するには、少なくとも 2 ビルド分の詳細データが必要です。  

リソース カバレッジ詳細

リソース グループに従ってデータを表示するようにフィルターを設定している場合、単一のビルドのデータを表示したり、ビルトインのカバレッジ傾向のウィジェットを表示したりするには、リソース カバレッジ詳細も必要です。リソース グループは、1 個以上の Ant ファイル パターンによって定義されたファイルあるいはフォルダーの集合です。リソース グループによって、コードの特定部分のソフトウェア品質情報を参照できます (「プロジェクトへのリソース グループの追加」を参照)。

フィルターがリソース グループを使用しない場合は、リソース カバレッジの詳細の設定を無視できます。

構成の階層

1. Data Collector は、Parasoft ツールから新しい結果を受け取ったとき、最初にプロジェクトのビルド詳細ストレージ設定をチェックします (「ビルドの詳細設定」を参照)。  
2. プロジェクトのビルド詳細設定が構成されていない場合、Data Collector はグローバルなビルド詳細設定を使用します (「設定」を参照)。

3. プロジェクトも Data Collector のビルド詳細設定も構成されていない場合、テストとカバレッジの詳細の上限は、次の Java 引数で設定された値によって定義されます。

   -Dcom.parasoft.sdm.dc.build.details.to.keep

   引数は、<DTP_INSTALL>/bin ディレクトリにある variables ファイルで指定されます。メトリクスまたはリソース カバレッジのビルド詳細の場合、上限はありません。このオプションは非推奨であり、将来のバージョンで削除される可能性があります。

デフォルトのデータ保存期間の設定

保存されるデータの量は、ギガバイトなどのハード的な制限ではなく、履歴ビルドの数に基づいて決まります。デフォルトでは、DTP は以下のデータを保存します。

• 単体テスト データ: 2 つの履歴ビルド
• カバレッジ データ: 2 つの履歴ビルド
• リソース カバレッジ データ: 10 の履歴ビルド
• メトリクス データ: 10 の履歴ビルド

設定 

データの保存期間を設定するには、以下の操作を行います。

1. Data Collector サービスを停止します。「DTP サービスの停止」を参照してください。

2. <DTP_DATA_DIR>/grs/config/ にある DCConfig.xml 構成ファイルを開き、<details-retention-builds-count> 設定を探します。

   <!-- <details-retention-builds-count>
           <tests>2</tests>
           <coverage>2</coverage>
   		<resource-coverage>10</resource-coverage>
           <metrics>8</metrics>
    </details-retention-builds-count>-->

3. 設定のコメントを外し、プラクティスごとに保存するデータ量を指定します。値はビルドの数を表します。たとえば 1 を指定することは、そのプラクティスについてビルド 1 つ分のデータを保存することを意味します。 

   <details-retention-builds-count>
   	<tests>3</tests>
       <coverage>4</coverage>
   	<resource-coverage>12</resource-coverage>
       <metrics>9</metrics>
   </details-retention-builds-count>

4. ファイルを保存して Data Collector および DTP Server を再起動します。

テストの失敗の閾値の変更

デフォルトでは、Data Collector は 5000 件を超えるテストの失敗があるレポートを拒否します。以下の Data Collector JVM 引数を追加して上限を変更できます。

-Dcom.parasoft.sdm.rawstorage.failures.limit=5000

Linux の場合、<DTP_INSTALL>/bin/ にある variables ファイルで以下の文字列を変更できます。

JAVA_DC_CONFIG_ARGS=" -Dcom.parasoft.sdm.rawstorage.failures.limit=5000"

負の値を指定した場合、テストの失敗の数に関係なく Data Collector はレポートを拒否しません。

variables ファイルはアップグレード中に上書きされるため、DTP のアップグレード後に構成設定を再適用する必要があります。

SOAtest からの最大トラフィック レスポンスの構成

SOAtest から DTP に送信されるレポートには、リクエスト レスポンス メッセージが含まれる場合があります。デフォルトでは、Data Collector は 100 万 byte のメッセージ レスポンスを受け入れますが、次の Data Collector の JVM 引数を設定することで上限を指定できます。

-Dcom.parasoft.sdm.dc.traffic.max.length=<BYTES>

プロジェクトの自動作成の設定

デフォルトでは、Data Collector が DTP に存在しないプロジェクトを参照するデータを処理する場合、Data Collector が DTP にデータを送信する前に、プロジェクトが自動的に作成されます (データを送信するユーザーが DTP でプロジェクトを作成するための十分な権限を持っているものとします)。この機能を有効/無効にするには、次の操作を実行します。

1. <DTP_DATA_DIR>/grs/config/ ディレクトリにある DCConfig.xml ファイルを開き、<auto-create-projects> 要素を見つけます。

   <auto-create-projects>true</auto-create-projects>

2. プロジェクトの自動作成を有効にする場合は値を true に、無効にする場合は値を false に設定します。

<auto-create-projects> 要素が DCConfig.xml に存在しない場合は、デフォルトの動作が有効になり、要素が true に設定されているものとして扱われます。この機能を無効にしたい場合は、<auto-create-projects> 要素をファイルに追加し、false に設定してください。この機能が無効になっている場合、Data Collector は存在しないプロジェクトを参照するレポートを拒否します。

スレッド数の設定

Data Collector は、処理時間を短縮するために、複数のスレッドを使用してテスト ツールやコード解析ツールから受け取ったレポートを処理します。デフォルトでは、Data Collector は 2 つのスレッドを使用するように設定されています。 

この設定は、次に示すように、<DTP_DATA_DIR>/grs/config/ にある DCConfig.xml ファイルの <concurrency> 要素の下にあります。

<concurrency>
    <max-concurrency>2</max-concurrency>
    <max-write-conflict-retries>5</max-write-conflict-retries>
    <blocking blockers="build, coverageTag, runConfiguration"/>
</concurrency>

blockers 属性は、カンマ区切り値のリストをサポートします。

• build
• coverageTag
• runConfiguration

何も指定しない場合、デフォルトで "build, coverageTag, runConfiguration" が使用されます。同時実行を最適化する特別なニーズがない限り、デフォルトを使用することを推奨します。変更にはリスクが伴うことに注意してください。

Data Collector の処理時間の調整と最適化を試みる前に、サポートを受けることを強く推奨します。このプロセスは安全かつ簡単であり、次のことが含まれます。

• サポートが Data Collector の診断情報を収集します。そのためには、サポートが提供するクエリを実行し、データベースからデータを抽出する必要があります。機密情報は抽出されず、Data Collector が記録したタイミング情報のみが抽出されます。
• サポートは収集した情報を分析し、その評価に基づいて適切な提案を行います。