Data Collector はコード解析/テスト ツールからのレポートを受け取るコンポーネントです。Data Collector のストレージとアップロード制限の閾値は、組織の要件に合わせてユーザーが設定できます。
このセクションの内容:
Data Collector がアナライザーからファイルを受信して処理する際、処理されたレポート ファイルは <DTP_DATA_DIR>/data/_DEFAULT_/dc/stored フォルダーに置かれます。このフォルダーには、YEAR/MONTH/DAY/XXX/YYY という書式のサブフォルダーがあります 。XXX と YYY は整数です。この値はファイル名に基づいて計算されます。
保存するフォルダーの最大サイズを指定すると、古いエントリが自動的に削除されます。この設定は、ビルド詳細の保持設定ではなく、DTP に保存されている XML レポートにのみ適用されます (「Configuring Build Details Retention Settings」を参照)。
<DTP_DATA_DIR>/grs/config/ ディレクトリの DCConfig.xml ファイルを開き、次のエントリを探します。
<stored-folder> <max-size>20</max-size> <size-to-clean>5</size-to-clean> </stored-folder> |
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 ビルド分のテスト結果およびテスト カバレッジデータをデータベースに保存します (「Default Data Retention Settings 」を参照)。これらのプラクティスに関連するデータは「ビルド詳細」と呼ばれ、それぞれエクスプローラー ビューに表示するために使用されます。新しいレポートが DTP に送信された際にビルド詳細の上限を超えている場合、最も古い関連ビルドの詳細が削除されます。ただし、各ビルド詳細タイプは個別に保存されるため、あるビルド詳細タイプの制限を超えても、同じビルドの他のビルド詳細には影響しません。静的解析の詳細は常にデータベースに保存されます。保存についてユーザーが設定することはできません。
次の例では、2 ビルド分のテスト データが保存されており、[テストの傾向] ウィジェットの詳細レポートから利用できます。
プラクティスごとに、保持されるデータをビルド数で設定できます (「設定」を参照)。新しいレポートが DTP に送信されるときに Data Collector が保持するビルド詳細データを増やしたい場合、上限を引き上げます。ビルド詳細は大量のディスク容量を消費する可能性があるため、ディスク容量が問題になる場合は、上限を下げることを検討してください。DTP が意味のある情報を表示するには、少なくとも 2 ビルド分の詳細データが必要です。
リソース グループに従ってデータを表示するようにフィルターを設定している場合、単一のビルドのデータを表示したり、ビルトインのカバレッジ傾向のウィジェットを表示したりするには、リソース カバレッジ詳細も必要です。リソース グループは、1 個以上の Ant ファイル パターンによって定義されたファイルあるいはフォルダーの集合です。リソース グループによって、コードの特定部分のソフトウェア品質情報を参照できます (「プロジェクトへのリソース グループの追加を参照)。
DTP はメソッド レベルおよびリソース レベルでカバレッジを収集します。メソッド レベルのカバレッジ データは、カバレッジ エクスプローラー でカバレッジを表示するために必要です。明示的な記述がない限り、本ドキュメントでの「カバレッジ」はメソッド レベルのカバレッジを指します。 |
フィルターがリソース グループを使用しない場合は、リソース カバレッジの詳細の設定を無視できます。
プロジェクトも Data Collector のビルド詳細設定も構成されていない場合、テストとカバレッジの詳細の上限は、次の Java 引数で設定された値によって定義されます。
-Dcom.parasoft.sdm.dc.build.details.to.keep |
引数は、<DTP_INSTALL>/bin ディレクトリにある variables ファイルで指定されます。メトリクスまたはリソース カバレッジのビルド詳細の場合、上限はありません。このオプションは非推奨であり、将来のバージョンで削除される可能性があります。
保存されるデータの量は、ギガバイトなどのハード的な制限ではなく、履歴ビルドの数に基づいて決まります。デフォルトでは、DTP は以下のデータを保存します。
データの保存期間を設定するには、以下の操作を行います。
<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>--> |
設定のコメントを外し、プラクティスごとに保存するデータ量を指定します。値はビルドの数を表します。たとえば 1 を指定することは、そのプラクティスについてビルド 1 つ分のデータを保存することを意味します。
<details-retention-builds-count>
<tests>3</tests>
<coverage>4</coverage>
<resource-coverage>12</resource-coverage>
<metrics>9</metrics>
</details-retention-builds-count> |
デフォルトでは、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 から DTP に送信されるレポートには、リクエスト レスポンス メッセージが含まれる場合があります。デフォルトでは、Data Collector は 100 万 byte のメッセージ レスポンスを受け入れますが、次の Data Collector の JVM 引数を設定することで上限を指定できます。
-Dcom.parasoft.sdm.dc.traffic.max.length=<BYTES> |
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" が使用されます。同時実行を最適化する特別なニーズがない限り、デフォルトを使用することを推奨します。変更にはリスクが伴うことに注意してください。
Data Collector の処理時間の調整と最適化を試みる前に、サポートを受けることを強く推奨します。このプロセスは安全かつ簡単であり、次のことが含まれます。
適切な評価や指導を受けずにユーザー自身で Data Collector の調整と最適化を試みることは推奨しません。 |
DTP では SSL はデフォルトで有効化されています。ただし、Parasoft ツールに関係するセキュリティ関連の問題がある場合、SSL プロトコルおよび/または暗号化スイートを無効化できます。
<DTP_DATA_DIR>/conf/ ディレクトリにある DCServerConfig.xml 構成ファイルを開き、除外するプロトコルおよび/または暗号化スイートを適切な要素で指定します:
<!-- comma separated list of protocols to exclude By default, TLSv1, TLSv1.1 are excluded --> <excluded-ssl-protocols>TLSv1,TLSv1.1</excluded-ssl-protocols> <!-- comma separated list of cipher suites to exclude --> <excluded-cipher-suites></excluded-cipher-suites> |
Data Collector を再起動します。
リバース プロキシは、高可用性を実現したりネットワーク セキュリティを強化するために使用されることがあります。組織でリバース プロキシを使用している場合は、リバース プロキシ環境で動作するように Data Collector を構成できます。Data Collector 構成ファイルの構成に加えて、リバース プロキシ サーバーも構成し、リクエストを正しいポートに転送する必要があります。詳細については「リバース プロキシのサポート」を参照してください。
<DTP_DATA_DIR>/conf ディレクトリにある DCServerConfig.xml 構成ファイルを開きます。<dc-reverse-proxy-protocol> : ユーザーが接続するリバース プロキシ サーバーのプロトコル (HTTP または HTTPS)。<dc-reverse-proxy-port> : ユーザーが接続するリバース プロキシ サーバーのポート。<dc-reverse-proxy-host> : ユーザーが接続するリバース プロキシ サーバーのホスト名。<dc-reverse-proxy-path>: (オプション) リバース プロキシ サーバーが Data Collector を介して DTP にデータをアップロードするために使用できるパスを指定します。Data Collector、Report Center、およびその他の DTP アプリケーションがシングル コンテキスト パスを使用するように構成されている場合に、それらへのアクセスを提供します。パスを設定する必要があるのは、リバース プロキシがシングル コンテキスト パスをサポートするように構成されている場合だけです。パスは / で開始する必要があります。 次の例では、Parasoft レポートが https://reverse-proxy123.example.com:7777/dtp/dc に送られ、http://your-dtp-server.example.com:8082 に転送されます。
<root-config> <!-- fields that always need to be are not part of the reverse proxy setup --> <dc-server-protocol>http</dc-server-protocol> <dc-server-port>8082</dc-server-port> <!-- reverse proxy setup --> <dc-reverse-proxy-protocol>https</dc-reverse-proxy-protocol> <dc-reverse-proxy-port>7777</dc-reverse-proxy-port> <dc-reverse-proxy-host>reverse-proxy123.example.com</dc-reverse-proxy-host> <dc-reverse-proxy-path>/dtp/dc</dc-reverse-proxy-path> ... other fields ... </root-config> |
これらのフィールドを設定していない場合、レポートを Data Collector にアップロードするときに Parasoft ツール (Jtest など) が失敗します。
また、大きなリクエスト ペイロードを処理するようにリバース プロキシを構成する必要もあります。その理由は、サイズがメガバイトのレポートを Parasoft ツールが生成することがあるからです。詳細については、リバース プロキシ サーバーのドキュメントを参照してください。