When we manage multiple assets, we must know what we have and their state. This is especially true when managing complex web ecosystems. Whether they are applications dependent on continuous communication with endpoints, or architectures reliant on multiple origins.
At NOC, we don’t specifically talk to inventory management, or discovery, but should be invested in. Especially if other teams in the organization can deploy digital assets (e.g., marketing).
What we can help with, however, is monitoring known assets. This is how…
What is Asset Monitoring?
Whether you’re responsible for 1, or a thousand, digital assets, asset monitoring is undeniably part of your administrative toolbox. At least it should be.
This is especially true if your website is critical to how your organization makes money.
The NOC asset monitoring service is designed to help administrators keep an eye on the health of known digital assets. An asset can be any of the following:
- Fully Qualified Domain Name (e.g., noc.org, cleanbrowsing.org);
- IP;
- AP Endpoints;
- Asset monitoring is specifically looking at performance and availability, and should be all inclusive.
Asset Monitoring Deployments
When deploying an asset monitoring strategy, be cognizant of the entire stack. Never assume one piece will never go down.
Asset Monitoring Deployments
Perhaps the most basic scenario is a website that is utilizing a Content Delivery network (CDN). There are two very specific configurations you want to consider when setting up your monitors in this scenario:
| Type | Description |
|---|---|
| The Edge | CDN providers refer to this concept of the edge often, it’s meant to describe their network. It is where your content is cached and what is used to amplify your sites performance globally. |
| The Origin | This is where your website is hosted. These are the folks you pay on a monthly basis, or maybe host on one of your internal servers. |
You also want to consider if the monitor is local, or global. Are you checking it from one location, or multiple.
In this example, you want to configure your monitors to keep on eye on both – the edge and the origin. You do this by configuring the monitors to look at two specific request types:
| Type | Description |
|---|---|
| HTTP/HTTPS | HTTP/HTTPS are the web protocols used by browsers to render your website, it’s a communication mechanism between the browser and your server. Because you’re using a CDN, when you monitor this request type it’s going to tell you if the edge is up. |
| PING | PING, however, is fundamentally different, it is a networking protocol used to check if a server on the network is accessible. |
Administrators will typically configure HTTP/HTTPS monitors by default, but often miss a very important monitor – the origin. This will prove problematic when there is an issue – “Why is the CDN down?”. It might not be the CDN at all, but rather the origin that is down (generating the infamous 502 gateway error).
Adding Monitors with NOC
Adding monitors for a configuration like this is done via the monitoring dashboard.
The image below shows you what you see when configuring a monitor. The platform gives you two very distinct options between HTTP/HTTPS and Ping monitoring.
This is HTTP/HTTPS configuration, looking at the domain that a user might look for in their browser:
To look at the reachability of the origin server, it would look like this:
In the example above, the HTTP/HTTPS monitor is looking at the performance and availability of the CDN, while the PING monitor is looking at the reachability of the origin.
In addition to the types of monitors, at NOC you can choose where to check from. This allows you to choose which areas are most important to your organization.
Asset Monitoring is Critical
Monitoring assets is a critical administrative function, but often under utilized or poorly configured. The scenario provided above is a derivative of a recent case with a customer whose website was down.
Their monitors were showing that HTTP/HTTPS requests were up. This was courtesy of the edge provided by their CDN. What they didn’t realize was that the cache was doing it’s job. It was trying to solve the availability problem; the real issue was the origin.
In total, their critical website was down over 12 hours, but up for 90% of that to new prospects. New users were saved because of the CDN, but existing customers were infuriated (i.e., they couldn’t interact with the site).
When managing digital assets you must be thoughtful of the entire stack, it’s what your customers rely on you for.
If you have questions about your current monitoring deployment, send us a note at support@noc.org.