their very own monitoring system. • Developers should not worry about monitoring. This was supposed to be "IT stuff". • Architecture was deemed OK if all systems were showing green. • Monitoring systems were not standard. Each system could potentially use a different vendor. @riferrei @jeeconf
to transactions of one application. • Metrics: Statistics and numeric measures aggregated by time. • Distributed Tracing: complete view of what happened within a single transaction. It answers: ◦ Which services were involved? ◦ If it was slow, who caused that? ◦ If failed, who actually failed? @riferrei @jeeconf
available. • Standards are getting created to ensure a single programming model for each μService. • Deployment mechanisms such as Kubernetes are also taking care of that automatically. • Network proxies such as Service Meshes are also handling this. @riferrei @jeeconf
facto standard to handle data. • Prediction? It will be the central nervous system of any company. • μServices in general already use Kafka to exchange messages and keep their data stores in-sync. • With event streaming becoming even more popular, the Kafka adoption tend to grow even more. @riferrei @jeeconf
your Java code with Kafka • Trace producers and consumers • Decorators and Interceptors API • Pluggable tracers via classpath via the tracer resolver library. • Dense documentation available. https://github.com/opentracing-contrib/java-kafka- client @riferrei @jeeconf
tracing in JVM-based applications that you don't have the source-code. • Examples: REST Proxy, Kafka Connect and KSQL Servers. • Allows you to group μServices based on the topics they use. https://github.com/riferrei/jaeger-tracing-support @riferrei @jeeconf