DEV Community: Nadeem ahamed

Download Azure Service Bus messages using Serverless360

Nadeem ahamed — Tue, 03 Aug 2021 11:17:54 +0000

From our experience handling Azure Service Bus messages, one frequent suggestion we get from the support person is to download messages from Azure Service Bus entities like Queues and Topic Subscriptions. By downloading the messages as a local copy, it becomes easy for them to debug the messages and use it at a later point in time. Basic knowledge of Azure Service Bus messaging entities is a pre-requisite for the better understanding of this feature.

Azure Service Bus Messages

Microsoft Azure Service Bus is used for delivering information in a reliable and a much easier way. The messaging service ensures that the information is delivered even if the two parties are never both online at the same time, or if they aren’t available at the exact same time.

Messages are sent by the sender to the receiver through the Azure Service Bus. The message transferred through Azure Service Bus consists of the actual message body and the properties of that message. The message may be sent to or received from the Service Bus Queues or Topic Subscriptions.

Message Processing Challenges in Azure Portal solved in Serverless360

Azure Portal does not facilitate viewing Azure Service Bus messages. But real-time business scenario would require processing these messages for various business scenarios. Serverless360 understands the requirement and comes up with the following message processing capabilities on Azure Service Bus Queues and Topics

Send messages
Resubmit & Delete Messages
Resubmit & Delete Dead-Letter messages
Repair and Resubmit messages

The latest addition to the above capabilities is the feature to download messages. This blog focuses on the message download capability.

Business scenarios require Azure Service Bus messages to be downloaded for further processing. On demand from customers for saving messages for various purposes, Serverless360 has now got the capability to download messages as single or in bulk.

The messages will be downloaded as a zip file with text files containing the JSON object of the message. Each message will be saved in a separate text file.

Downloaded Message Content

The downloaded Message file holds the JSON content, that includes the following properties of the message:

Message Body
Sequence number
Message Id
Size
Schedule enqueued time
Enqueued time
Time to live
Content type
System properties
The custom properties

Do you have a requirement to save your Azure Service Bus Messages? Do it with Serverless360 now!

File Format

The name of the zip folder will be the name of the Queue or Topic Subscription to which the messages belong. The name of the text file will be the Message-Id of that message. The file will have all the required properties of the message along with its content, which can be utilized for further processing

Winning with Application Insights Logging

Nadeem ahamed — Thu, 29 Jul 2021 10:48:53 +0000

Introduction

This article will focus on using Azure Application Insights to monitor the real-world business apps. Azure Application Insights is an Application Performance Management (APM) service for developers and DevOps professionals. It is used to monitor an app that is live in real-time.

It supports a variety of platforms including .NET, Node.js, Java, and Python hosted on-premises, hybrid, or any public cloud. Application Insights can be used in two ways to monitor your Application. They are,

Codeless Monitoring
Code-based Monitoring

What Can Be Monitored?

Azure Application insight is ideal for developers to monitor how an application works in real-time from performance to error logs. As an APM tool, it can monitor

Request rates, response times, and failure rates
Exceptions
Pageviews and load performance
Diagnostic trace logs
Custom events and metrics and many more

User can achieve all the above-mentioned monitoring goals with the help of tools in Application insights like Application Map, Live Metrics, Dashboards, etc.,

Codeless Monitoring

In Codeless Monitoring, Users can get to monitor the Application without any modification to the code, provided the application is hosted in an Azure Service like Azure Web App or Azure Virtual Machine. These resources are natively integrated with the Application Insights that can be enabled from the Azure portal itself. Now let us see how to enable Azure Application insights for an Azure Web App

How Do You Implement Application Insights in Web API?

Go to your Azure Web App -> Application Insights
Click Turn on Application insights.

You can either choose the existing Application Insights instance or create a new one by providing the Name and Location. And Click on Apply to turn on the Application Insights for this Web-App.

The Web app will now be enabled with the Application Insights and the user can achieve monitoring goals like live monitoring and failure detection.

Code-based Monitoring

Codeless Application monitoring will be very useful if the application is hosted in Azure Resources like VMs and App Services. Whereas, if the Application is hosted in any other Cloud Service provider or hosting service, then code-based monitoring will be the go-to option. With this monitoring solution, it is possible to monitor the applications or APIs built using

ASP.NET Core
ASP.NET Framework
JAVA
Python
Node.JS runtime

With the help of Application Insights Logging, it is also possible to monitor background services and Client-side JavaScript with the help of Application Insights. Now let us take a .NET Core application and see how to integrate Application Insights.

How Do I Enable Application Insights in Azure?

Create an Azure Application Insights instance in Azure Portal. To create it, click on Create a Resource menu in the left Navigation and Type Application Insights in the Search box.

Now, Give the Name and other details like Resource Group Name, etc., Click Create
Once the Application Insights instance is created, go to Properties in the left side navigation bar to get the Instrumentation key that will be required for our Application to establish the connection.

Open your .NET Core Application and install the library “ApplicationInsights.AspNetCore” from NuGet Package.
Add AddApplicationInsightsTelemetry(); to the ConfigureServices() method in your Startup class

// This method gets invoked by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        // The following line enables Application Insights telemetry collection.
        services.AddApplicationInsightsTelemetry();

        // This code adds other services for your application.
        services.AddMvc();
    }

To establish a connection between the Application and the Azure Application Insights, we need to provide the Instrumentation key in json as an Environment variable as below

{
      "ApplicationInsights": {
        "InstrumentationKey": "< Application Insight Instrumenation – Key >"
      },
      "Logging": {
        "LogLevel": {
          "Default": "Warning"
        }
      }
    }

Now, run the Application. Go to the Application Insights instance that was created in the Azure Portal. Go to Live Metrics in the Left Navigation bar.

Live Monitoring is on, and you can infer the Application performance from the widgets on key performance indices.

With the help of Live Monitoring, it is possible to monitor a variety of Metrics like Request rate, Request Failure rate, Outgoing requests, Failed Requests, and many more.

How Do I Log Exceptions in Application Insights?

By configuring the Application as mentioned above, the user can monitor all the requests and logs sent to Azure Application insights. But when the need is to monitor only the logs which are in the Warning or Error state, it can be achieved by filtering the Log information based on Severity as mentioned below

To filter the logging data, the user must create a builder in the CreateWebHosting() method and add a filter as below code:

//Program.cs
public class Program
{
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
      WebHost.CreateDefaultBuilder(args)
        .UseStartup()
      .ConfigureLogging(
            builder =>
            {
                builder.AddApplicationInsights("ikey");        
        builder.AddFilter
                                 ("", LogLevel.Warning);
            }
        );
}

Once the filtering has been set, the user can log the necessary information from the Controller as below
//ValuesController.cs
public class ValuesController : ControllerBase
{
    private readonly ILogger _logger;

    public ValuesController(ILogger logger)
    {
        _logger = logger;
    }

    // GET api/values
    [HttpGet]
    public ActionResult> Get()
    {
        using (_logger.BeginScope(new Dictionary { { "MyKey", "MyValue" } }))
            {
                _logger.LogWarning("An example of a Warning trace..");
                _logger.LogError("An example of an Error level message");
            }
        return new string[] { "value1", "value2" };
    }
}

It is also possible to log the data from our logging services by providing the necessary information. This Azure Application Insights Logging can be useful when the need is to monitor the performance of an Application.

How Do I See Exceptions in Application Insights?

Open the Application Insights Search window in Visual Studio, and set it to display events from your app. While you’re debugging, you can do this just by clicking the Application Insights button. Notice that you can filter the report to show just exceptions.

Users can even use the application insights created in Azure Portal to view all the errors happening in their system.

How Do I View App Insight Logs?

In the Azure portal, browse to the required resource group and select the required resource like Function App, Web App, etc.,

In the monitoring section, select the logs option and all the logs captured will be displayed.

But When the Application comprises a variety of Azure Serverless Resources and the need is to monitor the whole Application along with Azure resources, Application Insights Logging cannot be the right solution for this scenario.

