Solution: Add telemetry to track metrics

[mrmarcsmith]

Implements #415

I have added the sending of "add", "update", "delete", "start", "stop", and "exception" events via telemetry. I have also injected assertions into the existing job_broardcast_tests and executor_test files to verify functionality of the telemetry events.

Testing strategy:

1. Each test registers to a common TelemetryTestHandler in the test class.
2. The test performs a job event and the source code calls telemetry execute.
3. TelemetryTestHandler receives those events and uses send/2 to pass a message back to the test thread
4. we use "assert_receive" or "refute_receive" to verify the message was received as expected

[coveralls]

Pull Request Test Coverage Report for Build 5a0b9f2c1917ba71c5967bfe6be674472d71c4cb-PR-453

• 31 of 31 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+1.07%) to 87.2%

---

Totals
Change from base Build 546758291c94f6a41042a507c35ac1ac5b89eb46:	1.07%
Covered Lines:	327
Relevant Lines:	375

---

💛 - Coveralls

[mrmarcsmith]

@maennchen when you get back from vacation I would love your feedback on this!

[rraub]

@mrmarcsmith It would probably be worth adding some documentation around how a user would consume these telemetry events in the readme or the other markdown doc folder.

[mrmarcsmith]

@rraub good idea! I’ll work on that

[maennchen]

@mrmarcsmith Thanks a lot for the PR!

There's a few cases I think we should handle:

• JobBroadcaster / init should call [ :quantum, :job, :add ] for all jobs
• JobBroadcaster / delete_all should call [ :quantum, :job, :delete ] for all jobs
• [:quantum, :job, *] should contain the job itself in the metadata
• [:quantum, :job, *] should contain the scheduler module name itself in the metadata (if someone has multiple schedulers)

[mrmarcsmith]

@maennchen I have completed your requested changes. I am wondering if passing module: __MODULE__ in the metadata was what you were asking for in point 4 because that was already present

[maennchen]

@mrmarcsmith This is not exactly what I meant with the module:

There's a name for the main scheduler. This would for example be Acme.Scheduler (The module that contains the use Quantum code)

JobBroadcaster: This module name is available as scheduler in the State.

Executor: The scheduler is not yet passed to the executor module. It has to be passed from the Supervisor to ExecutorSupervisor.start_link/1 to ExecutorSupervisor.init/1 to Executor.execute/3.

[maennchen]

@mrmarcsmith PS: Sorry for the merge conflict. Can you solve it our should I resolve it before merge?

[mrmarcsmith]

@maennchen Sounds good! I can take of those merge conflicts

[mrmarcsmith]

@maennchen This is ready to be re-reviewed. I ended up adding the scheduler option to the following opts modules so i could pass the scheduler around. Can you think of any end user rational for accessing these ops modules directly that might be a breaking change?

• Quantum.ExecutorSupervisor.StartOpts
• Quantum.ExecutorSupervisor.InitOpts
• Quantum.Executor.StartOpts

[maennchen]

We also need to trigger an update event here:

• https://github.com/quantum-elixir/quantum-core/pull/453/files#diff-2d3fae9a29455d58e947c99642c86ecbR134
• https://github.com/quantum-elixir/quantum-core/pull/453/files#diff-2d3fae9a29455d58e947c99642c86ecbR196

[maennchen]

This will only be executed for active jobs. I think we also want to call it on inactive ones.

[maennchen]

@mrmarcsmith This is for sure not a breaking change. The modules are not documented and therefore considered internal.

[mrmarcsmith]

@maennchen dialyzer is throwing Unknown type: Module.t/0 on the change you made. How do you want to proceed?

[maennchen]

@mrmarcsmith Oops, that's not the first time i make this error. Should just be atom().

[mrmarcsmith]

testing now

[maennchen]

@mrmarcsmith After this change it's ready to merge 😊

[mrmarcsmith]

local test and dialyzer passed! Thank you for the help