2021.03.29

Multi-Instance Plugin Documentation

• Sampler plugin development guide: ldmsd-sampler-dev
• Storage plugin development guide: ldmsd-store-dev

Meeting Notes:

Sampler plugin API

• Mult-instance plugin interface

• Currently implemented in master branch

• Tom would like to implement it with those who would like to use it and test it

• Design goals:

  • Support legacy and multi-instance plugins concurrently
  • Query plugin implementation version (e.g. ensure a plugin is compatible w/ the ldmsd version)

• Multiple instances of a plugin w/ different configurations

  • Storage plugins

• CSV store w/ separate output sub-directories

  • SOS store w/ different root path

• Sampler

  • vmstat samplers w/ different schema
  • Disk samplers, one for each monitored device

• Dynamically add new plugin types

• Share common base-class logic across plugin instances of the same type

• Query the metric sets provided by a plugin

• Query the configuration of a plugin

• Ability for plugins exchange data over a transport

  • Receive dynamic/asynchronous data from computes
  • Receive status/state info from remote

• Plugin types

  • Dynamic additions of new plugin types

• New plugin types added by loading its base class shared library and classing its init() interface

  • Plugin uniquely identified by its name
  • List of loaded plugin types can be queried from config interface
  • Set of pre-defined plugin types can be pre-loaded

• Plugin instances:

  • Instance shares base class logic from plugin-type.

• Sampler plugin goals:

  • Can normalize the metric set schema to contain the attributes necessary for effective storage and analysis
  • Supports different base-classes for sampler
  • Minimize the logic present in each sampler
  • Support samplers that produce multiple metric sets
  • Support samplers that have sets that change

• Multiple version types that will check the version of ldmsd and the base/sub-classes. Multiple checks that will see if ldmsd and the base/sub-classes match.

• Concerns regarding changes in the config or changes to how things are initialized or when the schemas are updated.

• On the agenda for next meeting:

  • Storage partitions.