What happens over time if my CloudWatch alarms go to an SNS Topic but that topic has no subscriptions? - cloudwatch-alarms

I have some CloudWatch alarms that I need to set up and I only want alerts from a composite alarm (more than one of the components making up the composite alarm are set to ALARM)
I do not want to receive alarms from the individual components of this composite alarm because this would only inform us of a transitory condition that usually self-resolves.
My quesstion is, If a create an SNS Topic called "Unmonitored" for example and have those component alarms get sent to that topic do these alarms start to accumulate over time and how does AWS handle this?
I couldn't find any information on SNS lifespan or what happens to messages sent to an SNS topic when there are no subscriptions to that topic set up.
Edit: as a test I created a CloudWatch alarm with an SNS Topic that has no subscriptions and I get this message in the console:
Warning: "This action sends a message to an SNS topic with no endpoints or the endpoints are in a different account."
Which is to be expected.

Related

Azure Service Bus subscriber is needed to send the message to the topic

I have tried to send a message to the topic of Azure Service Bus but it is not having any subscribers for now and it was showing there is no matching subscription found for it. So I have created a temporary subscriber for that and sent the message successfully.
So my question is it compulsory to having a subscriber to send the message to the topic??
Thanks for the help!
You do not have to have subscriptions under the topic to be able to publish messages. But in order to receive messages, subscriptions have to exist. Subscribers can come online later and fetch those events. Without subscriptions, subscribers will not get anything as the topic doesn't know what to retain and for whom.

Read and Delete one or more message from azure service bus topic using logic app

Can we Read and Delete one or more message from azure service bus topic using logic app?
what does the Complete Message Action will do on a Logic App.
Read
You could read a message from the service bus. You could use one of the below connectors and triggers :
Get messages from a queue
Get messages from a topic
Or you could use one the following triggers which will get the message content to be read :
When a message is received in a queue (auto-complete)
When a message is received in a queue (peek-lock)
When a message is received in a topic subscription (auto-complete)
When a message is received in a topic subscription (peek-lock)
When one or more messages arrive in a queue (auto-complete) When one
or more messages arrive in a queue (peek-lock)
When one or more messages arrive in a topic (auto-complete)
When one or more messages arrive in a topic (peek-lock)
https://learn.microsoft.com/en-us/connectors/servicebus/#triggers
Complete Message Action (Also - Delete)
The operation completes a message in a queue or topic depending on which conector you use.
What does completes a message mean ?
When the receive operation is initiated, the message is locked by the receiving client. The message in the queue/topic remains undeleted. In case the message is not completed, the message would be available to be consumed again for the receiving clients after the lock expires.
So in short complete a message means that the message should be marked as processed and deleted from the queue or topic.
https://learn.microsoft.com/en-us/connectors/servicebus/#get-messages-from-a-queue-(peek-lock)
Update :
You could do something like below :
Explanation :
The above logic app gets triggered on a http request with the messages count that needs to be read.
Subsequently mentioned count of messages is retrieved from the service bus - topic combination and completed eventually.

Azure event grid with service bus topic subscription and Logic app web hook not triggering

I am using Service Bus premium to create Event Subscription (Event Grid) and the Endpoint I am using Webhook ( Logic App Endpoint) .
My use case is : whenever the message is received in service bus topic the event should get trigger and the webhook should be called.
The webhook endpoint is of Logic App URI .
Issue : For 15-20 message in the topic the event gets triggered and the logic app is fired and after that even for any number of message the event does not get triggers.
Note : I am using Peek-Lock in my logic app and the message is not completed yet , number of messages i can see in the topic/subscriptions which are not yet processed.
Event not triggering even there are many messages in the topic/subscription.
Your use case, such as "whenever the message is received in service bus topic the event should get trigger and the webhook should be called." can not be handled by Azure Event Grid.
The following use cases are in this scenario:
No event is published when there is no message in the entity.
The event is published immediately when the first message is arrived into the entity and there is no active listener for 360+ seconds on the entity
The event is published every 120 seconds when the listener is still non-active and there are at least one message in the entity
The event is published after 360 seconds listener idle (non-active) time and still there are at least one message in the entity. For example, if we have 5 messages in the entity and the subscriber will pull-up only one message using a REST Api, the next event will be published after 360 seconds. In other words, the watchdog entity allows to keep a listener in the idle time for 360 seconds.
As you can see, the AEG can help to wake up a receiver, in other words to avoid a continuously polling for messages in the ASB entity.

How to extract message attributes from AWS SNS Notification?

I am writing a small node-express app that has a POST endpoint that is set to receive Amazon SNS notifications. I have done everything that is needed to receive SNS Notifications.
After reading Using Amazon SNS Message Attributes it seems that the Message Attributes set when publishing to a topic can be extracted and used. However I cannot see the Message attributes in the notifications I receive. Is it advisable to depend on data set in message attributes?
Or should we never try and extract message attributes because they are used for other purposes such as subscription filter policies perhaps?

Messages sent to Topic are getting lost if no subscriptions are specified

In Azure Service Bus, if below is the sequence of events, then all's fine -
Create Topic
Create Subscriptions inside Topic
Send Messages to Topic
With above, the subscriptions are triggered when a message is sent. This is expected.
However, if we modify the above sequence like this
Create Topic
Send Messages to Topic
Create Subscriptions inside Topic
In this case, as messages are sent to a topic whilst no subscriptions were in place, when the subscriptions are indeed created, the previously sent messages don't show up in their list. Those messages are essentially 'lost'. Am not able to see those messages in Service Bus Explorer too.
The above sequence flow is relevant because we have detached publishers and subscribers, where the publisher just sends a message and subscribers, when they come online, create the subscriptions and handle them. The order in which the publisher and subscriber come online is not guaranteed.
How can I access/process messages sent to the topic before the subscriptions are created? What happens to such messages in the first place?
Thanks
It turns out that the above behavior is by design - if no subscriptions are there, then the message is lost.
To overcome this, Azure Service Bus provides a property on topic to enable the pre-filtering of messages before they are sent. So, if no filters/subscriptions are available, it'll throw an exception
Set the option on the Topic
namespaceManager.CreateTopicAsync(new TopicDescription(topicName)
{
EnableFilteringMessagesBeforePublishing = true
});
Whilst sending the message, check for exception
try
{
await topicClient.SendAsync(brokeredMessage);
}
catch (NoMatchingSubscriptionException ex)
{
// handle the exception, maybe send it to dead letter queue using DeadLetterAsync
}

Resources