What’s the first place that you look when you have a problem with your application? We recently posed this question to our Twitter followers. Not surprisingly, the answer that came back was the change log. If your system is running fine and then suddenly stops working after a deployment, chances are that the answer lies within the code that changed.
— Scott Oseychik (@scottos) July 16, 2014
Fortunately, GitHub has a webhook API that can send logs to Loggly any time there’s a change in the code. It’s easy to set this up using our HTTP/S Event Endpoint. You can add the “github” tag to these logs to make them faster to find via search. Here is an example, but make sure to insert your own customer token before using it.
By bringing GitHub change logs into Loggly, you can correlate deployed code changes with system changes measured through your log data. And as a result, you can uncover bugs and other deployment issues much faster.
GitHub’s webhook API gives you access to data about pushes, deployments, pull requests, releases, and more. Even if GitHub is interacting with another service to do the actual code push, you can log the action through GitHub so that you have a record of it.
The process I have described above works with any cloud service offering a webhook API. Our documentation also provides some information about integrating with PagerDuty’s webhook API. You can even use plain text to send change logs from deployment systems that don’t offer webhook APIs by sending file logs to Loggly.
New code always has the potential to cause errors and production problems, so it pays to stay on top of it. For example, our customer Rumble Entertainment compares post-release and pre-release metrics every single time they release code. As a result, Rumble can often detect potential problems within minutes. (You can read our case study to learn more.)
Of course, the best way to see the value of managing change logs in Loggly is to experience it for yourself! So why not sign up for a free trial?