Monitor Console Guide

 

This page provides a complete guide to using the Monitor section of the Namirasoft Infra Console. You will find a detailed explanation of how monitoring checks are configured and structured for infrastructure and application health monitoring, along with descriptions of each field used when creating and managing Monitor configurations. Use this guide to understand how Monitor configurations allow Namirasoft Infra to proactively check the health and performance of your systems.

 

What Is a Monitor?

A Monitor in Namirasoft Infra represents a configuration that defines how the platform should check the health, availability, and performance of your infrastructure components, applications, and services. Monitor configurations are proactive checks that run at scheduled intervals to verify that your systems are operating correctly.

 

Monitor configurations enable Namirasoft Infra to perform various types of health checks including HTTP endpoint monitoring, ping tests, port availability checks, database query verification, cache connectivity tests, messaging system checks, Docker container status, and Kubernetes pod health. When a monitor check fails, it can trigger alerts through the configured Topic, enabling rapid response to issues before they impact users.

 

Each Monitor configuration belongs to a specific Project and Environment, ensuring that monitoring checks remain organized according to your operational context. Monitors can be configured to run from different locations (global, server, or Kubernetes) and can check systems deployed in various environments.

 

The Challenge in Proactive System Monitoring

Modern infrastructure and applications require constant vigilance to ensure availability and performance. Without proactive monitoring, teams often discover problems only after users are affected, leading to:

 

• Reactive Incident Response: Teams respond to issues after they occur rather than preventing them

 

• Alert Fatigue: Too many irrelevant alerts or too few meaningful ones

 

• Monitoring Fragmentation: Different tools for different types of checks (HTTP, database, etc.)

 

• Configuration Complexity: Managing scheduling, retries, timeouts across multiple monitoring tools

 

• Notification Overload: Inconsistent alert delivery methods and channels

 

• Health Check Gaps: Missing critical checks for important system components

 

• Scale Challenges: Managing hundreds of monitoring checks across distributed systems

 

While individual systems may have some built-in health checks, they typically lack centralized configuration, intelligent scheduling, and integrated notification systems.

How Namirasoft Infra Solves the Problem

Namirasoft Infra addresses proactive monitoring challenges through structured Monitor configurations that provide a unified approach to health checking across all your systems.

 

Monitor configurations establish a consistent framework for defining what to check, how often to check it, what constitutes a failure, and how to respond when issues are detected. By offering multiple monitor types (HTTP, Ping, Port, Database, Cache, Messaging, Docker, Kubernetes), Namirasoft Infra accommodates diverse monitoring needs while maintaining consistent configuration and alerting patterns.

 

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.

 

By treating Monitors as first-class configuration entities, Namirasoft Infra enables teams to maintain comprehensive health checking, reduce incident response times, and ensure system reliability through proactive monitoring.

 

Overview of Monitor Fields and Options

Below is a detailed explanation of the fields available when creating or managing a Monitor configuration. Understanding these fields helps ensure your monitoring checks are properly configured for reliable health monitoring.

 

• ID (string): This is a unique identifier automatically assigned to the Monitor configuration when it is created.

 

• User ID (Namirasoft Account’s ID): This is the unique identifier assigned to the Namirasoft Account user who owns the Monitor configuration. It is used internally to track who created and has access to this monitoring setup.

 

• Workspace ID (Namirasoft Workspace’s ID): This refers to a workspace created in the Namirasoft Workspace app, which identifies the workspace where the Monitor configuration is created.

 

• Name (String): This is a human-readable label used to identify the Monitor configuration. The name helps teams distinguish between multiple monitoring checks and should clearly indicate what is being monitored.

 

• Project (Enum): This field specifies which Project the Monitor configuration belongs to. A Project is a logical container that groups related infrastructure components together.

 

You must create a Project before creating a Monitor 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 which Environment the Monitor operates within. An Environment represents a stage in your development lifecycle.

 

You must create an Environment before creating a Monitor 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.

 

• Topic (String): This field selects the Topic that will receive messages from this monitor. 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.

 

• Upside Down (Checkbox): When checked, this inverts the normal logic of the monitor. Normally, a successful check (like an HTTP 200 response or an open port) means the system is healthy. When Upside Down is enabled, a successful check is treated as a failure, and a failure (like an HTTP error or a closed port) is treated as a success.

