Our integration with Collibra is now available in public preview! It enables customers to integrate data and AI observability directly into their data catalog. This helps teams manage trust at scale, communicate incidents clearly, and track the health of data assets directly where stakeholders already work.
We've made some tweaks to our Volume anomaly detection, making it slightly less sensitive. Users should expect Volume thresholds to widen slightly, with the effect of roughly ~20% fewer Volume alerts.
A few months ago, we rebuilt our Volume anomaly detection, making it dramatically more sensitive. These changes nearly tripled the number of Volume alerts that Monte Carlo sends. The overall reception to these changes has been great, but we've found the default 'Medium' sensitivity to be sending more alerts than is universally desirable. As a result, we've implemented these changes to make it slightly less sensitive.
Users can still benefit from our most sensitive anomaly detection by setting Sensitivity to High.
The Asset Editor and Asset Viewer user roles are no longer available. These roles only had access to the Assets page in Monte Carlo. They were introduced a few years ago for customers who were using Monte Carlo as a data catalog. However, users have generally struggled to see value when assigned these roles, so ultimately we have chosen to deprecate them.
Configurations (users, authorization groups, single sign-on defaults, etc) that already have these roles selected will not be impacted. They can keep the Asset Editor and Asset Viewer role.
Users can now discover and investigate ETL job performance issues natively in MC via the Job Performance Dashboard. Airflow DAGs, dbt jobs, Databricks workflows, Azure Data Factory pipelines are supported. See docs here.
Over the next two weeks, all Dimension Tracking monitors will be switched over to Metric Monitors that use the Relative row count metric. No interruption to service or monitoring coverage is expected. You can read more about the Relative row count metric in our documentation.
The change is part of a broader effort over the last several months to clean up old monitor types. This helps to streamline reporting, filtering, and overall usability across Monte Carlo.
This change has been communicated to affected accounts over email during the last several weeks.
Over the coming weeks, we’ll release major changes to how users interact with alerts from Metric and Custom SQL Monitors. This is a follow-on to similar capabilities we released for Freshness & Volume back in February.
After this release, when users receive a Metric or Custom SQL alert:
The anomaly is automatically excluded from the set of data that trains the models. This means thresholds don’t automatically widen after an alert.
Users can ‘mark as normal’ if they’d like to re-introduce the anomaly into the set of training data. This widens the threshold.
Users can ‘select training data’ to exclude periods of the monitors history that they don’t want to models to learn from. This typically narrows the threshold.
These changes gave users dramatically more control of their thresholds when we released them for freshness and volume, and we’re excited to do the same for Metrics and Custom SQL. Because it helps to keep thresholds tighter, it also has the effect of leading to more alerts.
Note that these replace the Fixed alert status influencing the anomaly detection. With this change, alert status will be completely decoupled from tuning the anomaly detection. See our docs for more detail.
Click "Mark as normal" on a Metric or Custom SQL alert to re-introduce that data point to the set of data that trains models. This will widen the threshold.
Click "Select training data" to select periods of the monitor's history to exclude from training the models. This typically narrows the threshold.
Monte Carlo released an Azure Devops Repos Integration, which allows customers to evaluate code impact on data. Users can see pull requests from Azure Repos overlaid on incident charts as well as displayed on a table's assets page, which help users assess the impact of such pull requests on their data. See details and instructions in docs https://docs.getmontecarlo.com/docs/azure-devops
Over the past few days, we released a few changes to data products:
Health tab is replaced with Data Operations. The Health tab was outdated and its metrics were inconsistent with the most popular Data Operations Dashboard. The new Data Product > Data Operations tab is an embedding of the Data Operations dashboard. If you’d like to further filter/edit/save the dashboard, there’s a path to click out into Dashboards > Data Operations to do so.
Simpler creation flow. The experience to create a Data Product is now one page instead of two, and more closely mimics the experience of creating a monitor.
Coming soon: optimizations to Data Product lineage. We’ll default to the ‘Table’ view instead of the lineage view, and release some changes to improve loading times for big lineage graphs.
Data Operations section within a Data Product. Click on the ... in the top right to open the view directly in the Data Operations Dashboard, which allows further filtering, customization, and saving.