Integration API

Integration allows you to customize every major aspect of Blip without modifying its core code. That lets you tailor Blip to meet your requirements and work in your 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 object 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", args)

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.

External database modules use a separate RegisterDatabaseModule hook to declare and validate a database type. The module still uses the metrics registry for its collectors. See Database modules for the complete integration contract.

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

An external database module decorates the database factory instead of replacing unrelated database support. See Database modules for the fallback and provider delegation requirements.

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

Set Plugins.ParsePasswordSecret to customize how Blip maps the raw AWS Secrets Manager payload from config.aws.password-secret to database credentials. If this callback is not set, Blip uses DefaultPasswordSecretParser: password is required, and username is optional. Blip passes SecretString bytes when present; otherwise, it passes SecretBinary bytes. The credentials argument is initialized with the configured monitor username; custom parsers must set credentials.Password and can override credentials.Username.

Blip’s built-in MySQL factory and external modules that use the shared credential factory honor this callback.

plugins.ParsePasswordSecret = func(ctx context.Context, cfg blip.ConfigMonitor, payload []byte, credentials *blip.DbCredentials) error {
    credentials.Password = string(payload)
    return nil
}

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.