This is a continuation of Part 1, in which:
- A new “lite” Raspberry Pi OS image was installed and configured.
- The InfluxDB TICK stack was installed.
- The kiosk/dashboard environment was set up.
- Socat and Node-RED were installed (each are optional).
Set up InfluxDB
The instructions below assume use of InfluxDB 1.8.x.
Database and User Creation
For security, InfluxDB should be configured to require authentication. The user creation details that follow are based upon those provided by InfluxData.
First, create an administrative user via the CLI. Type influx in the system shell, then the following at the InfluxDB shell (where <user> and <password> are replaced with the desired values):
CREATE USER <user> WITH PASSWORD '<password>' WITH ALL PRIVILEGESOnce this session is ended, future InfluxDB shell sessions will require a username and password. Instead of just influx, type the following at the system shell:
influx -username <user> -password <password>A database is needed to write data to. Name this database something relevant to the organization and dashboard content. In the InfluxDB shell:
CREATE DATABASE <database>This database needs a default retention policy. I’ve decided to keep high-resolution resolution data for 12 (twelve) hours. A longer-term retention policy will be created later that will down-sample this data. In the query below, REPLICATION 1 is required, set to “1 for single node instances” per this guide. Don’t forget the DEFAULT keyword.
CREATE RETENTION POLICY twelve_hours ON <database> DURATION 12h REPLICATION 1 DEFAULTThe default retention policy can always be changed later.
Next, create a non-administrative user with write privileges to the database. This user will be used by data providers (i.e. Telegraf, Node-RED) to post values to the database. In the InfluxDB shell:
CREATE USER <write_user> with PASSWORD '<password>'
GRANT WRITE ON <database> TO <write_user> Then, create a third user with both read and write privileges to the database. This user will be used for dashboard access to the data.
CREATE USER <write_user> with PASSWORD '<password>'
GRANT ALL ON <database> to <read_write_user>Configuration File
As of right now, my configuration file is quite simple. I like clean configuration files, so the first thing I did was copy the repo-provided sample config to influxdb.conf.sample.
For the most part, I’m sticking with default settings, as they work just fine for this application. If you have time (and I recommend it), review each setting in this guide and set up your configuration accordingly.
My configuration is as follows (I’ve removed the inline comments), with a description afterwards:
reporting-disabled = false
[meta]
dir = "/var/lib/influxdb/meta"
[data]
dir = "/var/lib/influxdb/data"
wal-dir = "/var/lib/influxdb/wal"
# wal-fsync-delay = "5s"
query-log-enabled = false
[coordinator]
log-queries-after = "0s"
[monitor]
store-enabled = false
[http]
auth-enabled = true
log-enabled = false
pprof-enabled = false
max-connection-limit = 50
flux-enabled = true
[logging]
level = "warn"In the configuration above:
- Reporting of anonymous data to InfluxData is disabled (
reporting_disabled). - The
[meta] dir,[data] dirandwal-dirdefinitions are required, even though I’m using the default locations. If they’re not included, Influx DB will not start. There are some considerations for the location of these paths, particularly for the Write Ahead Log (WAL), which is a temporary cache for written points:- Recall that in this application, an SD card is in use. Should the WAL be located on another storage device to reduce flash memory wear?
- Per the docs, the WAL and data directories should be on separate devices if write load is heavy. I don’t think we’re anywhere near approaching that scale for this project.
- The
wal-fsync-delaydirective doesn’t seem to work, so it’s temporarily commented out. The intent was to reduce the frequency at which data is written from the WAL. - In an attempt to minimize SD card wear (at the penalty of reduced debugging info):
- query logging (
query-log-enabled) is disabled. - the logging level is set to
warn(could be downgraded toerror). - slow query logging is disabled (
log_queries_after) – this is actually disabled by default. - the recording of internal statistics is disabled (
store-enabled). - HTTP request logging is disabled (
log-enabled).
- query logging (
- HTTP and HTTPS authorization is required (
auth-enabled). - Debugging via HTTP is disabled (
pprof-enabled). - Maximum connections are set to a somewhat arbitrary 50 (
max-connection-limit). - The Flux query endpoint is enabled (
flux-enabled) to support Flux queries in Chronograf.
Compaction Issues (SBC Limitations)
While researching recommendations from other projects, I came upon this post, which doesn’t exactly bode well for running InfluxDB on a Raspberry Pi SBC (especially a 3B, with only 1 GB of RAM).
My takeaways (for now, pending future review):
- InfluxDB may be designed primarily for large-scale operations, running in the cloud, and isn’t intended to be rebooted regularly. That perception certainly doesn’t align with the IoT/SBC model.
- Many of the individuals with issues seem to be running fairly large-scale data collection operations. For this project, data collection is quite limited (which should help). Less than a dozen points collected every 5 seconds.
- Keeping the database small is critical. Deleting old data is a must-do. I’m going to target keeping the data directory to well-under my RAM size (1 GB).
- The present version of Raspberry Pi OS is 32-bit (though there is a 64-bit beta). Switching to an alternate OS that supports a 64-bit environment may help, though with potential hardware support downsides. This likely wouldn’t do much on a Pi with only 1 GB of RAM, however.
- I’ll keep an eye out for future developments…
For now, I’m going to keep the design as-is. System performance during the 2021 pool season will reveal a lot, I think.
A quick way to reveal the directory sizes for InfluxDB:
sudo du -h --max-depth=1 /var/lib/influxdb/Final Customization
To disable the logo at startup, add the following on the existing line in /boot/cmdline.txt:
logo.nologo