Building microservices using IBM CloudPaks as amateur developer 2/5
Tags: Openshift 4, Microservices, Logging, Microservice Architecture

Building microservices using IBM CloudPaks as amateur developer 2/5 Chechu Follow Sep 12 · 4 min read

Microservices Logging in Openshift

This is the second article of a set of 5 about how to code microservices using IBM CloudPaks:

1.Leveraging Kabanero 2. MicroServices logging in OpenShift 3. Working with ServiceMesh and Microservices 4. Async Communication for Microservices with IBM Event Streams and IBM MQ (Kafka and MQ) 5. Microservices reliability across Kubernetes clusters with IBM MultiCloud Manager

In the first article, I built an app following a microservice architecture, but it can be a nightmare to debug that application, in a multi-user scenario by leveraging the native logging system. As we introduced a more “dispersed” architecture, tracing a request through the different microservices can get complicated, especially with a multi-user deployment. As we need to identify each “thread’s” progression through the microservices, we will need a method to identify each “thread”. Let's review the app and see my approach to solve this problem looking at the logs dropped.

Microservices Application Topology

Microservice App Architecture

Looking at one “thread” progression, for example on the management page load request:

Looking at even this simple app running in a multi-user scenario, it is apparent that a lot of log entries will be generated for the same transaction without any context to identify the user who generated the log entry, making it impossible to quickly diagnose an issue.

In order to address this challenge, I created my own solution based on the Mapped Diagnostic Context instead of the logging framework.

Here is an outline of my solution:

In a nutshell, the UI (React microservice) creates a unique ID, that is attached to each request that a transaction generates, together with the respective username.

In my local development with Appsody, we can see the following:

The schema I used for the logs is the following:

reqID: “16de6c53–7279–467f-b689-dd9c03ca8d6b”

user: “admin@chechu.com”

status: “successful”

service: “auth”

message: “(/api/users/login) — User Login: admin@chechu.com SUCCESS”

Using ReqID and user I can trace the progress of a transaction across all microservices. The other keys will identify the respective microservice, the status, and a detailed message.

The code added is in this repos:

- UI : React portal using IBM Carbon Design

- APIGW : API gateway to expose the backend microservices to the React portal

- Auth: Authentication microservice to validate users accessing backend microservices are logged.

- Management: Microservice that manages the creation of the courses.

- K8sManager: Microservice that manage the creation of the workspaces on Openshift and the Linux VM (to run ‘oc’ commands)

*** Each article’s code is hosted in a branch on this repo, with the Master branch hosting all the modifications across the 5 articles.

Once we push the new code to our repos, the pipelines described in the previous article will start to deploy the new pods. If the Openshift cluster has the logging operator installed we can use Kibana to see the logs and filter them. The example below shows a flow of ‘user login’ and selects a ‘course’, which retrieves or creates a workspace.

And if we filter by the “reqID”: “bb696da4-e3e7–4dd5–9860–578a80ea2bcd”, we can trace the progress of the request through the microservices.

Wrap Up

Following the Mapped Diagnostic Context presented above, we can implement a “distributed tracing” microservice pattern, explained here. This facilitates debugging a transaction that spans across different microservices. This becomes critical as the topology gets more dispersed.

If you find this helpful you might want to take a look at the next article of the series — Working with ServiceMesh and Microservices— (to be published on September 21st).