Introduction
In this article, We will discuss our experience deploying Jagger and the challenges we overcame.The purpose of this article is to demonstrate how to quickly deploy Jaeger and explain deployment nuances.
So what is Jaeger and why is it needed on projects and for what tasks is it better to use it?
Jaeger is a distributed tracing system that helps developers monitor and troubleshoot the performance of microservices-based applications. It tracks requests as they move through multiple services, provides a comprehensive view of your application's behavior, and enables you to optimize performance and troubleshoot issues.Jaeger is also useful for release validation, capacity planning, and security and compliance. It is especially well-suited for cloud-native and containerized applications.
As a standard practice, it is common for us to depend on helm charts that are authorized by the manufacturers or reputable libraries such as Bitnami.
In this example, we take the official Jaeger chart:
- helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
- helm install my-jaeger jaegertracing/jaeger --version 0.71.14
It is necessary to configure Jagger in such a way that it is able to store traces in the database while also allowing for the database to grow beyond 80% memory usage. This will require a careful and deliberate approach to ensure that the system is properly configured and optimized for maximum performance. It is important to keep in mind the potential impact of this configuration on the overall system, and to take appropriate measures to ensure that it does not disrupt the normal functioning of other processes or applications. With careful planning and implementation, however, it should be possible to achieve the desired outcome without any significant issues or complications.
For our chart configuration, we added two instances of a Cassandra database. During testing, we encountered an issue with a hotrod format that was meant to send traces to Jager, but we didn't receive any traces. Despite the setback, we persisted and found another application that successfully simulates sending traces, resulting in Jager receiving the necessary information and everything working as intended. It took some time, but we were able to resolve the issue.We concluded that the solutions provided in official charts don't always work. After conducting tests, we have identified the optimal solutions for our database and trace stream.
We will be using two databases with 1 CPU, each with 2 GB of memory and 20 GB of storage.The modifications have been made on the Cassandra chart.Cassandra's chart needs to be included in Jaeger's main chart.
Summarizing
In conclusion, we have successfully implemented a solution for one of our projects. Through this process, we acquired knowledge on how to establish optimal limits for the Jager configuration database that align with our specific requirements. By utilizing Jager in real-world projects, we were able to ensure observability, track requests between microservices, and gain valuable insights into service dependencies and behavior.
