Advanced Log Management

Use LogDNA to manage your running application’s logs

In IBM Garage Method, one of the Operate practices is to automate application monitoring, including logging. Imagine your application isn’t working right in production even though the environment is fine. What information would you want in your logs to help you figure out what’s wrong with your application? Build logging messages for that information into your application.

Given that your application is logging, as are lots of other applications and services in your cloud environment, these logs need to be managed and made accessible. LogDNA adds log management capabilities to a Kubernetes cluster and its deployments. The Developer Environment includes an IBM Log Analysis with LogDNA service instance configured with a LogDNA agent installed in the environment’s cluster. Simply by deploying your application into the Developer Environment, LogDNA collects the logs, just open the LogDNA web UI from the IBM Cloud dashboard to browse your application’s logs.

LogDNA log management

IBM Log Analysis with LogDNA explains how to configure and use an instance of the LogDNA service, but the Developer Environment has already done this for you. You can skip these steps about provisioning an instance, installing an agent, and user access.

LogDNA dashboard

Open the LogDNA web UI for your environment’s cluster

IBM Log Analysis with LogDNA: Viewing logs explains how to open the web UI
In the IBM Cloud dashboard, navigate to Observability > Logging
Find the logging instance named after your environment’s cluster, such as showcase-dev-iks-logdna. To help find it, you can filter by your resource group.
In the logging instance, press the View LogDNA button to open the LogDNA web UI

Give it a try

Before you start to understanding how to look at your application logs, make sure you have deployed an app into your development cluster. Each of the template apps has a logging framework included, this Git it a Try will use template-node-typescript as an example.

The LogDNA service is already created, bound and configured to listen to logs from your development cluster.

Open the **LogDNA instance that is named the same as your development cluster
Click on All Apps and enter the name of your app or narrow the app selection using the suffix that you used to create it
Select the app you want to monitor
You will now see just the logs for your app

Add some logging to your app

All the common logging frameworks support the ability publish different types of log statement. The developer can use the log level to help trap specific information or error conditions. The common log levels are info, debug, warn and fatal. It is best practice to add log statements to help operations teams and monitoring services to help identify possible issues quickly.

Add the following debug statement and error condition to the greetings implementation in your app.


  async greeting(name: string = 'World'): Promise<string> {
    this.logger.info(`Generating greeting for ${name}`);
    this.logger.debug('This is a debug message from inside my API');
    // Only Trigger error if the name passed in matches ERROR
    if (name === 'ERROR' ) {
        try {

Now that we have introduced some debug messages, let’s adjust the log level for the application.

To add LOG_LEVEL settings to you app, edit the deployment.yaml in your chart folder and add the following debug value to the LOG_LEVEL env property

-env:
    name: LOG_LEVEL
    value: debug

Test the app changes locally first before deploying
```
npm run start
```
Push your changes back to your server repo and wait for your CI pipeline to complete build and deploy
Open up the LogDNA console and narrow the logs to just your app
Open the app into a browser: Run igc ingress -n {your namespace} and select your running app
Switch to HTTPS and test the /hello/{name} API and pass in some data. You have introduced a DEBUG message and an ERROR into this API logic. Click the Execute button a few times to simulate some API calls.
Try the API with your own name, and you will see just the DEBUG message appearing
Try the API with ERROR as the name , and this will trigger the error code we put in the API service
You will see the errors appearing in LogDNA triggered by your application

Try scaling you pods for the app and calling the API again and come and watch the logs and see where the API call is being routed and which pod is triggering the error

There is lots more information around how to use LogDNA, these links will help:

Conclusion

It’s important to be able to manage the logs of your deployed applications to help identify issues and quickly understand how to resolve them. The Developer Tools configures LogDNA directly to you development cluster to make it easy to get the log you data you need as a developer. Just deploy your application into your Developer Environment and its logs start appearing automatically, open the LogDNA web UI and browse your logs.

Edit this page on GitHub

Cloud-Native Advanced: Advanced Monitoring

Resources: Code Patterns Overview