Connecting the Enterprise with Azure Event Grid and Serilog
In all companies, large and small, there is no One app to rule them all. The reality is that there are often dozens, sometimes hundreds, of apps/services/tools/etc that we use to help ourselves or to provide services to our clients.
In all companies, large and small, there is no One app to rule them all. The reality is that there are often dozens, sometimes hundreds, of apps/services/tools/etc that we use to help ourselves or to provide services to our clients. So how do you get all of your services and tools working in concert to meet your goals, objectives, and strategies? How do you take that "legacy" service that a client has been using for ten years and make it play nicely with your shiny new microservice? The answer you want to give is "re-write it all!" or let's change our tool to "X"; however, more often than not, it's expensive or impractical for the business. In this post, I'll focus on leveraging Azure's new Event Grid service to help answer some of those questions.
Event Grid is designed to be a lightweight, low-dependency, and large-scale reliable messaging solution for reactive or event-driven workflows. Its integration points make it different from other reliable message offerings in Azure. You send events as a JSON payload through a simple HTTP Post, which any number of registered HTTPS endpoints can receive. The filtering is also straightforward; each subscriber can filter on the event subject and/or the event type strings that come in with every event payload. HTTP JSON in, reliable and filtered HTTP JSON out, doesn't get much simpler than that. More on Azure Event Grid.
Now that I know how my events will get around, the question becomes, how can I send them across various apps easily and uniformly? Typically, you embed the code directly, build your library, or leverage/extend an existing library. I explored most options while prototyping but settled on Serilog as my solution. Serilog is a successful and highly extensible open-source logging framework for .NET, focusing specifically on supporting structured data in log events. The primary way to extend Serilog is through Sinks, which are custom-coded destinations for your log events. Many of the sinks come directly from and are maintained by the GitHub community, which continues to thrive. For those reasons and because I like the project and contribute to it often, I decided to build a sink for Event Grid. The Serilog Event Grid sink project.
From your .NET app, install and set up your logger
Install the main sink from NuGet along with any enrichers you may want to be included with your event.
Install-Package Serilog.Sinks.EventGrid
# optional enrichers
Install-Package Serilog.Enrichers.Environment
Install-Package Serilog.Enrichers.Process
There are quite a few options for setting up the logger with the Event Grid sink. Though in this example, I'm defining the Event Grid topic configuration in my app.config
, and setting up my event payload to always contain my transformed UserContext
along with the machine & process information.
Add your log event code
The resulting event through your registered subscriber endpoint
Now What?
That's up to you. You are now emitting rich custom events from your new or existing app with just a few lines of code. Custom client billing, real-time notifications in slack, extended processing in a serverless function...all sounds pretty good to me :)