* This stack has for purpose to know if all promises, services, custom monitoring scripts went/are ok.
Monitor
* The second purpose of this stack is to implement a zero-knowledge feature : it means you can use its control interface to provide the user with sensible data. It can also let the user change some parameters
=======
* It also provides a web interface, to see which promises, services and custom scripts failed. It also provide a rss feed to easily know the actual state of your instance, and to know when it started to went bad. You can also add your own monitoring scripts, or cgi files (or just files) that you would want to check easily using a web interface.
This stack has for purpose to know if all promises went/are ok.
Implementation :
----------------
It provides a web interface, to see which promises failed. It also provide a rss
1/ In the software.cfg of your Software Release, extends the stack
feed to easily know the actual state of your instance, and to know when it
2/ In the template that will be copied for the buildout in the instance folder (instance.cfg ?), you have to add these parts:
started to went bad.
###Parts to add for monitoring
slap-parameters
Index:
certificate-authority
cron
- Activate monitoring for you software
cron-entry-monitor
- Add a monitor promise
cron-entry-rss
- Information about URL access
deploy-index
- Monitor promise configuration example
deploy-index-template
- Promise requirements
deploy-monitor-script
- monitor.haljson example
deploy-rss-script
- monitor.conf example
deploy-settings-cgi
deploy-status-cgi
make-rss
Activate monitoring for your software
monitor-promise
-------------------------------------
setup-static-files
certificate-authority
You just have to extend the monitor stack from your software.cfg.
public
zero-parameters
You can also create a new buildout which extends your software, and the
cgi-httpd-wrappers
monitoring stack:
public-symlink
[buildout]
* If you want to add a custom monitoring script, you can write it (in whatever language you wish) and save it in YOUR_INSTANCE_FOLDER/etc/monitor.
extends =
The only thing to know, is that if your script successfully passed, do not return or print nothing. If there is a problem, you can print the explanation on stdout or stderr
monitor_url
my_software_url
* Here are 2 promises that you can add to your instance buildout, to see if it is working (one is ok, not the other) :
[google-promise]
In your instance.cfg, your publish section should be named `[publish]` in order
recipe = slapos.cookbook:check_url_available
to extends the one of the monitoring stack.
path = $${directory:promise}/google
url = http://www.google.com
Then, in the same file you can configure the monitor by adding this section:
dash_path = ${dash:location}/bin/dash
curl_path = ${curl:location}/bin/curl
[monitor-instance-parameter]
monitor-httpd-ipv6 = ...
[failing-promise]
monitor-httpd-port = ...
recipe = slapos.cookbook:check_url_available
monitor-title = ...
path = $${directory:promise}/fail
url = http://127.0.0.2
dash_path = ${dash:location}/bin/dash
Add a monitor promise
curl_path = ${curl:location}/bin/curl
---------------------
For instance, we want to create a promise for KVM log parsing. Add these
CGI Scripts:
sections in its instance.cfg:
------------
This stack also provides a web interface, in wich you can execute custom cgi scripts, or just print files. The web link is provided in the published parameters, as for the password that you have to change as soon as possible
[directory]
monitor-promise = ${:etc}/monitor-promise
In that interface you will have access to the previous scripts and the RSS feed. You can also add your files/scripts.
[kvm-log-parser-promise]
For that, there exists a folder /var/cgi-bin. You should see that directory as a tree having of deep 2. In /var/cgi-bin, you must create only folders, which are called categories. In each category, you can then add your own files.
recipe = ....
filename = kvm-log-parser
The backend system will automatically render the webpage according to the inside structure of the cgi-bin directory. Moreover, it will also let you access to your scripts only if you are logged in : you do not need do do your own authentication system !
* /!\A default password is set up at the installation : "passwordtochange". It has to be rewritten in the control interface by the user itself
* /!\ If you use the recipe zeroknown, never name a parameter "recipe" or "password".
We can optionaly add promise title:
* The control interface will let you change the values of the options declared in the [public] section of the config file (see zeroknown recipe). Other section's values will just be printed. These values won't be overwritten by buildout.
* If you want to allow a user to change a parameter, use the recipe zeroknown, with the buildout section name : "[public]"
[kvm-log-parser-promise-parameter]
* If you manually change a parameter, it could take some time for the modifications to be applied (at least 1 or 2 slapgrid-cp)
# fill with -> see "Service config example" below
* If you need to change the port of the web interface of the monitoring stack, just create in your software release file a part called [monitor-parameters] and give the new port value to the parameter "port".
Open HTTP GET on static files, open HTTP POST on cgi
GET <root_monitor>/ // classical monitoring interface
GET <root_monitor>/monitor.haljson // monitor conf
GET <root_monitor>/public/<service>.status.json // service status json
Example for KVM log parsing promise
GET <kvm_monitor>/monitor.haljson
GET <kvm_monitor>/public/kvm-log-parser.status.json
GET <kvm_monitor>/public/kvm-log-parser/index.html
POST <kvm_monitor>/cgi-bin/monitor-run-promise.cgi?service=kvm-log-parse // rerun the promise
Information about internal file tree
------------------------------------
Tree for monitor runtime:
etc/monitor.conf // generated by slapos
etc/cron.d/monitor // generated by slapos
bin/monitor.py // generated by slapos
srv/monitor/web/index.html // static
srv/monitor/web/monitor.css // static
srv/monitor/web/monitor.js // static
srv/monitor/web/monitor.haljson // generated by monitor.py
srv/monitor/public/.... // generated by monitor.py
srv/monitor/private/.... // generated by monitor.py
Example for KVM log parsing promise
etc/monitor-promise/kvm-log-parse.cfg // generated by slapos (kvm-log-parser-promise)
etc/monitor-promise/kvm-log-parse // generated by slapos (kvm-log-parser-promise)
var/kvm-log-parser-promise/interface/index.html // generated by slapos (kvm-log-parser-promise)
var/log/kvm.log // generated by kvm
var/log/kvm-log-parse-last-report.csv // generated by kvm-log-parse
srv/monitor/public/kvm-log-parse.status.json // generated by kvm-log-parse (indirectly by the monitor promise executor)
srv/monitor/public/kvm-log-parse/kvm.log -> var/log/kvm.log // generated by monitor.py
srv/monitor/public/kvm-log-parse/kvm-log-parse-last-report.csv -> var/log/kvm-log-parse-last-report.csv // genareted by monitor.py
srv/monitor/private/kvm-log-parse/interface -> var/kvm-log-parser-promise/interface // generated by monitor.py
Monitor promise config example
------------------------------
Example for KVM log parsing promise
# etc/monitor-promise/kvm-log-parse.cfg
[service]
[service]
title = Kvm log parse
title = Kvm log parse
frequency = <Cron Syntax>
frequency = <Cron Syntax>
public-path-list = $instance/var/log/kvm.log # automatically symlink to srv/monitor/public/$service/
public-path-list = $instance/var/log/kvm.log # automatically symlink to srv/monitor/public/$service/
private-path-list = $instance/var/log/kvm.log # automatically symlink to srv/monitor/private/$service/
private-path-list = $instance/var/log # automatically symlink to srv/monitor/private/$service/
On cron, the command will be something like:
on cron, the command will be `${service:frequency} ${monitor:promise-executor-path} '${monitor:service-pid-folder}/${service:name}.pid' '${service:status-path}' '${promise_path}' `