Here comes the Business activity monitoring in Serverless360 to perform end to end tracking on Azure Serverless Applications.

Business Activity Monitoring

Business Activity Monitoring in Serverless360 is a tool to perform end to end tracking of the Azure Serverless applications. Serverless360 BAM can be instrumented in your business application using the Exposed APIs also available as .Net SDK and Logic App Connector. Implementing Business Activity Monitoring can provide visibility on the messages flowing through the components of the business application like never before.

Business Transactions

Every Transaction of an Application will be tracked in a separate section where the status of the transactions can be viewed along with the status of each stage in a transaction.

It is also possible to view the data flowing through every stage along with the tracking of key business properties.

Analytics & Monitoring

Business Activity Monitoring in Serverless360 also offers the capability to monitor the transactions when there is a failure or exception. Users will be notified through the configured Notification channels whenever there is an exception in any of the Business transaction. Calendric view in Business process monitor helps to understand transaction monitoring history.

Consider when there is a need to analyse how the application is performing based on the custom property tracked. Serverless360 Dashboard helps the user to create widgets and analyze business transactions in a graphical view. User can give the input as a BAM query and get the data as advanced graphical widgets as below

Summary

Application Insights along with Logging is the best tool for live monitoring of Applications much needed for developers, whereas it is too complex for an operations or support user. Their need would be a tool like Serverless360 to monitor and track the whole Serverless Application with better monitoring and management capabilities. To know more about Serverless360 on how it is better compared with other monitoring solutions offered by Azure, Follow the Links below

End-to-end Correlation Across Logic Apps

Nadeem ahamed — Fri, 23 Jul 2021 13:02:23 +0000

In this blog post, I would like to discuss achieving end-to-end correlation across Logic Apps, a need to have a solution while dealing with an Enterprise application involving multiple Logic Apps. Let us understand the concept with the help of a real-time scenario.

The Scenario- Employee On-boarding System
Here we consider an organisation that has a well-defined Employee Onboarding process. Multiple Logic Apps are involved in building this Onboarding application. Below is the illustration of the Logic Apps engaged in the application.

The HR portal compiles the Employee details into a Service Bus message which gets processed by the back end, automated using Logic Apps. The ‘Onboard’ is the one that defines the core workflow. This Logic App, in turn, calls out to various other Logic Apps to achieve actions like Background Verification (BGV), Employee Addition to Organisation Databases (Addition), Enrolling Employee for Insurance (Insure). Based on the success of the underlying process, the ‘Onboard’ Logic App will either complete the Service Bus message or dead letter the same. The Logic App definition is as below:

What is Correlation?
Correlation is the mechanism for relating workflows to each other. For example, Background verification followed by adding that Employee detail to the Organisation database in the Onboarding workflow as above. Commonly, each of the workflow mentioned above can be a Logic App. Hence business workflow definitions would involve multiple Logic Apps. In which case, end to end correlation across these Logic Apps becomes critical.

Why Is It Needed?
When the application workflow spans multiple Logic Apps, there is a need for the end-to-end correlation to get the much-needed business visibility.

For example, in the scenario mentioned above, the message containing Employee details flows through 4 Logic Apps to complete the onboarding process. It would be essential for the business to understand if all the four stages of the process get through or not.

It is essential to understand where the message got stuck in the end-to-end execution if we simplify the requirement.

How Is Correlation Implemented in Logic Apps?
Logic App implicitly can correlate the runs using a Correlation Id. The ‘Onboard’ Logic App invokes the other 3 Logic Apps, BGV, Addition and Insure, in the scenario above. When we investigate their run histories, we can observe a unique correlation id associated with every new transaction.

Below is the details section of a specific run of the Logic App ‘Onboard’. Observe the highlighted Correlation Id in the image below.

Please Note: Above is the screenshot from Serverless360 that highlights the run details of a Logic App in a Business Application. In the Azure portal, find the same as below:

Observe the same Correlation ID in the Logic App, BGV:

The Correlation ID remains the same in the corresponding run details of the other two Logic Apps too:

This way, every Employee processing is associated with a unique Correlation ID by default.

Hence it is possible to correlate runs across multiple Logic Apps using the Correlation ID and recognise them as a complete transaction.

Auto-generated vs Custom Correlation Ids
When this Correlation ID is good to have, the autogenerated GUID is not that useful. It is hard to interpret the actual Employee that is getting onboarded. What can be helpful is, configuring the Employee ID itself as the Correlation ID. And this is possible!!!

We can custom define the Correlation ID by setting the parameter “x-ms-client-tracking-id”. In this case, I am choosing to put the Employee ID to this parameter. If the Logic App is HTTP triggered, then this value can be set in the header. In my case, it is a Service Bus Queue triggered Logic App; hence I had defined this as a user property on the Service Bus message.

Upon setting this property, I observe the correlation ID is set as the Employee ID, just as expected. PFB the screen capture that displays the correlation ID set as the Employee ID, which is more beneficial.

This correlation Id flows through the Logic Apps BGV, Addition and Insure as well:

Correlating Messages over Logic Apps
I intend to correlate all the transactions corresponding to an employee by the Employee ID. Let us first explore one solution available in the Azure portal itself.

The Logic Apps Management Solution allows you to monitor and manage your Logic Apps. This solution provides you with a summary of the overall health of your Logic Apps, with options to drill into details and troubleshoot unexpected behaviour patterns.

With rich, out of the box views, you can get insights into crucial processing, including:

• Summary of all logic app runs.
• Ability to drill into details of the logic app runs by their names or by their processing status.
• Logic app run details including their status, execution times and unique identifiers to establish correlation across Logic Apps.
• Ability to identify resubmitted runs of a logic app.

Pre-requisite: To take advantage of this solution, Logic Apps should enable Log Analytics to push diagnostics data to the OMS workspace.

With the Employee ID set as the Correlation ID, I could filter the records by Employee ID in the Tracking ID column. Below is the list of actions carried out for Employee with ID, 133595.

I am happy to attain this correlated result with the minimal configuration of custom defining the Correlation ID on the Service Bus message that kick starts the ‘Onboard’ Logic App. Indeed impressive!!!

Serverless360 BAM to Correlate Logic Apps
Logic App Management’s above result is simple to set up and does provide the much-needed correlation. However, this could be complex for the HR team to handle, and it might not be practical to share them with access to the Azure portal. Considering the HR team as the business users in this context, how can we securely provide them with the end-to-end visibility on the message flowing through this Serverless Application? How can we help them figure out what happened with onboarding a specific Employee?

There is a need for the organisation to build an end-to-end traceability/monitoring solution that business users can use in any integration solution. However, tracking is often an afterthought, and the operational support team struggles to run the implemented solution. Sometimes the delivery team will work on a solution. Still, often it is bespoke and challenging to use across projects, and teams spend about 20-30% of their time addressing this challenge, building custom solutions like logging components and web dashboards. The solution will be premature most of the time since creating enterprise-grade tracking/monitoring solutions requires enormous effort.

That is precisely the challenge we are tackling in Serverless360 with the BAM feature.

Let us see how the Employee Onboarding process can be well defined and tracked in Serverless360 BAM

Model your business processes, transactions, stages and map them to physical processing elements in integration solutions.

Define properties to track business values at run-time. Correlate the flow of data within your system. Configure reprocess to restore failures.

This implementation requires instrumentation in Azure Logic Apps, which Serverless360 facilitates with its Custom Logic App Connectors:

• Start Transaction: This stage marks the beginning of the instrumentation. In our scenario, this occurs in the ‘Onboard’ Logic App when the Service Bus message is received.

• Checkpoint with Correlation: When the subsequent stage occurs in another Logic App, use this connector to correlate using the Employee ID as below

When the subsequent stage appears in the same Logic App, use the checkpoint connector. In our case, the last stage is in the ‘Onboard’ logic App that marks the process completion can either be successful or cause a business exception based on the onboarding status. By configuring the property SL360-Exception it is possible to capture the business exceptions as below.

