Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add some initial Honeycomb support #45

Merged
merged 17 commits into from Feb 2, 2017
Merged

Add some initial Honeycomb support #45

merged 17 commits into from Feb 2, 2017

Conversation

sarahhodne
Copy link
Contributor

@sarahhodne sarahhodne commented Jan 24, 2017

This PR adds some Honeycomb integration. It sends the following events:

  • clone
  • terminate
  • http-request

All events contain the X-Request-ID value if the HTTP header is set (we don't set this anywhere yet, but that way it's tracked when we start to do that).

The HTTP request event has information about the request duration, the HTTP method, URL path (e.g. /instances/fafafafa-fafa-fafa-fafa-fafafafafafa), response code (e.g. 200), and the number of bytes written.

The clone event differs a bit in information depending on how far in the clone it gets. It always has the image name, total duration, whether the clone succeeded or failed (and the error if it failed), and a string field that specifies how far the clone got (roughly "where did the Start() method return).

In addition, it tracks this information as it becomes available:

  • How long it took to wait for the semaphore "rate limiting"
  • The ESXi host name of the host the image is on
  • The name of the new VM
  • The time it took to "setup" (i.e. the time spent in the Start method before the clone is started, which is spent doing things like "find the base VM and snapshot" and "find the resource pool to place the VM in")
  • The time it took to run the "clone" task
  • The name of the host the VM is on after the clone
  • The time it took to run the "power on" task
  • The name of the host the VM is on after being powered on

The terminate event is similar in that it tracks more information as it goes along. It also tracks total duration, whether it succeeded or failed, the error, and how far in the method it got before returning. In addition it tracks:

  • The name of the VM being terminated
  • How long it took to wait for the semaphore "rate limiting"
  • If the "power off" errored (we normally ignore this since it could be that the VM is already powered off, which would lead to an error, and since we immediately move on to destroying the VM we assume that that would error too)
  • The time it took to run the "power off" task
  • The time it took to run the "destroy" task

@sarahhodne sarahhodne self-assigned this Jan 24, 2017
This sends some initial data about the incoming requests to Honeycomb.
Since we create the builder in a init() and set the write key after all
the configuration is parsed, the builder ends up without a write key and
no events are sent.
started - now makes for negative durations
Copy link
Contributor

@meatballhat meatballhat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌 ✨

@sarahhodne sarahhodne merged commit 18caf29 into master Feb 2, 2017
@sarahhodne sarahhodne deleted the hh/honeycomb branch February 2, 2017 10:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants