I use a product from a former MVP, Thomas Ardal to handle logging from my Azure Web and API Apps.
The product is elmah.io
Every time there is an error I receive an email like the one shown below.
When I click on the link, I am able to view the detail view from my dashboard
The first thing I noticed is the URL. In this case it is a GET operation with /feed/ for the path. My API App does not have an operation that has feed in the path.
In the upper right corner there is list symbol with a red star on it. When I click on it, I am presented with Quick Fixes for the issue, as shown below.
I want to be able to see where the Request originated from. I click on WHOIS. This takes me to dpip where I am able to see the Geo location for the IP Address as shown below
The Security rating provides me with additional information.
Clicking on the Proxy type Tor provides me with more information,
Without elmah.io I would not know about issues like this
Configuring my API App was easy.
I don’t usually write product reviews.
I highly recommend you take elmah.io out for a test drive .
I was working on a project that required a multi-tenant Logging and Notification Service
The solution I came up with was to use the Event Grid trigger for a Logic App. There would be two Logic Apps; one for receiving the event message and the other for sending notifications as shown in the following figure.
The following are the steps in the workflow.
- Receive Event Messages from different publishers
- Loop through messages and parse out Errors Events. Send the Error Events to the Notifications Logic App.
- In parallel, insert the Document into Cosmos DB and Data Lake Store.
- The Notifications Logic App evaluates the contents and queries Cosmos DB for the notification type (Email and/or SMS) and recipients
- The Notification is sent.
Because the Event sources were different, there was possibility that there could be duplicate Id’s in the Event message. In order to solve this issue, I used the Logic App Compose Action to wrap the Event Message and rename the Id to
EventId as shown below.
To parse out the Error event type, I added a Decision Action using
@equals(toUpper(triggerBody()?['eventType']), 'ERROR'). Additional logic can be added to satisfy any Business Rule.
I used the Cosmos DB Create or Update document Action to save the event messages. The
Id value is auto generated, The partition key is the
Data Lake Store was used for archival. Because the messages were being saved to both Cosmos DB and Data Lake Store at the same time, all I needed to do is set the
TTL Time-To-Live value of 10 days on the Collection. This eliminated the need to add a another Logic App to archive the Event before the Time-To-Live date.
Because the Notification Logic App uses a Manual Trigger, I needed to return a response back.
- You can leverage Logic Apps with the Event Grid Trigger to handle Logging of any type of events.
- You can save the Event message in Cosmos DB and concurrently archiving the message in Data Lake Store.
- Using simple business logic for evaluating the Event message
- Storing Notification Recipient information in a Cosmos DB document.
- The application follows the Azure Event Driven Architecture Architectural Style.