Upon implementation of Serverless360 BAM, the business can enjoy the following benefits:

• Search for specific transaction based on a tracked property (Employee ID in this case)
• Focused view of all failed transactions in the ‘Action Required’ tab
• Assign a transaction to a team member to act on the same!
• Monitoring on saved queries and for exceptions
• Reprocess the failures to restore business.
• Dashboard full of Insights from the tracked info

Serverless360 BAM is not limited to Logic Apps; you can Perform end-to-end tracking on business process flow across Azure resources and hybrid integrations.

Conclusion
To summarise, we discussed correlation and its need considering a real-time scenario of the Employee On-Boarding Process. We explored the default correlation id in the Logic Apps and discovered how to make it usable by custom defining the same. When I assigned the Employee ID to the Correlation ID, it did solve our requirement of correlating the process across multiple Logic Apps using the Logic App Management. Technical users can manage and monitor the Logic Apps in the Azure portal using Logic App Management. However, for business users to get end-to-end visibility, better insights, proactive monitoring, and reprocessing toolset to restore business, Serverless360 BAM turns out to be the best solution.

Azure Service Bus Session Enabled Message Processing

Nadeem ahamed — Thu, 15 Jul 2021 08:03:38 +0000

This blog will brief on handling messages in session enabled Azure Service Bus Entities. To start with, let us have a brief introduction on Azure Service Bus. Azure Service Bus is a multi-tenant and fully managed cloud messaging service that is used to send information between applications and services. The asynchronous nature of operation offers flexible, brokered messaging, along with structured first-in, first-out messaging and publish/subscribe capabilities.

What is Azure Service Bus Session?
Azure Service Bus sessions offer combined and ordered handling of unbounded sequences of related messages i.e, it provides a way to group set of related messages. It also provides concurrent de-multiplexing of interleaved message streams while preserving and guaranteeing ordered delivery. A session in fact acts as a sub-queue storing messages from different sessions. Some of the common scenarios for using session are:

Grouping of huge message streams into related message streams
Identifying messages from a specific client

How the Session Works?
Any application or client sending messages to a Service Bus Queue or Topic can create a session by setting the ‘SessionId’ property to any value which uniquely identifies that session. On a session enabled Service Bus Queues and Topic Subscriptions, sessions come into play when there is at least one message with a specific ‘SessionId’. Once a session is created, there is no defined time for the session expiry or disappears. A message can be received for a session today and the next message a year later, if the SessionId matches with the session.

With this introduction, let us hop into creating session enabled entities, sending and receiving messages from it.

Creating Session Enabled Entities
Session Enabled entities can be created from the Azure portal by setting the ‘Enable sessions’ flag. This is applicable to both Queues and Topic Subscriptions.

The session enabled Azure Service Bus Queue can be created by setting the ‘RequireSession’ property to true, using WindowsAzure.ServiceBus library in .Net client.

QueueDescription _azureQueue = new QueueDescription("session-enabled-queue")
{
RequiresSession = true
};

NamespaceManager namespaceManager = NamespaceManager.CreateFromConnectionString(“connectionString”);

var queue = await namespaceManager.CreateQueueAsync(_azureQueue);

Service Bus Basic tier doesn’t support creating session enabled entities. Standard and Premium tiers support sessions.

Sending Messages to Session Enabled Entities
Sending messages to session enabled Service Bus entities is little different from entities in which session is not enabled. It is mandatory to set ‘SessionId’ property in every message that is being sent. Messages without ‘SessionId’ cannot be sent to Session enabled Queues. However, any message sent without ‘SessionId’ to a session enabled Topic will be forwarded only to non-session enabled subscriptions, session enabled subscriptions will not receive them.

MessagingFactory messagingFactory = MessagingFactory.CreateFromConnectionString(“connectionString”);
QueueClient client = messagingFactory.CreateQueueClient(“queueName”);
var brokeredMessage = new BrokeredMessage(new MemoryStream(Encoding.UTF8.GetBytes(“MessageContent”)));

brokeredMessage.MessageId = Guid.NewGuid().ToString();
brokeredMessage.SessionId = Guid.NewGuid().ToString();
await client.SendAsync(brokeredMessage);

Receiving Messages from Session Enabled Entities
Like sending messages, receiving the messages from session enabled Service Bus entities is also different.

MessagingFactory messagingFactory = MessagingFactory.CreateFromConnectionString(“connectionString”);
var queueClient = messagingFactory.CreateQueueClient(“queueName”);
var sessionClient = await queueClient.AcceptMessageSessionAsync(“sessionId”);
BrokeredMessage _message = await sessionClient.ReceiveAsync();
await sessionClient.CloseAsync();

A Receiver to receive session enabled messages is created by the client, accepting a ‘sessionId’ as a parameter. In the reactive call back model, it registers a session handler. When the Session Message Receiver object is accepted and while it is held by a client, that client holds an exclusive lock on all messages with the session’s ‘SessionId’ that exist in the Queue or Subscription, and on all messages that will still arrive with the same ‘SessionId’ while the session is held.

Receiving messages without setting ‘SessionId’ using AcceptMessageSessionAsync() will receive the first message in the Queue or Topic Subscription and will initialize the session receiver with the SessionId of that message.

The lock on the session is released when ‘Close()’ is called on the session client, or when the application is unable to perform the close operation. The lock on the session should be closed as soon as it no longer needs it or does not expect any further messages.

Session State
The session state of a message is an opaque binary object that can hold data of the size of one message, which is 256 KB in case of Service Bus Standard, and 1 MB in case of Service Bus Premium. The processing state corresponding to a specific session can be stored inside the session state. The recorded processing state corresponding to that session becomes instantly available when the session is acquired by a new processor in case of any unexpected failures in the previous processor processing that session.

All existing sessions in a Queue or Topic Subscription can be enumerated with GetMessageSessions() on the QueueClient and SubscriptionClient using WindowsAzure.ServiceBus library in .Net client. The session state remains if it is not cleared up, even if all the messages in a session are consumed.

The session state held in a Queue or in a Topic subscription counts towards that entity’s storage quota. It is recommended to clean up the retained state, after the application is finished with a session, to avoid external management cost.

Concurrent Sessions
When multiple concurrent receivers start receiving messages from the Queue, the messages belonging to a specific session are dispatched to the specific receiver that is currently holding a lock on that session.

With that operation, huge message stream residing in a Queue or Subscription is de-multiplexed to different receivers and those receivers can be on different machines, since the lock management happens service-side, inside Service Bus.

A receiver cannot have two messages concurrently in flight, but the messages must be processed in the order. A new message can only be obtained when the prior message has been completed or dead-lettered. Abandoning a message causes the same message to be served again with the next receive operation.

Sessions with Partitioned Entities
In a partitioned entity, if a message has the ‘SessionId’ property set, then the ‘SessionId’ is used as a partition key. By this way, all messages belonging to the same session are handled by the same message broker.

To send a transactional message to a session enabled Queue or Topic, the message must have the ‘SessionId’ property set. If the ‘PartitionKey’ property is specified as well, it must be identical to the ‘SessionId’ property. If both the ‘Partitionkey’ and ‘SessionId’ differ, then it turns out to be an invalid operation exception.

Unlike non-partitioned Queues or Topics, it is not possible to use a single transaction to send multiple messages to different sessions. If attempted, it will return an invalid operation exception. Read more about Azure Service Bus partitioned entities here.

Scenario where Session Enabled Entities can be Used
Consider a scenario, where 3 different clients are sending messages to Service Bus Queue concurrently (i.e. say 1 message from 1st client, then 2 messages from 2nd client, 1 message from 3rd client and again 2 messages from 1st client) with a unique Identifier corresponding to each client and at the receiving end, interleaved messages from each client should be received by different receivers.

In this scenario, the session enabled Queues are of great help. The client application, sending the message must set a unique identifier as a ‘SessionId’ in each message that is being sent. Now, the receiving application should create Session Receiver using the respective ‘SessionId’ and receive the set of messages related to the specific client. By this way, all the messages corresponding to a specific client can be received by a single receiver.

