HTTP router for hubot HealthCheck

[diegodorgam]

When the bot dies, we don't have any notification.
There are a few possible situations where a bot can die, an outage of the server can be one of those.
But the thing is that we need to check if the bot is alive and able to post messages into the server, and the best way to do this is enabling a http endpoint where we can send a GET request and receive some data back.
For that we have a good example in https://leanpub.com/automation-and-monitoring-with-hubot/read#leanpub-auto-serving-http-requests
We could use some inspiration from hubot-diagnostics but remembering that we need to have the bots health information through http requests, for infrastructure checking purposes.

/assign @arthurTemporim

[timkinnane]

This would be good to have in the SDK. It might be a requirement anyway for @mikaelmello's project to show status of all bots in an admin view. It can be achieved more easily in Hubot though, because it has an express server built in, so maybe use this issue to work on draft feature and proof of concept, then when it's functional and settled, we could migrate it into SDK? Would have to find some light-weight way of setting up a HTTP listener, because most bot frameworks include a server and I wouldn't want to double up by adding one to the SDK.
Another option might be using the SDK just an a consistent interface but still setup the listener in the bot. Each framework adapter/connector could set up the listener in their own way, but pass a standard event through the SDK.

[diegodorgam]

Totally, in fact I think that once we do have a manager interface for bots, the server could use a ddp event to check if the bot is online and responding, maybe even collect some stats of usage, and then provide that information to a rocketchat server webhook or some REST API endpoint, so any external application could check and use that info to maintain, restart or kill the bot.
But again, that would require that rocketchat server would be prepared to take that info periodically from the websocket connection, or at least having a ddp event to be emitted by the bot to server, kind like the "ping"/"pong" messages, but with actual useful information to be received and stored, if it could do that maybe we wouldn't need a http server.

For now I totally agree that we need to scratch this first, and Hubot's http router seems to be our best shot now. We can focus on designing the data object to be sent, and then just add other interface to retrieve it, maybe keep them both, the DDP event (could call it check) and a built-in REST API endpoint like http://0.0.0.0:3080/api/v1/check.

Just shooting some ideas here.. =P