> For the complete documentation index, see [llms.txt](https://docs.euno.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.euno.ai/sources/data-observability/monte-carlo/monte-carlo-integration-discovered-resources.md). # 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**, and **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. Derived from the monitor's `description` (the label shown in the Monte Carlo UI), falling back to the API `name` and then the monitor UUID when no description is set. | | `type` | Resource type value (`montecarlo_monitor`). | | `native_id` | Stable UUID of the monitor in Monte Carlo. Used for deduplication across crawls. | | `parent_container` | Parent **`montecarlo_account`** URI | | `montecarlo_monitor_is_enabled` | `true` when the monitor is enabled (neither paused nor a draft), `false` when it is paused or a draft, and null when the underlying status is unknown. Derived from the raw monitor's `isPaused` and `isDraft` flags. Indexed for EQL search. | | `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, column, or a dbt resource that `defines` an impacted table or column is the impacted asset of one or more active Monte Carlo alerts, the following properties are added to the resource. dbt enrichment reaches every dbt resource type that points at a physical table or column through `defines` — `dbt_model`, `dbt_source`, `dbt_seed`, and `dbt_snapshot` for tables, and `dbt_column` for columns: | Property | Description | Applicable Resources | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | `has_active_montecarlo_alerts` | `true` when the resource has at least one attached active alert; `false` when cleared. Indexed for EQL search. | `table`, `column`, `dbt_model`, `dbt_source`, `dbt_seed`, `dbt_snapshot`, `dbt_column` | | `active_montecarlo_alerts_count` | Count of distinct active Monte Carlo alerts attached to this resource. Indexed for EQL search. | `table`, `column`, `dbt_model`, `dbt_source`, `dbt_seed`, `dbt_snapshot`, `dbt_column` | | `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. Not indexed for EQL predicates on individual payload fields. | `table`, `column`, `dbt_model`, `dbt_source`, `dbt_seed`, `dbt_snapshot`, `dbt_column` | Use `has_active_montecarlo_alerts` and `active_montecarlo_alerts_count` to search for impacted resources in EQL. Use the Observability tab or browse `montecarlo_monitor` resources for full alert payload details. ### 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. | | `monte_carlo_target_refs` | Graph-free target refs parsed from Monte Carlo `tables`/`assets` rows before graph resolution. Each ref includes `table_uri` and, when available, `column_name`, `column_uri`, `warehouse_uuid`, `database_name`, `schema_name`, and `table_name`. These fields are also sampled in the run report for mapping troubleshooting. | #### 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_monitor` | has parent | `montecarlo_account` | `parent_container` on the monitor | ### Usage in EQL You can filter Monte Carlo resource types and alert indicators in Euno's search and EQL. Individual fields inside the `active_montecarlo_alerts` JSON payload 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" # Warehouse tables with active Monte Carlo alerts has_active_montecarlo_alerts = true and type = "table" # dbt models with more than one active alert active_montecarlo_alerts_count > 1 and type = "dbt_model" ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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.