Handling Session Enabled Entities using Serverless360
Serverless360 is a 3rd party application to manage and monitor Azure Serverless components. Serverless360 offers capabilities such as creating Session enabled entities, sending and receiving messages with ease.

Summary
This blog has briefed on working and handling messages in Session enabled entities. To wrap up, the session provides a way to group set of related messages. It also concurrently de-multiplexes interleaved message streams while preserving and guaranteeing ordered delivery which can be used at various scenarios as discussed above.

Azure Event Hub logging, monitoring and alerting

Nadeem ahamed — Wed, 09 Jun 2021 12:13:18 +0000

Introduction
Azure Event Hub is an event ingestion service and a big data streaming platform. It is highly scalable and capable of processing millions of events per second. Azure Event Hub is simple, secures the real-time data and can easily connect millions of devices across platforms.

With this quick introduction, let us understand the following key concepts

Event Producers
Event producers can send events via protocols like HTTP or AMQP. The events sent from the event producers are moved to the Event Hub and each Event Hub is partitioned, which ranges from 1 to 32 partitions.

Partition Key
The partition key helps in processing the events in order.

Event Consumer
Event Consumer reads data from an Event hub.

Create a Namespace
The very first step in creating an Event Hub is the creation of the Namespace with the details below

• Subscription- Choose from the available
• Resource group- Use existing or create new
• Name- to identify
• Location- as per user base
• Pricing tier- The Standard tier of Azure Event Hubs provides features beyond what is available in the Basic tier.

The following features are included with Standard

• Longer event retention
• Additional brokered connections, with an overage charge
for more than the number included
• More than a single consumer group
• Capture
• Kafka integration(Event Hubs for Kafka)
• Throughput Units – controls the Event Hubs traffic. A single throughput unit allows 1 MB per second of ingress and twice that amount of egress. Standard Event Hubs can be configured with 1-20 throughput units. Auto-inflate enables you to start small with the minimum required throughput units you choose.

Once Event Hub namespace is created, Event Hub can be created with the following configurations

• Name
• Partition count
• Message Retention period

Sending Events
Events can be sent to the Azure Event Hub by using Visual Studio 2019.
Here .NET is used to send messages to Event Hubs,

• Create a Console Application.
• Install NuGet Package, MicrosoftAzureServiceBus to enable connecting to Event Hub

Add the following using statements,

using System.Threading;
using Microsoft.ServiceBus.Messaging;

You can add the following code under the Main method,

Once you run the console application, the events are sent to the Event Hubs.

Send Events to Event Hub from Serverless360
A smarter alternative to the solution above is the Send Event Automated task for Event Hubs in Serverless360. One can simulate a real-time scenario by triggering a huge number of events to an Event Hub without writing a single line of code. The Serverless360 GUI encapsulates the underlying complexity and hence improves operational efficiency.

How Do I Monitor My Azure Event Hub?
Azure Event Hub can be monitored from Azure portal using the Azure metrics or you can even use Serverless360 to perform monitoring. Now lets have a deep discussion on both of these monitoring offerings.

Monitoring Azure Event Hubs in Azure Portal
Microsoft Azure offers entity level monitoring where the monitoring is done based on the metrics enabled. Incoming requests, outgoing requests, and successful requests are captured under the metrics section. You can also filter those metrics based on the aggregation value. For example, you can filter your Incoming requests based on the count.

Logging in Event Hubs
Azure Event Hubs logging provides information about the operations done under the Event Hub namespace. Azure Event Hubs have two types of logs namely, Activity Logs and Diagnostic Logs.

Activity Log
Activity logs capture all the actions that are performed on a task and these logs are always enabled. You can view the activity log under the Event Hub namespace.

Diagnostic Log
Diagnostic logs capture well-provided information about all the actions and operations that take place under the Event Hub namespace. A diagnostic setting specifies a list of categories to perform logs and metrics to be collected from the resource and one or more destinations to stream them.

To create a Diagnostic log,
• Click on Diagnostic settings under the Monitoring section.
• Click on Add diagnostic setting

• Under the Category details, you can choose the log that is to be enabled
• In the Destination details, you can choose your destination

To know more about event logs and configurations related to it check, Logging events to Event Hubs

Monitor Event Hubs in Serverless360
Serverless360 offers managing and monitoring of Azure resources like Logic Apps, Function Apps, Service Bus Queues, Topics, Event Hubs, Event Grid, etc., Azure provides the resource level monitoring on their metrics, but the actual need would be Consolidated monitoring at the application level. For monitoring Azure Event Hubs from multiple perspectives, Serverless360 has three types of monitors: Status Monitor, Threshold monitor, and Data monitor.

How Do I Check My Data Usage on Event Hub?
You can use Azure metric page or other third-party tools like Serverless360 to monitor on the data usage on event hubs. The data usage can be monitored on the namespace level or even at Event hub level.

Conclusion
Azure Event Hubs help in processing millions of event data and monitors the metrics at the entity level. Serverless360 provides consolidated monitoring at the application level. In Azure, only a couple of metrics can be configured to be monitored but in Serverless360 you can monitor entities on multiple metrics. Enhance the performance of your Event Hub with Serverless360

Choosing Azure Monitoring Tools for Cloud Native Integration Solutions

Nadeem ahamed — Wed, 12 May 2021 12:29:39 +0000

Azure Monitoring Tools play a critical role in all forums right from a small company to a large enterprise. It is one of the prioritized metrics because it is essential to keep an eye on various components integrated into a business application to understand if they are functioning as expected.

On the other hand, it is also valuable in understanding the errors at the right time and rectifying them so that an organization incorporates healthy functioning

What is APM?
Application Performance Management is about providing a solution to performance-related queries. For example, is it available, is it working as expected, is it meeting your SLA, is the experience for users as expected? and a lot more. APM solutions will typically look on to certain tools like App Dynamics, Dynatrace, New Relic and much more.

Determine your business use case before opting an Azure Monitoring Tool
It is important to determine the type of monitoring tool that is required to your Azure Application. Analyze if it is simple enough to know the performance of the application, is it meeting your SLA, is the experience for users as expected? or if you need to find the errors in your application at the right time and rectify it using a tool like Serverless360 which is significantly build to improve the efficiency of your operations and support team in resolving issues.

Azure Monitoring Tools
Serverless360
Though the scope of Serverless360 is way more than Azure Monitoring, it helps you to keep a check on the health, availability, performance and operational metrics. Once, you determined where the actual error happened using its built-in monitors, it helps you to solve the particular problem. For Instance, Reprocessing of dead-lettered messages to a Queue or Topic once it piled up in the queue.

Dynatrace
Dynatrace brings infrastructure and cloud, application performance, and digital experience monitoring into an all-in-one, automated solution that’s powered by artificial intelligence. Dynatrace will be mainly useful for developers to perform Application, Infrastructure and Cloud monitoring.

AppDynamics
AppDynamics provides an end to end visibility into the performance of your application. They provide end-user monitoring, infrastructure visibility, application performance monitoring and business performance monitoring.

Datadog
Datadog is a monitoring service for multi cloud-scale applications, providing monitoring of servers, databases, tools and services, through a SaaS-based data analytics platform.

Azure Monitor
Azure Monitor maximizes the supply and performance of your applications and services by delivering an inclusive solution for collecting, analysing, and working on telemetry from the user’s cloud and on-premise environments.

Azure Application Insights
Application Insights are used to monitor live applications and to Detect and Analyse issues in the applications. It can do anomaly detections and also designed to improve performance and usability.

NewRelic
New Relic Infrastructure can be used to monitor your Azure services based on the user query. New Relic offers monitoring services for Cloud applications, Servers, databases, containers and Infrastructure and cloud monitoring.

The Value Proposition for Serverless360
Reduced Total Cost of Ownership
The value proposition for Serverless360 is to save you money by giving you the tools to allow a support team to manage the day to day operations of your Serverless solutions built on Azure and reduce the number of times that your support team needs to escalate support calls to developers, IT administrators and delivery team.

