This message was deleted.
# ask-elementary-ai
s
This message was deleted.
k
Yes! The quickest and most flexible way is to use a variable in your
dbt_project.yml
to control Elementary's enablement:
Copy code
vars:
  enable_elementary: false

models:
  elementary:
    +schema: "elementary"
    +enabled: "{{ var('enable_elementary', false) }}"
With this setup: • Elementary is off by default — a plain
dbt run
or
dbt build
won't run Elementary models. • Enable it on demand by passing the var at the CLI:
Copy code
dbt run --vars '{"enable_elementary": true}'
[deactivate by default] ------------------------- Environment-based toggle (alternative) If you want Elementary to be automatically enabled in specific environments (e.g.,
prod
) without needing to pass a var each time:
Copy code
models:
  elementary:
    +schema: "elementary"
    +enabled: "{{ target.name in ['prod', 'analytics'] }}"
[disable per env] ------------------------- Important: Don't forget the hooks The
+enabled
config disables the models, but the on-run-end hooks are controlled separately. To fully disable Elementary (models + hooks), also add these vars:
Copy code
vars:
  disable_run_results: "{{ target.name != 'prod' }}"
  disable_tests_results: "{{ target.name != 'prod' }}"
  disable_dbt_artifacts_autoupload: "{{ target.name != 'prod' }}"
  disable_dbt_invocation_autoupload: "{{ target.name != 'prod' }}"
[disable hooks] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
@kapa.ai currently the hook for elementary upload artifacts is disabled , lets say I set up slack alerts from elementary would the disabled artifacts affect my alerts ?
k
Yes, disabling artifact uploads will affect your alerts, but the impact depends on which upload variable you've disabled. Here's a breakdown: disable_dbt_artifacts_autoupload: true (metadata only) This disables updates to metadata tables like
dbt_models
,
dbt_tests
, and
dbt_sources
. Your test results and run results will still be collected, so alerts based on test failures will continue to work. However, metadata shown in alerts (e.g., model names, owners, tags) may become stale if your project structure changes. [on-run-end hooks] Disabling result uploads (disable_run_results, disable_tests_results) If you also disable these, test results and run results won't be uploaded, which means Elementary will have no data to generate alerts from — your Slack alerts will stop working. [disable hooks] Elementary's own recommendation > "We strongly recommend not to disable the hooks for environments you want to monitor using Elementary." [on-run-end hooks] Recommended setup for Slack alerts If you want alerts to work while still controlling artifact uploads, use this pattern:
Copy code
vars:
  disable_dbt_artifacts_autoupload: true      # disables metadata uploads (safe for alerts)
  disable_run_results: false                  # keep this enabled for alerts
  disable_tests_results: false                # keep this enabled for alerts
  disable_dbt_invocation_autoupload: false    # keep this enabled for alerts
Then manually refresh metadata when your project changes:
Copy code
dbt run --select elementary.edr.dbt_artifacts
This way, your Slack alerts remain fully functional while you control when metadata is updated. [disable hooks] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
@kapa.ai will disable_dbt_artifacts_autoupload : true affect the report generation tho ?
k
Setting
disable_dbt_artifacts_autoupload: true
will partially affect report generation, but not completely break it. Here's what happens: What still works: • Runtime tables (
dbt_run_results
,
elementary_test_results
,
dbt_invocations
) are still populated by the on-run-end hooks, so test outcomes, model run times, and execution history will still appear in reports. [on-run-end hooks] What may be affected: • Reports rely on joining runtime results with metadata from artifact tables (e.g.,
dbt_tests
,
dbt_models
). If those metadata tables are stale or outdated, tests and models may be misrepresented or missing from reports. [dbt artifacts] • New models, tests, or sources added to your project won't show up in reports until you manually refresh the artifacts. • Config changes (owners, tags, severity, etc.) won't be reflected in the report context. The fix: Run the following whenever your project structure changes (e.g., after a deployment):
Copy code
dbt run --select elementary.edr.dbt_artifacts
This keeps metadata current without needing to upload it on every single run. [reduce on-run-end time] In short: reports will still show runtime data, but the project metadata context (model names, test configs, owners, etc.) may become stale if you don't manually refresh artifacts after project changes. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Based on your setup (Airflow + Cloud Run + BigQuery) and the context from our conversation (artifacts autoupload already disabled), here's how to set up Elementary Slack alerts: 1. Install the Elementary dbt Package & CLI Make sure the Elementary dbt package is in your
packages.yml
and the CLI (
edr
) is installed in your Cloud Run environment:
Copy code
pip install elementary-data
pip install 'elementary-data[bigquery]'
[CLI install] 2. Create a Slack App 1. Go to the Slack app creation page and create a new app from scratch. 2. Under "OAuth & Permissions", add these Bot Token Scopes: ā—¦
channels:join
,
channels:read
,
chat:write
,
files:write
,
users:read
,
users:read.email
,
groups:read
1. Click "Install to Workspace" to generate a Slack Bot Token. [Slack setup] 3. Configure Elementary to Use Slack You can pass credentials via CLI or a config file. For Cloud Run, environment variables are the cleanest approach: Via CLI (in your Airflow BashOperator or Cloud Run command):
Copy code
edr monitor --slack-token <your_slack_token> --slack-channel-name <channel_name>
Or via `~/.edr/config.yml`:
Copy code
slack:
  token: <your_slack_token>
  channel_name: <slack_channel_to_post_at>
  group_alerts_by: table  # or alert
