Releasing a new feature can be a difficult task, especially when you have a large customer base.
A software company has to think about all possible scenarios even when making small changes in the application.
A small flaw in these changes can have a great impact. For example, whenever a feature is released, many customers completely accept it, but there may be some who perceive it as an incomplete feature or even as a bug. While some customers request for the modification according to their wants, others don’t.
As a startup we want to experiment with a lot of ideas and features to test impact and direction, but pushing a lot of things may have a significant impact on production with edge cases that are hard to account for.
Following are some problems we faced before we adopted application logging -:
Too much time spent on development & release: Detecting bugs at development phase & release was difficult due to lack of proper tracking.
Lack of awareness of application status: No one would know if application services were running or not unless someone reported a bug. This resulted in us firefighting a lot.
Too much manual intervention: Due to lack of automated monitoring, lots of hours were spent on low impact tasks. Developers and Testers had to test services before releasing, to check whether other features got affected. Due to interdependency of applications in our software, this was a huge problem.
Decreased team productivity & efficiency: Releases were slow, bugs were abundant and we started focusing more on fixes than on growth. This had an adverse impact on our business.
To shift our focus back to business growth, we started implementing application logging in our microservices with existing libraries like Monolog for php & Winston for javascript.
That being said, setting up a strong base for logging was not something that happened overnight.
As we moved into microservices quite recently, it took us some time to implement logging in our services. We had to make a list of crucial events in our application, and then add logs with relevant information.
For example: Pagevamp’s main selling point is “Turning facebook page into a website” . While it may sound relatively simple, many things happen behind the scene to instantly build websites. This creates many error points that can cause the main feature to fail. We go through many steps like getting Facebook data of a user’s page, reorganizing data, saving data into our database, creating & linking domain to that page, creating a subscription, etc. So we started logging those events with relevant information like “Trial subscription started ,[ other relevant information like id]” with proper Log Levels like (error,debug,info,warn).
These logs are then sent to Google Stack Driver from our application at run time. Stack driver accumulates all our application logs, processes them and renders them according to our needs. Therefore, we could filter the log by application level, text, occurrence, date & so on.
Here is one interesting thing we did from our logs. We created a Stack Driver Alert from our logs, we specified that the log with text “Subscription renewed [data]” should be sent from our application everyday or within 2 hours, so whenever our subscription renewing service doesn’t work we get notification in our emails / slack channels.
This ensures that our engineers can immediately fix a big issue which is directly affecting our ability to collect money! Most of our services are monitored by logs, so failure of services is quickly detected, cutting manual intervention.
In addition, we are prompted by our own software and this is much less embarrassing than if we are notified by our customer!
BENEFITS OF APPLICATION LOGGING
- Developing & releasing a feature has become really easy — all we need to do is “First Log then Debug ”.
- By using Cloud Logging Services, all we need to do now is observe the occurrence pattern of logs. We get instant notification if there is a glitch in the system, allowing us to take quick measures to fix it.
- With automated systems in place, our team can focus more on productive tasks instead of worrying about the uptime of our services.
- We no longer need to wake up alarmed as most bugs are caught before release & also quickly after release. Sleep is important for everyone!
- After gathering data through logs used in Stack Driver, we process information in Google Data Studio to generate reports and visualize relationships between variables such as user location and account status. This allows us to target our services more effectively.
“If Dog is a man’s best friend, Log is a developer’s best friend.” — Source
Conclusion -: Using too many logs in an application can create problems, so it’s important to figure out a proper plan of action beforehand and implement logs accordingly.
If you haven’t started using logs in your application, start today! There are a lot of Cloud Logging Services like Sematext, Loggly, Logentries, and Rollbar. Getting started is really easy!
Top comments (0)