Microservices - Service Observability

Microservices - Service Observability

In Microservices context, Services are observable if we can collect their metrics, see their logs, analyze their tracing information, and finally getting required services’ alerts.

Some of the observability requirements are provided by the cloud platform where Microservices are deployed, for example metrics, logging, and alerts are common capabilities in most kubernetes based Cloud platforms including Red Hat openshift, where tools like Prometheus, Grafana, Hawkular, Elasticsearch are openshift core components.

Yet tracing is still missing and this is why in most Microservices implementations observability directly maps to tracing where services owners request clear visibility about where services calls are going.

While the first three need not to be considered while developing Microservices, tracing has to be considered and it has its on impact on developing Microservices. Tracing requires code instrumentation where developers mark their code before every trace request and then mark it again towards the end of each scope, creating what is called trace span, the span is a data structure stores all what happens between the trace start and end marks (span is a tracing unit of work).

Tracing makes sense where it expands across different Microservices, and this is why spans can reference other spans, can spawn other spans, and can be children to other parent spans.

There are two code instrumentation methods

1 - Explicit, where developers need to inject tracing code inside the services.

2 - Implicit, enable tracing without extra code, for example some frameworks allow change java bytecode on runtime where other frameworks are already instrumented so whenever developers use them to build new Microservices, Those services become tracing ready and this usually happens through configuration like JAX-RS and CDI tracing in Spring framework that require nothing but adding some dependencies in your POM file.

Red Hat openshift provides all the above and more through Istio - its service mesh platform, Istio is shipped with Kiali and Jaeger.

Kiali provides answers to the questions: What microservices are part of my Istio service mesh and how are they connected? While Jaeger provides the monitoring and troubleshooting of all  transactions within Istio service mesh.

learn.openshift.com provides very interesting interactive tutorial for Istio - https://learn.openshift.com/servicemesh/ - including Kiali scenario that can be directly launched on https://learn.openshift.com/servicemesh/adv1-kiali URL.

To view or add a comment, sign in

More articles by Wael Eldoamiry

Others also viewed

Explore content categories