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
This configures the LogDNA agent on every worker (node) in a cluster:
To confirm the successful creation of LogDNA agent on every worker node in the cluster, run the following command:
kubectl get pods
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:
After installing Vegeta, run the following command:
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.
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.,):
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.
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:
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.
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