Allowing the Azure developers to spend more time delivering core features of business value to your organisation and hence lowering the total cost of Ownership on the Azure Serverless Application.

Aid all your stakeholders
Service Map
We have recognised that there are big challenges for organisations as they increase their adoption of the cloud they fall into a problem where the lack of available skills and experience in cloud technologies.

The more cloud solutions you build the more your delivery teams end up spending time dealing with escalated support cases because the support team do not have the skills and experience to deal with them.

This quickly kills the velocity of your delivery team and I am sure many readers will recognise this problem. To address this issue Serverless360 offers Service Map, through which you can keep your support team informed about the flow of your process and the correlation between them.

Customised Dashboards
The best analogy to compare Serverless360 and an APM product is to think about a car. A car has a dashboard to tell you how fast you are going and if there is a problem. It also has a petrol cap to let you fill it up when it needs gas. Both APM and Serverless360 can play the role of the dashboard in your car, some cars even have a diagnostics port where you can plugin and get metrics from the onboard computer.

APM covers this area. Serverless360 can play the role of the petrol pump and petrol cap to allow an operator to take any action on the system. Lifting the bonnet of the car and starting to fiddle with the engine, well that’s where you need a qualified mechanic and that is the equivalent of the Azure Specialist accessing the Azure Portal.

Assured Monitoring
To achieve this value proposition, we need to have some monitoring capabilities because some organizations do not have big investments in APM solutions, but our monitoring capabilities are focused around more specific use cases than that in an APM product so while we can tick many boxes in this area we do not position Serverless360 as a replacement to your APM capability. Further, Serverless360 allows doing monitoring of different Azure subscriptions in a single pane of dashboard.

BAM-Business Activity Monitoring
Any business organization would require an end to end tracking of the business flow to have adequate knowledge of what is happening at which stage and when. Serverless360 encounters this need by featuring the Business Activity Monitoring (BAM) where the user will be notified with transactions and stage details under each transaction. This will turn out to be of best use for all the stakeholders to acquire information on the business flow.

Automated Tasks
Though Serverless360 offers a good message processing for Service Bus queues and Topics we also consider the reduction of manual intervention and therefore we brought in Automation Tasks. The automated tasks do message processing and message creation and also deletion in an automated way by scheduling them for the user’s concerned time. Above all, these automated tasks reduce the manual effort and provide effective message processing for a massive count of messages.

The Value Proposition for APM
The typical value proposition for an APM product is something like the below list of items:

Cloud monitoring as a service
Software Intelligence
Application Performance Monitoring for the Enterprise
Multi-Cloud APM

What this means is that the APM product is focused on processing the mass of telemetry data that an enterprise produces in their data centres or across their 1 or more cloud providers and also turn that data into something that people can understand and present visualisations that make it possible to determine if your applications are working or not.

The strength of these products is often in their range of connectors allowing them to bring in data from many different sources such as SQL, Web Apps, Azure, AWS, etc.

Overview Comparison of APM and Serverless360
The below diagram provides an overview of the similarities and differences between APM and Serverless360.

Conclusion
In conclusion, the difference between APM products and Serverless360 is that APM products address the question “Do I have a problem”. Serverless360 is aimed at the scenario where we understand that day to day problems do happen and we want to give your support operator the tools to efficiently fix the problems securely and safely without the need of an expert.

Azure Service Bus Dead-Letter Queue Monitoring

Nadeem ahamed — Wed, 28 Apr 2021 07:04:40 +0000

Azure Service Bus dead-letter Queue

Azure Service Bus queues and topic subscriptions provide a secondary sub-queue, called a dead-letter queue. The purpose of the dead-letter queue is to hold messages that cannot be delivered to any receiver, or messages that could not be processed. So, any message that resides in the dead-letter queue is called a dead-lettered message.

Dead-Letter Queue Reasons

Before investigating the best way to monitor and reprocess Service Bus messages efficiently, let us quickly hop in and understand the reasons behind why an active message get dead-lettered.

Most of the time we could notice that the message fails to reach the receivers due to the following reasons;

Dependent service not available

• Faulty message
• Process code issue
• Dependent service not available

Dependent service not available

This could be one of the foremost and time after time reasons where the services that reply on message delivery may go down for a short period. For instance, Redis or SQL connection issues may often happen.

Faulty Message

If in case the message doesn’t have a mandatory parameter or some value is incorrect, then the message will end up in the dead-letter queue after the max delivery count is attained.

The failed delivery can also be caused by a few other reasons such as network failures, a deleted queue, a full queue, authentication failure, or a failure to deliver on time.

Here we can drill down the reasons into two ways:

• System-level dead-lettering
• Application-level dead-lettering

Reasons for System-level dead-lettering

• Header Size Exceeded – Maximum header size: 64 KB
• Error on processing subscription rule
• Exceeding time to live value
• Exceeding maxDeliveryCount –

When DeliveryCount exceeds MaxDeliveryCount, the message is moved to the DLQ, specifying the ‘MaxDeliveryCountExceeded’ reason code. This behaviour cannot be disabled, but you can set MaxDeliveryCount to a very large number. You could specify the Maximum Delivery Count between 1 and 2147483647.

• When Session id property is set to true (the default is false)

Reasons for Application-level dead-lettering

• Messages that cannot be properly processed due to any sort of system issue
• Messages that hold malformed payloads
• Messages that fail authentication when some message-level security scheme is used

Monitoring Service Bus dead-lettered messages made easy

Be it Azure Service Bus Queue or Topic Subscriptions, Serverless360 makes it handy to monitor the dead-letter messages in your testing, pre-production and production environments.

It completely eliminates the complexity or limitation of Azure Monitor which might not fulfill your production environments requirements. For instance,

• Monitor multiple Queues and Topics Subscriptions dead-lettered count in a single report
• Monitor a Queue metrics against another metric, for instance, compare active messages vs dead-lettered messages
• Consolidated monitoring of both the property values and status of Service Bus

I will take you through Serverless360 and showcase how quickly you can configure the alert rule to monitor the dead-lettered messages.

Once you signed up for a free trial, associate the Azure Service Bus in Business Application (Serverless360 feature) – this module lets you access, monitor and manage various Azure resources.

To configure rules, head to the desired resource type in the Manage resources section inside the Business Application. Select the respective queue or topic for which the rules should be configured, and choose the dead-letter count property with warning threshold and error threshold. That’s it.

Repair and resubmit the dead lettered messages with no code overhead

Serverless360 makes your life easier when it comes to repairing and resubmitting the dead-letter messages providing out of the box features like

• Advanced search option to find the dead-lettered message
• Intelligent automation to bulk resubmit the dead-lettered messages
• Variety of message receval modes like Peek-lock and Deffered mode
• Back up and purge messages
• Download particular set of messages

Now, look at the step-by-step process to resumit the dead-lettered messages in Serverless360

• Click the queue whose dead letter messages must be processed, this will lead to a message retrieval dashboard.
• Select dead letter tab and click to get a specified count of messages

• Select those messages to be resubmitted and click resubmit

• Select the destination Queue and proceed to resubmit

• The messages can also be repaired and resubmitted

• The user can also view the properties, content and dead letter reason of a message

Conclusion

I hope this blog gave a better understanding of Azure Service Bus Dead Letter Queue, the reason behind a message getting dead lettered. We also discussed on how Serverless360 can help to process Dead letter messages much smarter way.

Also, check how to Resubmit and Delete Dead-letter Messages of Queues and Topic Subscriptions blog for more insights.

Test Azure Service Bus Performance by Generating a Million Test Messages in Queue, Topic or Event Hub

Nadeem ahamed — Mon, 22 Feb 2021 06:22:14 +0000

For the people into azure service bus namespaces – we often have the need to test our system integration by generating some test messages or events on to the Azure Service Bus entities. You might need this for QA/Development for performance testing, load testing etc. Service Bus Explorer has been the only key tool so far which has its own limitations being a Desktop app. In one of my recent blog post – Sending Messages / Events to Service Bus Entities using Serverless360- I’ve explained what are those constraints and how Serverless360 helps overcome them. It explains why Serverless360 can be a good alternative if you’re still using Service Bus Explorer.

