The easiest way to run SMG these days is using the OCI-compatible container image. It comes bundled with a bunch of service clients needed to access services natively (e.g. redis, mysql clients etc).
The actual container runtime does not need to be Docker but the examples below will use docker as the most popular choice. Note that these commands should be mostly compatible with RedHat’s podman too.
SMG needs two logical persistent volumes to be kept across container restarts
The /etc/smg/conf.d/ directory is intended for “manual” configs (in the Kubernetes case these would normally be ConfigMaps). Typycally one would configure any needed SMG globals there, notification recipients etc and possibly some one-off stats. It is not strictly required for basic SMG functioning.
The /opt/smg/data directory will be used by SMG to store all persistent data including actual rrd files under /opt/smg/data/rrd/, monitor logs, monitor states persisted across restarts but can also contain target configs the autoconf plugin (/opt/smg/data/conf/autoconf.d/). These can be maintained by human or managed/generated by a Configuration Management system like Ansible or Chef, or in the Kubernetes case - the Kube (autodiscovery) plugin. Note that the SMG autoconf plugin will also use targets defined in /etc/smg/autoconf.d/, which is the intended location for “manually” managed targets. One can mount that as another persistent mount and use it, however the examples in these howtos will use /opt/smg/data/conf/autoconf.d/ for simplicity.
The autconf private (conf/autoconf-private.d/) directory also lives under /opt/smg/data - this directory contains all autoconf targets template outputs and is normally owned/managed by the plugin. That (/opt/smg/data/conf/autoconf-private.d) directory is included by the bundled with the image /etc/smg/config.yml which is required for autoconf to function.
Here are some example commands to get the SMG image up and running on a local Linux machine.
$ sudo mkdir -p /opt/smg/data /etc/smg/conf.d ; sudo chown `whoami` /etc/smg/conf.d /opt/smg/data
$ docker run -d --name smg -p 9000:9000 \
-v /etc/smg/conf.d:/etc/smg/conf.d -v /opt/smg/data:/opt/smg/data \
gcr.io/asen-smg/smulegrapher:latest
Point your browser to http://%DOCKER_HOST%:9000 (the local SMG stats should show up in a minute or two). Note that its possible to run SMG in root-less container runtime (tested with podman docker emulation). Also the /etc/smg and /opt/smg dirs don’t need to be in a system-wide location (can be under your home dir), yet these are used with the examples in the howtos for consistency.
Then add stuff under /etc/smg/conf.d or /opt/smg/data/conf/autoconf.d/ and to reload conig use one of:
$ docker exec smg /opt/smg/inst/smg/smgscripts/reload-conf.sh
or
$ curl -X POST http://%DOCKER_HOST%:9000/reload
Use the docker logs command to check for errors if something does not look right.
Note that such setup is fine for small-scale operations (like up to a few thousands of graphs updated every minute). For more demanding/production setups it is recommended to use rrdcached for batching the writes and nginx to serve the images.
Use the docker/docker-compose.yaml file in the SMG repo to easily bring up a production-ready SMG setup.
$ sudo mkdir -p /etc/smg/conf.d ; sudo mkdir -p /opt/smg/data ; sudo chown `whoami` /etc/smg/conf.d /opt/smg/data
$ git clone https://github.com/asen/smg.git
$ cd smg/docker
$ docker-compose up -d
or (with podman)
$ podman-compose up -d
Point your browser to http://%DOCKER_HOST%:9080 (the local metrics stats should show up in a minute or two)
And if you are running Kubernetes - check the k8s/ dir for example production deployment.