Goal Summary:

Several large customers have disabled runtime data because of performance and scalability challenges in Central. We need a way to provide a mode of operation where they can still have collection (process/network data) enabled, without impacting their stability. 

Goals and expected user outcomes:

• Goal 1: Removal of runtime (process and network) historic data if collection has been disabled
• Goal 2: Historic process/network data even for active deployments is only stored a maximum of 7 days (this requires changing the UI to reflect the same in risk>process)
• Database structure of process and network data optimized

The goal is that customers won´t need to disable collections. 

Out of scope:

• Dividing collection of process and data in 2 separate variables
• (Optional) Only a subset of process/network arguments are stored to reduce load on central with no effect on process/network baselines, process/network policy violations and listening endpoints
• (Optional) Only a subset of network arguments are stored in central **

Acceptance Criteria:

A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.

<enter general Feature acceptance here>

Success Criteria or KPIs measured:

A list of specific, measurable criteria that will be used to determine if the feature is successful. Include key performance indicators (KPIs) or other metrics., etc. Initial completion during Refinement status.

<enter success criteria and/or KPIs here>