domingo, 6 de noviembre de 2016

Adding metrics/monitoring to the Mac menu bar

In the past I used to have an extra screen close to my desk where I was able to show different dashboards with metrics to monitor the health of our services.    Depending on the service we can use things like graphite, cloudwatch or google analytics.

These days I'm finding some challenges to keep using that approach so I decided to explore the option of showing those metrics in the menu bar of my Mac.

First thing I needed was an app allowing me to put custom stuff in the menu bar.  I explored a couple of options and I ended up using BitBar:
https://github.com/matryer/bitbar

BitBar is a free app that is able to execute almost any script (bash, python, ruby...) and put the output of it in the menu bar with many customizable options for icons, images and format.

Right now I wanted to monitor a couple of services using graphite, another from cloudwatch, show some statistics from google analytics and ideally monitor a heroku app.

- Graphite: It was trivial to write a 1 line bash script curl-ing the graphite endpoint with &format=json and parsing the output with jq.
https://gist.github.com/ggarber/9490390fdcb5db0251cdb6d3ca6faef9

- CloudWatch: I used a python script and boto3 to be able to get CloudWatch statistics for AWS Firehose but after a couple of try-error iterations the final script was very simple too.
https://gist.github.com/ggarber/8317179246ca11bfe867c93f9c6f0e2d

- Google Analytics: This was the most challenging part specially because the authentication part.   I ended up using this sample from Google tuned to print the exact information I wanted: https://developers.google.com/analytics/devguides/reporting/core/v4/quickstart/service-py

- Heroku: I was not able to figure out how to access programmatically the requests/sec metrics that are shown in the web dashboard :(

The end result is this one, you can even use emojis (:mushroom) to make the information more colorful:




miércoles, 28 de septiembre de 2016

How much plumbing is required to build and deploy a server exposing the simplest HTTP API

I got into an interesting discussion today about the future of development & deployment and one of the premises was that today there is too much plumbing involved on building and deploying everything.

I argued that it was not that much plumbing with modern frameworks or with project templates (like yeoman ones) and that deployment had been heavily simplified in environments like Heroku.

So, in this quick & dirty post I will try to prove my point building a simple HTTP server exposing a Hello-World HTTP API.

Creating the app:

➜  echo "import os
from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

app.run(host='0.0.0.0', port=int(os.environ.get('PORT', 5000)))> app.py
➜  echo "flask" > requirements.txt
➜  echo "web: python app.py" > Procfile


Initializing the source control (git) and comiting the changes:

➜  git init
Initialized empty Git repository in /Users/ggb/projects/rgb/.git/
➜  git add *
➜  git commit -m "First version"

Deploying to production:

➜  heroku create rgb-ggb
Creating ⬢ rgb-ggb... done
https://rgb-ggb.herokuapp.com/ | https://git.heroku.com/rgb-ggb.git
➜  git push heroku master *

Try It!: https://rgb-ggb.herokuapp.com/

Summary:


Code: 7 LoC (4 is the plumbing of starting the server and it has to be done only once)
Deployment: 1 file (Procfile) to tell heroku how to start your app (this is not needed for node.js apps and could be autogenerated with a yeoman template) + 1 git push command in the console (and a "heroku create" command the first time)