...logging library which adds another layer of promise to capture the input parameters and resolving responses
Will there be any performance impact as the number of microservices and messages in between increases?
Also, how did you monitor system state changes from the logs?
I am new to monitoring and currently studying event-store mechanism.
I gave my kids 7 pencils for painting. Each color meant a musical note. Then I played simple chords on the guitar with the colors they picked. Now they got paintings with soundtracks.
Hi thanks,
For logging, we had a run of perf tests. The impact was negligable considering the benefits.
The perf impact of the microservice architecture is another topic to go through. One should seriously consider if it is really needed. Anyways, in our case, we use AWS auto-scaling groups and a pub-sub mechanism using SNS -SQS coupling. So I am really glad about the scalability of the entire system.
For system state changes, pre-release: we got scripts of queries for error logs. You can search your logs excluding the known issues, which brings up only the new errors. Post-release: 1-we have error alerts (you can configure throttling, error count and such conditions about the alerts) 2-we added duration of each function call into our custom logging library. So we have rules about the long running function. Anything runs over X ms in a microservice and Y ms in-between microservices trigger an alert.(actually maybe i should add this perf checks to the original post). Hope this helps.
Nice post.
...logging library which adds another layer of promise to capture the input parameters and resolving responses
Will there be any performance impact as the number of microservices and messages in between increases?
Also, how did you monitor system state changes from the logs?
I am new to monitoring and currently studying event-store mechanism.
Hi thanks,
For logging, we had a run of perf tests. The impact was negligable considering the benefits.
The perf impact of the microservice architecture is another topic to go through. One should seriously consider if it is really needed. Anyways, in our case, we use AWS auto-scaling groups and a pub-sub mechanism using SNS -SQS coupling. So I am really glad about the scalability of the entire system.
For system state changes, pre-release: we got scripts of queries for error logs. You can search your logs excluding the known issues, which brings up only the new errors. Post-release: 1-we have error alerts (you can configure throttling, error count and such conditions about the alerts) 2-we added duration of each function call into our custom logging library. So we have rules about the long running function. Anything runs over X ms in a microservice and Y ms in-between microservices trigger an alert.(actually maybe i should add this perf checks to the original post). Hope this helps.
Sure it does. Thanks for explaining.
Btw what is your startup?