A key-value pair associated with a Modality entity. Most Modality entities can have attributes, notably events, timelines, and workspaces. Attributes are a core part of how Modality works, letting you store and manage arbitrary data in a structured way. Event attributes commonly contain either system runtime information or metadata useful for managing and organizing the events. For example, an event fired by a sensor might have a
payload attribute to report the runtime sensor reading value, as well as a
subsystem attribute, allowing you to lump it together with all other events from its subsystem for analysis.
# Causal Graph
Underlying data representation of recorded system execution in Modality. Modality records events sequentially per timeline, and timelines can be causally related by recording their interactions. This representation is what underlies Modality's SpeQTr language, allowing you to see which events precede (and could therefore potentially have caused) other events.
Type of plugin used with the
modality-reflector run command to run long-running data collection operations that listen indefinitely for data from running systems. This is in contrast to importers, which are for discrete data collection operations on fixed sets of data, typically from files.
Unit of information collected by Modality and used to build a trace. Every event must be associated with a single timeline. Events can have any number of attributes to report system data or event metadata. Events can come from whatever underlying tracing technology your system uses through Modality's data collection plugins.
# Logical Time
Use of clocks based on ordering rather than actual wall-clock time. Logical time values only mean anything in relation to each other. If event
a was recorded at logical time
1 and event
b was recorded at logical time
3, we know
a happened before
b. Differently to wall-clock time, though, logical time doesn't necessarily tell us how much earlier
a was than
b. Logical time underlies Modality's tools related to causality, with the idea that if event
a happened before event
a could have contributed to causing
Modality's daemon which receives system data, builds a trace of overall system execution, and serves trace data to the CLI. To collect or import data a connection to modalityd must be available. To analyze collected data, the CLI must have the connection to modalityd correctly configured. These connections are configured with the modalityd configuration file, the modality-reflector configuration file for data collection, and the
modality config command for CLI configuration.
Type of plugin used with the
modality-reflector import command to run data collection operations for fixed sets of data, typically from files. This is in contrast to collectors, which are for long-running data collection operations that listen indefinitely for data from running systems.
A way to record causal links between timelines. Every time a timeline communicates with another the sending timeline could have influenced the behavior on the receiving timeline. If you record events with the appropriate special attributes Modality can track these interactions between timelines. This allows Modality to trace causal connections between timelines, enabling you to query for event patterns across timelines.
Platform or data source specific extension to a reflector for collecting data to Modality. Plugins functionally translate from a given tracing technology to Modality's data format, enabling you to get whatever data your system produces into Modality. There are two types of plugins for data collection—importers and collectors. Auxon Deviant introduces a third type of plugin, mutators, for manipulating your system's behavior.
A subset of the data in a workspace, generated automatically by Modality according to a segmentation rule in the workspace definition file. Segments let you automatically chunk up your data based on timeline attributes. One example use case for segments is to separate runs of your system—you could have a workspace for all the data collected from a given test rig segmented by
run_id, automatically creating a segment for each discrete run of your system.
Data collection infrastructure for Modality. Reflectors receive data from your system and send it to modalityd. They use an extensibility model based on plugins to be able to collect any kind of data. Reflectors can be chained to create a flexible data collection architecture to match your system constraints. They can also add attributes to the events and timelines that pass through them, enabling you to automatically enhance your data with architecture-based metadata.
# Time Domain
Analysis of signals and events with respect to wall clock time. This is in contrast to the logical clocks that Modality uses which are not associated with wall clock time but rather with the sequence of events. Because clocks drift, wall clock time can only be used in Modality for timelines which are in the same time domain, i.e. which use the same clock.
A sequence of events with a specific ordering. Timelines are flexible, so mapping your system to a set of timelines is up to you. A timeline essentially just needs to be a source of events that you know will be in order. For a desktop application you might have a timeline for each thread. In an embedded system, each microcontroller could be a timeline. Timelines have attributes which you can use to filter them when defining workspaces and segments.
Generic term for a collection of events, timelines, and their relations that Modality builds into a causal graph to record what happened during system execution.
View onto Modality's database that only consists of a certain subset of the data. Since Modality's database contains all data you have ever collected, workspaces are necessary to ensure you ask questions of the appropriate set of data. You define workspaces with a workspace definition file, selecting which timelines should be included. In addition, Modality can automatically split your workspace into segments based on rules in your workspace definition.