Torch the light - Implementing Observability for Microservice Architectures
0 likes60 views
The document discusses the challenges and strategies of implementing observability (o11y) in cloud-native architectures, emphasizing the importance of data collection for insights into application performance. It outlines various observability levels and the tools, such as Kong and Grafana, that can be utilized for effective monitoring and analysis in both on-prem and cloud scenarios. The conclusion highlights the necessity of integrating o11y from the beginning and using collected data to enhance application understanding and management.
Torch the light - Implementing Observability for Microservice Architectures
- 2. ● O11y Challenges ● Solution strategy ● Use Cases ● Conclusion Agenda
- 4. Cloud-native - the new normal Traditional approach Monolithic architecture Cloud-native approach Microservice architecture
- 5. ● Dynamic infrastructures ● Hybrid/Multi-Cloud scenarios ● Microservices/Serverless architectures ● Containerized application workloads ● Kubernetes as default application runtime ● Automated CI/CD tool chain From centralized application architectures to decentralized ones Architectures become distributed
- 6. Implementing Observability is key to gather needed information Prepare for the unknown ● Goal: Learn as much as possible about your apps ● Collect data about ○ what happens in an app (Logs) ○ how apps are performing (Metrics) ○ how a request is processed (Traces)
- 7. Consistence & efficiency challenge 1 2 3 O11y - levels: (1) Edge (2) App-2-App (3) In-App
- 9. ● Kong Plugins to emit respective data ○ HTTP / TCP Log ○ Prometheus ○ Zipkin ● Kong EE provides more information OOTB (Vitals) ○ # API calls (per API resource) ○ # Errors / Successful requests ○ … ● Gateway might be deployed as ○ Kubernetes Ingress Controller ○ Standalone Gateway (on VM or Bare Metal) Using Kong API Gateway Collecting data at the edge level
- 10. ● Kuma Observability policies are used to emit needed data ○ TrafficLog ○ TrafficMetrics ○ TrafficTrace ● Metrics data can be collected for Data and Control plane ● Insights into Mesh topology with Service Map ● Options for Mesh Gateway ○ Kong ○ Kubernetes Gateway API (if operated on K8s) Using Kuma / Kong Mesh Collecting data at the App-level
- 11. ● Component usage: ○ Visualization: Grafana ○ Logging: Loki (Log Shipping: FluentD / FluentBit / Promtail) ○ Metrics: Prometheus (for long-term storage Cortex / Thanos) ○ Tracing: Tempo ○ Alerting: Prometheus Alert Manager ● Operating models ○ Self-managed on-prem ○ Grafana SaaS offering Using Grafana Stack to create a 360 degree view Analyzing and monitoring the data
- 12. Conceptual O11y architecture ● Flexible, cloud-agnostic approach ○ Independent of architecture and platform ■ VM / Bare Metal ■ Containers / K8s ■ Cloud / On-prem ○ Easily extensible ● Completely based on Open Source ● Declarative approach (no code changes) Based on Kong and Grafana
- 13. Use Cases
- 14. ● Goals: ○ Transparency to data usage ○ Using o11y data to being able to analyze and optimize data access and processing ■ Ingestion ■ Processing ■ Analysis ● Solution blueprint: ○ Pure on-prem scenario ○ Kong for Kubernetes EE ○ Kuma (Multi-Zone Mesh with mixed workloads) ○ Grafana Stack for Monitoring (App-level) Insights to data access and processing in a Data Lake scenario Scenario #1: Data APIs
- 15. ● Goals: ○ Transparency about data usage ○ Monitor overall platform state (not only infra) ○ Insight to data flows with respect to state & performance ● Solution blueprint: ○ Hybrid scenario (On-prem / AWS) ○ Kong for Kubernetes OSS (Multiple Data Planes) ○ Kuma (currently not yet implemented, but planned) ○ Grafana Stack for Monitoring (App-level) Insights to cloud-native integration flows Scenario #2: Modernisation
- 16. Conclusion
- 17. ● Mindset change needed (similar to DevOps) ● Challenges to find ○ Right tool stack ○ Questions to answer (Unknown unknowns) ● Important things are ○ O11y should be thought of from the beginning and is not limited to application runtime ○ Collecting as much insights as possible ○ Using the collected data to learn about application behaviour … it’s more than just technology Consistent O11y strategy is critical
- 18. ● Visibility in distributed application landscapes is key for successful managing such environments ● Kong’s platform components allows to setup a declarative O11y approach that is ○ Flexibel ○ Extensible ○ Not limited to Microservices, as Legacy apps could also be instrumented respectively ○ Based completely on Open Source ● Grafana Stack can be used to create 360 degree view to every heterogenous application landscape Key takeaways
- 19. Thank you!