export and scrape dibbler prometheus stats #143

Open
vegardbm wants to merge 1 commits from dibbler-prometheus into main
Owner

As it stands it would be pretty difficult to add another database connection.

As it stands it would be pretty difficult to add another database connection.
Author
Owner
closes Drift/issues#192
vegardbm reviewed 2026-06-07 09:35:19 +02:00
oysteikt reviewed 2026-06-07 10:55:51 +02:00
@@ -0,0 +15,4 @@
jobs.dibbler = {
interval = "1m";
connections = [
"postgres://pvv_vv:WP97&amDp&*gfhg3TyR8@postgres.pvv.ntnu.no"
Owner

bro...

bro...
Author
Owner

lol, lmao even

lol, lmao even
vegardbm marked this conversation as resolved
vegardbm force-pushed dibbler-prometheus from 13a9af64bc to 864cdab35e 2026-06-07 17:58:42 +02:00 Compare
vegardbm reviewed 2026-06-07 18:03:52 +02:00
@@ -0,0 +48,4 @@
help = "Sum of purchases for the current day.";
labels = [ "thing" ];
values = [ "sum" ];
query = "SELECT SUM(price) FROM purchases GROUP BY DATE(time) ORDER BY DATE(time) DESC LIMIT 1";
Author
Owner

This is likely inefficient.

This is likely inefficient.
Owner

If we put a database index on time it's probably gonna be less inefficient. How fast does it run with current data?

If we put a database index on `time` it's probably gonna be less inefficient. How fast does it run with current data?
Author
Owner
pvv_vv=*# EXPLAIN ANALYZE SELECT SUM(price) FROM purchases GROUP BY DATE(time) ORDER BY DATE(time) DESC LIMIT 1;
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=2359.35..2359.35 rows=1 width=12) (actual time=30.052..30.054 rows=1.00 loops=1)
   Buffers: shared hit=367
   ->  Sort  (cost=2359.35..2501.88 rows=57010 width=12) (actual time=30.051..30.052 rows=1.00 loops=1)
         Sort Key: (date("time")) DESC
         Sort Method: top-N heapsort  Memory: 25kB
         Buffers: shared hit=367
         ->  HashAggregate  (cost=1361.68..2074.30 rows=57010 width=12) (actual time=28.429..29.387 rows=5194.00 loops=1)
               Group Key: date("time")
               Batches: 1  Memory Usage: 1305kB
               Buffers: shared hit=364
               ->  Seq Scan on purchases  (cost=0.00..1076.62 rows=57010 width=8) (actual time=0.034..14.387 rows=57038.00 loops=1)
                     Buffers: shared hit=364
 Planning:
   Buffers: shared hit=51
 Planning Time: 0.349 ms
 Execution Time: 31.113 ms
(16 rows)
```text pvv_vv=*# EXPLAIN ANALYZE SELECT SUM(price) FROM purchases GROUP BY DATE(time) ORDER BY DATE(time) DESC LIMIT 1; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------ Limit (cost=2359.35..2359.35 rows=1 width=12) (actual time=30.052..30.054 rows=1.00 loops=1) Buffers: shared hit=367 -> Sort (cost=2359.35..2501.88 rows=57010 width=12) (actual time=30.051..30.052 rows=1.00 loops=1) Sort Key: (date("time")) DESC Sort Method: top-N heapsort Memory: 25kB Buffers: shared hit=367 -> HashAggregate (cost=1361.68..2074.30 rows=57010 width=12) (actual time=28.429..29.387 rows=5194.00 loops=1) Group Key: date("time") Batches: 1 Memory Usage: 1305kB Buffers: shared hit=364 -> Seq Scan on purchases (cost=0.00..1076.62 rows=57010 width=8) (actual time=0.034..14.387 rows=57038.00 loops=1) Buffers: shared hit=364 Planning: Buffers: shared hit=51 Planning Time: 0.349 ms Execution Time: 31.113 ms (16 rows) ```
Author
Owner

There is another one which is also pretty bad compared to the others:

pvv_vv=*# EXPLAIN ANALYZE SELECT SUM(price) FROM purchases;
                                                      QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=1076.62..1076.63 rows=1 width=8) (actual time=16.758..16.759 rows=1.00 loops=1)
   Buffers: shared hit=364
   ->  Seq Scan on purchases  (cost=0.00..934.10 rows=57010 width=4) (actual time=0.030..8.101 rows=57038.00 loops=1)
         Buffers: shared hit=364
 Planning Time: 0.042 ms
 Execution Time: 16.784 ms
(6 rows)
There is another one which is also pretty bad compared to the others: ``` pvv_vv=*# EXPLAIN ANALYZE SELECT SUM(price) FROM purchases; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------- Aggregate (cost=1076.62..1076.63 rows=1 width=8) (actual time=16.758..16.759 rows=1.00 loops=1) Buffers: shared hit=364 -> Seq Scan on purchases (cost=0.00..934.10 rows=57010 width=4) (actual time=0.030..8.101 rows=57038.00 loops=1) Buffers: shared hit=364 Planning Time: 0.042 ms Execution Time: 16.784 ms (6 rows) ```
Owner

Yeah, but that one is kinda inherent. There's no way to sum all purchases without actually looping over all the purchases and summing them. You can speed either by creating a index on the expression (effectively moving the calculation to being done everytime someone makes a purchase) or by doing more fancy things to only sum news rows onto a previously cached sum.

