Veneur-emit time

[redsn0w422]

Summary

This PR adds a -command flag to veneur-emit. If you pass a command to -command, veneur-emit will:

1. Skip/ignore any metrics by flag;
2. Execute the command passed in;
3. Report the runtime of that executable as a Timing metric.

Motivation

A lot of use cases of veneur-emit involve a shell script, where the user would get the time, run some program, get the time again, calculate the difference, and then send the elapsed time as a Timing metric via veneur-emit. This PR makes it easier to do so.

Test plan

I added tests for timeCommand.

Rollout/monitoring/revert plan

Puppet!

r? @cory-stripe

TODO:

• Do we care about the exit status of the executable?
  We do - veneur-emit will grab the exit status and put it on the Timing metric as a tag: exit_status:0, for example.

• cmd.Start() & cmd.Wait() OR cmd.Run()?
  cmd.Run() gets the job done, for now.

• Do we want to have a timeout on the executable?
  Too many edge cases for a timeout, so if the user wishes, they can add a timeout to the command passed to veneur-emit.

• Do we want the user to be able to send other metrics as well, or should we skip that entirely?
  Skip metrics. Calling veneur-emit is trivial, and if they want to send other metrics, they can just call it repeatedly.

• Support sending the Timing via SSF?
  SSF does not (yet) support Timing metrics.

[stripe-ci]

Gerald Rule: Copy Observability on Veneur and Unilog pull requests

cc @stripe/observability
cc @stripe/observability-stripe

[cory-stripe]

Some notes:

• Please ask @aditya-stripe and @asf-stripe and @krisreeves-stripe to see if they have suggestions on making sure we don't reinvent shell handling.
• We should return the exit status of the command as our exit status so we don't "hide" failures.
• We should definitely support SSF
• Timeout is pretty cool, but maybe worth a separate PR
• I think we can skip other metrics for now, they can call this command again if they want them.

[krisreeves-stripe]

Summary from my conversation with @yasha-stripe:

This is a bit of an awkward usage of --. A more normal (to my eyes, which probably doesn't agree with Go convention anyway) invocation would look like veneur-emit -shellCommand foo -- --foo-switch (or, in the case of subcommands, veneur-emit subcommand -- --subcommand-switch. However, I think it's fine as-is, particularly if this is not an easy pattern to implement. It's much nicer to be able to entirely avoid shell quoting hassles than the alternatives I can think of. I'm not a total shell beast, so maybe there's a pattern I'm unaware of?

I'm +1

[asf-stripe]

Two comments, the rest looks great (:

[asf-stripe]

Use %q here instead of '%s' for an auto-quoted string (:

[asf-stripe]

As we discussed, let's cut out the middle-sh and execute the command directly (:

[asf-stripe]

😍

[cory-stripe]

What's TODO here?

[ghost]

Thanks! I forgot to write the rest of the documentation :)

[cory-stripe]

👍