Use this option when you are monitoring for the presence of an error condition. For example, if you have a special endpoint that returns an error message when something is wrong, you would enable Up Side Down so that receiving that error (a successful response) triggers an alert.

 

• Caller Type (Enum): This field determines where the monitor check will be executed from. It defines the location or agent that will perform the health check on your target system. Choose the option that matches how you want to connect to the system being monitored:

 

• • Global: The check runs from Namirasoft’s global monitoring network. Use this for public-facing services (like a website or API) that are accessible from the internet.

 

• • By Server: The check runs from a specific Server you have configured in Namirasoft Infra. Use this for internal systems that are only reachable from within your private network, or when you need to use a specific server as a jump host.

 

• • By Kubernetes: The check runs from within a specific Kubernetes cluster you have configured. Use this for services running inside a Kubernetes environment that are accessed via internal cluster networking.

 

• Description (String): This field allows you to document the purpose, content, or special characteristics of the Monitor. It helps teams understand what is being monitored and their significance.

 

• Heartbeat Interval Scheduler (String): This field selects the schedule that determines how often the monitor runs its check. The schedule defines the exact frequency (e.g., every 30 seconds, every 5 minutes) at which Namirasoft Infra will test the health of your system.

 

You must create a schedule in Namirasoft Scheduler before selecting it here. If you haven’t created a schedule yet, click the “+” icon next to this field. This will open Namirasoft Scheduler where you can set up a new schedule with your desired interval.

 

• Retries (Integer): This field specifies how many additional times the monitor should attempt its check if the first attempt fails. For example, setting this to 2 means the monitor will try up to two more times after an initial failure before declaring the system unhealthy. This helps prevent false alerts caused by temporary network glitches or brief service hiccups.

 

• Heartbeat Retry Interval (Integer): This field sets how long the monitor should wait between each retry attempt when a check fails. The number you enter here works together with the Unit field to define the waiting period (e.g., wait 30 seconds between retries).

 

• Heartbeat Retry Interval Unit (Enum): This field sets the time unit for the retry interval. Select Seconds, Minutes, or Hours to define how long the monitor pauses between retry attempts.

 

• Request Timeout (Integer): This field defines the maximum amount of time the monitor will wait for a response from the system it is checking. If the system does not respond within this time, the check is considered failed. This prevents the monitor from hanging indefinitely. The number works with the Unit field to define the timeout duration.

 

• Request Timeout Unit (Enum): This field sets the time unit for the request timeout. Select Seconds, Minutes, or Hours to define how long the monitor waits for a response.

 

• Health Check Retention (Integer): This field determines how long the results of past monitor checks are kept in the system for review and analysis. The number you enter here works with the Unit field to define the storage period (e.g., keep results for 90 days).

 

• Health Check Retention Unit (Enum): This field sets the time unit for the retention period. Select Days, Months, or Years to define how long historical check data is stored.

 

• Monitor Type (Enum): This field selects the type of health check the monitor will perform. It determines what kind of test Namirasoft Infra will run to verify the status and performance of your system. Each type has specific configuration fields tailored to check different aspects of your infrastructure, from simple network connectivity to complex application logic.

 

Choose the monitor type that matches the component you want to check. The configuration fields below will change based on your selection.

 

• • HTTP: An HTTP Monitor is a type of health check that tests web-based services like websites, APIs, or microservices, by sending an HTTP request and analyzing the response. It doesn’t just check if a server is reachable; it verifies that your web application or service is running correctly and behaving as expected

 

What does it check? It checks if your website, API, or web application returns the expected HTTP status code (like 200 OK), responds within a required time, and returns the correct content or data structure.

 

What’s the difference? Unlike a Ping Monitor (which only tests if a server is on the network) or a Port Monitor (which only tests if a specific port is open), an HTTP Monitor tests the actual application logic. It can tell you if your login page is loading, if your API health endpoint returns {"status": "up"}, or if your checkout process is broken by a server error.

 

Use this monitor type when your goal is to:

 

1. 1. 1. Ensure a website or web application loads successfully for users.

      2. Verify that a critical API endpoint is up and returning valid data.

      3. Monitor a specific feature or page within a larger application.

      4. Confirm that a health-check URL for a microservice reports a healthy status.

      5. Check that a third-party service you depend on is responding as expected.

 

