- Verify if quick mode is displayed
- Verify if user is able to click on interesting fields
- Verify on clicking interesting fields user is able to view the field
in sql mode
- Verify if on clicking interesting field when histogram is enabled,
expected results are displayed
- Verify if error displayed on entering random text in histogram mode
when quick mode is on
- Verify should display order by as default when switched to sql mode
- Verify if on page refresh the orderby is still present by default in
sql mode
- Verify if on page adding removing the interesting field removes in
from sql mode and the results too
Instead of waiting for `CONFIG.chrome.chrome_sleep_secs` to let the data
load in the dashboard for report, frequently, check for the `span`
element with a loop.
In sql mode, if query does not contains " order by " it throws error.
Solution:
On switching to sql mode, by default added "order by _timestamp desc" in
logs query
While implementing a filter search feature with dropdown menus for
variables, an error occurred due to undefined values. This error
hindered the functionality of the search feature, causing unexpected
behavior when attempting to filter results.
## Reports
Both `ZO_CHROME_ENABLED` and `ZO_SMTP_ENABLED` ENV variables need to be
`true` for reports to work.
**Report APIs -**
```
POST /api/{org_id}/reports
PUT /api/{org_id}/reports/{report_name}
GET /api/{org_id}/reports
GET /api/{org_id}/reports/{report_name}
DELETE /api/{org_id}/reports/{report_name}
PUT /api/{org_id}/reports/{report_name}/enable?value=<true|false>
```
**Report body**
```
{
"createdAt": "2024-03-23T09:46:32.913574782Z",
"dashboards": [
{
"dashboard": "7177215109754781699",
"folder": "default",
"tabs": [
"default"
],
"timerange": {
"from": 0,
"period": "1h",
"to": 0,
"type": "relative"
},
"variables": []
}
],
"description": "Report description",
"destinations": [
{
"email": "mail@gmail.com"
}
],
"enabled": false,
"frequency": {
"cron": "",
"interval": 1,
"type": "weeks"
},
"lastEditedBy": "root@example.com",
"mediaType": "pdf",
"message": "Email message",
"name": "report_name",
"orgId": "default",
"owner": "root@example.com",
"password": "ComplexPass#123",
"start": 1711187192913571,
"timezone": "Asia/Calcutta",
"timezoneOffset": 330,
"title": "Email subject",
"user": "root@example.com"
}
```
**ENVs**
| ENV | Description |
|------|---------------|
| `ZO_CHROME_ENABLED` | Must be `true` for reports, Default - `false` |
| `ZO_CHROME_PATH` | If chrome is enabled, custom `chrome` executable
path can be specified. If not specified, it looks for chrome executable
in default locations. If still not found, it automatically downloads a
good known version of `chromium`. |
| `ZO_CHROME_CHECK_DEFAULT_PATH` | If `false`, it does not look for
chromium in default locations, Default is `true`. |
| `ZO_CHROME_DOWNLOAD_PATH` | If chromium can not be found in default
locations and also `ZO_CHROME_PATH` is not specified, it downloads the
system specific chromium in the given path. Default is `./download`
(gitignored). `chromium` is downloaded for the first time only,
afterwords, `chromium` is fetched from the given path. If there is any
error regarding download of `chromium`, delete the download folder as it
might be in a bad state. |
| `ZO_CHROME_NO_SANDBOX` | If `true`, it launches chromium in
`no-sandbox` environment. Default is `false` |
| `ZO_CHROME_SLEEP_SECS` | Specify the number of seconds the
`service::dashboards::reports::generate_report()` will wait to load all
the data in the headless chromium dashboard. Default is `20` seconds. |
| `ZO_CHROME_WINDOW_WIDTH` | Specifies the width of the headless
chromium browser. Default is `1370` |
| `ZO_CHROME_WINDOW_HEIGHT` | Specifies the height of the headless
chromium browser. Default is `730` |
## Scheduler
Currently `Scheduler` is implemented for only `Sqlite`, `Postgres` and
`MySql`.
**API**
```rust
pub trait Scheduler: Sync + Send + 'static {
async fn create_table(&self) -> Result<()>;
async fn create_table_index(&self) -> Result<()>;
async fn push(&self, trigger: Trigger) -> Result<()>;
async fn delete(&self, org: &str, module: TriggerModule, key: &str) -> Result<()>;
async fn update_status(
&self,
org: &str,
module: TriggerModule,
key: &str,
status: TriggerStatus,
retries: i32,
) -> Result<()>;
async fn update_trigger(&self, trigger: Trigger) -> Result<()>;
async fn pull(
&self,
concurrency: i64,
alert_timeout: i64,
report_timeout: i64,
) -> Result<Vec<Trigger>>;
async fn clean_complete(&self, interval: u64);
async fn watch_timeout(&self, interval: u64);
async fn len_module(&self, module: TriggerModule) -> usize;
async fn len(&self) -> usize;
async fn is_empty(&self) -> bool;
async fn clear(&self) -> Result<()>;
}
```
**ENVs**
| ENV | Description |
|------|---------------|
| `ZO_ALERT_SCHEDULE_CONCURRENCY` | The number of `scheduled_jobs` the
`alert_manager` can process at a time. Default is `5` |
| `ZO_ALERT_SCHEDULE_TIMEOUT` | Visibility timeout for alerts. Default
is `90` seconds |
| `ZO_REPORT_SCHEDULE_TIMEOUT` | Visibility timeout for reports. Default
is `300` seconds |
| `ZO_SCHEDULER_MAX_RETRIES` | Maximum number of retries that will be
made for a `scheduled_job`. Default is `3` |
| `ZO_SCHEDULER_CLEAN_INTERVAL` | Time interval after which the
`Scheduler` will clean up the queue. Default is `30` seconds |
| `ZO_SCHEDULER_WATCH_INTERVAL` | Time interval after which the
`Scheduler` will watch for timeout for `scheduled_jobs`. Default is `30`
seconds. |
**Workflow**
- should not allow adding drilldown without name
- should add variable under drilldown and verify if drilldown is added
- delete the created dashboard once verification is done
- The notification has been eliminated during the configuration of
absolute dates.
- The SQL mode should not trigger the query automatically upon
deactivation if run query flag is true.
- The Histogram feature should remain inactive while SQL mode is
enabled.
- Modifications related to the quick mode.
- Within SQL mode, the "_timestamp" field is required, and an "order by"
clause is necessary.
---------
Co-authored-by: Hengfei Yang <hengfei.yang@gmail.com>
Problem:
Observed that the User Session Viewer was yielding incorrect results
when filtering session events data. The root cause was identified as the
improper handling of a compound predicate within the SQL query used for
data retrieval.
Solution:
When parentheses were added around the conditions `session_id='xyz' &&
(type='error' or type='action' or type='view')` to logically group them,
this fixed the issue.
dependabot[bot]
dongjinlong
Neha P
Ashish Kolhe
Omkar Kesarkhane
Subhra264andomkark06
Ankur Srivastava
Bhargav
ktx-vaidehi
Huaijin
Hengfei Yang
胡同里有猫