Framework Definitions - Intel ® Cluster Checker Plugins
Framework definitions (FWDs) are plugins with the purpose of defining the scope of both data collection and analysis for Intel® Cluster Checker. Unless otherwise specified, Intel® Cluster Checker will use the health_base framework definition (health_base.xml). Pre-defined framework definitions are located at or .
/opt/intel/clck/20.x.y/etc/fwd/
/opt/intel/oneapi/clck/<version>/etc/fwd/
FWDs can contain:
Other framework definitions
: A framework definition may contain other framework definitions. They are found inside the includes
include
<includes> <include>path/to/fwd.xml</include> </include>
Data providers
: For data collection, the providers contained in a framework definition define the data to be collected. The tag providers
provider
<providers> <provider>provider_name</provider> </providers>
Message catalogs (signs and diagnoses)
: The message catalog defines what messages will appear to describe signs, diagnoses, and remedies. The tag message
catalogs
group
group
entry
<message_catalogs> <group> <entry>message_catalog.xmc</entry> </group> </message_catalogs>
Analyzer extensions
: During analysis, an analyzer_extension
analyzer_extension
group
group
entry
<analyzer_extension> <group> <entry>analyzer_extension_name</entry> </group> </analyzer_extension>
Knowledge base modules
: The knowledge base contains rules that produce signs and diagnoses. The tag kb_mods
mod
<kb_mods> <mod>kb_mod.clp</mod> </kb_mods>
A description
: The tag fwd_descr
<fwd_descr>This framework definition is an example</fwd_descr>
Postprocessor extensions
: Postprocessor extensions are responsible for formatting the results of analysis and providing readable output. The tag postproc_extensions
group
entry
Extending Intel® Cluster Checker
.<postproc_extensions> <group> <entry>postprocessor_extension_name</entry> </group> </postproc_extensions>
Groups
: The group
abc
def
group
<analyzer_extension> <group path="abc/"> <entry>extension1</entry> <entry>extension2</entry> </group> <group path="def/"> <entry>extension3</entry> <entry>extension4</entry> </group> </analyzer_extension>
Provider path
: The provider_path tag defines a custom path for provider XML files. The default provider path is /opt/intel/clck/20.x.y/etc/providers
<provider_path>custom_provider_path</provider_path>
Provider auxiliary path
: The provider_auxiliary_path tag defines a custom path for provider scripts. The default provider path is /opt/intel/clck/20.x.y/provider/share
<provider_auxiliary_path>custom_provider_auxiliary_path</provider_auxiliary_path>
Analyzer extension path
: The extension_path
/opt/intel/clck/20.x.y/analyzer/intel64/cpp
<extension_path>analyzer_extension_path</extension_path>
Knowledge base path
: The kb_path
/opt/intel/clck/20.x.y/kb
<kb_path>custom_kb_path</kb_path>
The following file myFramework.xml contains an example of a custom framework definition. This framework definition includes the framework definition myFramework2.xml. Additionally, it specifies the provider myProvider and the analyzer extension myExtension. The CLIPS knowledge base module defines the classes and rules to run. The message catalog messages.xmc will define any messages to display.
myKB_Module.clp
The provider path, provider auxiliary path, extension path, and knowledge base path are commented out in this example. The tool will now use the default locations for these paths
<configuration> <framework_definition name="myFramework"> <includes> <include>fwd/myFramework2.xml</include> </includes> <providers> <provider>myProvider<provider> </providers> <message_catalogs> <group> <entry>messages.xmc</entry> </group> </message_catalogs> <analyzer_extension> <group> <entry>myExtension</entry> </group> </analyzer_extension> <kb_mods> <mod>myKB_Module.clp</mod> </kb_mods> <!--<provider_path></provider_path> --> <!--<provider_auxiliary_path></provider_auxiliary_path> --> <!--<extension_path></extension_path> --> <!--<kb_path></kb_path> --> <fwd_desc>This is my custom framework definition</fwd_desc> <framework_definition> </configuration>