> 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 creates a container for the connected Monte Carlo account and a resource for every Monte Carlo monitor, and enriches existing warehouse and dbt resources with active-alert data: * Monte Carlo account (`montecarlo_account`) * Monte Carlo monitor (`montecarlo_monitor`) * Enriched table (`table`) * Enriched column (`column`) * Enriched dbt model (`dbt_model`) * Enriched dbt source (`dbt_source`) * Enriched dbt seed (`dbt_seed`) * Enriched dbt snapshot (`dbt_snapshot`) * Enriched dbt column (`dbt_column`) The integration does not discover or import warehouse hierarchy (databases, schemas, tables, views, models, or columns). 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. ## Resource hierarchy ``` Monte Carlo account └── Monte Carlo monitor ``` ## Monte Carlo account (`montecarlo_account`) The top-level container created once per Monte Carlo source. It also stores the warehouse connections returned by Monte Carlo's `getWarehouses` API and the source's [warehouse mapping](/sources/data-observability/monte-carlo.md#warehouse-uri-prefix-mapping), which Euno uses to resolve alerts to the correct resources. | Property | Type | Description | | ----------- | ------ | --------------------------- | | `name` | string | The Monte Carlo account ID. | | `type` | string | Always `montecarlo_account` | | `subtype` | string | Always `montecarlo_account` | | `native_id` | string | The Monte Carlo account ID. | **URI pattern** ``` montecarlo. ``` Example: `montecarlo.8f14e45f-ceea-467e-9d1b-0b7c1f3a2e6d` ## 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 | Type | Description | | ------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `name` | string | 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` | string | Always `montecarlo_monitor` | | `subtype` | string | Always `montecarlo_monitor` | | `native_id` | string | Stable UUID of the monitor in Monte Carlo. Used for deduplication across crawls. | | `montecarlo_monitor_is_enabled` | boolean | `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. Searchable in EQL. | | `active_montecarlo_alerts` | list | Active alerts associated with this monitor in the most recent crawl. Each entry includes the full alert detail payload plus target refs parsed from Monte Carlo table and asset MCONs (see [Alert payload](#alert-payload)). Empty when the monitor has no active alerts. Not searchable in EQL. | **URI pattern** ``` montecarlo..monitor. ``` Example: `montecarlo.8f14e45f-ceea-467e-9d1b-0b7c1f3a2e6d.monitor.3c59dc04-8f2b-4e1a-a5f7-6b2d9e0c1a47` ## Enriched table (`table`) A warehouse table (owned by the warehouse integration) that is the impacted asset of one or more active Monte Carlo alerts receives these properties: | Property | Type | Description | | -------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `has_active_montecarlo_alerts` | boolean | `true` when the resource has at least one attached active alert; `false` when cleared. Searchable in EQL. | | `active_montecarlo_alerts_count` | number | Count of distinct active Monte Carlo alerts attached to this resource. Searchable in EQL. | | `active_montecarlo_alerts` | list | Active alerts attached to this resource, aggregated from all `montecarlo_monitor` resources whose active alerts target it. Each entry mirrors the alert detail payload (see [Alert payload](#alert-payload)). Visible on the resource **Observability** tab in the UI; individual payload fields are not searchable in EQL. | 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. ## Enriched column (`column`) A warehouse column (owned by the warehouse integration) receives the same properties as an enriched `table` when a field-scoped alert resolves to it. ## Enriched dbt model (`dbt_model`) A dbt model (owned by the dbt integration) receives the same properties as an enriched `table` when it `defines` a table that is impacted by an active alert. ## Enriched dbt source (`dbt_source`) A dbt source (owned by the dbt integration) receives the same properties as an enriched `table` when it `defines` an impacted table. ## Enriched dbt seed (`dbt_seed`) A dbt seed (owned by the dbt integration) receives the same properties as an enriched `table` when it `defines` an impacted table. ## Enriched dbt snapshot (`dbt_snapshot`) A dbt snapshot (owned by the dbt integration) receives the same properties as an enriched `table` when it `defines` an impacted table. ## Enriched dbt column (`dbt_column`) A dbt column (owned by the dbt integration) receives the same properties as an enriched `table` when it `defines` an impacted physical column. ## Relationships Each row is one relationship edge, written in the canonical direction for its family. Use the predicate in each heading to search for these relationships in EQL. ### Containment (`has parent` / `has child`) | Source type | Relationship | Target type | Notes | | -------------------- | ------------ | -------------------- | ----- | | `montecarlo_monitor` | has parent | `montecarlo_account` | | Alerts are not separate Euno resources and do not create graph relationships. The Monte Carlo integration does not change lineage or hierarchy between the tables, columns, and dbt resources it enriches. ## Alert payload Each entry in the `active_montecarlo_alerts` 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, table and physical-column URIs parsed directly from Monte Carlo payloads. | | `monte_carlo_target_refs` | Target refs parsed from Monte Carlo `tables`/`assets` rows before they are resolved to Euno resources. 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-uri-prefix-mapping) from source configuration, to parse impacted table and field references. Euno then resolves those references to existing Euno resources: table-scoped references resolve to `table` resources, field-scoped references resolve to physical `column` resources, 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, column, and dbt resource, * updates each impacted resource's `active_montecarlo_alerts` list, * keeps the alert in the `active_montecarlo_alerts` list of its originating `montecarlo_monitor` resource. These lists are refreshed on every run; alert properties are cleared from resources that are no longer targeted by an active alert. ## 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` payload are not indexed for EQL predicates. ``` # 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" # dbt columns with active Monte Carlo alerts has_active_montecarlo_alerts = true and type = "dbt_column" ``` --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.euno.ai/sources/data-observability/monte-carlo/monte-carlo-integration-discovered-resources.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.