Introduction

In this blog post, we will see how we can simulate a real-time load test of 1 million events/ messages to Azure Service Bus Queue, Topic or Event Hub.

As of now, we have different offerings for Free and Paid customers. Free users can have 10000 events/messages per Activity whereas Paid users can have 1000000 (1 million) events/messages. So, even if you’re just trying out Serverless360, you can still generate 1 million events/messages using multiple activities and be running them multiple times. Paid users can have them in one go.

Azure Service Bus Performance Test – Generating One Million Messages/Events in Serverless360

You can either create an Activity Configuration that you can re-use it as many times in future, or you can opt to start an activity right from the entity level. Please refer to the blog post above for how to create Activity Configuration and re-use it.

We can achieve the different pace of message delivery by trying out various combinations of options like Think Time, Batch Size, Message Count, Task Count etc. with the activity configuration. Depending upon the license plan users can configure 1 million events/messages in one go whereas or create multiple activities to achieve the 1 million count using “run-once” multiple times. Let’s see how the Configuration helps with the message delivery speed.

Configuring 1 Million Messages in One Go

Set the message count to 1 million in the input box and that’s it. It will start sending messages to the specified entity one by one.

Speeding up the Delivery Rate With Multiple Threads

When you increase the TaskCount, it creates additional processes to send the messages together. For example – if TaskCount is 2, then there will be two parallel processes – processing the same activity, speeding up the delivery rate by twice as normal. At the time of writing this post, Serverless360 allows 10 processes per activity. So, it can speed up the delivery by 10 times if you say so.

Deliver Messages Faster in Batch

Another configuration which helps deliver messages faster is “Send Batch”. When you enable Send Batch and set the batch count – it bundles the messages and sends them in one go. At the time of writing this post, Serverless360 allows 10 messages/events at max per batch.

So, it can also help deliver the messages 10 times faster but, there is a catch. When you specify the count for batch-size, make sure the size of the batch does not exceed the allowed quota per message or event size. At the time of writing it is 256KB for a Standard tier and 1 MB for Premium tier. Please refer to the Service Bus Quotas for more details.

Therefore “Send Batch” and “TaskCount” together, if enabled with max values (10), can help speed up the delivery up to 100 times.

Serverless360 displays the progress of the activity to Service Bus Entities.

Conclusion

Based on the different scenarios for the performance or load test one can have various combination of events/message delivery using Serverless360.

Manage and Monitor Azure Service Bus using Serverless360

Nadeem ahamed — Mon, 15 Feb 2021 03:50:40 +0000

This blog is focused more on how to manage and monitor Azure Service Bus using Serverless360.

Key Takeaways

• Understanding Azure Service Bus and its applications
• Deep integrated tooling from Serverless360 for better management of Service Bus
• Consolidated Monitoring from Serverless360 to monitor Azure Service Bus in various perspectives
• Achieving Advanced Security in dealing with Azure Service Bus

What is Azure Service Bus?

Azure Service Bus is a messaging service on cloud used to connect any application, device or service running in the cloud to any other application or service. Handles messages in the FIFO format. It comprises of two entities Queues and Topics.

Service Bus in business?

Azure Service bus has become the most integral part of the Serverless applications as a messaging service. Let us consider a familiar real-time application, Cab booking system – FlyWheelCabs, for better understanding on Azure Service Bus.

Challenges in the Azure portal

Though Azure Service bus is powerful, there are some challenges in managing them through the Azure portal. Here are some business challenges that most Azure users face while manage and monitor Azure Service bus in the Azure portal

No Deep Integrated tooling
No Message visibility
No Message processing
No Consolidated monitoring
No Auditing

So, what would be the solution to solve these challenges?

The one platform to Manage and Monitor the Azure Serverless application is Serverless360.

Integrated tooling

In the FlyWheelCabs system, there is a requirement to auto-filter messages into subscriptions which can be achieved by defining a rule in the topic subscriptions. There is no straight forward solution available in the Azure portal to achieve this. Serverless360 facilitates creating boolean, correlation and SQL filters in the Service Bus Topic Subscriptions. If not for Serverless360 one should use the .Net SDK and implement a custom application to achieve this task.

Many such critical business tasks can be achieved at ease using Serverless360 without writing even a single line of code.

There would be a need to move the resources from staging namespace to production namespace, Serverless360 handles this challenge in an efficient way with import capability. With this capability, one or more Service bus Queues or Topics can be moved from one namespace to another. The exact definition of the Queues and Topics including the Topic subscriptions and even rules will get replicated saving considerable testing and development effort.

With Serverless360, we can also create, delete and change the state of a Service Bus Queue or Topic.

Message processing

Say the Logic App listing to the Queue in the FlyWheelCabs application went down for some reason this will have an impact on the Queue. Dead Letter Messages might pile up due to Time to Live Expiry. This is just one scenario, in business applications the messages would be dead lettered due to the various system or custom reasons.

In the Azure portal, it is not even possible to view the properties and message details. Whereas the real-time need is to process those messages to restore the business.

With Serverless360 Message Processing, it is possible to reprocess and resubmit a business-critical message to another queue or topic.

It is also possible to back up those business-critical messages into a storage blob associated in the composite application.

Activities

When a huge number of messages in multiple Service Bus Queues and Topic Subscriptions need to be managed at ease without any manual intervention, Service Bus activities are the choice.

Auto-process left behind messages in Service Bus

The Logic App listening to the Service Bus Queue might leave behind certain messages unprocessed. These messages need to be moved to another Service Bus Queue to accomplish failover processing. This must be carried out at a defined frequency to ensure none of the cab bookings go unserved. This critical business requirement can be achieved using automated activities to process active messages in Service Bus.

Resubmit and Delete Dead-letter Messages of Queues and Topic Subscriptions

Nadeem ahamed — Mon, 08 Feb 2021 03:01:51 +0000

Azure Service Bus is used as a messaging service in many enterprises. Service Bus contains two types of messaging entities, Queues, and Topics.

Queue

Queues transmit the messages in FIFO (First In, First Out) message delivery. Each message in a Queue can be received by only one active receiver.

Topic

In contrast to the Queues, Topics may contain multiple Subscriptions, each Subscription resembles a Queue. So, the same message can be received from different Subscriptions of a Topic. Based on predefined Rules, the messages can be sent to different Subscriptions.

Dead-letter

Service Bus Queues and Topic Subscriptions provides a secondary Sub-Queue, called a Dead-letter Queue (DLQ). This Dead-letter Sub-Queue is created at the time of entity creation. Dead-letter Queue holds the messages, which have any problem in processing. The messages in Dead-letter Queue can be removed by receiving it. There are certain reasons, why the messages move to Dead-letter Queue. They are,

HeaderSizeExceeded
TTLExpiredException
Session id is null
MaxTransferHopCountExceeded
Specified by application

For more detailed information on Dead-letter, refer Overview of Service Bus Dead-letter Queues.

Serverless360 provides efficient capabilities to analyze volume of DLQ messages and provide a summary count of messages dead lettered due to various reasons, refer Dead Letter Analytics using Serverless360 for more details

Resubmit and Delete

Service Bus Explorer is the commonly known tool for managing Service Bus entities. Even though it is very useful, it has limitations in handling the Dead-letter messages. In this blog, Let us see how Serverless360 helps to handle dead letter messages in resubmission and delete scenario. To know more on how we built this capability, please read: Serverless360 provides a reliable and safe solution for handling the Dead-letter messages

Peeking Messages from Dead-letter Queue

After configuring Service Bus entities in Serverless360, the Operations section of Service Bus Queue or Topic Subscription provides the options to Resubmit or Delete the Dead-letter messages. The user can navigate to Operations section by clicking the entity path or Operations link.

The Operations section contains three different tabs for handling the main Queue messages and Dead-letter Queue messages.

Messages

