Developers can leverage their knowledge of existing libraries, and don’t have to learn to use a new one every time they start a new job.There are no additional dependencies for the application.If the original logger (to file) is configured to flush on each write, then it’s virtually impossible that logs will be lost.There is no need to dangerously buffer them in memory. The log shipper can send logs to the store in bulk.If there is a problem sending logs to the store, the original log files are still there as a single source of truth.Files are about as fast as it gets for an application to write logs.The log shipper is an offline process, and will not directly impact performance of applications.This approach has a number of advantages: There are more than enough out there that you can just pick up and use. Again, you don’t have to write the log shipper yourself. So what is the alternative? Simply keep writing to log files, and have a separate application (a log shipper) send those logs to a centralised store. These practical issues don’t even take into consideration the effort and complexity involved in creating a fully-featured logging library. Even worse, if the logging library isn’t designed properly, it may carry dependencies on mutiple logging stores. This is a form of coupling that doesn’t work very well with microservices. Through the logging library, the application must depend on a client library for that logging store.The application must take the performance hit of communicating with the remote endpoint.Logs buffered in memory can be permanently lost if the application terminates unexpectedly. That’s great! Your logs are now in one place and you can search through them effortlessly! And your code is even DRY because you wrote another common library (hey, you only need like 35 of them now to write a new microservice).īut wait, having applications write directly to a log store is wrong on so many levels. So… you need to write a logging library that all your microservices can use to write the logs to a central data store (could be any kind of relational or NoSQL database). You begin to break up the monolith into microservices, and realise that you now have log files everywhere: in multiple applications across different servers. You have your big software monolith that’s writing to one or more log files. In order to realise just how stupid reinventing the wheel is, let’s take an example scenario. They could just use one of the myriad existing solutions out there, which are probably far more robust and performant than theirs will ever be. There are so many logging frameworks out there, it’s just crazy.Īnd despite this, it baffles me why so many companies today still opt to write their own logging libraries, either from scratch or as abstractions of other logging libraries. As such, it’s a problem that has been solved to death. You’ll find it in virtually every application out there. If we were running managed services within the cloud, then logging to file would often not be an option, and in that case we should use whatever logging mechanism is available from the cloud provider.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |