Knative Log Analysis with LogDNA on IBM Cloud

Compute Open source

10 January 2019

By: Vidyasagar Machupalli

IBM Log Analysis with LogDNA

In this post, I’m going to show you how to use the IBM Log Analysis with LogDNA service to configure cluster-level logging for an app named Knative-node-app published in the IBM Cloud Kubernetes Service. If you haven’t deployed an app on Knative before, please read this post: “Install Knative with Istio and Deploy an App on IBM Cloud.” (Remember to choose the default Kubernetes version while creating the cluster.)

IBM Log Analysis with LogDNA offers administrators, DevOps teams, and developers advanced features to filter, search, and tail log data, define alerts, and design custom views to monitor application and system logs.

From the moment you provision a cluster with IBM Cloud Kubernetes Service, you probably want to know what is happening inside the cluster. You need to access logs to troubleshoot problems and preempt issues. At any time, you want to have access to different types of logs, such as worker logs, pod logs, app logs, or network logs. In addition, you can monitor different sources of log data in your Kubernetes cluster. Your ability to manage and access log records from any of these sources is critical. Your success in managing and monitoring logs depends on how you configure the logging capabilities for your Kubernetes platform.

Provision an IBM Log Analysis with LogDNA instance and Configure the LogDNA agent

Before provisioning the instance, check the Prerequisites.

Once you have the app running on the Knative Kubernetes Cluster, provision an instance of the IBM Log Analysis with LogDNA service:

Choose a region/location (us-south).
Select a resource group.
Select an appropriate plan (7-day Log Search recommended for this post).
Click Create. With this step, you configure a centralized log management system where log data is hosted on IBM Cloud.

Configure your Kubernetes cluster to send logs to your LogDNA instance

Once the service is provisioned under https://cloud.ibm.com/observe/logging, click on Edit log sources and then click Kubernetes.

Observability on IBM Cloud

You should see two commands to automatically install a logdna-agent pod on each node of your cluster:

kubectl create secret generic logdna-agent-key --from-literal=logdna-agent-key=<INGESTION_KEY>

kubectl create -f https://repo.logdna.com/ibm/prod/logdna-agent-ds-us-south.yaml

This configures the LogDNA agent on every worker (node) in a cluster:

LogDNA agent on K8s Cluster sending logs to IBM Log Analysis with LogDNA

To confirm the successful creation of LogDNA agent on every worker node in the cluster, run the following command:

kubectl get pods

kubectl commands on IBM kui tool

Launch the LogDNA dashboard and view logs

Let’s check and search the logs and create some graphs by clicking View LogDNA. On a new tab, Under Everything, you should start seeing all the logs in real-time.

For this, we need to generate some traffic/load and there are many open source libraries/tools available. In the post, we will be using Vegeta, an HTTP load-testing tool and library. You can also use hey.

Before generating the load, let’s quickly check whether the IP_ADDRESS and HOST_URL are set properly while deploying the app:

echo $IP_ADDRESS
echo $HOST_URL

After installing Vegeta, run the following command:

echo "GET http://${IP_ADDRESS}" | vegeta attack -duration=300s -header "Host: ${HOST_URL}" | tee results.bin | vegeta report
 vegeta report -type=json results.bin > metrics.json
 cat results.bin | vegeta plot > plot.html
 cat results.bin | vegeta report -type="hist[0,100ms,200ms,300ms]"

You can open the plot.html file in the folder you have run the above command to see the Vegeta plot:

On the LogDNA dashboard, you can search/filter for various fields in the search box and also highlight the terms you are interested in. You can also save this as a View as a bookmark by clicking on Unsaved View.

LogDNA dashboard

For archiving logs to IBM Cloud Object Storage, refer this link.

You can filter the logs by tags, sources, Apps, and Levels (info, error etc.,):

Filtering the logs

Boards and graphs

A board is a named collection of graphs and is similar to a view. All boards are located in the Boards List and may contain any number of graphs. Changes made to a board are automatically saved.

To create a new board, on the left pane , click on the icon below the dashboard and click +NEW BOARD. Let’s call this knative-board.

Click on +Add Graph.
Select destinationApp as the field to graph.
Choose knative-node-app-00001 as the optional value and click Add graph.

New graph creation

A new graph will be created with a plot of destinationApp over a period of 24 hours (feel free to change the timeframe). You can also add a new plot by clicking +Add Plot below the graph:

knative-board with multiple graphs

As Knative is known for its autoscaling capabilities, let’s see how the autoscaler behaves with incoming traffic/requests by adding a new graph as shown in the image above.

Knative Serving Autoscaler is another Kubernetes Deployment running a single Pod that watches request load on the Pods running user code. It increases and decreases the size of the Deployment running the user code in order to compensate for higher or lower traffic load.

Additionally, as an extension to the graphs you created, you can see the breakdown (a histogram) of various fields like nodes, destinationNames, etc., by clicking on the arrow below the graph and +Add. You can create multiple breakdowns.