Define the implementation standard for developing checkers/notifiers

[falzm]

Hi

Could you please define a standard/API or some guidelines so that anyone could contribute new checkers/notifiers to this project?

About checking protocols/applications that aren't natively supported by the standard Go lib: would you prefer use existing external packages or strictly develop yours to avoid external dependencies?

m.

[oguzbilgic]

As for now, I am not sure what the best structure for the notifiers is. So I think we should first start by implementing new checkers.

Contribution Flow

• First create an issue for the checker that you want to implement.
• Explain the configuration interface and implementation details you have planned.
• Discuss the details with the maintainers.
• When the details are clarified and agreed, implement your suggestion in your feature branch.
• Send a pull request when you think your feature is complete.

Configuration Interface

Since this is a compiled tool not a library, pandik's main user interface is .pandik.json configuration file. So the important thing is how specific checker's config is organized.

{
  "type": "name-of-the-checker",
  "url": "urloftheserver.com",
  "freq": "10m",
  "data": {
    "key": "value",
    "key2": "value2"
  }
}

First three fields (type, url, freq) of this json is must have for each monitor. The data field is optional, and it contains the required data for the specific type of checker. For example for a ftp server checker, this might me username and password.

Implementation Details

• Each checker should only be just one function.
• Function name and monitor type in the conf file should match. e.g. checkHTTPStatus() - > http-status
• Follow the naming convention for the monitor type. e.g. protocol-thethingchecked -> http-keyword or http-status
• Use go's standart library whenever possible.
• Try to write your own implementation for any protocol that is not included in go's standart library.
• Try not to make any other changes if you are implementing a new checker.
• Checker should return true if its sure that the monitor is up.
• Checker should return false if it is sure that the monitor is down
• Checker should return error if for any reason check could not be completed.

Note: I will keep this post up to date. So please check frequently. I might move this in to a wiki page in the future.

[gedex]

Hi,

I think the best approach to organize checkers and notifiers is to package it. Thus, the structure becomes:

checkers/
  http_status.go
  http_status_test.go
  ssh.go
  ssh_test.go
  ...
  checkers.go // defines interface and/or util funcs


notifiers/
  twitter.go
  twitter_test.go
  web.go
  web_test.go
  ...
  notifiers.go // defines interface and/or util funcs

What do you think?

[falzm]

I agree with @gedex: "pluginify" the checkers and notifiers to facilitate the development.

[oguzbilgic]

Maybe in the future when we have 100s of checkers/notifiers, I can see it being useful but We can already create separate files if checker/notifier is complicated enough. so What is the advantage of putting checkers and notifiers in a separate package/directory.

[gedex]

I don't have any obvious reason other than organizing the structure. But yeah, they can go to separate files under the package main.