DEV Community

Vidyasagar Machupalli
Vidyasagar Machupalli

Posted on • Originally published at Medium on

Knative Log analysis with LogDNA on IBM Cloud

In this post, you will learn how to use the IBM Log Analysis with LogDNA service to configure cluster-level logging for an app named Knative-node-app published in IBM Cloud Kubernetes Service. Refer this post - Install Knative with Istio and deploy an app on IBM Cloud, to setup a nodejs app.

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 wish to know what is happening inside the cluster. You need to access logs to troubleshoot problems and pre-empt 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. Therefore, your ability to manage and access log records from any of these sources is critical. Your success 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

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
  • 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 below 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 also create some graphs by clicking View LogDNA. On a new tab , Under Everything , you should start seeing all the logs in realtime.

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 $HOST_URL

After installing Vegeta, run the below command

echo “GET [http://${IP_ADDRESS](http://%24%7BIP_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 — another k8s Deployment running a single Pod which 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 > +Add. You can create multiple breakdowns.

Worker Nodes information

We have just touched the tip of the iceberg and there are many fields/metrics to look out for. Explore the tool with different load and filters.

Questions or concerns? Post a question or Reach out on Twitter @ VidyasagarMSC

Further reading

Top comments (0)