diff --git a/site/plugins.md b/site/plugins.md index cbfb83388..ef8da18a2 100644 --- a/site/plugins.md +++ b/site/plugins.md @@ -6,9 +6,11 @@ menu_order: 80 The following topics are discussed: * [Official Plugins](#official-plugins) - * [Listening Protocol](#listening-protocol) - * [Reporting](#reporting) - * [Interfaces](#interfaces) + * [Plugins Internals](#plugins-internals) + * [Plugin ID](#plugin-id) + * [Plugin Registration](#plugin-registration) + * [Reporting](#interfaces-interface) + * [Other Interfaces](#other-interfaces) With a Scope probe plugin, you can insert custom metrics into Scope and have them display in the user interface together with the Scope's standard set of metrics. @@ -32,15 +34,30 @@ You can find all the official plugins at [Weaveworks Plugins](https://github.com If the running plugin was picked up by Scope, you will see it in the list of `PLUGINS` in the bottom right of the UI. -## Listening Protocol +## Plugins Internals + +This section explains the fundamental parts of the plugins structure necessary to understand how a plugin communicates with Scope. +You can find more practical examples in [Weaveworks Plugins](https://github.com/weaveworks-plugins) repositories. + +### Plugin ID + +Each plugin should have an unique ID. It is forbidden to change it +during the plugin's lifetime. The scope probe will get the plugin's ID +from the plugin's socket filename. For example, the socket named +`my-plugin.sock`, the scope probe will deduce the ID as +`my-plugin`. IDs can only contain alphanumeric sequences, optionally +separated with a dash. + +### Plugin registration All plugins must listen for HTTP connections on a Unix socket in the `/var/run/scope/plugins` directory. The Scope probe recursively scans that directory every 5 seconds, to look for any sockets being added (or removed). It is also valid to put the plugin Unix socket into a sub-directory, in case you want to apply some permissions, or store any other information with the socket. -When a new plugin is detected, the scope probe begins requesting reports from it via `GET /report`. +When a new plugin is detected, the scope probe begins requesting reports from it via `GET /report`. So every plugins **must** implement the report interface. +Implementing an interface means handling specific requests. All plugin endpoints are expected to respond within 500ms, and respond in the JSON format. -### Reporting +### Reporting Interface When the Scope probe discovers a new plugin Unix socket, it begins to periodically make a `GET` request to the `/report` endpoint. The report data structure returned from this will be merged into the probe's report and sent to the app. An example of the report structure can be viewed at the `/api/report` endpoint of any Scope app. @@ -63,17 +80,15 @@ For example: } ``` -> **Note:** The `Plugins` section includes exactly one plugin description. The plugin description fields are: `interfaces` including `reporter`. - -The fields are: +> **Note:** The `Plugins` section includes exactly one plugin description. The plugin description fields are: * `id` is used to check for duplicate plugins. It is required. * `label` is a human readable plugin label displayed in the UI. It is required. -* `description` is displayed in the UI -* `interfaces` is a list of interfaces which this plugin supports. It is required, and must equal `["reporter"]`. -* `api_version` is used to ensure both the plugin and the scope probe can speak to each other. It is required, and must match the probe. +* `description` is displayed in the UI. It is required. +* `interfaces` is a list of interfaces which this plugin supports. It is required, and must contain at least `["reporter"]`. +* `api_version` is used to ensure both the plugin and the scope probe can speak to each other. It is required, and must match the probe's value. -### Interfaces +### Other Interfaces Currently the only interface a plugin can fulfill is `reporter`.