Only threshold can work without "window": it takes one datapoint from metric and checks if it falls over threshold. In case of pattern and anomaly detector it's impossible to make detection on one datapoint, so we need to define the size of the window which could be used for pattern / anomaly detection. Supposedly, we need to

1. implement method get_detection_window from AnalyticUnit trait.
2. fill bucket in DetectionRunner::run with of size get_detection_window
3. run detection on bucket

I've changed the Seasonality value from 7220 to 722 and now I can't do anything, analytics always showing the Learning status

Maybe we can display logs somewhere so that a user have better understanding of what's going on

for a reason I can't edit confidence param in anomaly unit.

Steps to reproduce:

• Choose anomaly detector
• try to change confidence param from 10 to something else

Behavior:

• confidence tot changed

Closes #55

This PR makes it possible to configure hastic using environment variables

Changes:

• remove config::Environment::with_prefix("HASTIC") usage because it doesn't support nested keys, e.g. alerting.type
• use update_from_env instead (a function copied from here: https://github.com/rust-lang/mdBook/blob/f3e5fce6bf5e290c713f4015947dc0f0ad172d20/src/config.rs#L132), it replaces __ in the variables with .

Configuration example:

HASTIC_PORT=8000 \
HASTIC_PROMETHEUS__URL="http://localhost:9090" \
HASTIC_PROMETHEUS__URL="rate(go_memstats_alloc_bytes_total[5m])" \
cargo run

TODO: we also need to add configuration docs to the readme, I'll do it in a separate PR

• [ ] refactor methods resolve and resolve_au in analytic_unit_service to work with db
• [x] field in db
• [x] take active analytic unit from db by id
• [x] case of default active analytic unit (fresh start of the server)
• [x] set active analytic unit in db
• [x] config patch vs db

Closes https://github.com/hastic/hastic/issues/51

Changes

• New DetectionRunnerDetection type and it's usad ein AnalyticUnitSerive and DetectionRunner

Closes https://github.com/hastic/hastic/issues/102

Changes

• New DataService module which contains analytic_units_connection and segments_connection
• SegmentService and AnalyticUnitsService now take ds: &DataService param

closes https://github.com/hastic/hastic/issues/99

Changes

• use v-model instead of :value -- don't really know why it works, but docs are here: https://v3.vuejs.org/guide/migration/v-model.html#using-v-bind-sync

Closes #48

Changes:

• change AnalyticStatus type: store availability and message instead of just message
• handle GET /status errors
• display error message if server is down
• do not display anything below the Analytic Status if server is down

TODO:

• remove the empty space (where the chart should be) if server is down
• #92

Other changes:

• change default port: 8000 -> 4347

Closes https://github.com/hastic/hastic/issues/83

Changes

• MetricService now has get_detection_step method which return 10 -- it's a hack
• PatternAnalyticUnit returns avg_pattern_length in get_detection_window -- it's also not 100% right cuz there used unwrap and formally learning results can be None

Notes

This PR doesn't really introduce bucket and query from metrics_service used to get data for detection

Closes https://github.com/hastic/hastic/issues/65

Changes

• ramade from scratch AnlyticSerivice::patch_config: now it extracts data from db instead of Default
• new method AnalyticUnitConfig::patch_needs_learning which replaces a bit logic of AnalyticUnitConfig::patch. AnalyticUnitConfig::patch is maybe deprecated now
• new methods in PatchConfig and AnalyticUnitService for resolving / setting configs by it -- it's still hack where id and type_id correspond to each other

Other

• code format

Notes

• the code is really ugly it this point and logic of id's vs PatchConfig should be rethought
• logic of need_learning overlaps with logic of same_type in AnalyticService::patch_config
• it's not that update db work in blocking way

Hello, i was trying to play a bit with this tool but i get the following

Description: The error above was given by Adblock extension but in any case i cant "connect" the influx database to hastic (see below)

Setup: Influxdb and grafana are on the same docker-compose file of hastic and both are under authentication. Influxdb and grafana are running ok and i can plot all my data. Sensors are posting to influx with the same token i'm using for hastic

Regards,

When detection runner starts with anomaly unit, it detects too many segments. For example, if I started DetectionRunner::run(1641685784), then the line let detections = a.detect(ms.clone(), t_from, t_to).await.unwrap(); works with t_from = 1641721134, but the first detection in detections is (1641685784, 1641685924), the second is (1641685934, 1641685984) and there are375in thedetections`

the error I've got:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: error trying to connect: tcp connect error: Connection timed out (os error 110)

Caused by:
    0: tcp connect error: Connection timed out (os error 110)
    1: Connection timed out (os error 110)', src/services/analytic_service/analytic_unit/pattern_analytic_unit.rs:365:59
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrac

I am connecting to remote prometheus instance. We should handle this case better without panic

There is a comment in the code

impl Config {
    pub fn new() -> anyhow::Result<Config> {
        let mut config = config::Config::default();

        if std::path::Path::new("config.toml").exists() {
            config.merge(config::File::with_name("config")).unwrap();
        }

        update_from_env(&mut config);

        if config.get::<u16>("port").is_err() {
            config.set("port", 4347).unwrap();
        }

        // TODO: print resulted config (perfectly, it needs adding `derive(Debug)` in `subbeat`'s `DatasourceConfig`)
        Ok(Config {
            port: config.get::<u16>("port").unwrap(),
            datasource_config: resolve_datasource(&config)?,
            alerting: resolve_alerting(&config)?,
        })
    }
}

so this issue is about printing to log (console) variables values