• • • HTTP URL: This field defines the full web endpoint that Namirasoft Infra sends the monitoring request to. The URL must include the protocol (http:// or https://), domain or IP address, and endpoint path.

 

You can obtain the HTTP URL from:

1: Application or API documentation

2: Developer or DevOps teams managing the service

3: API gateway dashboards (e.g., AWS API Gateway, Azure API Management, GCP APIGateway)

4: Browser developer tools when accessing the application

5: Backend service configuration files

 

Use:

Public service URLs to monitor external availability

Internal service URLs to verify infrastructure health

Health-check endpoints (recommended), such as:

 

Health endpoints are preferred because they are designed to respond quickly and safely without affecting production workloads.

 

• • • HTTP Method: This field specifies the request method Namirasoft Infra uses when sending monitoring requests to the target service. The correct method is typically defined in API documentation or integration specifications.

 

• • • • GET: This method retrieves information from the service without modifying server-side data and is generally the safest and most commonly used method for availability monitoring and health endpoint validation.

 

• • • • POST: Sends data to the service and is typically used for authentication validation, workflow simulation, or service functionality verification that requires request payloads.

 

• • • • PUT: Updates or replaces existing resources and is usually used only when monitoring requires validation of update workflows or configuration changes.

 

• • • • DELETE: Removes resources from the service and is rarely used for monitoring because it may modify production data. This method should only be used in controlled testing environments or where lifecycle operation validation is required.

 

If the required method is not specified in service documentation, GET should normally be used as the default monitoring method.

 

• • • HTTP Body Encoding: This field defines the format used to encode the request body when the selected HTTP method requires payload data. The correct encoding format is typically specified in API documentation or OpenAPI/Swagger specifications.

 

• • • • JSON: This format uses structured JavaScript Object Notation and is the most widely used format for modern REST APIs and cloud-native services.

 

• • • • XML: This format uses Extensible Markup Language and is commonly used in legacy enterprise applications or SOAP-based services.

 

• • • • X_WWW_FormUrlEncoded: Encodes request payloads as key-value pairs and is frequently used for web form submissions, authentication workflows, and certain legacy web applications.

 

Users can identify the correct encoding method by reviewing API request examples, integration documentation, or inspecting requests through developer tools or API testing platforms.

 

• • • HTTP Header: This field allows users to define additional metadata sent with the HTTP request. Headers are often required for authentication, content type declaration, version control, or API authorization.

 

Header values are typically provided in API documentation, security guidelines, developer instructions, or API gateway configuration panels. Users can also identify required headers by inspecting successful requests using browser developer tools or API testing tools.

Common headers include authorization tokens, content-type declarations that must match the selected body encoding format, and API keys required for service authentication. Organizations should ensure sensitive authentication credentials are securely stored and periodically rotated according to security policies.

 

• • • HTTP Body: This field defines the payload data sent with HTTP methods that require request content, such as POST or PUT operations. The body content must follow the selected encoding format and match request examples provided in service or API documentation.

 

Users can obtain valid body structures from OpenAPI or Swagger specifications, Postman collections, or integration guides provided by service developers. Monitoring requests should use lightweight validation payloads and avoid sending commands that modify production data or trigger irreversible operations.

 

• • • HTTP Ignore SSL / TLS: This field determines whether Namirasoft Infra should ignore SSL or TLS certificate validation when connecting to HTTPS endpoints. The value typically accepts true or false.

 

When enabled, Namirasoft Infra continues monitoring even if the certificate is self-signed, expired, or issued by an untrusted certificate authority. This is commonly used when monitoring internal services or development environments.

 

In production environments, ignoring SSL or TLS validation is generally discouraged because it reduces connection security and may hide certificate-related failures.

 

• • Ping: When Ping is selected as the Monitor Type, Namirasoft Infra performs network connectivity checks by sending ICMP echo requests to a target system. These checks confirm whether a host is reachable over the network and help detect infrastructure availability issues such as server downtime, routing failures, or network latency problems.

 

Ping monitoring is commonly used as a foundational availability check because it verifies whether a system is online and responding at the network level before performing more advanced service or application checks.

 

• • • Ping Host: This field defines the hostname or IP address of the system that Namirasoft Infra will send ping requests to. The value identifies the target system whose network availability is being verified.

 

Users typically obtain the host value from infrastructure configuration records, server deployment information, DNS configuration, or cloud provider dashboards. The host may be a public address for internet-accessible services or a private network address for internal systems.

 

• • • Ping Max Packets: This field defines the maximum number of ping request packets Namirasoft Infra will send during each monitoring cycle. The number determines how many connectivity attempts are performed before evaluating the system’s availability.

 

Sending multiple packets improves monitoring accuracy by reducing false negatives caused by temporary packet loss or network instability. A higher packet count provides more reliable availability measurements but slightly increases monitoring traffic.

 

Users should determine the appropriate packet count based on network reliability requirements and infrastructure sensitivity. Stable production environments often use multiple packets to confirm connectivity consistency, while development or test environments may use fewer packets to reduce monitoring overhead.

 

• • • Ping Packet Size: This field defines the size, in bytes, of each ping packet sent during monitoring. Packet size determines how much data is included in each connectivity request and can influence latency measurement and network path validation.

 

Smaller packet sizes provide basic connectivity checks with minimal network overhead, while larger packet sizes help detect fragmentation issues, network congestion, or bandwidth-related limitations. Packet size configuration is especially useful when monitoring systems that rely on consistent network performance.

 

Users should select a packet size that reflects their monitoring objectives and network architecture. Default packet sizes are typically sufficient for standard availability monitoring, while performance-sensitive environments may require custom sizing.

 

• • Port: When Port is selected as the Monitor Type, Namirasoft Infra verifies whether a specific network port on a target system is open and accepting connections. This type of monitoring confirms that a service is reachable and actively listening on its assigned port, which is essential for validating application availability, database connectivity, and service endpoint accessibility.

 

Port monitoring operates at the network service level. Unlike Ping monitoring, which checks if a system is reachable, Port monitoring verifies that a particular service running on the system is operational and accessible through its designated communication port.

 

• • • Host: This field defines the hostname or IP address of the system that Namirasoft Infra will attempt to connect to when performing the port availability check. The value identifies the target system hosting the service you want to monitor.

 

Users typically obtain the host value from server deployment documentation, DNS configuration, service configuration files, or cloud infrastructure dashboards. The host can represent a public service endpoint or an internal system within a private network.

 

• • • Port: This field defines the network port number that Namirasoft Infra will test for availability. The port identifies the specific service endpoint running on the target host. If the port is open and accepting connections, the monitor considers the service reachable. If the port is closed, blocked, or not responding, the monitor will mark the check as failed.

 

Users typically obtain the port number from application configuration settings, database connection details, service deployment documentation, or network architecture specifications. Many services operate on standard default ports, while others may use custom ports configured during deployment.

 

Common examples include:

• • • • 80 for HTTP web services
      • 443 for HTTPS secure web services
      • 22 for SSH remote server access
      • 3306 for MySQL databases
      • 5432 for PostgreSQL databases
      • 6379 for Redis cache services
      • 5672 for messaging systems such as RabbitMQ

 

Selecting the correct port ensures that monitoring accurately reflects service availability rather than general server connectivity. If you are unsure which port should be monitored, consult service deployment documentation or review the Service Connectivity Verification Guide.

 

• • Database: When Database is selected as the Monitor Type, Namirasoft Infra verifies database availability and operational health by establishing a connection using stored credentials and executing a validation query. This monitoring type confirms not only that the database service is reachable but also that it is functioning correctly and able to process queries.

 

Database monitoring provides deeper verification than network-level checks because it validates authentication, query execution, and database responsiveness. This helps detect issues such as authentication failures, database service downtime, connection pool exhaustion, or internal database performance problems.

 

• • • Database Credential: This field allows you to select an existing database credential configured in Namirasoft Infra. These credentials are used to securely connect to your database and execute monitoring queries.

 

If you have not created a database credential yet, visit Database section in Namirasoft Infra where you can create and configure a new database connection. Once the credential is created, you can return and select it from this list. For more information, please visit Database Console Guide.

 

• • • Database Query: This field specifies the query that will be executed on the selected database to verify connectivity and performance.

 

Users can obtain this query from their database administrator, application documentation, or by creating a simple test query that safely checks database availability. The query must be valid for the selected database type and should always return a predictable result suitable for monitoring.

 

• • Cache: The Cache monitor type is used to track the availability and performance of caching services such as in-memory data stores. It helps ensure that cached data can be accessed quickly and that the cache service is operating correctly.

 

This monitor requires selecting a cache credential that allows Namirasoft Infra to connect to the cache service and check its status.

 

• • • Cache Credential: This field allows users to select the credential used to access and monitor the selected cache service. The credential contains the connection and authentication details required for Namirasoft Infra to communicate with the cache instance and check its availability and performance.

 

If no credential has been created yet, users must click the + icon to create a new one. For detailed instructions about creating and managing cache credentials, refer to Cache Console Guide.

 

• • Messaging: The Messaging monitor type is used to monitor messaging and queue-based services that enable communication between systems and applications. It helps verify that messages can be sent, received, and processed without interruption.

 

This monitor requires selecting a messaging credential that allows Namirasoft Infra to connect to the messaging service and verify its operation.

 

• • • Messaging Credential: This field allows users to select the credential used to access and monitor the selected messaging service. The credential includes the connection and authentication details required for Namirasoft Infra to interact with the messaging service and monitor its status.

 

If users have not created a credential before, they must click the + icon to navigate to the credential creation page. For more information about credential setup and requirements, refer to Messaging Console Guide.

 

• • Docker Container: The Docker Container monitor type is used to track the status and health of a specific Docker container. It helps ensure that the container is running properly and remains accessible within your infrastructure.

 

This monitor requires connection details that allow Namirasoft Infra to communicate with the Docker service and identify the target container.

 

• • • Docker Container Connection Type: This field defines how Namirasoft Infra connects to the Docker daemon running on your server. Users must select the connection method based on how Docker is configured and exposed.

 

• • • • Socket: Common headers include authorization tokens, content-type declarations that must match the selected body encoding format, and API keys required for service authentication. Organizations should ensure sensitive authentication credentials are securely stored and periodically rotated according to security policies.

 

• • • • TCP HTTP: TCP HTTP connects to the Docker daemon through a network endpoint using an IP address and port. This option is typically used when Docker is hosted on a remote server or when remote monitoring is required. Users must ensure that Docker is configured to allow TCP connections and that the necessary network and security settings permit access.

 

• • • Docker Container Daemon: This field specifies the Docker daemon endpoint that Namirasoft Infra connects to in order to monitor containers. The value typically includes the socket path for local connections or the server address and port for TCP connections.

 

Users can obtain this information from Docker configuration files, Docker service settings, or the server configuration where Docker is installed. If unsure, users should consult their infrastructure administrator or server setup documentation.

 

• • • Docker Container ID or Name: This field specifies the container that should be monitored. Users can enter either the container ID or the container name assigned when the container was created.

 

This information can usually be obtained by listing running containers using Docker management tools or container dashboards.

 

• • Kubernetes Pod Monitor Type: The Kubernetes Pod monitor type is used to track the health, availability, and performance of specific pods running inside a Kubernetes cluster. This monitor ensures that your pods remain operational and meet expected performance criteria.

 

• • • Kubernetes Pod Controller Type:  This field defines the type of controller that manages the pod you want to monitor. Users must select the correct controller type based on how the pod was deployed.

 

• • • • DaemonSet: DaemonSets ensure that a copy of a pod runs on all (or selected) nodes in a cluster. Use this type when monitoring pods that must be present on every node, such as logging or monitoring agents.

 

• • • • Deployment: Deployments manage stateless pods and provide scaling, rolling updates, and self-healing for these pods. Use this type when monitoring application pods that are stateless and can be scaled horizontally.

 

• • • • StatefulSet: StatefulSets manage stateful pods with stable identities and persistent storage. Use this type when monitoring pods that require stable network IDs or persistent data, such as databases or caching systems.

 

• • • Kubernetes Pod Controller Name: This field specifies the name of the controller that manages the pod. Users should enter the exact controller name used when the controller was created in the Kubernetes cluster.

 

This information can be obtained from your Kubernetes cluster using commands like kubectl get deployments, kubectl get daemonsets, or kubectl get statefulsets.

 

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

 

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