Monitoring and alerting Microservices

Microservices exist for rapid development and deployment. Time to market a product is reduced significantly. But to monitor the container and API performance one needs tools.
If we build a client and from java code call the API or from AOP, it will send update to a time series database using JMS or REST call. Maybe a server component to get the data and update
One can configure Rules and actions - if CPU > 100 raise alert -> action send SMS or email or call a HTTP URL with json data.
For visualization one can use grafana or custom tools.

Comments

Post a Comment

Popular posts from this blog

Ignite Running in Static IP multicast mode

Apache Ignite throws multicast exception in local machine when multicast is on and internet is connect. The following is an example of multicast IP discovery  <!-- Explicitly configure TCP discovery SPI to provide list of initial nodes. -->         <property name="discoverySpi">             <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">                 <property name="ipFinder">                      <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder. multicast . TcpDiscoveryMulticastIpFinder ">                         <property name="addresses">                             <list>               ...
Read more

JPA Vs SpringJDBC

Recently I conducted many interviews for my employer, one 8-9 yrs exp candidate asked me what data access object layer do we use in our project. I was thinking a bit as , like they do with persistence - polyglot persistence, we maintain different DAO technologies - JPA, proprietary JDBC, JDO, Spring JDBC. you cannot say which one is the best. It depends on the context but definitely having so many things for performing dataaccess is not advisable. In this topic I will try to explore the JPA and Spring JDBC. Spring is a life savior, it's template concept reduces the boilerplate code but still the jdbc template comes with baggages - row mapper, SQL, parameters etc. If you have good knowledge of database schema, you want to execute stored procedure, you want more handle on your code to access the db. Then go for Spring, you can debug easily and have control on your DTO. If you need to abstract away the SQL, hide complexity, write less code, dont need to execute the stored proced...
Read more

NSSM service eats 100% CPU

Image
NSSM logstash service can cause a fatal CPU hungry outage in your clients unless you override the AppExit default value. By default it comes as default 'Restart' To change it to ' Stop service ' you need to run the following command nssm set logstash AppExit Default Exit It will change the service definition as follow Other v alid exit actions are: Restart Ignore Exit Suicide  
Read more