Support for arbitrary target metadata about canary HOT 3 CLOSED

So this is a feature i have been working as well as it would be very important for my uses of this in a site monitoring project I am working on.

I have a patch written that implements a counter on each Sensor for the "number of concurrent checks" for the given state (pass/fail, currently defined by return code being above 400). However, this is not in a PR as it builds off #26.

#26 implements a first attempt at the ability to reload canaryd live. Once that is in I do want to refactor it to not have to wait for all sensors to stop, but only sensors for targets that are no longer defined in the manifest. Once that change goes in, I would like to add a separate goroutine that periodically checks the manifest for changes, and if changes are detected initiate a reload (which I believe is a feature listed for the v4 release).

Once #26 is in, I can put the above feature up for review, and will start on the features I want:

• Ability to specify request headers (per target url in the manifest)
• Ability to check for response headers (per target url, and will be part of the measurements that is published)
• Ability to check for patterns (be it simple string inclusion or regex) per target url, affecting pass/fail).

It would also be nice to dynamically specify the pass/fail conditions in the manifest, such as:

• expected "pass" return codes (some urls should pass on a 403 by example),

lastly, it might be nice to move away from ENV variables for a lot of the daemon configurations (default sampling interval, rampup mode, etc). This could be done via a local configuration JSON file, or including them in the manifest that is loaded.

I think with those abilities canaryd will be much more usable as a site monitoring agent.

@blalor @gorsuch what are your thoughts on the above feature sets? I have no problems implementing these, but will have to do them in order and will be blocked on the reviews.

from canary.

Overall that sounds good to me, but I don't see "metadata" in there anywhere. :-)

Reloading will be useful. I'm going to be putting the manifest into Consul to distribute out to sensors in different datacenters.

The current Target implementation could be expanded to either have a Metadata interface{} field which could be blindly deserialized from JSON, or separate Tags []string and Attributes map[string]string fields. The advantage of the former is that arbitrarily-structured data could be passed to publishers. The latter would be more structured within the framework, and is probably a better solution overall…

from canary.

I believe we can consider this issue closed with #28 landing (thanks @blalor!).

@jmeichle feel free to open up individual PRs or issues to discuss your above ideas. I'm a big fan of where you are going in general, but getting down to the specifics would probably be easier for discussion.

from canary.