Currently we only support bearer auth, we need to support basic auth also

we currently just dump our alert struct to alert buffer.
prometheus also just dump it's alert struct to alert buffer.

to work with systems the expect prometheus alert struct, we need to dump a struct the looks like a prometheus alert strucs ( this alert mode should have a cli flag like --dump-full-alerts or other flag )

Alerts [1] should post alert changes to an alert buffer [2].

[1] https://github.com/MohawkTSDB/mohawk/tree/master/alerts
[2] https://github.com/ilackarms/message-buffer

a general example for possible post code:

client := http.Client{}
...
req, err := http.NewRequest("POST", url, <alerts json as buffer>)
...
resp, err := client.Do(req)
...

In the code we sometimes use fmt [1] other time log [2] , we need to use log consistantly throw the code.

For example this two snippets are equivalent:

fmt.Println(err)
os.Exit(1)

log.Fatal(err)

[1] https://github.com/MohawkTSDB/mohawk/blob/master/main.go#L28
[2] https://github.com/MohawkTSDB/mohawk/blob/master/api/server.go#L204

May I suggest using vndr to vendor packages in this project.

For example, to build the command line interface, mohawk is using github.com/spf13/cobra and github.com/spf13/viper. This will require from anyone who builds mohawk from source to do go get -u -v github.com/spf13/viper before compiling.

This is not always good as at the time of work the master branch was pointing at commit a while today master points at commit b which breaks the API that was used in commit a and that ends in failing to compiling mohawk in the future.

I think we should move from 'one thread to rule them all' model to 'one thread for each alert' [1] this will allow different alerting frequencies for different metrics (currently alerts worker run for all metrics at the same rate AlertsInterval) at the future I think we should probably group alerts by their Interval or give each alert an Interval/Frequency field.
[1] Essentialy, moving this line -

This is far term goal for me..
cc: @yaacov

Currently alerts fire, only state that the value is outside valid range, alert object should also hold:
a. time of alert status change
b. time/value pair that triggered the status change.

In some modules we have a verbose variable [1] we need:

• use it to printout useful log messages.
• remove it from modules that do not need to printout logs on verbose mode.
• add it to modules that need to printout logs on verbose mode.

[1] https://github.com/MohawkTSDB/mohawk/blob/master/middleware/authorization.go#L28

Similar issue: #48

go lint test is not 100% [1]

[1] https://goreportcard.com/report/github.com/MohawkTSDB/mohawk

Currently we do not have any way for the user to adjust the alert buffer url [1]
Users should be able to configure the alert server url.

[1] https://github.com/MohawkTSDB/mohawk/blob/master/alerts/alerts.go#L68

Currently all routers must have a static route.
We need to handle routes that have dynamic paths ( e.g. files from dir or bad requests )

Our current smoke tests only check the /status [1] route in the api module and the --version [2] in the cli module, we need more smoke tests :-)

• test data post and get
• alerts on and off
• alert fire no more then 5 sec after trigger value post,
• more tests to the cli module ( will wait for next iteration :-) )

[1] https://github.com/MohawkTSDB/mohawk/blob/master/test/mohawk.bats#L32
[2] https://github.com/MohawkTSDB/mohawk/blob/master/test/mohawk.bats#L25

The import of packages across the project is referencing @yaacov private repo (i.e github.com/yaacov/some_pkg) and it should probably be github.com/MohawkTSDB/mohawk?

Example: (

I have found a security vulnerability in Mohawk I would like to report. Please provide me with information on how to do so.

Best regards,
Benjamin

Adding some more control on the frequency of the alert worker - If user knows he only pushes data once / twice a day (or even once an hour) there is no need to check every ten seconds, on the other hand if he/she knows he pushed every millisecond then checking once an ten seconds (like we do now) is irrelevant..

• add a command line ( + config file ) argument to set the alert check loop interval in seconds [1], now hardcodded to 10s.
• fallback to 5s, alerts should fire immediately on change.

[1] https://github.com/MohawkTSDB/mohawk/blob/master/alerts/alerts.go#L78

Adding complex alerting i.e.

Alert #1 :  "free memory too low"
Alert #2: "cpu_usage too low"
Alert #3: Alert #1 && Alert #2 are on.

https://github.com/MohawkTSDB/mohawk/blob/master/server/handlers/authorization.go#L39

Add a /hawkular/alerts/raw api endpoint:
[ EDIT: always filter by tenant ]

a. get all alerts

Extra points for:

b. filter by state
c. filter by alert_id ( using regex )

Additional points if:

Add a /hawkular/alerts/status api endpoint:
a. get status of alert runner ( e.g. interval, buffer url, time of last complete check cycle ... )

I would like to suggest a more readable way to create and use middlewares.

Instead of creating a structure with parameters, we can write a function that get those parameters and return a new function that implements the logic of the middleware.

For example, instead of writing a authentication middleware like this

type AuthMw struct {
  Token string
  RegexpPath string
  next http.Handler
}

func (amw *AuthMw) SetNext(h http.Handler) {
  amw.next = h
}

func (amw *AuthMw) ServeHTTP(w ..., r ...) {
   ...
  amw.next(w, r)
}

It will be done in the following way:

func AuthDecorator(token, regexpPath string) Decorator {
   pRegex := regexp.MustCompile(regexpPath)
   tokenVal := "Bearer " + token
  return Decorator(func(h http.HandlerFunc) http.HandlerFunc {
    ...
    h(w,r)
  })
}

In that way we wrote less code and it is easier to reason what the middleware does.

In addition, we could easily wrap middlewares together

var m Middleware
for ix, mw := range middlewares {
 if ix == 0 {
  m = mw
 } else {
  m = mw(m)
 }
}

The alerts module [1] does not have unit tests.

[1] https://github.com/MohawkTSDB/mohawk/tree/master/alerts