Messages from the active Queue can peek under the “Messages” tab. The User can only peek the messages from the active Queue. They cannot receive it. The messages can be retrieved by either specifying the “count” or specifying from “sequence number” along with “count”.

Dead-letter

The dead-letter tab provides the options to access the messages in Dead-letter Queue. The user can choose between two types of receive modes, Peek-Lock or Defer.

Resubmit and delete Azure Service bus dead-letter messages of Queues and Topic with Serverless360.

Peek-Lock

After retrieving the messages, User can filter the messages based on the Error Reason due to which the messages are moved to the Dead-letter Queue. The message body, properties and the reason for Dead-letter can be viewed using the context menu available for each message.

Defer

As discussed in Resubmit and Delete Messages in Azure Service Bus Messaging, receiving messages in Defer mode, changes the message status from Active to Defer. Therefore, the message cannot be removed from the Queue, without the sequence number of the message. Serverless360 allows the Users to Resubmit or Delete the messages received in Defer mode.

Resubmit

Choosing the messages that need to be resubmitted and clicking RESUBMIT link provides the option to choose the destination entity. The destination entity may be a Queue or a Topic under the same namespace.

After choosing the destination entity, by clicking the PROCEED link, the messages get resubmitted to the selected entity and removed from the Dead-letter Queue. The status of the resubmission will be displayed with the required information.

Delete

Similarly, simply selecting the messages and clicking DELETE link deletes the selected messages.

Audit

Serverless360 provides the Governance and Audit logs for the Users. This feature can be used for the tracking of operations. Any user activity to resubmit or delete messages are tracked in this section.

Thus, we have a safe solution to handle the Dead-letter messages of Queues and Topic Subscriptions. In addition to this, Serverless360 provides a more advanced way of Resubmission and Deletion of messages by creating activities.

How to monitor multiple Azure subscriptions in a single dashboard

Nadeem ahamed — Wed, 03 Feb 2021 05:30:21 +0000

Introduction

In a typical enterprise, there would be multiple Azure subscriptions managed across various tenants. Each tenant would have multiple subscriptions for respective environments. This blog focuses on managing the multiple Azure Subscriptions with Serverless360. Let us take a simple scenario to have a better understanding of how Serverless360 overcome the challenges faced in the Azure portal with the help of Composite Application.

Scenario

Let us consider a scenario where an organization named Fly Wheel Cab, with multiple systems like Vehicle Management, Driver On-Board Management, Booking Management, and these systems possess multiple environments like Dev, Staging, and production that has respective subscriptions on every tenant as below

Considering the above scenario, there is no single place to manage and monitor all the subscriptions of multiple tenants. When there are multiple resources interacting with other resources in another tenant, it is not possible to group and manage all resources in a single place. Below are some common challenges that most of the Azure users would face with the Azure portal

No Application Visibility
No Consolidated Monitoring
No Deep Integrated tooling
No Application-level security

In this article, we will see how Serverless360 can solve the above challenges with the help of the Composite Application.

What is a Composite Application?

Manage your Azure resources from different Azure subscriptions and tenants in a logical container, Composite Application. User will get an Application-level view of your Azure Serverless business orchestration with the help of Composite Application

1.Logically group all your siloed entities that participate in your business solution into a Serverless Composite Application

2.Entities can be from different Azure Resource Groups, Azure Subscriptions, and Azure Regions

3.Access all your business orchestrations at one place, Composite Application dashboard.

4.This dashboard offers a comprehensive view of the current state of all entities that constitute business orchestrations.

5.Get immediate feedback on the entity status based on the configured monitors at the entity dashboard.

To make a connection between Composite Applications and Azure Subscriptions, Service Principal can be used in Serverless360. Service Principal is an Azure active directory application that requires a contributor level of access.

A Composite Application can have multiple dashboards. Each dashboard consisting of different types of customizable widgets which can be configured and arranged to meet the user need.

Providing Access to Azure Subscription

A Service Principal is an application within Azure Active Directory, which is authorized to access resources or resource groups in Azure. Serverless360 uses the authentication tokens of the Service Principal to manage the resources.

User can assign permissions to the Service Principal that are different than your own Azure account permissions. Typically, these permissions are restricted to exactly what Serverless360 can do.

User needs the following parameters to associate the Service Principal into Serverless360

To associate the Service Principal, user need to create the Service Principal

Steps to create Service Principals

1.Log in to the Azure portal and navigate to the “Azure Active Directory”-> App Registrations

2.Click on the “New registration” and create the Service Principal

Once the App is created, get Client ID, Subscription ID, Tenant ID, Client Secret to associate it to Serverless360.

To Authorize the Service Principal to Access the Resource Groups

1.Navigate to the “Subscriptions” and click on that.

2.In the left panel find the “Access Control IAM” and click Add ->Add role Assignment.

3.Select the application created and click save.

Associating Service Principal into the Serverless360

Enter the following credentials in Serverless360 and click save

1.Subscription Id
2.Tenant Id
3.Client Id
4.Client Secret

In the Service Principal section, the user can add multiple Service Principals of the same tenant or different tenants

Composite Applications

Once the Service Principal is associated, create the Composite Application to group all the resources of multiple subscriptions and tenants into a single container. Now users can leverage various operational and support capabilities offered by Composite Applications. Below described some of the key capabilities of Composite Applications.

Service Map

Service Map will help users visualize how the entities in a composite application relate to each other. This serves as a physical representation of the architecture, the user can derive relationships between the entities that constitute the composite application. It provides a clean dashboard with a full application view and displays the state of each entity based on its monitoring configuration.

Bring the Entities to the Board

In the service map section of the Composite Application, the entities associated with the Composite Application are listed on the left side menu. It is also possible to include a component that is not in the scope of Serverless360 but will be a part of the solution. The required entities can be selected from the left section (palette), which will add the representation of the entity in the right section (diagram pane).

Connect the Entities to Define the Flow

A connection can be made between the entities by clicking and dragging from the center of the representation

Save the Diagram

Once the diagram is saved, the entities will be displayed with the current monitoring status. Access detailed Error.

Edit If Required

The diagram can be edited by clicking the edit option. The issues list will not be displayed while in edit mode.

Infer Entity Status

Service Map indicates the health of the entity with the following color coding

1.Healthy- Green
2.Warning- Amber
3.Error- Red

Click on the entity in warning or error state to fetch the details of the issue as below.

Serverless360 Live Dashboards

Dashboards in Serverless360 can be useful to know more about Azure resources in an application. With the variety of widgets available, users can analyze the azure resources on key metrics from various perspectives.

To know more about the Serverless360 dashboards

Monitoring Capability in Serverless360

Serverless360 helps the enterprises and offers an out of the box monitoring solution that assists the administrators to monitor the distributed azure services from different subscriptions and different tenant.

Types of Monitor

Threshold Monitor

The threshold monitor in Serverless360 sends immediate alerts based on the configuration whenever there is a violation. Users can also schedule the monitor based on the required day and time. Users can also limit the number of alerts to restrict spamming.

The threshold monitor also offers the auto-correct option that makes Azure services be always in an enabled state. Users can simply turn on the auto-correct option and configure the expected state. The threshold monitor will have an eye on the state and convert the state to the expected one if not. This auto healing capability enables the production resources to be always in an enabled state.

Autocorrect Alert Generated from serverless360 in Threshold monitor

The above result is here the Function app state is not matched to the Expected state now the Function app state will be healthy and compliance alert will be generated by the threshold monitor.

Status Monitor

Consider if the user needs a health report every two hours, they can create a status monitor and define the hours and notification channels. The status monitor can be configured to automate the daily health check by configuring the required hours.

Data Monitor

Data Monitor is a Performance monitor that offers an extensive set of metrics for every azure resource with which the performance, latency and memory consumptions can be monitored and alerted when there is a violation. Below are certain monitoring options that can be done with the help of a Data monitor.

1.Evaluate availability of Service Bus Queue / Topic by monitoring on a combination of metrics ‘Server Errors’, ‘User Errors’ and ‘Size’

