Talk was delivered at Kong Summit 2022 Abstract: Cloud-native architectures are usually implemented using a distributed microservice architecture style. This furthers agility and flexibility since changes can rapidly be implemented, as the services are loosely coupled. But this comes at a price -- application monitoring becomes increasingly complex. In this talk, Sven Bernhardt will show how a basic observability strategy can easily be implemented without the need to alter your existing application logic. Sven will demonstrate: - How to use Kong Gateway and Kuma to facilitate consistent logs, metrics, and traces across all services. - How to trace down the complete request lifecycle starting from the first call to Kong Gateway - How Kuma makes inter-service communication transparently comprehensible - How the Grafana stack — consisting of Grafana, Prometheus, Loki and Tempo — can be used to gather all observability data in a central place and provide it for further analysis.

1. Sven Bernhardt
SEPTEMBER 2022

2. ● O11y Challenges
● Solution strategy
● Use Cases
● Conclusion
Agenda

3. O11y Challenges

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

8. Solution strategy

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!