Integration API

Integration allows you to customize every major aspect of Blip without modifying its core code. That makes it easy and safe to tailor Blip to meet any requirements and work in any environment. For example, Blip does not collect MySQL NDB metrics, but if you run NDB, you can write a custom metrics collector for NDB, register it in Blip, then collect NDB metrics exactly the same as the built-in metric collectors. In fact, the built-in metric collectors implement the same interface; the only difference is that Blip automatically registers them on startup.

How you integrate with Blip depends on what you’re trying to customize:

All integrations must be set before calling Server.Boot.

A registry maps a resource name to a factory that produces an object for the resource. Blip has three registries:

The metric and sink registries are the most important: they allow you to make Blip collect any metrics and send metrics anywhere.

Every registry has a corresponding Make function that Blip uses to make objects for the named resources. For example, when a plan collects the status.global domain, internally Blip makes a call like:

collector, err := metrics.Make("status.global")

That works because Blip registered the built-in factory for the status.global metric domain on startup. This is also how custom metric collectors work: by registering a custom metric domain name and factory.

Factories are interfaces that let you override certain object creation of Blip. Every factory is optional: if specified, it overrides the built-in factory.

Plugins are function callbacks that let you override specific functionality of Blip. Every plugin is optional: if specified, it overrides the built-in functionality.

Implement a Receiver, then call event.SetReceiver to override the default. There is only one event receiver; use Tee to chain receivers.

Various packages have public variables that you can modify to fine-tune aspects of Blip. For example, the heartbeat package has several timeout and retry wait durations.