2.Check on the efficiency of Service Bus Queue / Topic by verifying if you are processing the right number of messages in the specified time window hence ensuring that you meet your business requirements

3.Check on reliability of the Logic App by monitoring the number failed runs ‘Runs Failed’ every hour

4.Get alerted on the consumption of the Logic App, by monitoring if the ‘Total Billable Executions’ exceeds a certain volume, etc. This feature can be of help to Azure portal administrators to ease tasks that an administrator is forced to do on a daily basis, and it is a monotonous/repetitive task.

This feature can also be used by Azure developers to understand if the applications that interact with Azure Service Bus Queue / Topic handle them the right way, by monitoring the User Errors generated.

Watch Monitor

Consider a business orchestration where a Logic App and Function App play a critical role. Failure in the Logic App or Function App is not acceptable as it would bring the business process down. Serverless360 watch monitor can continuously monitor the Trigger and Run history of an associated Logic App and notify the failure reason through the configured notification channels. In the case of the Function App, the invocation Log will be investigated to identify a failure. Watch monitors proves to notify the failure in the orchestration within the configured minutes (between 5 and 15 mins) of its occurrence.

Conclusion

Using Serverless360 user can manage and monitor the multiple subscriptions across tenants in a single place and it also offers

1.Monitoring for Azure resources at the application-level.

2.Operational capabilities for developers to manage Azure resources.

3.Service Map to view whole orchestration that enables support person to identify the issue easily.

4.Dashboards for better analysis of the Azure resources.

Azure Service Bus Throttling Conditions to be Considered in Messaging Platform

Nadeem ahamed — Fri, 22 Jan 2021 08:36:48 +0000

When architecting a solution in Azure, it is always important to keep in mind any limitations which might apply. These limitations can come not only from tier choice but also from technical restrictions. Here, we will have a look at the Service Bus throttling conditions, and how to handle them. When you are at the documentation page, it is clear there are several thresholds which will affect the maximum throughput achieved before running into throttling conditions.

• Queue/topic size
• Number of concurrent connections on a namespace
• Number of concurrent receive requests on a
queue/topic/subscription entity
• Message size for a queue/topic/subscription entity
• Number of messages per transaction

Azure Service Bus Throttling conditions

Each of these conditions has their characteristics and ways in which to handle them when they occur. It is important to understand each, as it allows us to take decisions on the following steps. And, set up a resilient architecture to minimize risks. Let us have a look at each and at the options to mitigate these thresholds.

Queue/topic size

This threshold stands for the maximum size of a Service Bus entity and defined when creating the queue or topic. When messages are not retrieved from the entity or retrieved slower than they are sent in. The entity will fill until it reaches this size. Once the entity hits this limit, it will reject new incoming messages and throws a QuotaExceededException exception back to the sender. Maximum entity size can be 1, 2, 3, 4 or 5 GB for the basic or standard tier without partitioning. 80GB standard tier with partitioning enabled as well as for the premium tier.

When this occurs, one option is to add more message receivers, to ensure our entity can keep up with the ingested messages. If the entity is not under our control, another option would be to catch the exception, and use an exponential backoff retry mechanism. By implementing an exponential backoff, receivers get a chance to catch up with processing the messages in the queue. Another option is to have the receivers use prefetching, which allows higher throughput, clearing the messages in our entity at a faster rate.

Number of concurrent connections on a namespace

The second threshold discussed in this post is about the number of connections allowed to be open simultaneously to a Service Bus namespace. Once all of these are in use, our entity will reject subsequent connection requests, throwing a QuotaExceededException exception. To mitigate this condition it is essential to know that queues share their connections between senders and receivers. Topics, on the other hand, have a separate pool of connections for the senders and receivers. The protocol used for communication is also essential, as NetMessaging allows for 1000 connections, while AMQP gives us 5000 connections.

This means that as the owner of the entities, there is the possibility to switch from queues to topics, effectively doubling the number of connections. Beware though, this will only increase the number of total allowed connections, but if there is already a large number of senders or receivers, it will still just give us the maximum of connections the chosen protocol gives us for each of these. If the sender or receiver client is under our control, there is also the option to switch protocols, which could provide us with five times the amount of connections when switching from NetMessaging to AMQP.

Number of concurrent receive requests on a queue/topic/subscription entity

This threshold applies to the number of receive operations invoked on a Service Bus entity. Each of our entities has a maximum of 5000 receive requests it can handle concurrently. In case of topic subscriptions, all subscriptions of the topic share these receive operations. Once the entity reaches this limit, it will reject any following receive requests until the number of requests is lower and throws a ServerBusyException exception back to the receiver. To handle this limitation, once again the option is there to implement an exponential backoff retry strategy while receiving messages from our Service Bus entity. An alternative would be to lower the total number of receivers.

Message size for a queue/topic/subscription entity

Service Bus entities only allow for a limited size for their incoming brokered messages. When trying to send in larger messages, the entity rejects these and throws a MessageSizeExceededException exception back to the sender. For the basic and standard tier, the maximum message size is 256KB, while for the premium tier it is 1MB. When working with large messages, it is possible to split these and send the chunks over the line, re-assembling them on the receiver side. Another option is to implement a claim check pattern, in which case storage of the large payload is done at an alternative location and only a reference to this is sent in the brokered message.

Number of messages per transaction

When sending messages in transactions, the limit is 100 messages per transaction, both for synchronous and asynchronous calls. When trying to post more messages inside of a single transaction, the entity throws a TransactionSizeExceededException exception back to the sender and rejects the complete transaction. The answer to this restriction is making sure the calling code never exceeds 100 messages in a transaction.

Retries

For several of the throttling conditions doing retries is a plausible solution to ensure our client delivers its messages in the end. This is the case in any situation where time can help resolve the problem. The fix can be due to retrieval of messages, closing of connections, or the number of clients decreasing. However, it is important to note that retries will not help for all these throttling conditions. For example, when a message is too large, retrying this message will never result in success. Therefore, it is important to check the actual exception that you receive when catching these. Depending on the type of message, you can take decisions on the next steps.

Furthermore, by default retries will occur every 10 seconds. While this is acceptable for many occasions, it might be better to implement an exponential retry mechanism instead. This mechanism retries with an increasing interval, for example first after 10 seconds, then 30 seconds, then 1 minute, and so on. This mechanism allows for intermittent issues to resolve quickly. But also help on lasting exceptions thanks to the increasing interval between retries mitigates provided by an exponential backoff retry mechanism.

Monitoring

When working with Service Bus, it is crucial to implement a suitable monitoring strategy. There are several options to do this, ranging from the built-in tooling in Azure to using a third-party product like Serverless360. Each of these solutions has their strengths and weaknesses. When it comes to watching the Service Bus throttling state, Azure Monitor has recently added new metrics which allow us to do just that. These capabilities are currently in preview and gives several metrics to keep an eye on Service Bus namespaces and entities. One of these metrics is Throttled Requests, giving us insights into the number of requests throttled.

Subsequently, it is even possible to set up alerts on top of these metrics, which you can accomplish through Azure Monitor. Add an alert rule for this scenario. These rules define when to trigger alerts, and which actions to take.

These actions range from sending out an email or SMS, all the way to calling webhooks or invoking Logic Apps. These latter options give us the possibility to start custom workflows, notifying specific teams, creating a ticket, and more like these. For this, specify an action group with one or more actions in the alert rule. Consequently, it is even possible to create multiple action groups can for different alert types. Here you can send high-level alerts to the operations team and service-specific alerts to the owners of that service within the organization.

Serverless360 provides easy configuration and notification options for service bus monitoring and raise alerts for Service Bus Throttling conditions.

Conclusion

When setting up an architecture with Azure services it is always important to keep an eye on the capabilities. In this case, we investigate Service Bus throttling conditions. Often, mitigation is done by adjusting some of the properties of our clients or implementing a retry strategy. Additionally, to keep clear insights into our environment, a monitoring strategy needs to be implemented for our situation. Where alerts are triggered in case any of these throttling conditions occur.