Log Collection

The application logs are very important for users to find and locate problems especially in production environment. This doc will introduce how to use loki addon to collecting application logs and analysis them.

Log Collection - 图1tip

This section will more likely to introduce how to collect and analysis logs. If you just want to get real time logs from application for debug, you can just use vela logs command or check it on UI console provided by velaux addon.

We need to enable the loki and grafana addon for this capability.

The loki addon can be enabled in two modes:

  • Collecting application logs by specify trait, this is the default behavior when enabling log collection.
  • Collecting all applications logs from container stdout.

To make this mode work, you need to enable loki addon by setting parameter agent=vector:

  1. vela addon enable loki agent=vector

Log Collection - 图2caution

When enable loki addon without the agent parameter, no log collector will be enabled, only loki service deployed.

After this addon enabled with agent=vector, a loki service will be deployed in the control plane as a log store, and a log collection agent vector will be deployed as daemon for all nodes of each current managed clusters.

Log Collection - 图3note

If you want to specify the clusters, you can specify the clusters parameter when enabling addon. When new cluster joined, you need to enable this addon once again to install on these newly joined ones.

Finally, you will get the following traits for log collection.

  • file-logs
  • stdout-logs

One application needs to configure above trait to make the log collected. These traits can also support configuring the vector VRL configuration to perform specific parsing method on the log content. The following chapters will introduce this part in detail.

  1. vela addon enable loki agent=vector stdout=all

After the addon enabled with stdout=all, the vector agent will collect all stdout logs of application pods automatically. No additional traits need to be configured. The collected logs will be delivered to the loki service in the control plane cluster for storage.

Log Collection - 图4caution

The most advantage of this mode is that all logs configuration is simple and automatic, while the disadvantage are:

  1. Collecting all running pods will cause a lot of pressure on the loki service when there are too many applications. On the one hand, not all logs are needed, it can waste disk storage a lot. On the other hand, the vector agents of each cluster need to transmit the collected logs to control plane cluster, which will consume lots of network bandwidth.
  2. The full collection mode can only collect logs in a unified way, and no special log parsing can be done on different applications.
  1. vela addon enable grafana

Log Collection - 图5caution

Even if you have enabled the grafana addon as described in the “Automated Observability Documentation”, you still need to re-enable the addon to register the loki data source to grafana.

After the loki addon enabled, a component will be installed in each cluster, which is responsible for collecting Kubernetes events and converting them to logs transmit to loki. You can also view and analyze the events of the system through the Kubernetes events dashboard in the grafana addon.

event-log

Details

KubeVela Events dashboard

  1. ---
  2. **Kubernetes Event overview** Displays the number of latest Kubernetes events in each time period of the system.
  3. ---
  4. **Warning Events** The number of `Warning` type events.
  5. ---
  6. **Image Pull Failed/Container Crashed .../Pod Evicted** The number of events that indicate application failures, such as image pull failure and pod eviction in the last 12 hours.
  7. ---
  8. **TOP 10 Kubernetes Events** Top 10 types of events with the highest number of occurrences in the last 12 hours.
  9. ---
  10. **Kubernetes Events Source** Pie chart of the controllers producing these events.
  11. ---
  12. **Kubernetes Events Type** Pie chart of involved resource object types of events.
  13. ---
  14. **Kubernetes Live Events ** The recent event logs.

As mentioned above, if you’re not enable the stdout full collection mode, you can collect stdout logs by specify trait.

Configure the stdout-logs trait in the component, as follows:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: app-stdout-log
  5. namespace: default
  6. spec:
  7. components:
  8. - type: webservice
  9. name: comp-stdout-log
  10. properties:
  11. image: busybox
  12. traits:
  13. - type: command
  14. properties:
  15. command:
  16. - sh
  17. - -c
  18. - |
  19. while :
  20. do
  21. now=$(date +"%T")
  22. echo "stdout: $now"
  23. sleep 10
  24. done
  25. - type: stdout-logs

After the application is created, you can find the deployment resource created by the application in the application dashboard of grafana, click Detail button to jump to the deployment resource dashboard, and find the log data below. as follows:

normal-log

If your application is an nginx gateway, the stdout-logs trait provide the capability to parse nginx combined format log to json format as follows:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: nginx-app-2
  5. spec:
  6. components:
  7. - name: nginx-comp
  8. type: webservice
  9. properties:
  10. image: nginx:1.14.2
  11. ports:
  12. - port: 80
  13. expose: true
  14. traits:
  15. - type: stdout-logs
  16. properties:
  17. parser: nginx

Then a special nginx access log analysis dashboard will be generated as follows:

nginx-log

Details

KubeVela nginx application dashboard

  1. ---
  2. **KPI's** Contains the gateway's core key metrics, such as total request traffic in the last twelve hours, and percentage of 5xx requests.
  3. ---
  4. **HTTP status statistic** Statistics of the number of requests for each request code.
  5. ---
  6. **Top Request Pages** Statistics of the most visited pages.

You can also set customize parse configuration for your application log in this trait. As follows:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: nginx-app-2
  5. spec:
  6. components:
  7. - name: nginx-comp
  8. type: webservice
  9. properties:
  10. image: nginx:1.14.2
  11. ports:
  12. - port: 80
  13. expose: true
  14. traits:
  15. - type: stdout-logs
  16. properties:
  17. parser: customize
  18. VRL: |
  19. .message = parse_nginx_log!(.message, "combined")
  20. .new_field = "new value"

In this example, we transform nginx combinded format logs to json format, and adding a new_field json key to each log, the json value is new value. Please refer to document for how to write vector VRL.

If you have a special log analysis dashboard for this processing method, you can refer to document to import it into grafana.

The loki addon also support to collect file logs of containers. It doesn’t matter with which mode you’re enabling the loki addon, it works for all modes. Use the trait as follows:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: app-file
  5. namespace: default
  6. spec:
  7. components:
  8. - type: webservice
  9. name: file-log-comp
  10. properties:
  11. image: busybox
  12. traits:
  13. - type: command
  14. properties:
  15. command:
  16. - sh
  17. - -c
  18. - |
  19. while :
  20. do
  21. now=$(date +"%T")
  22. echo "file: $now" >> /root/verbose.log
  23. sleep 10
  24. done
  25. - type: file-logs
  26. properties:
  27. path: /root/verbose.log

In the example, we let business log of the my-biz component write to the /data/daily.log path in the container. After the application is created, you can view the corresponding file log results through the deployment dashboard.

Log Collection - 图9tip

It should be noted that the logs that need to be collected mustn’t is in the root directory of the container, otherwise it may cause the container to fail to start.

Last updated on Aug 4, 2023 by Daniel Higuero