[send Slack alerts] 4. Add edr monitor to Your Airflow DAG After your dbt run and test steps, add an
edr monitor
step. A typical Airflow DAG pattern:
Copy code
from airflow.operators.bash_operator import BashOperator

dbt_run = BashOperator(
    task_id='dbt_run',
    bash_command="dbt run --profiles-dir ..."
)

dbt_test = BashOperator(
    task_id='dbt_test',
    bash_command="dbt test --profiles-dir ..."
)

edr_monitor = BashOperator(
    task_id='elementary_monitor',
    bash_command="edr monitor --slack-token $SLACK_TOKEN --slack-channel-name $EDR_SLACK_CHANNEL"
)

dbt_run >> dbt_test >> edr_monitor
[Airflow scheduling] 5. Keep Your Current Artifact Setup Since you already have
disable_dbt_artifacts_autoupload: true
and a separate job running
dbt run --select elementary
on deploy, your alerts will work fine — test results and run results are still collected by the hooks, which is what
edr monitor
uses to generate alerts. [on-run-end hooks] > Note: By default, Elementary sends alerts for failures only (not warnings). To also receive warning alerts, make sure
disable_warn_alerts
is not set to
true
in your
dbt_project.yml
. [disable_warn_alerts] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
@kapa.ai would adding elementary-data in the requirements.txt download the cli ?
k
Yes — adding
elementary-data
to your
requirements.txt
and running
pip install -r requirements.txt
will install the Elementary CLI (
edr
) along with the Python package. They are the same package. [CLI install] For BigQuery, you'd want both lines in your `requirements.txt`:
Copy code
elementary-data
elementary-data[bigquery]
After installation, you can verify it worked by running:
Copy code
edr --help
One common gotcha: On macOS, the
edr
executable may be installed in a location not on your
PATH
by default. If you get
command not found: edr
after installing, check the warning in your terminal output — it will tell you the path to add. [troubleshooting] In containerized environments (like your Cloud Run setup), this is usually not an issue as long as the package is installed in the same Python environment that executes the commands. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
@kapa.ai this is not for local setup. It is on the cloud run docker image
k
Good point — for your Cloud Run Docker image, the same
pip install
approach applies, but there are a few container-specific things to be aware of. Installing in a Docker Image Add to your `requirements.txt`:
Copy code
elementary-data
elementary-data[bigquery]
Then in your Dockerfile:
Copy code
RUN pip install -U pip
RUN pip install -r requirements.txt
This will install the
edr
CLI inside the container. [CLI install] Common Docker-Specific Gotchas 1.
edr
not found in PATH
After
pip install
, the
edr
executable may not be on the container's
PATH
. Add this to your Dockerfile:
Copy code
ENV PATH="/usr/local/bin:/usr/local/lib/python3.11/site-packages:/usr/local/lib/python3.11/bin:${PATH}"
Adjust the Python version to match what's in your image. [PATH issue] 2. Permission errors when
edr
runs
Elementary tries to install its internal dbt packages at runtime. In a container with a non-root user, this can cause
PermissionError
. Pre-install them during the image build as root:
Copy code
RUN dbt deps --project-dir $(python -c "import os; from elementary.monitor import dbt_project_utils; print(os.path.dirname(os.path.realpath(dbt_project_utils.__file__)))")/dbt_project
[permission fix] 3. Alternative: Use the official Elementary Docker image If you'd rather not manage the installation yourself, Elementary publishes a ready-to-use Docker image:
Copy code
docker pull ghcr.io/elementary-data/elementary:latest
The
ENTRYPOINT
is already set to
edr
, so you can run commands directly. [Docker docs] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
@kapa.ai what methods do you support to use the Elementary CLI ?
k
Based on the knowledge sources, here are the supported methods to install and use the Elementary CLI: Installation Methods 1. pip (Recommended) The standard way to install:
Copy code
pip install elementary-data
# Then add your warehouse adapter:
pip install 'elementary-data[bigquery]'
pip install 'elementary-data[snowflake]'
pip install 'elementary-data[redshift]'
pip install 'elementary-data[databricks]'
pip install 'elementary-data[athena]'
pip install 'elementary-data[trino]'
pip install 'elementary-data[clickhouse]'
pip install 'elementary-data[duckdb]'
pip install 'elementary-data[dremio]'
pip install 'elementary-data[spark]'
pip install 'elementary-data[vertica]'
# Postgres doesn't require an adapter step
[CLI install] 2. Install from Source
Copy code
git clone https://github.com/elementary-data/elementary
pip install ./elementary
[CLI install] 3. Docker Image Elementary provides an official pre-built Docker image with
edr
, adapters, and pinned dependencies already included:
Copy code
docker pull ghcr.io/elementary-data/elementary:latest
# Or a specific version:
docker pull ghcr.io/elementary-data/elementary:v0.20.0
[Docker docs] Deployment / Orchestration Methods Once installed, the CLI can be run via: [Elementary in production] • Airflow — using a
BashOperator
after dbt tasks • GitHub Actions — using the dedicated
elementary-data/run-elementary-action
• GitLab CI — using the Docker image in a CI pipeline • Prefect • Meltano — via a custom Elementary integration • Cron • Elementary Cloud — fully managed option > Note:
uv
is not a supported installation method — if you install via
uv
, the CLI commands may not register correctly. [uv issue] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
@kapa.ai useful queries to run to get data from the elementary schema
k
Here are some useful queries you can run against the Elementary schema, all derived directly from the knowledge sources: 1. Find Time Taken per Model for a Specific Run First, find the invocation ID from
dbt_invocations
, then pull model execution times:
Copy code
SELECT
    name,
    status,
    execution_time,
    execute_started_at,
    execute_completed_at
