I’ve been an intern at VTS for almost two months and about half way through my time, a Raspberry Pi and a flat screen TV arrived in the office specifically for the engineers. The possibilities were endless but eventually, we decided that a unified place for all of the important statistics should be created. I took that on as a side project.
What to Put
I polled the team on what statistics they felt would be important to be able to glance at and see our performance. We came to a consensus with some New Relic metrics, open GitHub pull requests, and Sidekiq Queue count. These values, we decided, were important to showing us how our application is performing in real-time.
Shopify wrote a fantastic little tool to create a customized dashboard, so I got right to work on playing around and trying to get an MVP to put up.
How it works
Dashing has a fantastic community so most of the widgets I needed were already mostly built, all I had to do was supply an API key.
Response Time, and
Apdex Score are all pulled from one New Relic API call. The top left widget cycles through the open pull requests for web, iOS, and Android via the Octokit gem. This way, each team can see how many features are waiting to be merged in. Finally, the Sidekiq widgets are made through a custom HTTP request that I wrote to count the total jobs in our Sidekiq, as well as cycle through each of our queues to see how many jobs they have.
In doing my research for Dashing, I found a widget called “Hotness”. Hotness allows me to set upper and lower bounds for each widget and change the color of the widget accordingly. Obviously, a good value for our error rate, response time, pull requests, and Sidekiq widgets is as close to zero as possible, therefore, those widgets are green. If there’s ever a problem, the widgets will turn yellow, then red. That way, even if we’re across the office, we can easily glance at the board to see if anything needs our attention. We also try to keep our Apdex score as close to 100 as possible, and it will turn red if it drops below 90.
Ready for Expansion
Dashing makes it incredibly easy to add more and more widgets as well as resize all the widgets. This way, if someone comes up to me and makes a suggestion for the dashboard, it’s easy to make one and deploy it to the dashboard in minutes.
Dashing allows widget-specific refresh times, which allows us to get data in as close to real-time as we want. This became a problem for me pretty quickly. I figured we should check things every second so that they’re as up to date as possible. But then, GitHub. My GitHub widget makes 3 requests, if I did that every second (and I did), I would be making almost 11,000 requests per minute! In fact, the first day I did this GitHub blocked my token for 24 hours, forcing me to change the refresh time to a much more reasonable 10 minutes. The point is, choose realistic times to reload data based on the APIs you hit and how often the data really changes. It makes sense to reload our New Relic statistics frequently, but not things like GitHub pull requests.
Building a tool like this was a lot of fun because it was valuable to us as engineers and helps us to be a much more productive team. VTS provides a great environment where side projects like this are encouraged so long as they provide value. If you, or someone you know, wants to work at a place like that, we’re hiring so you should definitely reach out!