Alert Console Guide

 

This page provides a complete guide to using the Alert section of the Namirasoft Infra Console. You will find a detailed explanation of how alerts are configured to notify teams when infrastructure, services, or metrics exceed defined thresholds. Use this guide to understand how Alerts work, how to configure them accurately, and how they integrate with monitoring workflows.

 

What Is an Alert?

An Alert in Namirasoft Infra is a condition-based notification mechanism that activates when specific operational metrics or events meet predefined criteria. Alerts enable teams to detect issues early and respond quickly, helping maintain system stability and service reliability.

 

Each Alert belongs to a specific Project and Environment, ensuring that notifications remain properly organized within their operational context. Alerts can monitor individual Servers, Kubernetes clusters, or specific metrics, and are delivered through a Topic, which distributes notifications to configured communication channels.

 

The Challenge in Proactive Alerting

Modern infrastructure environments generate large volumes of operational data, making it difficult to detect meaningful problems before they affect system performance or user experience. Without well-structured alerting, organizations commonly face several challenges:

 

  • Alert Fatigue: Excessive or irrelevant notifications cause teams to overlook critical alerts.

 

  • Inconsistent Thresholds: Different teams define alert conditions differently, creating unreliable monitoring standards.

 

  • Notification Fragmentation: Alerts are delivered through disconnected systems, making communication inefficient.

 

  • Missing Context: Alerts may lack enough operational detail to support fast diagnosis.

 

  • Delayed Response: Unclear alert ownership or escalation processes slow incident resolution.

 

  • False Positives: Frequent alerts triggered by temporary spikes reduce confidence in monitoring systems.

 

Although many monitoring tools can detect anomalies, they often lack structured alert logic, contextual insights, and integrated notification workflows required for efficient incident management.

How Namirasoft Infra Solves the Problem

Namirasoft Infra improves alerting reliability through structured Alert configurations that generate precise, actionable notifications with strong operational context.

 

Alert configurations define clear evaluation rules, including which metrics to monitor, what threshold values indicate problems, and how multiple data points should be analyzed. By integrating with the broader Namirasoft ecosystem, alerts automatically include contextual infrastructure details and can be delivered through coordinated communication channels.

 

Once configured, monitors run automatically according to their schedules, perform health checks, and report status back to Namirasoft Infra. Failed checks can trigger alerts through integrated notification systems, enabling teams to respond quickly to emerging issues before they escalate into major problems.

 

Once configured, alerts continuously evaluate incoming metric data and trigger notifications only when defined conditions are met. Notifications are routed through configured Topics to connected Subscribers, ensuring the right teams receive accurate information through their preferred communication platforms.

 

By treating Alerts as structured operational entities, Namirasoft Infra helps teams reduce monitoring noise, maintain consistent alerting standards, and accelerate incident response through reliable and well-organized notifications.

 

Overview of Alert Fields and Options

Below is a detailed explanation of the fields available when creating or managing an Alert configuration. Understanding these fields helps ensure alerts are accurate, actionable, and aligned with operational monitoring requirements.

 

  • ID (string): This is a system-generated unique identifier assigned when the Alert configuration is created. This value cannot be modified.

 

  • User ID (Namirasoft Account’s ID): This is the unique identifier assigned to the Namirasoft Account user who created or owns the Alert configuration. This field is used internally for access control, auditing, and activity tracking.

 

  • Workspace ID (Namirasoft Workspace’s ID): This refers to a workspace created in the Namirasoft Workspace app where the Alert configuration exists. Workspaces organize infrastructure resources and monitoring configurations across teams and operational groups.

 

  • Name (String): This is a human-readable label used to identify the Alert configuration. The name should clearly describe the monitored condition to help teams quickly recognize the alert’s purpose.

 

  • Project (Enum): This field specifies the Project that the Alert configuration belongs to. Projects serve as logical containers that group related infrastructure components and monitoring configurations.

 

You must create a Project before creating an Alert configuration. If no Project exists, you can click the “+” icon next to this field, which redirects you to the Project configuration page. For more information about Projects, visit the Project Console Guide.

 

  • Environment (Enum): This field specifies the Environment where the Alert operates. Environments represent operational stages such as development, staging, or production.

 

You must create an Environment before creating an Alert configuration. If no Environment exists, you can click the “+” icon next to this field, which redirects you to the Environment configuration page. For more information about Environments, visit the Environment Console Guide.

 

  • Server (String): This field specifies which Server this alert should monitor. You can select one server from the list. If you don’t select any server, the alert will not be activated for any server.

 

You must configure Servers before selecting them here. If no Server exists, click the “+” icon next to this field to create one. For additional guidance, visit Server Console Guide.

 

  • Kubernetes (String): This field specifies which Kubernetes cluster this alert should monitor. You can select one Kubernetes configuration from the list. If you don’t select any Kubernetes configuration, the alert will not be activated for any Kubernetes cluster.

 

This field is optional. If no Kubernetes configuration exists, you can click the “+” icon next to this field to create a new one. For more information about Kubernetes, visit the Kubernetes Console Guide.

 

  • Topic (String): This field selects the Topic that will receive messages from this alert. A Topic is an entity in Namirasoft Notification Sender that collects messages from applications and forwards them to connected Subscribers, which then deliver messages through configured channels like email, SMS, Slack, Microsoft Teams, or Telegram.

 

