Introduction

Organizations need visibility into how frequently models are being used, and to keep track of distributions of input and output data. ModelOp Center provides volumetric monitors out-of-the-box (OOTB) but also allows you to write your own custom metrics to monitor your model. The subsequent sections describe how to add a volumetric monitor, assuming an OOTB monitor.

Adding Volumetric Monitors

As background on the terminology and concepts used below, please read the Monitoring Concepts section of the Model overview documentation.

To add volumetric monitoring to your business model, you will add an existing “Monitor” to a snapshot (deployable model) of the business model under consideration. Below are the steps to accomplish this. For tutorial purposes, these instructions use all out-of-the-box and publicly available content provided by ModelOp, focusing on the German Credit Model and its related assets.

The "German Credit Data" dataset classifies people described by a set of attributes as good or bad credit risks. Volumetric monitoring can be used to govern the model in various ways including verifying that the number of input records match the number of output records and matching identifiers in input records to output records.

Associate a Monitor to a Snapshot of a Business Model

1. In MOC, navigate to the business model to be monitored. In our case, that’s the German Credit Model.

2. Navigate to the specific snapshot of the business model. If no snapshots exist, create one.

3. On the Monitoring tab, click on + Add, then click on Monitor

   Open

   

4. Search for (or select) the Volumetric Monitor: Summary from the list of OOTB monitors.

5. Select a snapshot of the monitor. By default, a snapshot is created for each OOTB monitor

   Open

   

6. On the Input Assets page, you’ll notice that the only asset that is required is sample data. This is because this volumetric monitor computes metrics on 1 dataset only, and thus does not do a comparison to a baseline/reference dataset. For our example, select df_sample_scored.json as the Sample Data Asset. Since the file is already an asset of the business model, we can find it under Select Existing

7. We will skip adding a threshold on this monitor. For examples on how to add a threshold, please visit this page.

8. The last step in adding a monitor is adding an optional schedule. To do so, click on ADD A SCHEDULE. The Schedule Name field is free-form. The Signal Name field is a dropdown. Choose a signal that corresponds to your ticketing system (Jira, ServiceNow). Lastly, set the frequency of the monitoring job. This can be done either by the wizard or by entering a cron expression. Note: schedules are optional; a monitor may be run on-demand from the business model’s snapshot page, or by a curl command.

9. On the Review page click SAVE

To run a monitor on demand, click on COPY CURL TO RUN JOB EXTERNALLY. The CURL command can then be run from the application of your choosing.

Run a Monitor On-demand (UI)

To run a monitor on-demand from the UI, navigate to the business model’s snapshot page and click the play button next to the monitor of interest. A monitoring job will be initiated, and you will be redirected to the corresponding job page once the job is created.

Schedule a Monitor DIY (CURL)

Monitors can be scheduled to run using your preferred enterprise scheduling capability (Control-M, Airflow, Autosys, etc.) While the details will depend on the specific scheduling software, at the highest level, the user simply needs to create a REST call to the ModelOp Center API. Here are the steps:

1. Obtain the Business Model snapshot’s UUID. This can be found, for instance, in the URL of the snapshot page, as shown in this example:

2. Similarly, obtain the Monitoring Model snapshot’s UUID.

3. Within the scheduler, configure the REST call to ModelOp Center’s automation engine to trigger the monitor for your model:

   1. Obtain a valid auth token

   2. Make a call (POST) to the ModelOp Center API to initiate the monitor. The endpoint is

      <MOC_INSTANCE_URL>/mlc-service/rest/signal

   3. The body should contain references to the Model Life Cycle (MLC) being triggered, as well as the business model and monitor snapshots, as shown below:

      { "name": "com.modelop.mlc.definitions.Signals_Run_Associated_Model_Jira", "variables": { "DEPLOYABLE_MODEL_ID" : { "value": <UUID_of_business_model_snapshot_as_a_string> }, "ASSOCIATED_MODEL_ID": { "value": <UUID_of_monitoring_model_snapshot_as_a_string> } } }

This process is made easier by copying the CURL command provided at the last step of the monitoring wizard

The copied command will look something like this:

curl 'http://localhost:8090/mlc-service/rest/signalResponsive' -H 'Accept: application/json, text/plain, /' -H 'Content-Type: application/json' -X POST -H 'Authorization: Bearer <token>' --data-raw '{"name":"com.modelop.mlc.definitions.Signals_Run_Associated_Model_Jira","variables":{"DEPLOYABLE_MODEL_ID":{"value":"23282688-62a6-47ae-8603-16f380efca57"},"ASSOCIATED_MODEL_ID":{"value":"1dc64c1e-3634-4e2e-b37d-71d04a9ee5ef"}}}'

Monitoring Execution

Once the scheduler triggers the signal, the corresponding MLC (listening to that signal) will be initiated. The sequence of events include:

1. Preparing the monitoring job with all artifacts necessary to run the job

2. Creating the monitoring job

3. Parsing the results into viewable test results

4. Comparing the results against the thresholds in the decision table

5. Taking action, which could include creating a notification and/or opening up an incident in JIRA/ServiceNow/etc.

These steps can be summarized in the following Model Life Cycle (MLC)

Monitoring Results and Notifications

Sample Standard Output of a Volumetric Monitor

Monitoring Test Results are listed under the Test Results table:

Upon clicking on the “View” icon, you’ll have two options for looking at test results: graphical (under “Test Results”), and raw (under “Raw Results”).

Visual elements

1. Numerical Summary Table

2. Categorical Summary Table

Raw Results

The “Raw Results” tab shows a clickable (expandable and collapsable) JSON representation of the test results

To get a JSON file of the test results,

1. Navigate to the “Jobs” tab of the snapshot and click on “Details” next to the monitoring job of interest

2. Click on “Download File” under “Outputs”

Sample Monitoring Notification

Notifications arising from monitoring jobs can be found under the corresponding model test result

If a ticketing system is configured in ModelOp Center, such as Jira, a ticket will be written when an ERROR occurs (as in above), and a link to the ticket will be available next to the notification. In the example above, since there were no thresholds set on the monitor, the job automatically passed.

Volumetric Monitors Details

Model Assumptions

Business Models considered for volumetric monitoring have a few requirements:

1. An extended schema asset for the input data.

2. Input data contains at least one numerical column or one categorical column.

Model Execution

During execution, volumetric monitors execute the following steps:

1. init function extracts extended input schema (corresponding to the BUSINESS_MODEL being monitored) from job JSON.

2. Monitoring parameters are set based on the schema above. numerical_columns and categorical_columns are determined accordingly.

3. metrics function runs a summary volumetric test.

4. Test result is returned under the list of volumetric tests.

For a deeper look at OOTB monitors, see the Python Monitoring package documentation (subscribed Customers only): https://modelopdocs.atlassian.net/wiki/spaces/py132