For those of you who have had to deal with microservice architectures, you know how quickly they can get exponentially more complex. Network deploys and configs can end up taking as much as 1/3 of developer time, which is already constrained. This translates directly into lost productivity, and lost money when failures make root cause analysis more difficult, and SLA uptime is lost.

Passing requests through an edge gateway allows for developers to view all http requests and API calls connected to the gateway within seconds or minutes of the request. Because the gateway sits at the edge, response times for 99+% of the internet are minimal.

In this tutorial, we'll show how easy can be to monitor request-level traffic using an edge gateway.

General Architecture

Here is an example of what the end result looks like. You can see that there is an API call that is returning a 400 error, and might need to be evaluated more closely.

Without an edge gateway, it could take hours or days to recognize the error, or worse, have a client call you in the middle of the night letting you know your SLA is being affected.

Updating the DNS records are often the only change to a project's architecture that are needed to set up an edge gateway:

Public-facing Domain -> Edge Gateway -> Web Server 

Step 1: Connect the edge gateway to the web server

In the no/low code edge gateway, we'll use an auto-import function which auto-populates rules for monitoring the subdomain.

For simplicity and security's sake, we will use a subdomain (example.snowowl.co), which act in the place of a web server.

Step 2: Connect a public-facing domain to the edge gateway

A public facing domain is the domain that you want the public to navigate to, to to view the webserver's contents. In this example, we will use the domain: public.snwlgdaddy.com .

To connect public.snwlgdaddy.com to the edge gateway, we just need update the DNS records in domain's DNS registar (i.e. GoDaddy, AWS Route53, Google Domains, etc), using the information provided by the gateway.

Step 3: Test traffic and monitor your microservices/API calls

With the gateway connected between your public traffic and your webserver, the last thing that needs to be done is some testing to verify that the architecture is functional.

You can view snapshot summaries of your connected domains to quickly assess if there are spikes in failures, and where those failures might be coming from. Additionally, you can drill down to the individual request level for any http request or API call and view the request/response headers.

Snow Owl (SnowOwl.co) is a no/low code edge gateway that provides request-level monitoring, can install within 15 minutes, and allows for custom routing via a rules engine for a variety of use cases. Feel free to view our documentation at docs.snowowl.co and DM us for beta access.