- Smarty 67.6%
- Makefile 32.4%
| templates | ||
| .gitignore | ||
| .helmignore | ||
| Chart.yaml | ||
| icon.svg | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| values.yaml | ||
Dexcom Exporter
This helm chart provides a Prometheus exporter for Dexcom data - a blood sugar monitor.
It uses the Dexcom API to retrieve data, and thus needs suitable credentials. Using the same credentials as you would use for the Dexcom Follow App should work.
This also includes:
-
a
ServiceMonitor: will cause Prometheus to automatically scrape the exporter for data. -
a few
PrometheusRulesto create alerts for when the blood sugar level is too high or too low.
The k8s cluster must already have
Prometheus
installed as this provides the Custom Resource Definitions for
ServiceMonitors and PrometheusRules.
Note that this helm chart only installs the prometheus exporter for a single Dexcom user. If you need to monitor multiple Dexcom users, you need to install multiple instances, each with their own set of credentials.
Values
Most values for the helm chart are pretty vanilla and uninteresting
enough to only be documented as comments in
values.yaml.
For a working installation, you probably only need to set these values:
dexcom:
username: "YourDexcomUserName"
password: "YourDexcomPassword"
region: ous
friendlyName: "Little Red Riding Hood"
dexcom.username
Username for the Dexcom Share user (not the follower)
dexcom.password
password for the Dexcom Share user
dexcom.region
Regions: Dexcom seems to split the world into 3 regions:
us: the USAjp: Japanous: Everthing else ("outside the US"?, but Japan is neither inside nor outside the US?)
I.e. their naming is not consistent and does not follow commonly used standards.
Note that specifying the wrong region will cause authentication to fail.
dexcom.friendlyName (optional)
The human-readable human name of the person whose blood sugar is being monitored.
This is used in alerts in preference over dexcom.username as
usernames are not really "human" enough. E.g. your dexcom username
may be something like joebloggs76; setting dexcom.friendlyName to
Joe Bloggs makes for nicer alerts.
Alerts
The installation includes PrometheusRules which create alerts for
high/low blood sugar levels.
By default there 2 main types of alerts:
BloodSugarLevelLow(with a label:action: needsGlucose)BloodSugarLevelHigh(with a label:action: needsInsulin)
Each alert comes in 2 varieties with different severity labels:
warning and critical.
At the moment the alerts levels are only expressed in units of mmol/ltr. (US: Users: Sorry: you have to convert from mg/dl)
The defaults are:
| Glucose Level | Alert |
|---|---|
| x < 3.1 | alertname=BloodSugarLevelLow severity=critical action=needsGlucose |
| x < 4 | alertname=BloodSugarLevelLow severity=warning action=needsGlucose |
| 4 <= x < 11 | No alert |
| 11 <= x | alertname=BloodSugarLevelHigh severity=warning action=needsInsulin |
| 20 <= x | alertname=BloodSugarLevelHigh severity=critical action=needsInsulin |
| no data | alertname=NoBloodSugarData severity=warning |
The levels can be customised in the rules section (see
values.yaml for details).
As a design choice: alerts are specific to a dexcom user; customising the alert levels for one user will not affect other users.
In addition, all alerts will have these labels:
dexcom_username=xxxx: the username the alert pertains to, as given in.Values.dexcom.usernamecategory=bloodsugar: an easy way to identify blood sugar related alerts, regardless of which user it pertains to.
AlertManager
Note that when blood sugar level is very high (e.g. > 20), prometheus
will fire both alerts for BloodSugarLevelHigh - i.e. both the one
with severity=warning and the one with severity=critical (same
thing happens with the BloodSugarLevelLow alerts with levels < 3.1).
This is not a problem as the default AlertManager configuration
inhibits warning alerts when a critical alert with the same name
is firing. This is due to Alertmanager's default configuration which
contains:
inhibit_rules:
- source_matchers:
- severity="critical"
target_matchers:
- severity=~"warning|info"
equal:
- namespace
- alertname
However: This default configuration is a problem if you monitor multiple dexcom users: If:
- Dexcom user
Alicehas a blood sugar level of 12: Prometheus will an alert withdexcom_username=Alice,alertname=BloodSugarLevelHigh&severity=warning - and dexcom user
Bobhas a blood sugar level of 22: Prometheus will fire an alert withdexcom_username=Bob,alertname=BloodSugarLevelHigh&severity=critical - and the two dexcom exporters are installed in the same kubernetes namespace
Then Alertmanager will inhibit the alert for Alice ! (a similar
scenario exists for alertname=BloodSugarLevelLow)
To fix this problem, do one (or more) of:
- Install the dexcom exporters in separate namespaces
- Tweak the Alertmanager configuration to include
dexcom_usernamein the list underequal
Metrics Exposed
The metric names and descriptions are documented in the README.md of the container (adjust URL for the exact container version in use).
The metrics will be decorated with a few labels:
-
dexcom_username: The user name of the dexcom user -
dexcom_eu_username: (deprecated) The user name of the dexcom user. This label only exists for backward compatability; it will be removed in a later release. -
job: Usuallydexcom-exporter, as it is derived from the helm release name chosen at installation time, unlessnameOverrideorfullnameOverrideis set.
Prometheus will also add other (standard) labels like endpoint,
instance, namespace, pod, and service.