I wouldn't really worry though, it's still just 16 milliseconds

Yeah, but that one is kinda inherent. There's no way to sum all purchases without actually looping over all the purchases and summing them. You can speed either by creating a index on the expression (effectively moving the calculation to being done everytime someone makes a purchase) or by doing more fancy things to only sum news rows onto a previously cached sum. I wouldn't really worry though, it's still just 16 milliseconds
Owner

Here's the relevant statements ftr:

CREATE INDEX "purchases_by_date" ON "purchases"(DATE("date"));
CREATE INDEX "purchases_price_sum" ON "purchases"(SUM("price"));
Here's the relevant statements ftr: ```sql CREATE INDEX "purchases_by_date" ON "purchases"(DATE("date")); CREATE INDEX "purchases_price_sum" ON "purchases"(SUM("price")); ```
vegardbm reviewed 2026-06-07 18:10:38 +02:00
@@ -1,5 +1,6 @@
config:
mysqld_exporter_password: ENC[AES256_GCM,data:I9K+QMqaN3FOOVKzeOR9Q6UERStXX0P8WEHyN1jzzbM=,iv:UxvIdlfAyJvNuxPkU4+guKPa0fiD0vVLzHOTYktcmso=,tag:ltnIqEwESYx9HBu8UN0ZLw==,type:str]
postgresql_dibbler_password: ENC[AES256_GCM,data:wP4CVz9qRE3CJrblWWYqOIkcH3LM5H81,iv:j8zr1TRNlPPqIppYlWhDoKlL7m2Ph2wQlU6bvFj8R9A=,tag:Cfp8zbYkoLqI7DTDpOBlJw==,type:str]
Author
Owner

This duplicates the dibbler postgresql database password.

This duplicates the dibbler postgresql database password.
Owner

Probably fine for now, we don't have very good order in our sops files. At some point we should do some spring cleaning and create shared files for shared passwords

Probably fine for now, we don't have very good order in our sops files. At some point we should do some spring cleaning and create shared files for shared passwords
oysteikt reviewed 2026-06-08 03:23:11 +02:00
@@ -0,0 +80,4 @@
LoadCredential = "postgresql_dibbler_password:${
config.sops.secrets."config/postgresql_dibbler_password".path
}";
ExecStartPre = ''/bin/sh -c '${lib.getExe' pkgs.coreutils "cat"} ${configFile} | ${lib.getExe' pkgs.jq "jq"} -c \".jobs[0].connections[0]=\\\"postgres://pvv_vv:$(${lib.getExe' pkgs.coreutils "cat"} %d/postgresql_dibbler_password)@postgres.pvv.ntnu.no\\\"\" > /run/prometheus-sql-exporter/config.yaml' '';
Owner

This one is kinda hard to read.

Modern systemd allows you to prepend a | to get rid of the /bin/sh invocation. jq also has --slurpfile and --rawfile to get rid of most of the file trickery. Also, newlines are allowed with a \ just like in ExecStart (alternatively you can construct the args with lib.cli.toCommandLineShellGNU)

ExecStartPre = ''
  |${lib.getExe pkgs.jq} \
    --null-input \
    --compact-output \
    --slurpfile config '${configFile}' \
    --rawfile pw '%d/postgresql_dibbler_password' \
    --from-file '${pkgs.writeText "prometheus-sql-exec-start-jq-filter" ''
      ("postgres://pvv_vv:\($pw | gsub("\n"; ""))@postgres.pvv.ntnu.no") as $pg_uri
      | $config[0]
      | .jobs[0].connections[0] = $pg_uri
    ''}' > /run/prometheus-sql-exporter/config.yaml
'';
This one is kinda hard to read. Modern systemd allows you to prepend a `|` to get rid of the `/bin/sh` invocation. `jq` also has `--slurpfile` and `--rawfile` to get rid of most of the file trickery. Also, newlines are allowed with a `\` just like in `ExecStart` (alternatively you can construct the args with `lib.cli.toCommandLineShellGNU`) ``` ExecStartPre = '' |${lib.getExe pkgs.jq} \ --null-input \ --compact-output \ --slurpfile config '${configFile}' \ --rawfile pw '%d/postgresql_dibbler_password' \ --from-file '${pkgs.writeText "prometheus-sql-exec-start-jq-filter" '' ("postgres://pvv_vv:\($pw | gsub("\n"; ""))@postgres.pvv.ntnu.no") as $pg_uri | $config[0] | .jobs[0].connections[0] = $pg_uri ''}' > /run/prometheus-sql-exporter/config.yaml ''; ```
Author
Owner

What you provided works. Modified to use |, --slurpfile and --rawfile.

What you provided works. Modified to use |, --slurpfile and --rawfile.
vegardbm marked this conversation as resolved
vegardbm added 1 commit 2026-06-08 10:54:27 +02:00
prometheus for dibbler
Eval nix flake / evals (pull_request) Successful in 6m14s
Eval nix flake / evals (push) Successful in 6m33s
be87d98060
vegardbm force-pushed dibbler-prometheus from 864cdab35e to be87d98060 2026-06-08 10:54:27 +02:00 Compare
Some checks are pending
Eval nix flake / evals (pull_request) Successful in 6m14s
Eval nix flake / evals (push) Successful in 6m33s
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin dibbler-prometheus:dibbler-prometheus
git checkout dibbler-prometheus
Sign in to join this conversation.
No Reviewers
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Drift/pvv-nixos-config#143