Microservice Monitoring

Following with the previous post, we were thinking about how monitor our microservices, and here is our proposal:

monitoring

  • Data Collector (fluentd). Instead of using the common ELK Stack (elasticsearch, logstash, kibana) or Elastic Stack, we substitute logstash for fluentd. There are some comparisons like this one. logstash has a limited on-memory queue and you would need to install a message brocker, such as redis, RabbitMQ or Apache Kafka, to facilitate a buffered publish-subscriber model or enable persistent queues with limitations.Each microservice logs through console and we’ll use the Docker fluentd logging driver to process these logs and send them to our elasticsearch.
  • Distributed tracing system (Zipkin). It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. We’ll store the information in our elasticsearch.Each microservice will use Spring Cloud Sleuth to trace each request, maintain an unique identifier and keep track. Spring Cloud Sleuth will send the data to Zipkin.
  • Distributed Search and Analytics (elasticsearch). We’ll store our data in elasticsearch so we will be able to search whatever we want in our logs.
  • Explore, Visualize and Discover data (kibana). We’ll visualize our stored data using kibana.
Advertisements