Fields Overview

Field configuration objects provide Mona with instructions for initial processing of the exported data, essentially laying out the schema of the Context Class, while utilizing Mona’s extensive ETL capabilities, allowing, for example, to create new metrics to track, derived from the raw data. If the Context Class can be treated as a description of a data table on Mona’s analytical database, then the Fields are the definitions for the table’s columns.

Fields are created using field-building functions, which take exported data variables (or other, previously computed Fields) as input sources. By default, Mona will use the identity function, which is the function you leverage if you want to use the data you export as is without special manipulations. A complete list of available functions is available on the next page.


Character Limitations

  • A field name must contain either A-Z, 0-9, or "-","_","@"
  • A field name can not be only a number (123 is NOT accepted, while abc123 is)
  • A field name can not be a single symbol ("_", "-", or "@" are NOT accepted, but "@@@" is)

A Field configuration object MUST contain the following:

  • type : A mandatory parameter, unless do_not_save = true. Tells Mona how to treat the output of the field building function. Valid options are numeric, string, and boolean. Additional types, e.g., vector and timestamp, are planned for future versions.
    • NOTE: When using a specific type, Mona will try to cast (pythonic way) the actual function output to that type. So, for example, if you’re using a field-building function that returns a string, but your type is boolean, a non-empty string will cause a true value.

A Field configuration object CAN contain the following:

  • source OR sources:
    • source: To be used when the Field should be created based on a single exported variable/previous field. There are three variations of this:
      • String representing the source variable / previously defined field name.
      • An array with variable names. Mona will try the variable names in order, such that if one is missing or has null data, the next one will be used.
      • An object with variable names and a default value. Example: {"names": ["source_name_1", "source_name_2"], "default_value": 0}
    • sources: To be used when the Field should be created based on multiple exported variables. An array, in which each value represents one source, and follows the structure mentioned above for the “source” parameters.
    • By default, if no "source" or "sources" are mentioned, the Field‘s name (as given in the JSON key) is used as the single source.
    • TIME: one of Mona's default sources is the "TIME" source. This "TIME" represents the exact time an instance occurs. With field-build-functions, this source can be used to create new fields such as "day_of_week" and others.


Field Ordering

When building fields during data ingestion, a field’s “source” will be searched for in the list of existing fields defined before the given field, and if not found, will be searched for in the raw data exported to Mona. Therefore, the order of fields has consequences - if you plan to derive a field from another field, you must order them accordingly

  • function: A single field-building function to use. Available functions are listed below. Defaults to "identity" - which is also the common case: when you just want to use a value exactly as you exported it to Mona.

  • do_not_save: A boolean that can state that a field is an intermediary calculation, only to be used as a source for other fields, and should not be stored as part of the Context schema.

  • use_as_metric: A boolean that states whether a boolean or numeric field should be used as a performance metric in the monitoring context or not. Default is true.

  • args: An array of arguments to send to the field-building function

  • kwargs: A dict of argument keys and values to send to the field-building function. “args” and "kwargs" are to be used similarly to how they are used in Python.

Did this page help you?