Created attachment 188071 [details] diff -Nru from 1.8 to 2.0.0 Hey guys, attached you'll find the diff (made with diff -Nru) from current prometheus in ports (1.8) to 2.0.0, as the new version reduces required IOPS by 90%, and thus greatly improves usability.
Hey, thanks for the update. Shouldn’t it be released as net-mgmt/prometheus2 as storage engines are not compatible and official migration guide recommens launching two versions at once and use replicate data via network.
I have no prior experience with a situation like this. Might make sense, on the other hand maybe a warning? It would make more sense if they had a 1.x branch running aside with 2, but that's not gonna be the case.
Created attachment 188387 [details] renames prometheus-2.0.0 to prometheus2-2.0.0 As requested, i've renamed the package to prometheus2-2.0.0 while adding a conflict with -1.*. lints, tested for 10.1 and 11.1 amd64.
I was just doing a little work on this when I thought I'd check to see if anyone else was looking at it. Given the migration path here, the prometheus2 package conflicting with Prometheus 1 means that it's difficult for a user to run both versions side by side. However, fixing that means changing a lot of things in the Prometheus 2 package, binary names, config names, etc. In order to run both versions of Prometheus, a user requires the following: - The Prometheus 1 /var/db/prometheus - A Prometheus 1 configuration file, with just the external_labels settings, if any - Prometheus 1 running on a different port, in read-only (no scraping) mode. - Addition of a remote_read setting to the Prometheus 2 config file. The main thing to preserve is the /var/db/prometheus directory, as such, I'd recommend changing the default $prometheus_data_dir to /var/db/prometheus2. This should preserve the old data in the vast majority of cases and we see other packages doing similar things under /var/db when there are version changes like this. I'd then provide some instructions via the pkg-message on running Prometheus 1 alongside Prometheus 2. This is only needed until the metrics in Prometheus 1 are old enough to no longer be required. The pkg-message could mention how a user can download the prometheus 1 package (pkg fetch -o . prometheus), extract it (cd <suitable dir> && tar xvf <path to prometheus pkg>) and run the binary (<path to extraction dir>/usr/local/bin/prometheus -config.file prometheus1.yml -web.listen-address :9094). Another method would simply be downloading the pre-compiled FreeBSD binary from Github, but then you lose the trust of the FreeBSD pkg system. If Prometheus was running under a jail, the whole process is obviously a lot simpler. Create a new jail for Prometheus 2, have it remote read the old Prometheus 1 without going through any of this (except maybe changing the port, depending on how your jail addressing works). At the very least, the Prometheus 2 pkg-message could provide a link to the migration guide and then the user can work out what's required for their setup. Even in this case, I believe changing the Prometheus 2 default $prometheus_data_dir is a good idea. -David
Hi David, Thank you for taking the time. Your plan looks good to me. Can you clarify if you think the new binary should be name `prometheus2`, or do you recommend that people deinstall prometheus v1 first, and reinstall it to a custom directory? -Jev
After considering this for a while, and speaking with some other FreeBSD porters, the best thing is probably to continue with the `prometheus2` package. However, it should not conflict with the `prometheus` package, as both are required to run together for the migration period if a user wishes to take that path. This means the binaries become `prometheus2` and `promtool2`, the config becomes `prometheus2.yml`, the pidfile becomes `prometheus2.pid`, the rc.conf variables receive similar treatment, etc. In this case, a few words in the `pkg-message` linking to the migration guide on the Prometheus site, should suffice. People can then work out what they need to do to fix up their old config to work with Prometheus 2 while not losing access to their old data immediately. The most complicated part is likely to be alerting and recording rules, but `promtool` can help with that and instructions for this are in the migration guide too. Viewing the `prometheus2.shar` that was submitted (which looks good), this should just be a few minor changes. -David
(In reply to David O'Rourke from comment #6) Hey David, thanks for getting the research up on this, i'll be making the modifications hopefully when i get time this week and re-upload the new shar. Thanks again!
I've added a bug report with a new prometheus2 port at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225169 The port works well and I've been running it for a short time locally. I've listed myself as the maintainer in the Makefile, but I'm happy for jevonearth to continue to maintain the prometheus2 port if he wishes since it's mostly based on his 1.x work. Conversely, I'm also happy to take over maintainership of the node_exporter and prometheus 1 ports if jevonearth is lacking time to maintain them these days. -David
Hi David, I'm happy for you to take maintainership of the v2.0 port. Thank you.
22:23 < phyber> anyone feel like quickly closing https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223720 ? This was handled elsewhere and the port was split into prometheus1 and prometheus2.