Introducing Custom Dashboards in NGINX Amplify

Introducing Custom Dashboards in NGINX Amplify

We are very excited to announce the addition of custom dashboards to NGINX Amplify, our SaaS-based tool for monitoring and managing NGINX. Now you can create your own dashboards populated with highly customizable graphs of NGINX and system-level metrics.

The 'My Custom Dashboard' screen in NGINX Amplify displays graphs of metrics specified by the user

As you can see, not only can the metrics be summed (or averaged across several NGINX servers), but it is also possible to create additional “metric dimensions”, for example, reporting the number of POST requests for a specific URI.

NGINX Amplify is currently in private beta. We want to thank everyone who provided their feedback and various suggestions. Everything you’ve told us so far has been incredibly helpful. If you haven’t yet, sign up for the private beta today.

Now, let’s dig deeper into the custom dashboards.

Using Custom Dashboards In NGINX Amplify

With this new feature, you can build bespoke sets of graphs for the metrics that NGINX Amplify collects.

Several use cases for a custom set of graphs that immediately come to mind are:

  • Checking NGINX performance for a particular application or microservice, e.g. based on the URI path
  • Displaying metrics per virtual server
  • Visualizing the performance of a group of NGINX servers – for example, front-end load balancers or an NGINX edge caching layer
  • Analyzing a detailed breakdown of HTTP status codes per application

To create a graph of custom metrics in NGINX Amplify, click 'CREATE DASHBOARD' on the 'Dashboards' drop-down menu

To create a custom dashboard, click CREATE DASHBOARD on the Dashboards drop-down menu, as shown in the screenshot above. Then click Edit in the upper right corner to start editing the dashboard. You can then add graphs and simple values to the dashboard.

The following dialog box appears:

In the 'Add graph to dashboard' dialog in NGINX Amplify, you create a custom graph by defining the metric, source, type of aggregation, and filter to apply

To add a graph, perform these steps:

  1. First pick one or more metrics of interest. You can combine multiple metrics on the same graph using the Add another metric button at the bottom.
  2. After the metric is selected, NGINX Amplify lists the objects for which it has already observed this particular metric. Select one or multiple objects here. In the example above the objects are the NGINX instances on the hosts called astra and otter.
  3. Select either sum or avg as the aggregation function.
  4. Last but not least, filtering is also available for NGINX metrics. If you click on Apply filter, you can then add multiple criteria in order to define specific “metric dimensions”. In the screenshot above, we are filtering by HTTP status code 401.
  5. Click Save when you’re done, and the graph is added to the dashboard. Obviously you can then edit the graph specs, move it around, resize, stack the graphs on top of each other, etc.

By default, we don’t really store all of the possible metric dimensions in the NGINX Amplify backend. A particular filter starts to slice the metric according to the specified dimensions only after the graph is created. Hence, it can be a while before the “filtered” metric is displayed on the graph – the end result depends on how quickly the log files are being populated with the new entries, but typically you will see the first data points in under 5 minutes.

How Custom Dashboards Work in NGINX Amplify

Below is a little bit more technical detail about how it all works.

Because NGINX Amplify is not a log analyzer, we had to enhance the Amplify Agent in order to implement additional slicing for metric dimensions. We’ve added capabilities in the Amplify Agent that enable it to parse the NGINX access logs on-the-fly and extract all the necessary metrics without sending the raw log entries elsewhere. Moreover, the Amplify Agent can actually understand custom log formats automatically, and start looking for various newly defined metric dimensions.

In a sense, what we have now in the Amplify Agent is a combination of real-time log analytics and collection of the standard metrics (i.e., metrics from the stub_status module). Again, the Amplify Agent does only the real-time log processing, and always on the same host where it is running.

Metric filters can be really powerful. By using the filters and creating additional metric dimensions, it becomes possible to build highly granular and very informative graphs. Bear in mind, though, that to enable the Amplify Agent to slice the metrics you must add the corresponding log variables to the active NGINX log format.

In addition to all of the above, we also wanted to describe the technical challenges that we had to overcome when implementing custom dashboards.

First of all, we have to deal with the many kinds of NGINX builds out there. Many people install NGINX from packages they find with their OS distribution, from our native repository at nginx.org, or maybe even from a third-party repository. Overall, there are many versions and many different flavors of NGINX builds in the wild. Automatically identifying a particular running binary and finding all its metrics is sometimes a very tricky thing to do. If you don’t see the Amplify Agent successfully detecting your perfectly valid NGINX instances, give us a buzz (through the Intercom icon at the bottom right of the NGINX Amplify screen) and we’ll investigate it.

For NGINX metric collection per se we had to standardize on pretty much just two common denominators – stub_status and the log files. We also collect some additional metrics using psutil(). If you don’t see a particular metric being collected, be sure to check the docs, and feel free to ask for help as well.

One of the hardest parts for us when implementing the custom dashboards has been designing the Add graph to dashboard dialog box. We really tried to make it as simple as possible, but given the complexity of the underlying metric collection mechanisms, your mileage may vary. Please feel free to send us any kind of observations and suggestions in regards to the usability of the graph configuration mechanism.

Last but not least, the Amplify Agent and the backend code had to be seriously revamped to support new metric breakdowns and additional metric dimensions. Sometimes bugs slip past our internal QA, so bear with us for a little while until it all settles.

Why Custom Dashboards?

When we first started to think about the graphs in NGINX Amplify, we had quite a few challenges and tradeoffs to manage. We ended up with an initial plan to implement a scalable metric collection and just the core set of graphs first – in order to begin with something that would be useful for basic graphing of NGINX performance.

As it turns out, a lot of our beta users really appreciated the ability to easily see what their NGINX servers are doing, as well as identify and pinpoint various performance related problems.

However, as soon as we launched the private beta in November 2015, we also started to get more and more requests for somewhat more powerful graphing capabilities. In particular, a number of people immediately asked how they could build individual graphs for virtual hosts on their NGINX instances – and not just instance‑wide cumulative graphs.

Summary

There are many things that we’d like to improve in the dashboards going forward. We ponder a lot of additional details like graph design, better labeling, color themes, copying graphs between dashboards – and most certainly dashboard‑creation wizards. If you have your own ideas, send them over!

We hope you’ll like the new dashboards and will dig out even more useful information about the lives of your NGINX servers!

As always, your feedback is highly valued, and very much appreciated.

The post Introducing Custom Dashboards in NGINX Amplify appeared first on NGINX.

Source: Introducing Custom Dashboards in NGINX Amplify

About KENNETH 19694 Articles
지락문화예술공작단

Be the first to comment

Leave a Reply

Your email address will not be published.


*


이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.