Problem configuring Kapacitor from Chronograf, where to find logs?

kapacitor
#1

I’ve installed a full TICK stack on a raspberry. Telegraf, InfluxDB and Chronograf are working correctly.

Now I’ve just installed Kapacitor and make it start, with my local InfluDB being the default db :

Sep 08 19:59:26 d367deb systemd[1]: Started Time series data processing engine..
Sep 08 19:59:27 d367deb kapacitord[47]: '##:::'##::::'###::::'########:::::'###:::::'######::'####:'########::'#######::'########::
Sep 08 19:59:27 d367deb kapacitord[47]:  ##::'##::::'## ##::: ##.... ##:::'## ##:::'##... ##:. ##::... ##..::'##.... ##: ##.... ##:
Sep 08 19:59:27 d367deb kapacitord[47]:  ##:'##::::'##:. ##:: ##:::: ##::'##:. ##:: ##:::..::: ##::::: ##:::: ##:::: ##: ##:::: ##:
Sep 08 19:59:27 d367deb kapacitord[47]:  #####::::'##:::. ##: ########::'##:::. ##: ##:::::::: ##::::: ##:::: ##:::: ##: ########::
Sep 08 19:59:27 d367deb kapacitord[47]:  ##. ##::: #########: ##.....::: #########: ##:::::::: ##::::: ##:::: ##:::: ##: ##.. ##:::
Sep 08 19:59:27 d367deb kapacitord[47]:  ##:. ##:: ##.... ##: ##:::::::: ##.... ##: ##::: ##:: ##::::: ##:::: ##:::: ##: ##::. ##::
Sep 08 19:59:27 d367deb kapacitord[47]:  ##::. ##: ##:::: ##: ##:::::::: ##:::: ##:. ######::'####:::: ##::::. #######:: ##:::. ##:
Sep 08 19:59:27 d367deb kapacitord[47]: ..::::..::..:::::..::..:::::::::..:::::..:::......:::....:::::..::::::.......:::..:::::..::
Sep 08 19:59:27 d367deb kapacitord[47]: 2017/09/08 19:59:27 Using configuration at: /etc/kapacitor/kapacitor.conf
Sep 08 19:59:27 d367deb kapacitord[47]: [run] 2017/09/08 19:59:27 I! Kapacitor starting, version 1.3.1, branch master, commit 3b5512f7276483326577907803167e4bb213c613
Sep 08 19:59:27 d367deb kapacitord[47]: [run] 2017/09/08 19:59:27 I! Go version go1.7.5
Sep 08 19:59:27 d367deb kapacitord[47]: [srv] 2017/09/08 19:59:27 I! Kapacitor hostname: localhost
Sep 08 19:59:27 d367deb kapacitord[47]: [srv] 2017/09/08 19:59:27 I! ClusterID: ee48dd54-7bba-4bf1-a7b5-516e0573de8c ServerID: caf7769f-3935-4d8c-929a-a608b5c13022
Sep 08 19:59:27 d367deb kapacitord[47]: [task_master:main] 2017/09/08 19:59:27 I! opened
Sep 08 19:59:27 d367deb kapacitord[47]: [scrapers] 2017/09/08 19:59:27 I! [Starting target manager...]
Sep 08 19:59:27 d367deb kapacitord[47]: [httpd] 2017/09/08 19:59:27 I! Starting HTTP service
Sep 08 19:59:27 d367deb kapacitord[47]: [httpd] 2017/09/08 19:59:27 I! Authentication enabled: false
Sep 08 19:59:27 d367deb kapacitord[47]: [httpd] 2017/09/08 19:59:27 I! Listening on HTTP: [::]:9092
Sep 08 19:59:27 d367deb kapacitord[47]: [run] 2017/09/08 19:59:27 I! Listening for signals

which looked good, except when I go to chronograf, click on “Configure Kapacitor”, then click on “Connect”, absolutely nothing happens (no error, no warning, nothing) and nothing is written in /var/log/kapacitor as well.

What should I do from here ?

P.S. I’m I using the conf your provide in resin .io demo with default = true for my local InfluxDB :

#2

So today, I’ve just clicked again on “Connect” in “Configure Kapacitor” and it just worked.

I think Chronograf is still very unstable in its display and UI, I’ve had similar problems editing a query, I had to do it 3 times before it’s taken into account.

I guess that’s the reason why you don’t use Chronograf in your Kapacitor “getting started”.

#3

BTW, if you’re running TICK on a Raspberry Pi, you might be interested in this:

Don’t be fooled by the project name. It’s a full docker-compose stack for the RPi, and it also includes Grafana. All configs and logs are exported to the host’s filesystem so you can easily configure and monitor the stack. I’ve had it running on a few RPis for several weeks now.

#4

Yes, it’s interesting, but how do you update your raspberries ? You ssh to each of them and issue some docker-compose commands right ?

#5

The reason I went with Docker rather than “native” installation is for faster deployment on fresh RPis and easy updates on an individual device basis. Flashing the microSD offline is probably just as effective, for initial installation at least.

Yes, the update process is to ssh to each and rebuild via docker-compose, which can be easily scripted if necessary. However, in terms of managing many devices, able to pull updates themselves automatically, there would obviously need to be a better way. Pre-configured apt packages on a package repository is one option, as is an accessible docker hub (registry) that the RPIs can pull docker images from, with a bit of scripting to support a DM interface for triggering updates. Docker’s layered filesystem would make most updates very small, and rollback is possible too by simply discarding layers (config rollback is a harder problem).

#6

Here, we are using “resin.io” platform. Quite limited for now, because u have only one container (it should evolve before end of year), but already very industrialized in many aspects (read-only rootfs for host, building automaton, fast deploy, …)