FROM elementary.dbt_run_results
WHERE invocation_id = '<your_invocation_id>'
  AND resource_type = 'model'
ORDER BY execution_time DESC;
[dbt run results] 2. Rank Tests by Execution Time in a Specific Schema Useful for identifying slow tests:
Copy code
WITH _execution_time AS (
    SELECT
        model_execution_id,
        unique_id,
        execution_time
    FROM dbt_run_results
),
_test_results AS (
    SELECT
        test_execution_id,
        test_unique_id,
        schema_name
    FROM elementary_test_results
    WHERE schema_name = '<SCHEMA_OF_INTEREST>'
)
SELECT
    test_unique_id,
    MAX(execution_time) AS max_execution_time
FROM _test_results
LEFT JOIN _execution_time ON model_execution_id = test_execution_id
GROUP BY test_unique_id
ORDER BY max_execution_time DESC;
[test execution time] 3. Count Total Tests and Filter by Type
Copy code
-- Total tests
SELECT COUNT(*) FROM elementary.dbt_tests;

-- Singular tests only
SELECT COUNT(*) FROM elementary.dbt_tests WHERE type = 'singular';
[dbt_tests table] 4. Average / Median Model Execution Time
Copy code
SELECT
    name,
    AVG(execution_time) AS avg_execution_time
FROM elementary.dbt_run_results
WHERE resource_type = 'model'
GROUP BY name
ORDER BY avg_execution_time DESC;
[execution time] 5. Recent Test Failures
Copy code
SELECT
    id,
    test_unique_id,
    status,
    detected_at,
    failures
FROM elementary.elementary_test_results
WHERE status IN ('fail', 'error')
ORDER BY detected_at DESC
LIMIT 20;
[elementary_test_results] 6. Tests That Frequently Warn (Over a Time Window)
Copy code
WITH per_test_summary AS (
    SELECT
        etr.table_name,
        etr.column_name,
        etr.test_name,
        SUM(CASE WHEN etr.status = 'warn' THEN 1 ELSE 0 END) AS num_warnings,
        COUNT(1) AS num_runs
    FROM elementary.elementary_test_results etr
    INNER JOIN (
        SELECT DISTINCT invocation_id
        FROM elementary.dbt_invocations
        WHERE run_started_at >= CURRENT_DATE - 7  -- last 7 days
    ) i ON etr.invocation_id = i.invocation_id
    GROUP BY 1, 2, 3
)
SELECT
    *,
    num_warnings / num_runs AS pct_of_time_warns
FROM per_test_summary
WHERE num_warnings > 0
ORDER BY pct_of_time_warns DESC;
[warning frequency] 7. Look Up Invocations (e.g., from Airflow runs)
Copy code
SELECT
    invocation_id,
    run_started_at,
    run_completed_at,
    command,
    job_name,
    cause,
    orchestrator,
    target_name
FROM elementary.dbt_invocations
ORDER BY run_started_at DESC
LIMIT 10;
[dbt_invocations] > Tip for your Airflow setup: You can populate
job_name
in
dbt_invocations
by setting the
DBT_JOB_NAME
environment variable in your Cloud Run container, making it easy to distinguish Airflow runs from manual runs. [dbt_invocations] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.