Pagevamp Tech
Published in

Pagevamp Tech

Extracting more value from application logs

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.

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!


  • Developing & releasing a feature has become really easy — all we need to do is “First Log then Debug ”.

“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!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store