Benefits of Accumulating Logs | Original
When I worked as a contractor for a bank before, we used a multi-cloud application platform to serve the microservices. At that time, I started to accumulate logs when working in the company.
Several years have passed, and I still think it is one of the best ways to help me work or do software engineering. As time goes by, in my logs directory, there are hundreds of log files.
I don’t have specific subdirectories or formal log file names for those. Sometimes, I just use that JIRA task name as my log file name prefix or that feature. And then I add a number to the suffix. It is like mutual-fund-1.log, mutual-fund-2.log etc. It means in the mutual fund microservice, I have that log when running that microservice.
Sometimes, when working on projects that serve multiple regions, I will add that country as a suffix, like mutual-fund-cn-1.log, mutual-fund-sg-1.log. The file names of logs are somehow casual. Because at that time, I needed to focus on error stacks or the surrounding function calling.
The logs of the programs matter. Everyone knows. However, I want to overstate the importance of accumulating logs instead of just watching them in the console and letting them go. You will know more convenience when the project is going on. You have more time to find the previous logs. You may need to know whether similar database stored procedure calling happened before. You may need to know whether the same error happened before. You may need to recall how to fix this problem last time.
There are tons of details in a big project or tens of microservices. And the errors, exceptions, or problems are happening again and again. The log is just like the running document of a program. And they are generated by the program automatically without human typing. And for developers, these logs are readable. So when starting a new task or fixing a new bug, you have hundreds of logs in your hand to fix this new bug. You are not alone.
Why do we accumulate them? Because things or knowledge are easily forgotten.
There was human civilization progress when paper was invented. And when computers were invented, there was another level of human civilization. Keeping notes on paper is just like accumulating logs in computers.
Not just for humans, but for AI chatbots, LLM tooling, these logs are becoming more and more important. The GreptimeDB, a database for the unified collection and analysis of observability data (metrics, logs, and traces) established in 2022 is not a coincidence.
Why didn’t I do that before? After I worked as a contractor for big banks, I needed to do more collaboration and work on bigger projects. Before that, most of the time in the startup or my startup period, I worked solo. When I worked at LeanCloud before, I worked on the IM app LeanChat for like half of the time.
And when I went into the more formal corporate world, development of the projects was different from my personal project or startup project. They have SIT, UAT testing environments. And the production environment is often just open to certain small team peers. Getting the logs from them and fixing problems becomes long and somewhat tedious. And running a project takes time, and the Jenkins pipeline often needs half an hour to run.
So I can’t run or test the program like a fly. I can’t do a deployment by simply typing a command on my personal computer and uploading code to the server for running.
So it somehow lets me accumulate logs to have more context to handle tasks. We better fix problems at first shot. We better verify our fix in just a few times. We are not easily able to get logs of the program that is running in a cloud or the server of the company, so we better copy it and save it on the local laptop, to do analysis.
And now, for my personal projects, I will accumulate the logs too. It becomes a habit. After working in big companies for some years, I somehow have more patience or strategy to make my projects bigger and longer. So I know I need these logs as time goes by.
Someone may say that you just need to have elegant code and a working project. You don’t need to accumulate the logs or error stack traces. It’s okay. When we have a bug or a new feature, we can run the program to get the current logs. We don’t need the logs from the development process. They are like the detailed records of scientific experiments. At first sight, it seems okay. But in the long term, if one day you want to work on it again, or you want to share it, or let others take over it, it may not be good.
I think there might be good opportunities here. In companies, why don’t we encourage every developer to share their accumulated logs? In open source projects, we should have that too. We don’t find others’ logs appealing because we don’t know them. We lose the context when saving those logs. And inside there, there seem to be tons of unrelated or trivial messages.
But the effort to accumulate logs is just trivial. It is just copy and paste every time we see some logs, especially those error logs. And how about we do it in an automated way? It’s a good idea to record the logs in a directory every time we run a project, like those Spring Boot projects.
The world becomes more and more digital, so accumulating logs of digital programs is just like accumulating books in a physical world.