You must create a Topic in Namirasoft Notification Sender console before selecting it here. If you haven’t created one, click the “+” icon to open Namirasoft Notification Sender and set up a new Topic. For more information, visit the Namirasoft Notification Sender website.

 

  • Description (String): This field allows you to document the purpose, scope, or special characteristics of the alert. It helps teams understand what condition triggers the alert and how to respond when it fires.

 

  • Metric Name (String): This field specifies the exact name of the metric that this alert will monitor. The metric name must match exactly how it appears in your monitoring data.

 

  • Trigger Sample Size (Integer): This field specifies how many consecutive metric samples must violate the threshold before the alert triggers. This helps prevent false alerts from temporary spikes by requiring sustained violation of the threshold. See Alert Configuration Examples for usage examples.

 

  • Trigger Aggregator (Enum): This field defines how multiple metric samples are combined into a single value before the alert condition is evaluated. Because infrastructure metrics often fluctuate, alerts typically analyze a group of recent metric values instead of relying on a single measurement.

 

The Trigger Aggregator determines which calculation method is applied to the collected samples. See Alert Configuration Examples for usage examples.

 

    • min: Uses the lowest value among the collected samples. This is useful when monitoring metrics where a drop below a safe level indicates a problem, such as available disk space or service availability percentage.

 

    • max: Uses the highest value among the collected samples. This is commonly used when monitoring resource usage metrics like CPU or memory, where spikes above safe limits indicate potential issues.

 

    • average: Uses the mean value across all collected samples. This is helpful when short spikes are acceptable but sustained high usage should trigger alerts.

 

    • sum: Uses the total value of all collected samples. This is useful when monitoring cumulative metrics such as total request count, total error count, or total data throughput over a period.

 

Selecting the correct aggregator ensures that alerts reflect meaningful operational behavior rather than temporary fluctuations.

 

  • Trigger Operator (Enum): This field defines how the aggregated metric value is compared against the Threshold value to determine whether an alert should be triggered.

 

The Trigger Operator represents the logical comparison rule used during alert evaluation. See Alert Configuration Examples for usage examples.

 

    • equal: Triggers when the metric value exactly matches the threshold.

 

    • not equal: Triggers when the metric value differs from the threshold.

 

    • less than: Triggers when the metric value falls below the threshold.

 

    • more than: Triggers when the metric value exceeds the threshold.

 

    • less than or equal: Triggers when the metric value is below or equal to the threshold.

 

    • more than or equal: Triggers when the metric value is above or equal to the threshold.

 

The operator defines the direction and condition of the alert logic.

 

  • Threshold (Integer): This field defines the numerical limit that the monitored metric is compared against. The Threshold represents the boundary between normal system behavior and a potential problem.

 

When the aggregated metric value satisfies the comparison defined by the Trigger Operator, and this condition persists for the configured Trigger Sample Size, the alert is triggered. See Alert Configuration Examples for usage examples.

 

  • Created At (DateTime): This shows the date and time when the Alert configuration was created. This value is automatically generated and cannot be modified.

 

  • Updated At (DateTime): This shows the date and time when the Alert configuration was last updated. The value changes automatically whenever configuration details are modified or when significant changes to the Alert occur.

 


Alert Configuration Examples:

To help you better understand how alert conditions are evaluated, the examples below demonstrate real-world alert configurations using common infrastructure monitoring scenarios.

 

  • Example 1 (Detecting Sustained High CPU Usage)

 

Scenario: You want to receive an alert when a server’s CPU usage remains high for a continuous period, rather than triggering alerts for short temporary spikes.

 

Configuration

 

    • Metric Name: cpu_usage_percent

    • Trigger Sample Size: 5

    • Trigger Aggregator: average

    • Trigger Operator: more than

    • Threshold: 80

 

How Namirasoft Infra Evaluates This Alert: Namirasoft Infra collects the latest 5 CPU usage measurements. Example collected samples:

 

Sample 175%
Sample 282%
Sample 385%
Sample 488%
Sample 584%

 

Step 1 (Apply Aggregator): The system calculates the average of the samples:

 

(75 + 82 + 85 + 88 + 84) ÷ 5 = 82.8%

 

Step 2 (Apply Operator and Threshold): Namirasoft Infra evaluates the condition:

 

82.8 is more than 80TRUE

 

Result: The alert is triggered because the CPU usage remained above the safe threshold across multiple measurements.

 

 

  • Example 2 (Detecting Critical Disk Space Drops)

 

Scenario: You want to be alerted immediately if disk space becomes critically low, even if it happens briefly.

 

Configuration

 

    • Metric Name: disk_free_gb

    • Trigger Sample Size: 3

    • Trigger Aggregator: min

    • Trigger Operator: less than

    • Threshold: 10

 

How Namirasoft Infra Evaluates This Alert: Namirasoft Infra collects the latest 3 disk space measurements. Example collected samples:

 

Sample 1 → 14 GB
Sample 2 → 9 GB
Sample 3 → 12 GB

 

Step 1 (Apply Aggregator): The system selects the lowest value among the samples.

 

Minimum value = 9 GB

 

Step 2 (Apply Operator and Threshold): Namirasoft Infra evaluates the condition:

 

9 is less than 10 → TRUE

 

Result: The alert is triggered because disk space dropped below the safe threshold during one of the monitoring samples.



Keep Your Infrastructure Running Smoothly and Reliably