One thing that is fundamentally different when comparing a legacy and traditional architecture to a distributed system such as Microservices or SoA is that due to the nature of more things being run in parallel, it is just hard to make sense of things. In fact, the move to write multi-threaded applications become more comment with the advent of multi-core CPUs in the last decade as a way to better use the system resources and to write a more performant software. While performance gains are great, running multi-threaded softwares comes with a caveat: it is harder to monitor, trace, debug and make sense of things.
There is yet another problem with monitoring when it comes to microservices. Traditionally the monoliths would have a set amount of executables and services that needs to be monitored. Even in terms of scaling, they only scale vertically, which means they run on a bigger machine and that doesn’t change the way things are monitored, which is having an eye on one machine that has everything (hence the word monolith). In microservices however, a decomposition of a software system may result to hundreds of micro service (Cinque et al, 2019) and each could be deployed to a separate box and scaled horizontally (e.g. run on multiple machines). So just by doing this, now you have tens if not hundreds of machines (whether virtual or physical) that you need to keep an eye on.
References
Cinque, M., Corte, R. D., & Pecchia, A. (2019, 27-30 Oct. 2019). Advancing Monitoring in Microservices Systems. 2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW)