Item types – meshIQ

The tracking data model consists of the following item types.

Item Type	Definition
Activities	A collection of related Events and/or sub-activities, as identified by instrumented application.
Events	An Event represents a distinct application operation or statement, optionally containing associated message data.
Snapshots	A Snapshot is a collection of information, as key/value pairs, identified by name and the time the information was collected.
Sources	A Source represents the origin of Events, Activities, and Snapshots. A Source is identified by a string known as its Fully-Qualified Name (FQN), which defines its ENCLOSES relationships.
Resources	A Resource represents the object that Events, Activities and Snapshots act on, or execute within. It also can be using an FQN string, which will identify the type of resource, as well as its name. Supported resource types are: DATASTORE CACHE SERVICE QUEUE FILE
Dictionaries	A Dictionary entry represents a free-form record. It is essentially a named collection of key/value pairs. The specific keys are application- and/or user-dependent. The type of the keys is STRING. The values can be of BOOLEAN, INTEGER, STRING or TIMESTAMP. Dictionary entries differ from the others that they are not tied to a specific repository. They can be associated with several repositories, or not associated with any repositories.
Sets	A Set is used to identify Activities and Events that meet specific criteria, as well as to define the objectives, or conditions, that the items that match the set should meet. The critical attributes of a Set are: Criteria – defines the conditions that must be met for inclusion in the set. Objectives – define the set of conditions that must be met (or should not be met) by members of the Set. Scope – defines how to include Activities and Events into the set, and is one of: Singular – Only the Activities and Events that directly match the Set Criteria are included in the set. These types of sets are commonly referred to as “Milestones”. Related – All Activities and Events that are “related” (stitched to) to those that directly match the Criteria are included. These types of sets are commonly referred to as “Groups”. Sequence – for Related sets, defines the expected sequence of Singular subsets.
Relatives	Relatives define the observed relationships between event and activity Sources, as well as the relationships between Singular Sets. The following relationships are identified: ENCLOSE – parent Source encloses, or contains, the child Source (e.g. DataCenter encloses Server indicates that the specified Server is in the specified DataCenter) SEND_TO – parent Source sends a data message to the child Source (e.g. Application A sends to Application B indicates that Application A has sent a message and Application B has received the same message), or parent Set sends a data message to child Set. ACTS_ON – parent Source “acts on” or “manipulates” child Resource (e.g. Application A acts on Resource B). This can be one of the subtypes below: ACTS_ON_WRITE – parent Source wrote to child Resource ACTS_ON_READ – parent Source read from child Resource
Input Data Rules	Input data rules allow for field value calculations at data ingest time. Both built-in fields and custom properties can be computed from other built-in fields or custom properties, and also from other computed fields. The computed value could be used to replace any value that’s already there, or appended to any existing value(s). By default, the input data rules are applied to all incoming Activities, Events, and Snapshots. However, the rules can have an optional criteria defined, so that the rules are only applied to specific input data.
Providers	A Provider is an instance of the implementation of a type of provider, which represents definition for the particular type of action to execute, generally in response to a trigger condition. A Provider Type defines a set of supported properties to control its execution. jKQL includes the following defined Provider Types: FileWriter – defines implementation of writing information to a file Emailer – defines the implementation of sending information in an email A Provider definition would represent an instance of one of these types, optionally with the default value for one or more of the Provider Type’s properties. For example, a Provider named “FileAppender” could be defined as an instance of FileWriter, with the value of the FileWriter “Append” set to TRUE, so that, when data is written to the file, it is appended to the current contents of the file.
Actions	An Action represents a task to execute, generally in response to a trigger condition, and is an instance of a particular Provider (NOT Provider Type), defining the values required by the specified Provider’s Type. For example, an Action named “WriteToLogFile” could be defined that would use Provider “FileAppender”, setting the FileWriter property “FileName” to “/tmp/trigger.log”. Triggers that reference this action would cause data to be appended to file “/tmp/trigger.log’.
Triggers	A Trigger represents a condition to test for, along with the Actions to take when the condition is met. The condition is specified using same format as in Subscribe (without the SUBSCRIBE TO and SHOW AS).
Jobs	Job entries represent the state of past, current, and scheduled jobs.
Logs	Log entries are records of actions occurring in system. The following log categories are supported: ERROR – errors that occurred during the processing of jobs, data streaming, user queries QUERY – user queries executed SUBSCRIBE – user subscriptions submitted and canceled TRIGGER – triggers started and stopped GENERAL – other items not fitting into the above categories
ViewTemplates	A ViewTemplate defines a generic template for a View. It defines a jKQL query (optionally with substituted parameters).
Views	A View represents a named query, providing a fixed result structure. The implementation is analogous to an SQL Materialized View. The query is either defined explicitly in the View definition itself, or is inherited from the ViewTemplate on which it is based. In the case of the latter, the View definition would include bindings for the specific parameters required by ViewTemplate. Views are evaluated on a defined interval, with the results cached for quick retrieval.
MLModels	MLModels are used for Machine Learning. In order to run Machine Learning on data, a ”model” must be created. Each model has specific attributes which are stored in MLModel.
Datasets	Datasets contain freeform, unanalyzed data. Entries to Datasets table are saved as is, with no additional processing. They can be used to store aggregations of other data items (Events, Snapshots, etc.), or can be used to store simple raw data. Their primary purpose is to define sets of data for Machine Learning.