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

API Development: Design-First or Code-First?

I just read this post in DZone (this is the original) related to “API Development: Design-First or Code-First?” and I am not agree with the second phrase in “The design-first approach advocates for designing the API’s contract first before writing any code. This is a relatively new approach“.

People talks about API’s like if they were born recently but we integrate systems since long time ago, so I think we should design API’s for those integrations, don’t you think? You can ‘google’ for “WSDL-first” or “Contract-First” and you will get a lot of results about “design-first” when we built SOAP API’s long time ago.

I personally prefer “Design-first” for some reasons:

  • It’s not only designing any API, it’s about your “Company API Strategy“. It’s about how will people think about the way you show your “business”.
  • Server and client side are able to build at the same time; it’s not implementation aware.
  • If you adopt “Code-first”, you have to be aware about the name conventions for the classes you declare. For instance, if you use the “DTO” suffix convention, may be this “DTO” suffix will be exposed in your API and it sucks.