We use the monitoring plug-in (Prometheus) to show how the Kong Gateway is configured.

By default, the metrics interface exposed by Kong is 8100/metrics, including some basic data monitoring, and more granular monitoring data (such as Routes, Services, HTTTP code, etc.) requires monitoring plug-in: Prometheus Plugin.

In addition, Kong also has the official Grafana Dashboard template. As long as the monitoring source is properly adapted, it can fully realize one-click monitoring graph construction. See grafana.com/grafana/das…

To prepare

Before we talk about monitoring, we first need to improve Prometheus (this Prometheus is not a plug-in, but a monitoring and acquisition tool), I directly use ali Cloud monitoring and acquisition, eliminating Prometheus installation and data storage problems.

If you deploy it yourself, you need to collect data in the form of the Kong Service address + monitoring Port. If successful, it will look something like this:

Only Kong’s own monitoring data does not involve request-related data.

General plug-in adaptation

First of all, the official provides certain function plug-ins, see: docs.konghq.com/hub/, then we can also… “By K8s custom resource adapter Kong various plug-in” way, see: docs.konghq.com/kubernetes-…

But I don’t recommend it.

The reason not recommended is that the above custom resource is like a bridge between the plug-in and the corresponding (Kong Routes) and (Kong Services). These are stored in the K8s data center, but later on, once you modify the plugin parameters, this change is not counted in the K8s resources, and when Kong restarts, the plugin information will be restored to the original.

So I recommend using the Admin API to manipulate plug-ins.

The Admin API operates on plug-ins

Using Konga UI, we can easily enable plug-ins. Note that plug-ins are also divided into global plug-ins and targeted plug-ins. In the afternoon, we directly created a global Prometheus Plugin.

Then go to the Grafana monitor and see the monitoring related to the request.

Other plug-in operations

Kong provides a number of free plug-ins, almost all of which can be directly operated on konga UI, such as Rate Limiting. However, I found that konga could not effectively pass some parameters to Kong when using the Proxy Cache Plugin. If this was the case, we would have to use Kong to customize the resource. Each change would require deleting the old definition and creating a new one.

In addition, we can also develop our own plug-ins, which also work on Konga.

conclusion

The official recommendation is to use the formal adaptation plug-in of Kong Custom Resources, but modification is not supported. Therefore, I recommend konga + Kong Admin API, which not only reduces our burden of understanding, but also facilitates specific operation.

There are some bugs in Konga and some Plugin fields cannot be correctly resolved, so we still need to rely on Kong Custom Resources.

There are many free plug-ins, and we won’t cover them all, but we’ll also provide examples of custom plug-ins later.