Reliability Risks Policies

Configure reliability violations using policies

Komodor offers default configurations for violations, based on market benchmarks and best practices.

However, some issues might be more (or less) crucial than others, depending on application types and organization protocols.

For that, Komodor allows customizing policies & configuring violations thresholds based on specific preferences:

• A default policy is provided
  • Thresholds are configurable
  • Option to enable or disable violation/configuration checks by default is available
• Option to add new policies:
  • To be applied on a specific scope (one or more cluster)
  • Include a policy priority (numeric, a higher number means higher priority)
  • Can include one or more checks, with configurable thresholds
  • Can exclude severities in case they are irrelevant to your organization
  • Each check configuration will override the default policy, or other policies for the same scope that have lower priority. 

NOTE: 

• The policy priority has to be a unique number.
• In case of multiple policies with different check configurations for the same scope, the higher priority policy will apply

Ignore reliability violations

As not all workloads, namespaces, or clusters are made equal, some organizations might not want to get prompted on specific violations on certain scopes. 
Komodor allows you to configure ignore rules to accommodate just that.

Under Reliability → Ignored Checks, you can create ignore rules, used to exclude checks that are not of interest to you or your organization.

If exclusions are defined, violations of the specific type will not appear on the Reliability dashboard, nor in an API call output. 

To re-include violations as part of Komodor’s reliability checks, you can delete the defined ignore rules, and the relevant violations will reappear on the platform.

NOTE: a user has to have manage:reliability permissions to manage ignore rules.