Add deployment reporting to monitoring systems

[sopel]

Not the least our first performance regression based on a code change (see #123) suggests to apply the meanwhile common deployment markers within our monitoring systems - currently available are:

• Boundary - Events
• Librato - Annotations
• New Relic - Deployments

All of these can be recorded via simple HTTP POSTs from scripts, though it might also be a good idea to generalize this for reuse by reporting on respective CloudFormation events (create/update/delete), which could be done from an external component monitoring the SNS notifications or a custom resource inside the stack.

• I'd prefer to look into the latter, though a script based approach is probably the correct KISS approach right now

[sopel]

@dpb587 - I've reconsidered this and the script approach isn't just more KISS but more or less required, insofar any auto scaled instance would need to report on its own at startup anyway, which should just be the standard pattern accordingly - let's talk about the approach and priority shortly in the upcoming hangout, but given you have already ensured the required credentials are available, this seems ready for implementation.

[sopel]

Moved to Icebox due to low priority.

[sopel]

:information_source: Deployment markers should also be added to our own LogSearch cluster(s) of course.

[sopel]

This relates to epics #293 and #294.

[sopel]

:information_source: This would also imply partial auditing of manual stack operations, e.g. via the AWS Management Console (see last paragraph in #297).

[sopel]

Deployment markers should also be added to our own LogSearch cluster(s) of course.

:information_source: Elasticsearch 1.0 (resp. the accompanying Kibana release) offers so called Chart Markers which would be ideal for the purpose of deployment markers of course, see what’s cooking in kibana for a screenshot.

• this depends on #320

[sopel]

Closed as Won't Fix due to project being retired to the CityIndex Attic.