Deep Dive: BVQ° Alerting

Most IT teams are familiar with the dilemma: Either alerts trigger too weakly, making it hard to detect looming issues in time or they overreact – flooding inboxes with false alarms. BVQ° takes a different approach, focusing from the outset on highly tailored alert rules. Right from the first launch, you’ll find a wide range of preconfigured alert rules that you can clone and refine as needed. This allows you to gradually build a highly customized alerting system that noticeably eases your day-to-day IT operations.
 

Why out-of-the-box alerts alone aren’t enough

BVQ° comes with over 700 predefined alert rules that cover common data center scenarios: high CPU or memory usage, unusual network performance, best practice violations and more. This gives you a quick start – but every IT infrastructure is unique. Some applications run smoothly at 80% CPU usage, while others become critical at just 60%. That’s why it’s essential to adapt the provided rules:

• Clone instead of reinventing: Use the cloning feature to duplicate an existing rule in seconds. Then tweak filters or thresholds to create a new rule that fits your exact needs.
• Fine-tuning: Whether you extend intervals, adjust thresholds, or narrow down target objects – the more precisely you configure, the more accurately your alerting responds.

Result: A warning infrastructure tailored to your environment in no time – without the need to build everything from scratch.
 

Fine-grained control through filters

In large environments, not every server is equally important. Often, specific clusters, volumes or SAN ports require distinct thresholds. BVQ° provides filters for this purpose:

• Tags or names: Restrict alerts to objects with names like “PROD_” or “DEV_” – depending on their importance.
• Logical operators: Combine throughput and latency values (“alert if both are abnormal”) instead of relying on single threshold checks.
• Regex or topology filters: Especially useful in heterogeneous environments, allowing you to isolate specific areas using regular expressions or complex topology selections.

This separation between general and fine-grained criteria helps avoid irrelevant alerts in your specific context.
 

Occurrence counter: meaningful alerts instead of alert floods

Few things are more exhausting than constant false alarms due to brief usage spikes. That’s why BVQ° offers the Occurrence counter concept – a powerful tool to filter out short-term anomalies. You can define:

• Consecutive violations: Should the value be exceeded multiple times in a row before a real alert is triggered?
• Violations per time window: Should an alert only be triggered after a certain number of violations within a time frame?
• SLA-fixed-window: Do you want to use entire days or weeks as a basis for detecting service level violations?

This ensures no premature false alarms – BVQ° only alerts when thresholds are repeatedly breached.
 

Time-based alerting: no panic during maintenance

Backups or batch jobs often run at night, temporarily stressing certain systems. If strict latency thresholds triggered alerts during these times, you’d receive constant email floods – even though everything is running as planned. That’s where BVQ°’s time windows come in:

• Cron expressions: Define that a specific alert is only active on weekdays between 9 AM and 5 PM – or exclude holidays, etc.
• Exclusion times: During your backup intervals, latency alerts remain silent because the activity is fully intentional.

This helps clean up the alert stream in advance and saves you tedious post-processing in ITSM systems.
 

Example workflow with BVQ°

Imagine you have a generic “Volume Latency Check” that triggers an alert at 5 ms. To make it useful in your production environment, you could take the following steps:

1. Clone: Duplicate the existing rule.
2. Add filters: Restrict the rule to volumes tagged with PROD.
3. Adjust thresholds: Set Error to 3 ms and Warning to 2 ms – but activate the Occurrence Counter so that at least three consecutive measurements above 3 ms are required before an error alert is triggered.
4. Time control: Use a cron entry to ensure alerts are active Monday–Friday from 8 AM to 6 PM and silent at night and on weekends.

After a quick validation check in the BVQ° interface, activate the new rule. From now on, the system only warns when the issue occurs repeatedly – during core working hours.
 

Conclusion: flexible, accurate, time-saving

With BVQ° Alerting, you create tailored alert concepts for different platforms, applications and time windows. Through cloning, filters, occurrence counters and time control, you transform a generic base package into a highly professional, customized monitoring system. The result: clear, actionable alerts instead of an undifferentiated flood of warnings.
 

Curious to learn more?

If you’d like to explore features like Occurrence Counter, SLA-Fixed-Window, or time-based alerting in more detail, feel free to reach out – we’ll work with you to develop the right alerting strategies for your organization and turn your monitoring into an effective early warning system for your IT infrastructure.