Messaging Console Guide

This page provides a complete guide to using the Messaging section of the Namirasoft Infra Console. You will find a detailed explanation of how messaging systems are connected and structured for infrastructure monitoring, along with descriptions of each field used when creating and managing Messaging configurations. Use this guide to understand how Messaging connections allow Namirasoft Infra to collect operational data from message brokers and queues to ensure reliable communication between services.

What Is a Messaging?

A Messaging in Namirasoft Infra represents a connection configuration that allows the platform to access and structure operational data from messaging systems. Messaging systems enable asynchronous communication between distributed applications through message brokers, queues, and topics.

 

Messaging configurations in Namirasoft Infra define how the platform connects to, monitors, and collects performance metrics from your message brokers. These configurations enable the collection of critical operational data including queue depths, message rates, consumer connections, error rates, and latency metrics. This data is structured and delivered to Namirasoft Expert, where it supports intelligent monitoring, performance analysis, and automated remediation workflows for your messaging infrastructure.

 

Each Messaging configuration belongs to a specific Project and Environment, ensuring that messaging monitoring data remains organized according to your operational context. Messaging systems can be deployed in various environments (on dedicated servers, within Kubernetes clusters, or as managed cloud services) and Namirasoft Infra provides consistent monitoring through flexible connection methods

 

The Challenge in Managing Messaging Infrastructure

Messaging systems are critical for decoupling services and enabling reliable asynchronous communication, but they introduce complexity in monitoring and management. As distributed systems scale, maintaining messaging performance and reliability becomes increasingly challenging:

 

• Queue Management: Monitoring queue depths, backlogs, and dead-letter queues across multiple instances

 

• Consumer Performance: Tracking message processing rates and consumer connection health

 

• Message Flow Visibility: Understanding message flow patterns and identifying bottlenecks

 

• Failure Propagation: Preventing message failures from cascading through dependent services

 

• Resource Management: Balancing memory, disk, and network resources for optimal message throughput

 

• Scale Complexity: Monitoring distributed message brokers and clusters requires specialized instrumentation

 

While messaging systems provide some basic metrics, they typically lack integration with broader infrastructure monitoring and intelligent analysis for proactive problem prevention.

 

How Namirasoft Infra Solves the Problem

Namirasoft Infra addresses messaging monitoring challenges through structured Messaging configurations that provide comprehensive visibility into messaging system performance and health.

 

Messaging configurations establish a standardized approach to connecting to messaging systems regardless of their deployment environment. By offering multiple connection types (direct, via server, or via Kubernetes), Namirasoft Infra accommodates various deployment patterns while maintaining consistent monitoring capabilities across different message broker implementations.

 

Once configured, Namirasoft Infra automatically collects structured operational data from messaging systems, including performance metrics, queue statistics, and consumer health indicators. This data flows into Namirasoft Expert, where it can be correlated with application and infrastructure metrics to provide complete visibility into how messaging impacts overall system reliability and performance.

 

By treating Messaging as a first-class monitoring entity, Namirasoft Infra enables teams to maintain reliable message flows, detect issues before they impact services, and optimize messaging infrastructure as part of their overall operational strategy.

Difference Between Messaging and Streaming

While both Messaging and Streaming handle data movement between systems, they serve different purposes and have distinct monitoring requirements:

Messaging is about reliable communication between services, while Streaming is about continuous data processing pipelines. For more information about Streaming, visit Streaming Console Guide.

Overview of Messaging Fields and Options

Below is a detailed explanation of the fields available when creating or managing a Messaging configuration. Understanding these fields helps ensure messaging systems are properly connected and structured for monitoring and operational analysis.

• ID (string): This is a unique identifier automatically assigned to the Messaging configuration when it is created. This is used internally to track this specific Messaging connection.

• User ID (Namirasoft Account’s ID): This is the unique identifier assigned to the Namirasoft Account user who owns the Messaging configuration. It is used internally to track who created and has access to this messaging 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 Messaging configuration is created. This ensures the configuration is organized within the correct operational workspace.

• Name (String): This is a human-readable label used to identify the Messaging configuration. The name helps teams distinguish between multiple messaging instances.

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

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

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

• Log Group (Enum): A Log Group is a logical container that stores and organizes log files from your applications and systems in Namirasoft Log. For Messaging configurations, this Log Group will contain message broker logs, error logs, and performance logs.

You must select an existing Log Group for this field. If no Log Group exists, you can click the “+” icon next to this field to create a new one. For more information about Log Groups and log management, visit Namirasoft Log.

• Messaging Type (Enum): This field specifies which type of messaging system you are connecting to. Selecting the correct messaging type ensures proper integration with system-specific monitoring features and metrics collection.

• • RabbitMQ: Rabbitmq is an open-source message broker that implements the Advanced Message Queuing Protocol (AMQP). RabbitMQ provides reliable message delivery, flexible routing, and supports multiple messaging patterns including point-to-point, publish/subscribe, and request/reply.

• Connect Type (Enum): This field specifies how Namirasoft Infra will connect to the messaging system. The connection type determines what additional configuration will be required and how the monitoring agent accesses the message broker.

• • Direct: Connect directly to the messaging system using its network address (host and port). Use this option when:

• • • The messaging system is publicly accessible with a fixed IP or hostname

• • • Namirasoft Infra has direct network access to the message broker

• • • You don’t need to route through a Server or Kubernetes cluster

• • By Server: Connect to the messaging system through a Server resource. Use this option when:

• • • The messaging system is running on or accessible only through a specific server

• • • You need to use SSH tunneling or agent-based monitoring on the server

• • • The message broker isn’t directly accessible from the Namirasoft Infra network

• • • When you select “By Server,” you will need to select which Server configuration to use. The Server must have network access to the messaging system and may require additional configuration for monitoring.

• • By Kubernetes: Connect to the messaging system through a Kubernetes cluster. Use this option when:

• • • The messaging system is running as a container inside a Kubernetes cluster

• • • The message broker is managed by a Kubernetes operator or deployed via Helm

• • • You need to access the messaging system through Kubernetes service discovery

• • • When you select “By Kubernetes,” you will need to select which Kubernetes configuration to use. The Kubernetes cluster must have the messaging system running and accessible via Kubernetes services.

• Description (String): This field allows you to document the purpose, role, or special characteristics of the messaging system. It helps teams understand the messaging system’s function within your infrastructure.

• Messaging Credential ID (String): This is the unique identifier of the credential set used to connect to the Messaging system. This references securely store authentication information (username, password, certificates, etc.) without exposing the actual credentials. The system creates this automatically when you configure messaging credentials.

• Connect Server ID (String): If the Connect Type is “By Server,” this field contains the unique identifier of the Server resource used for the connection. This links the Messaging configuration to the specific Server entity.

• Connect Kubernetes ID (String): If the Connect Type is “By Kubernetes,” this field contains the unique identifier of the Kubernetes configuration used for the connection. This links the Messaging configuration to the specific Kubernetes entity.

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

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