TRANSPARENT TRACING SYSTEM ON GRPC BASED MICROSERVICE APPLICATIONS RUNNING ON KUBERNETES
With the increasing use of distributed system-based applications, the demand for tracing system as debugging tools for respective system also increases. Specifically, on Kubernetes environment, tracing on microservice-based systems is not an easy task due to the heterogeneity of the architecture....
Saved in:
| Main Author: | |
|---|---|
| Format: | Final Project |
| Language: | Indonesia |
| Online Access: | https://digilib.itb.ac.id/gdl/view/49902 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Institution: | Institut Teknologi Bandung |
| Language: | Indonesia |
| Summary: | With the increasing use of distributed system-based applications, the demand for tracing
system as debugging tools for respective system also increases. Specifically, on Kubernetes
environment, tracing on microservice-based systems is not an easy task due to the
heterogeneity of the architecture. gRPC provides a more performant way to communicate
between microservice. This leads to a need of a tracing system that are transparent with respect
to the applications that supports gRPC as its main communication protocol to ease the use of
tracing on heterogeneous environment. The approach used to achieve transparency is passive
tracing. Passive tracing requires the system to perform tracing without any modifications to the
application or the application runtime. This system implements passive tracing by performing
packet interception on every packet sent by the application, recording the gRPC request data,
and writing the trace data to a log. The resulting log will be stored in Elasticsearch and
visualized using Kibana for further analysis. The implementation of this system adds an
average overhead CPU usage of 8.8% with Elastic stack and 3.5% without Elastic stack and
memory usage of 959 MB with Elastic stack and 378 MB without Elastic stack. In addition,
61.9% of the actual request successfully traced using this system. This implementation
successfully traces transparently, but the log-based approach makes the system unable to trace
recursively. This results request causality will not be known. This means the trace results can
only produce metadata for each request without knowing the relationship of one request with
another. Furthermore, the absence of request causality results an inaccurate number of the
success rate of the trace due to matching can only be done by service name and method without
the context of each request.
|
|---|