Microservices Observability

With microservice architecture, the communication between services can become quite complex.

Let's say that there are multiple calls chains between your services, but something is not going well, so you'd like to debug. How would you find out where the defect is? And how would you know what's going on in general during a specific request?

The answer to these questions is one of the most important things during the implementation of a microservice architecture, the observability!

Transcript

1. Microservices Observability
2. About us I am Tiago Angelo Software Engineer at Sensedia Working mostly with: - Java - RESTful APIs - Microservices - Container applications in production @kurtisangelo on Twitter /angelokurtis on GitHub 2
3. whoami! I am Claudio de Oliveira Book Author, Software Architect and Developer @sensedia Spring and Docker enthusiast @claudioed on Twitter /claudioed on Github 3
5. 5 Agenda › Microservices drawbacks › Distributed tracing systems › Spring Cloud Sleuth › Metrics for distributed systems › Kubernetes and Istio
6. 6 Glossary › Telemetry How to collect data that will provide observability (sensors) › Observability Monitoring, Alerting and Visualizations, Distributed Tracing and Log Aggregation.
7. MICROSERVICES DRAWBACKS Not all roses 7
8. Fallacies of distributed computing › the network is reliable › latency is zero › bandwidth is infinite 8
9. Microservices Drawbacks › How microservices connect each other › Network Latencies can be a bottleneck › Network can be unreliable › Control the UP and Running instances › It increase the non-functional requirements 9
10. your system doesn't look like this: 10 service1 service2 service4 service3 frontend DB
11. ...it looks more like this: 11 frontend ... Service1 10.0.0.11 service1 10.0.0.34 Service1 10.0.0.36 Service1 10.0.0.23 service1 10.0.0.4 service2 10.0.0.40 Service2 10.0.0.25 Service3 10.0.0.1 service3 10.0.0.17 Service3 10.0.0.7
13. Network Latency Problems › Which microservice was responsible? › How to find out where the defect is? › How know what is generally happening during a request? 13
14. The OpenTracing standard › Cloud Native Computing Foundation (CNCF) › it standardizes the instrumentation of applications for distributed tracing › its says a trace tells the story of a transaction › while a span represents a single call › distributed tracing systems collect and organize all this information in a nice interface and Zipkin is one of them 14
15. In the Java World 15 › the distributed tracing systems needs trace and span unique IDs › Tracers are responsible to add that logic to your application › Spring Cloud Sleuth for Java-based Spring applications
16. SPRING CLOUD SLEUTH Services interactions instrumented automatically 16
17. Features › Adds trace and span ids to the SLF4J Mapped Diagnostic Context (MDC) › Automatically instruments common ingress and egress points from Spring applications (servlet filter, rest template, feign client) › just add spring-cloud-sleuth-zipkin dependency and the service will generate and send traces to Zipkin via HTTP 17
18. Your log will be like this: 18 Trace id Span id Application name
19. 19 Stop talking and show me the code!
21. 21 intro
22. Let’s think a little bit differently... 22 intro
23. Key points for kubernetes › Kubernetes was designed to orchestrate containers and run container across multiple machines Yaml files for deployments and other stuffs 23 intro
24. Pretty Standard Kubernetes yamls 24 intro
25. What about the platform infrastructure for service communications ??? 25 YES!!! intro
26. And... no code changes at all !!!! 26 intro
27. 27 intro
28. But before, we need to learn some new concepts... 28 intro
29. Sidecar Pattern 29
30. Sidecar Pattern A service which can enrich the main service with utility tasks. Normally these tasks are cross-cutting and infrastructure related. 30 sidecar-pattern
31. 31 sidecar-pattern
32. › Proxying to remote services › Monitoring › Configuring › Telemetry Main Features 32 sidecar-pattern
33. A service mesh is a configurable infrastructure layer for a microservices application. Service Mesh 33 service-mesh
34. 34 We choose... ISTIO service-mesh
35. Goal › Service Mesh was designed to be that would handle the service communications 35 service-mesh
36. This approach can give us some advantages › We can take off some responsibilities from our microservices › Ribbon, Hystrix, Metrics and Tracer (OSS) › The platform can provide it for us 36
37. 37 Istio Advantages › Sidecar Proxy › Service Discovery & Load Balancing › Circuit Breaking › Fault Injection › Polyglot (golang, nodejs) it run as a sidecar › Can be used in legacy systems
38. 38 Istio Deployment
39. 39 istio
40. PILOT Component that programs the Envoy proxies, responsible for service discovery, load balancing, and routing. 40 istio
41. 41 MIXER Component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from Envoy and other services istio
42. 42 ISTIO ADD-ONs Open-Source components which will work together to provide some functionalities istio
43. 43 Prometheus Monitoring and Alerting systems toolkit designed to help these tasks for distributed systems. METRICS please, not logging and tracing istio-add-ons
44. Monitoring and troubleshooting microservices-based distributed systems 44 Jaeger istio-add-ons
45. Platform for beautiful analytics and monitoring 45 Grafana istio-add-ons
50. THANKS! Any questions? You can find us at: @claudioed · claudioed.oliveira@gmail.com @kurtisangelo · kurtis.angelo@gmail.com 50