You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/cloud/features/performance-monitoring/performance-alerts.mdx
+2-92Lines changed: 2 additions & 92 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,96 +3,6 @@ title: Performance Alerts
3
3
sidebarTitle: Performance alerts
4
4
---
5
5
6
-
Monitoring the performance of your dbt models is crucial for maintaining an efficient data pipeline. Elementary provides capabilities to set up alerts for long-running queries, helping you identify performance bottlenecks and optimize your data pipeline.
There are two main approaches to creating alerts for long-running model queries:
9
-
10
-
1.**Static Threshold Alerts**: Define specific time thresholds that, when exceeded, trigger an alert
11
-
2.**Anomaly Detection Alerts**: Use Elementary's anomaly detection to identify unusual increases in query execution time
12
-
13
-
## Static Threshold Alerts
14
-
15
-
You can define tests that fail when model execution times exceed predefined thresholds. This approach is straightforward and ideal when you have clear performance requirements.
16
-
17
-
### Implementation Steps
18
-
19
-
1. Create a singular test SQL file in your dbt project (e.g., `tests/test_models_run_under_30m.sql`):
20
-
21
-
```sql
22
-
{{ config(
23
-
tags=["model_performance"],
24
-
meta={
25
-
"description": "This test will fail on any models running over 30 minutes within the last 24 hours"
where CAST(generated_at AStimestamp) >= TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 day)
32
-
AND execution_time >=30*60
33
-
order by execution_time desc
34
-
```
35
-
36
-
In this example:
37
-
- The test monitors model runs over the past 24 hours
38
-
- It fails if any model takes longer than 30 minutes to run (1800 seconds)
39
-
- The test is tagged with "model_performance" for easy identification
40
-
- Results are ordered by execution time in descending order
41
-
42
-
When this test fails, Elementary will generate an alert based on your alert configurations. The test results will also be visible in the Elementary UI, showing the 5 worst-performing model runs.
43
-
44
-
## Anomaly Detection Alerts
45
-
46
-
Instead of using fixed thresholds, you can leverage Elementary's anomaly detection to identify unusual increases in execution time. This approach is more dynamic and can adapt to your evolving data pipeline.
47
-
48
-
### Implementation Steps
49
-
50
-
1. Define a source on the `model_run_results` view in your `schema.yml` file (or another YAML file):
51
-
52
-
```yaml
53
-
sources:
54
-
- name: elementary_models
55
-
schema: "your_elementary_schema"# Replace with your Elementary schema name
56
-
tables:
57
-
- name: model_run_results
58
-
columns:
59
-
- name: execution_time
60
-
data_tests:
61
-
- elementary.column_anomalies:
62
-
config:
63
-
severity: warn
64
-
tags: ["model_performance"]
65
-
arguments:
66
-
column_anomalies:
67
-
- max
68
-
dimensions: ["package_name", "name"]
69
-
timestamp_column: generated_at
70
-
anomaly_direction: spike
71
-
ignore_small_changes:
72
-
spike_failure_percent_threshold: 10
73
-
```
74
-
75
-
In this configuration:
76
-
- Elementary monitors the `execution_time` column for anomalies
77
-
- Dimensions are set to `package_name` and `name` to analyze each model individually
78
-
- The test only detects spikes in execution time (`anomaly_direction: spike`)
79
-
- Small changes under 10% are ignored (`spike_failure_percent_threshold: 10`)
80
-
- The severity is set to "warn" but can be adjusted as needed
81
-
82
-
This test will detect when a model's execution time increases significantly compared to its historical performance, triggering an alert when the increase exceeds the normal baseline.
83
-
84
-
## Choosing the Right Approach
85
-
86
-
Both methods have their strengths:
87
-
88
-
- **Static Threshold**: Simple to implement and understand. Ideal when you have clear performance requirements (e.g., "models must run in under 30 minutes").
89
-
90
-
- **Anomaly Detection**: More adaptive to your specific environment. Better at detecting relative changes in performance rather than absolute thresholds. Useful when normal execution times vary across different models.
91
-
92
-
You can implement both approaches simultaneously for comprehensive performance monitoring.
93
-
94
-
## Viewing Performance Alerts
95
-
96
-
Performance alerts appear in your regular Elementary alert channels (Slack, email, etc.) based on your alert configuration.
97
-
98
-
You can also view performance test results in the Elementary UI under the Tests tab, filtered by the "model_performance" tag that we added to both test types.
Copy file name to clipboardExpand all lines: docs/cloud/guides/troubleshoot.mdx
+7-4Lines changed: 7 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,12 +2,11 @@
2
2
title: "Troubleshooting"
3
3
---
4
4
5
-
### I connected my data warehouse but I don't see any test results
5
+
<Accordiontitle="I connected my data warehouse but I don't see any test results">
6
6
7
7
If you already connected your data warehouse to Elementary but are not seeing anything in the Elementary UI, there could be several reasons.
8
8
Try following these steps to troubleshoot:
9
9
10
-
11
10
**1. Validate elementary dbt package is deployed, working, and using the latest version**
12
11
13
12
- Refer to the [dbt package installation guide](/cloud/quickstart#install-the-dbt-package), and validate that your version in packages.yml is the one mentioned there. If not, upgrade and run `dbt deps`. Make sure to execute `dbt run --select elementary` for the package tables to be created.
@@ -20,8 +19,9 @@ Try following these steps to troubleshoot:
20
19
21
20
**4. Still no data in the table? Reach out to the Elementary team by starting an intercom chat from the Elementary UI.**
22
21
22
+
</Accordion>
23
23
24
-
### Column information cannot be retrieved
24
+
<Accordiontitle="Column information cannot be retrieved">
25
25
26
26
This error can happen because of a few reasons:
27
27
@@ -40,8 +40,9 @@ For more information on the permissions required by each data warehouse:
### How do I set up the table name of my Singular test?
45
+
<Accordiontitle="How do I set up the table name of my Singular test?">
45
46
46
47
Singular tests are sql queries that can reference more than one table, but are often intended to test a logic that is related to one table in particular.
47
48
In order to have that table name appear in the UI in the test results, test execution and more screens, you can set it up by adding the following to the config block of your singular test file:
Monitoring the performance of your dbt models is crucial for maintaining an efficient data pipeline. Elementary provides capabilities to set up alerts for long-running queries, helping you identify performance bottlenecks and optimize your data pipeline.
2
+
3
+
There are two main approaches to creating alerts for long-running model queries:
4
+
5
+
1.**Static Threshold Alerts**: Define specific time thresholds that, when exceeded, trigger an alert
6
+
2.**Anomaly Detection Alerts**: Use Elementary's anomaly detection to identify unusual increases in query execution time
7
+
8
+
## Static Threshold Alerts
9
+
10
+
You can define tests that fail when model execution times exceed predefined thresholds. This approach is straightforward and ideal when you have clear performance requirements.
11
+
12
+
### Implementation Steps
13
+
14
+
1. Create a singular test SQL file in your dbt project (e.g., `tests/test_models_run_under_30m.sql`):
15
+
16
+
```sql
17
+
{{ config(
18
+
tags=["model_performance"],
19
+
meta={
20
+
"description": "This test will fail on any models running over 30 minutes within the last 24 hours"
where CAST(generated_at AStimestamp) >= TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 day)
27
+
AND execution_time >=30*60
28
+
order by execution_time desc
29
+
```
30
+
31
+
In this example:
32
+
- The test monitors model runs over the past 24 hours
33
+
- It fails if any model takes longer than 30 minutes to run (1800 seconds)
34
+
- The test is tagged with "model_performance" for easy identification
35
+
- Results are ordered by execution time in descending order
36
+
37
+
When this test fails, Elementary will generate an alert based on your alert configurations. The test results will also be visible in the Elementary UI, showing the 5 worst-performing model runs.
38
+
39
+
## Anomaly Detection Alerts
40
+
41
+
Instead of using fixed thresholds, you can leverage Elementary's anomaly detection to identify unusual increases in execution time. This approach is more dynamic and can adapt to your evolving data pipeline.
42
+
43
+
### Implementation Steps
44
+
45
+
1. Define a source on the `model_run_results` view in your `schema.yml` file (or another YAML file):
46
+
47
+
```yaml
48
+
sources:
49
+
- name: elementary_models
50
+
schema: "your_elementary_schema"# Replace with your Elementary schema name
51
+
tables:
52
+
- name: model_run_results
53
+
columns:
54
+
- name: execution_time
55
+
data_tests:
56
+
- elementary.column_anomalies:
57
+
config:
58
+
severity: warn
59
+
tags: ["model_performance"]
60
+
arguments:
61
+
column_anomalies:
62
+
- max
63
+
dimensions: ["package_name", "name"]
64
+
timestamp_column: generated_at
65
+
anomaly_direction: spike
66
+
ignore_small_changes:
67
+
spike_failure_percent_threshold: 10
68
+
```
69
+
70
+
In this configuration:
71
+
- Elementary monitors the `execution_time` column for anomalies
72
+
- Dimensions are set to `package_name` and `name` to analyze each model individually
73
+
- The test only detects spikes in execution time (`anomaly_direction: spike`)
74
+
- Small changes under 10% are ignored (`spike_failure_percent_threshold: 10`)
75
+
- The severity is set to "warn" but can be adjusted as needed
76
+
77
+
This test will detect when a model's execution time increases significantly compared to its historical performance, triggering an alert when the increase exceeds the normal baseline.
78
+
79
+
## Choosing the Right Approach
80
+
81
+
Both methods have their strengths:
82
+
83
+
- **Static Threshold**: Simple to implement and understand. Ideal when you have clear performance requirements (e.g., "models must run in under 30 minutes").
84
+
85
+
- **Anomaly Detection**: More adaptive to your specific environment. Better at detecting relative changes in performance rather than absolute thresholds. Useful when normal execution times vary across different models.
86
+
87
+
You can implement both approaches simultaneously for comprehensive performance monitoring.
88
+
89
+
## Viewing Performance Alerts
90
+
91
+
Performance alerts appear in your regular Elementary alert channels (Slack, email, etc.) based on your alert configuration.
92
+
93
+
You can also view performance test results in the Elementary UI under the Tests tab, filtered by the "model_performance" tag that we added to both test types.
0 commit comments