Monitoring a JHipster microservice architecture in practice
Pierre Besson
Devoxx France 2018, April 19th 2018
Who am I ?
- FullStack & DevOps @IpponTech
- JHipster core team member
- 🍃 Spring
- 🐳 Docker
- ☸️ Kubernetes
- 300 collaborators worldwide (France, USA, Australia)
- 5 cities in France : Paris, Nantes, Bordeaux, Lyon, Toulouse
- Specialized in Java, Cloud, Big Data, JHipster Sponsor
Introduction to microservice monitoring
Problems & Solutions
The JHipster Console
The problems with monitoring microservices
- Distributed system -> More complex to observe
- Logs are dispersed in many many log files
- Hard to locate the microservice that caused a problem
- Hard to follow the chain of requests
- 🐇/🐢 Studying latency is hard
- 💂 Resiliency mechanism are hard to configure properly
The solution
Observability in 3 dimensions
- Logs : discrete event
- Metrics : numerical values (business or technical)
- Traces : chains of calls in the system (spans)
- Store everything in one place, with proper metadata
- Use a search engine to query and aggregate monitoring data
- Visualize using graphs and dashboards
- Navigate around highly correlated data
The JHipster Console
jhipster.tech/monitoring/
- Setup the ZELK stack (Zipkin, Elasticsearch, Logstash, Kibana) in docker
- Enable reporting from any JHipster app with a few properties
- Logs + metrics forwarded with logback-logstash-encoder
- Traces are forwarded to Zipkin using Spring Cloud Sleuth
- Logs are enriched with trace information (Trace ID)
- Data is stored in Elasticseach for a certain number of days (Curator)
JHipster Console Architecture
JHipster Console demo
Setting up the Console
Navigating around Kibana
Creating custom visualizations and dashboards
Graphing metrics, manipulating timeseries
Following call traces accross services (Kibana + Zipkin)
Thank you !
