# Monte Carlo Integration Discovered Resources ### Overview The Monte Carlo integration has two outputs: 1. It creates and maintains a first-class **`montecarlo_account`** container resource for the connected Monte Carlo account. 2. It creates and maintains a first-class **`montecarlo_monitor`** resource for every Monte Carlo monitor fetched in the crawl. 3. It enriches existing **table**, **dbt model**, **column**, and **dbt column** resources with active-alert data. The integration does not discover or import warehouse hierarchy (databases, schemas, tables, views, models, or columns) by reference — those resources must already exist in Euno from another source integration. Only alerts in active states (`Investigating`, `No Status`) are ingested. Alerts in terminal states (`Fixed`, `No Action Needed`, `False Positive`, `Expected`, `Resolved`, `Closed`, `Acknowledged`) are not stored or displayed. Euno fetches alerts whose `updatedTime` falls within the last **30 days**. An alert that remains active in Monte Carlo but has not been updated within that window may not appear in Euno until it is updated again. ### Ingested Resources & Properties #### Monte Carlo Account (`montecarlo_account`) The top-level container resource created once per Monte Carlo source. Holds warehouse connection metadata and the warehouse-to-Euno mapping context used to resolve alerts to the correct resources. | Property | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | The Monte Carlo account ID. | | `type` | Resource type value (`montecarlo_account`). | | `native_id` | The Monte Carlo account ID. | | `montecarlo_warehouses` | JSON list of warehouse connections returned by Monte Carlo's `getWarehouses` API. | | `database_mapping_context` | Copy of the warehouse mapping JSON from source setup (if configured). See [Warehouse mapping](/sources/data-observability/monte-carlo.md#warehouse-mapping) in the setup guide. | #### Monte Carlo Monitor (`montecarlo_monitor`) One resource is created per monitor returned by Monte Carlo's `getMonitors` API, including monitors with no active alerts. For `CUSTOM_SQL` monitors, custom rule details are included in the stored monitor payload; for `TABLE` monitors, table monitor details are included. | Property | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | Display name of the Monte Carlo monitor (falls back to the monitor UUID if no name is set). | | `type` | Resource type value (`montecarlo_monitor`). | | `native_id` | Stable UUID of the monitor in Monte Carlo. Used for deduplication across crawls. | | `active_montecarlo_alerts` | JSON list of active alerts associated with this monitor in the most recent crawl. Each entry includes the full alert detail payload plus graph-free target refs parsed from Monte Carlo table/asset MCONs. Empty when the monitor has no active alerts. | ### Resource — Monte Carlo Alert Enrichment When a table, mapped dbt model, physical column, or dbt column is the impacted asset of one or more active Monte Carlo alerts, the following property is added to the resource: | Property | Description | Applicable Resources | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | | `active_montecarlo_alerts` | JSON list of active alerts attached to this resource. Aggregated from all `montecarlo_monitor` resources whose active alerts target this resource's URI. Each entry mirrors the alert detail payload (see Alert Payload below). Visible on the resource **Observability** tab in the UI. | `table`, `dbt_model`, `column`, `dbt_column` | This property is not indexed for EQL search. To find resources with active alerts, use the Observability tab on individual resources or browse monitors via `type = "montecarlo_monitor"`. ### Alert Payload Each entry in the `active_montecarlo_alerts` JSON list captures the information Euno extracts from the Monte Carlo alert payload. #### Identity | Field | Description | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `id` | UUID of the alert in Monte Carlo. Used for deduplication and updates. | | `uuid` | Alternate alert UUID field (same value as `id` when both are present). | | `targets_uri` | On target-resource alert payloads, the resolved Euno resource URIs that this alert is attached to. On monitor alert payloads, graph-free table and physical-column URIs parsed directly from Monte Carlo payloads. | #### State | Field | Description | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `status` | One of `investigating`, `no_status`. Terminal states (`fixed`, `no_action_needed`, `false_positive`, `expected`, `resolved`, `closed`, `acknowledged`) are ignored. | | `severity` | One of `SEV-1`, `SEV-2`, `SEV-3`, `SEV-4`. | | `feedback` | Optional triage feedback recorded by the user in Monte Carlo. | #### Time | Field | Description | | ------------- | ------------------------------------------------------------------- | | `createdTime` | When the alert was first opened. | | `updatedTime` | Last change time (state change, new anomaly, or assignment change). | #### Monitoring | Field | Description | | ------------- | --------------------------------------------------------------- | | `name` | Display name of the alert. | | `type` | Alert type as returned by Monte Carlo. | | `monitorTags` | Tags attached to the originating monitor (`[{ name, value }]`). | #### Assignment / Ownership | Field | Description | | ------- | ----------------------------------------------------------------------------- | | `owner` | User identifier for the alert owner (`{ email }` as returned by Monte Carlo). | #### Asset Locator | Field | Description | | -------- | --------------------------------------------------------------------------------------------------- | | `tables` | List of Monte Carlo table references associated with the alert (`[{ mcon, tableId, isKeyAsset }]`). | | `assets` | List of Monte Carlo asset references (`[{ mcon, assetId, assetType }]`). | ### Mapping Alerts to Euno Resources Euno uses the Monte Carlo Canonical Object Name (MCON) from the alert's `tables` and `assets` fields, together with warehouse connection metadata and the optional [warehouse mapping](/sources/data-observability/monte-carlo.md#warehouse-mapping) from source configuration, to parse impacted table and field references. Monte Carlo processors then resolve those refs to existing Euno resources: table-scoped references resolve to table URIs, field-scoped references resolve to physical columns, and dbt resources whose `defines` relationships point at those tables or columns are also enriched. Once resolved, Euno: * attaches the alert to each impacted table, dbt model, and column resource, * updates each impacted resource's `active_montecarlo_alerts` list, * links the alert to the corresponding `montecarlo_monitor` resource. The relationship between an alert, its originating `montecarlo_monitor`, and the impacted resources is maintained on every run. ### Relationships | Source type(s) | Relationship | Target type(s) | Notes | | -------------------- | ------------ | -------------------- | -------------------------------------------------------------------------------------- | | `montecarlo_account` | has child | `montecarlo_monitor` | Every monitor is contained within the top-level account resource (`parent_container`). | ### Usage in EQL You can filter Monte Carlo resource types in Euno's search and EQL. Alert payload properties such as `active_montecarlo_alerts` are not indexed for EQL predicates. **Examples**: ``` # All Monte Carlo monitors in the account type = "montecarlo_monitor" # All Monte Carlo account containers type = "montecarlo_account" ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.euno.ai/sources/data-observability/monte-carlo/monte-carlo-integration-discovered-resources.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.