Monitoring Custom Metrics on AOM

Constraints

• The ICAgent is compatible with the monitoring data specifications of Prometheus. The custom metrics provided by pods can be collected by the ICAgent only when they meet the monitoring data specifications of Prometheus. For details, see Prometheus Monitoring Data Collection.
• The ICAgent supports only Gauge metrics.
• The interval for the ICAgent to call the custom metric API is 1 minute, which cannot be changed.

Prometheus Monitoring Data Collection

Prometheus periodically calls the metric monitoring API (/metrics by default) of an application to obtain monitoring data. The application needs to provide the metric monitoring API for Prometheus to call, and the monitoring data must meet the following specifications of Prometheus:

# TYPE nginx_connections_active gauge
nginx_connections_active 2
# TYPE nginx_connections_reading gauge
nginx_connections_reading 0

Prometheus provides clients in various languages. For details about the clients, see Prometheus CLIENT LIBRARIES. For details about how to develop an exporter, see WRITING EXPORTERS. The Prometheus community provides various third-party exporters that can be directly used. For details, see EXPORTERS AND INTEGRATIONS.

Preparing an Application

User-developed applications must provide a metric monitoring API, and the monitoring data must comply with the Prometheus specifications. For details, see Prometheus Monitoring Data Collection.

This section uses Nginx as an example to describe how to collect monitoring data. There is a module named ngx_http_stub_status_module in Nginx, which provides basic monitoring functions. You can configure the nginx.conf file to provide an interface for external systems to access Nginx monitoring data.

1. Log in to a Linux VM that can access to the Internet and run Docker commands.
2. Create an nginx.conf file. Add the server configuration under http to enable Nginx to provide an interface for the external systems to access the monitoring data.

   user  nginx;
   worker_processes  auto;
   
   error_log  /var/log/nginx/error.log warn;
   pid        /var/run/nginx.pid;
   
   events {
       worker_connections  1024;
   }
   
   http {
       include       /etc/nginx/mime.types;
       default_type  application/octet-stream;
       log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                         '$status $body_bytes_sent "$http_referer" '
                         '"$http_user_agent" "$http_x_forwarded_for"';
   
       access_log  /var/log/nginx/access.log  main;
       sendfile        on;
       #tcp_nopush     on;
       keepalive_timeout  65;
       #gzip  on;
       include /etc/nginx/conf.d/*.conf;
   
       server {
         listen 8080;
         server_name  localhost;
         location /stub_status {
            stub_status on;
            access_log off;
         }
       }
   }

3. Use this configuration to create an image and a Dockerfile file.

   vi Dockerfile

   The content of Dockerfile is as follows:

   FROM nginx:1.21.5-alpine
   ADD nginx.conf /etc/nginx/nginx.conf
   EXPOSE 80
   CMD ["nginx", "-g", "daemon off;"]

4. Use this Dockerfile to create an image and upload it to SWR. The image name is nginx:exporter.
   1. In the navigation pane, choose My Images. In the upper right corner, click Upload Through Client. In the displayed dialog box, click Generate a temporary login command. Then, click to copy the command.
   2. Run the login command copied in the previous step on the node. If the login is successful, the message "Login Succeeded" is displayed.
   3. Run the following command to build an image named nginx. The image version is exporter.

      docker build -t nginx:exporter .

   4. Tag the image and upload it to the image repository. Change the image repository address and organization name based on your requirements.

5. View application metrics.
   1. Use nginx:exporter to create a workload.
   2. Access the container and use http://<ip_address>:8080/stub_status to obtain nginx monitoring data. <ip_address> indicates the IP address of the container. Information similar to the following is displayed.

      # curl http://127.0.0.1:8080/stub_status
      Active connections: 3 
      server accepts handled requests
       146269 146269 212 
      Reading: 0 Writing: 1 Waiting: 2

Deploying Applications and Converting Nginx Metrics

The format of the monitoring data provided by nginx:exporter does not meet the requirements of Prometheus. Convert the data format to the format required by Prometheus. To convert the format of Nginx metrics, use nginx-prometheus-exporter, as shown in the following figure.

Figure 2 Using exporter to convert the data format

Deploy nginx:exporter and nginx-prometheus-exporter in the same pod.

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx-exporter
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-exporter
  template:
    metadata:
      labels:
        app: nginx-exporter
      annotations:
        metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"prometheus","path":"/metrics","port":"9113","names":""}]'
    spec:
      containers:
        - name: container-0
          image: 'nginx:exporter'  # Replace it with the address of the image you uploaded to SWR.
          resources:
            limits:
              cpu: 250m
              memory: 512Mi
            requests:
              cpu: 250m
              memory: 512Mi
        - name: container-1
          image: 'nginx/nginx-prometheus-exporter:0.9.0'
          command:
            - nginx-prometheus-exporter
          args:
            - '-nginx.scrape-uri=http://127.0.0.1:8080/stub_status'
      imagePullSecrets:
        - name: default-secret

The nginx/nginx-prometheus-exporter:0.9.0 image needs to be pulled from the public network. Therefore, a public IP address needs to be bound to each node in the cluster.

nginx-prometheus-exporter requires a startup command. nginx-prometheus-exporter -nginx.scrape-uri=http://127.0.0.1:8080/stub_status is used to obtain Nginx monitoring data.

In addition, add an annotation metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"prometheus","path":"/metrics","port":"9113","names":""}]' to the pod.

Verification

After an application is deployed, you can access Nginx to construct some access data and check whether the corresponding monitoring data can be obtained in AOM.

1. Obtain the pod name of Nginx.

   $ kubectl get pod
   NAME                              READY   STATUS    RESTARTS   AGE
   nginx-exporter-78859765db-6j8sw   2/2     Running   0          4m

2. Log in to the container and run commands to access Nginx.

   $ kubectl exec -it nginx-exporter-78859765db-6j8sw -- /bin/sh
   Defaulting container name to container-0.
   Use 'kubectl describe pod/nginx-exporter-78859765db-6j8sw -n default' to see all of the containers in this pod.
   / # curl http://localhost
   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   html { color-scheme: light dark; }
   body { width: 35em; margin: 0 auto;
   font-family: Tahoma, Verdana, Arial, sans-serif; }
   </style>
   </head>
   <body>
   <h1>Welcome to nginx!</h1>
   <p>If you see this page, the nginx web server is successfully installed and
   working. Further configuration is required.</p>
   
   <p>For online documentation and support please refer to
   <a href="http://nginx.org/">nginx.org</a>.<br/>
   Commercial support is available at
   <a href="http://nginx.com/">nginx.com</a>.</p>
   
   <p><em>Thank you for using nginx.</em></p>
   </body>
   </html>
   / #

3. Log in to AOM. In the navigation pane, choose Monitoring > Metric Monitoring to view Nginx-related metrics, for example, nginx_connections_active.