Skip to content

Latest commit

 

History

History
92 lines (66 loc) · 3.95 KB

PLUGIN_LIFECYCLE.md

File metadata and controls

92 lines (66 loc) · 3.95 KB
Raw

Plugin life cycle

A Snap plugin can be in a Loaded or Running state. A plugin can be loaded in the following two ways.

  1. snapteld was started with an auto discover path snapteld -a /opt/snap/plugins
  2. A user loads a plugin through the REST API or using the snaptel
    • curl -F file=@snap-plugin-publisher-file http://localhost:9191/v1/plugins
    • snaptel plugin load snap-plugin-publisher-file

A plugin transitions to a running state when a task is started that uses the plugin. This is also called a plugin subscription.

What happens when a plugin is loaded

When a plugin is loaded snapteld takes the following steps.

  1. Handshakes with the plugin by reading it's stdout
  2. Updates the metric catalog by calling the plugin over RPC
    • GetMetricTypes returns the metrics the plugin provides
    • GetConfigPolicy returns the conf policy that the plugin needs
  3. The plugin is stopped

It should be emphasized that when a plugin is loaded it is started but stopped as soon as the metric catalog has been updated.

What happens when a plugin is unloaded

When a plugin is unloaded snapteld removes it from the metric catalog and running instances of the plugin are stopped.

What happens when a task is started

When a task is started the plugins that the task references are started and subscribed to. The following steps are taken when a task is created and started.

  1. On task creation the task is validated (snaptel task create -t mytask.yml --no-start)
    • The schedule is validated
    • The config provided for the metrics (collectors), processors and publishers are validated
  2. On task starting the plugins are started (snaptel task start <TASK_ID>)
  3. Subscriptions for each plugin referenced by the task are incremented

Diving deeper

Task started - When a task is started the plugins which are referenced by the task manifest are subscribed to and a 'subscription group' is created. A 'subscription group' is a view that contains an ID, the requested metrics, plugins and configuration provided in the workflow.

start_task

Task stopped - When a task is stopped the plugins referenced by the subscription group are unsubscribed and the subscription group is removed.

stop_task

Plugin loaded/unloaded - When a plugin is loaded or unloaded the event triggers processing of all subscription groups. When a subscription group is processed the requested metrics are evaluated and mapped to collector plugins. The required plugins are compared with the previous state of the subscription group triggering the appropriate subscribe or unsubscribe calls. Finally, the subscription group view is updated with the current plugin dependencies and the metrics that will be collected based on the requested metrics (query).

load_unload_plugins

CollectMetrics - When a task fires and CollectMetrics is called the subscriptionGroup is used to lookup up the plugins that will be called to ultimately perform the collection.

collect_metrics