As a developer, we add logs to trace the issues and understand the flow of the code, but the fundamental benefit of having a logger is to get more tracing details to track the request execution.
Here we will go through the log observability details and tools which make tracing easier for the microservice architecture services.
Why do we need to monitor application logs?
Monitoring the logs is a fundamental process to help in identifying the memory leaks, application errors/issues and alert the development team to take immediate action.
Why do we need one more observability when we have a log monitor? Monitoring VS Observability?
Monitoring the logs may provide the detailed execution of the request, but it does not help in analyzing the factored mentioned below.
- What was the execution span interval of each method involving the operation?
- How many system resources were used for the execution of the request?
Developers were not worried much about the observability data initially because applications were monolithic, it was easy to trace the request execution and log tracing. But with microservice, it's not that simplified why to identify the request execution because it involves a lot of services for the single request execution.
Distributed log tracing is the mechanism involved in request execution in a microservice architecture system.
How Does distribution log tracing works?
Typically distributor logs tracer tools like Jaeger, Zipkin agents will intercept the request header log data with the unique Id and maintain that id in all the child chain requests in the other service and maintain the tracing of the request execution.
What is Observability data? What is OpenTelemetry?
Observability data will contains the fundamental data structure which can be presented to get the desired details for analysis and presentation.
Observability data structure:
- Tracing data.
- Context log data
- Metric data
OpenTelemetry is the open-source library that provides the APIs and SDK for the observability instrument data of the application and its combined product of the previously known open source tools.
OpenCensus + OpenTracing = OpenTelemetry
OpenTelementry support almost all languages.
- Java
- .Net
- Go
- Python
- NodeJS
OpenTelemetry Architecture
OpenTelemetry support two types of instrument observability data
- Manual Instrumentation.
- Auto Instrumentation.
Manual Instrumentation:
OpenTelemetry provides the SDK and API to collect the observability data manually, where the developer needs to initialize the OpenTelemetry logger and collector i.e., add the span in the respective endpoint for the request tracing.
Auto Instrumentation:
OpenTelemetry supports the auto instrumentation i.e., We do not need to add any code!. The simple configuration to get the observability data of the application.
Generally auto instrumentation work as a master-agent model.
- Agent will be collecting the data and send to the process i.e., as shown in the architecture image,
- The receiver will get the logs data and process the data as per the observability standards and export it to the tools like Jaeger, Zipkin.
OTEL Key Fields:
OpenTelementry provides a certain set of keys for the easy analysis of tracing, a few are listed below.
TraceId: The TraceId associated with the request.
SpanId: Than Span associated with the request.
TraceFlags: W3C trace flag.
Attributes: Additional associated attributes
For more W3C trace details check here
Tracing request span flow:
When the user clicks on the "Pay Now" button, the request transverse through service A to service B, and the request is queued for the further process, here we can see the "Span" request taken in each service transverse.
OpenTelemetry Logger and Metrics:
Logger: logger data will be helpful to trace the request flow, using the Jaeger, Zipkin tool we can visualize the request tracing
Metrics: Metrics data will be helpful to visualize the request rates, CPU utilization, etc. using tools like Prometheus.
*Part - 2: working samples.
*
Top comments (0)