Victoriametrics: Debian packages?

[kmansoft]

I know it's a single executable and so is super-easy to install, but ...

... think it would still be cool to have OS format packages, for Debian / Ubuntu (.dpkg) and CentOS / Fedora (.rpm). These could include systemd units for a truly single step install.

I don't know what your build environment is, but .dpkg's are easy to create using standard Linux command line tools like tar etc. without any Debian specific tools. In other words, a .dpkg can be created on any OS (linux distro).

Please see this for how that's done (someone else's project):

https://github.com/DeaDBeeF-Player/deadbeef/blob/master/tools/packages/debian.sh

This approach is also currently working for me in my own project, just fine.

[valyala]

@kmansoft , thanks for raising this question. It would be great to publish regular VictoriaMetrics packages for various Linux distros. Unfortunately we have little experience with packaging systems for Linux distros, so it would be better if someone with better experience could help us with this. See unofficial yum repo for VictoriaMetrics as an example.

[kmansoft]

I'll try to package for debian and submit a pull request next week.

[valyala]

This would be awesome!

[kmansoft]

I just pushed some initial work into

https://github.com/kmansoft/VictoriaMetrics

on the master branch.

This will create a .deb file:

$ ./package/package_deb.sh  amd64

And this will too:

make victoria-metrics-package-deb

The "code" (scripts) are in package_deb.sh.

I still have more work to do on systemd integration (enable the unit, restart if it was / is enabled) but in the meantime, some questions:

• Right now the script is called from the makefile, not the other way around, which is same as your existing arm targets are set up (in the makefile).

This is of course fine but makes it difficult to create packaging scripts from building and packaging more than one architecture "flavor". In other words, you can't run a single command and get .debs for amd64, arm64, ...

• Related to the first item, should I create make targets to package arm flavors?

Something like: victoria-metrics-arm-package-deb and victoria-metrics-arm64-package-deb???

• Should there be a boiletplate /etc/...conf file with at least some comments on what the options are and their default values? A lot of software does this, making it easier for users to learn about settings and/or tweak them.

[kmansoft]

By the way is there a PID file? I can't find one under /var/run

What is the default storage directory? I believe it's standard for data to be stored under /var/lib/ is there a config file option to set it (already seen the command line switch).

The help printout (victoria-timeseries -h) gives:

  -storageDataPath string
        Path to storage data (default "victoria-metrics-data")

But victoria-metrics-data is a relative directory, what is it relative to? The root?

Shouldn't the help message then say:

default "/victoria-metrics-data"

and not

default "victoria-metrics-data"

?

[kmansoft]

Should the executable be running under root - or should the install script create a separate user and run the executable as that user?

BTW dropping from root to a non-privileged user would ideally go into the software itself, not into its run scripts. I can try to take a look at that and maybe submit some code if there is interest.

[valyala]

This is of course fine but makes it difficult to create packaging scripts from building and packaging more than one architecture "flavor". In other words, you can't run a single command and get .debs for amd64, arm64, ...

This is quite easy to do with the following Makefile rule:

victoria-metrics-package-deb-all: \
        victoria-metrics-package-deb \
        victoria-metrics-package-deb-arm \
        victoria-metrics-package-deb-arm64 \
        ...

Should there be a boiletplate /etc/...conf file with at least some comments on what the options are and their default values? A lot of software does this, making it easier for users to learn about settings and/or tweak them.

victoria-metrics-prod -help lists all the config options with descriptions and default values. I'm unsure if additional /etc/...conf file is necessary. Probably such a file must contain instructions on how to run victoria-metrics-prod -help in order to see available config options.
Pull requests with improved descriptions or better default values for config options are welcome.

By the way is there a PID file? I can't find one under /var/run

victoria-metrics-prod doesn't create pid file, so it must be created by wrapper scripts.

What is the default storage directory?

The default storage directory is victoria-metrics-data relative to the current working directory where victoria-metrics-prod runs. See default value for -storageDataPath option. It is expected that the OS-specific package should set -storageDataPath option to more standard directory like /var/lib/victoria-metrics-data.

[valyala]

See also this issue for example instructions on how to set up VictoriaMetrics service under CentOS.

[kmansoft]

@valyala I incorporated all your feedback:

• Data directory under /var/lib
• Packaging for arm64
• "package all" target which builds and packages amd64 and arm64

... except one item: the PID file.

I'm reluctant to add wrapper scripts inside the systemd unit file.

And systemd will not create the PID file: https://serverfault.com/a/817560

This leaves the victoria-metrics process as "the" only actor that can create the PID.

What do you think if I add a new command line option to create a PID file? The default will be blank, i.e. do not create, therefore no change for people running victoria using their own scripts right now.

[valyala]

What do you think if I add a new command line option to create a PID file? The default will be blank, i.e. do not create, therefore no change for people running victoria using their own scripts right now.

-pidfile command line option may be added to VictoriaMetrics, but it is unclear the purpose of this option for VictoriaMetrics. The linked answer says the following about PIDFile option in systemd:

this option tells systemd where to find an existing PID file (if any). In most cases it's not required at all, as systemd will keep services in their own cgroups and does not need a PID file to keep track of them

and

Use of this option is recommended for services where Type= is set to forking

VictoriaMetrics process doesn't call fork(), so the PIDFile option looks redundant for it.

[kmansoft]

-pidfile command line option may be added to VictoriaMetrics, but it is unclear the purpose of this option for VictoriaMetrics.

Clear purpose: operating system integration.

tells systemd where to find an existing PID file (if any). In most cases it's not required at all,

First it's "traditional" to have a pid file.

Even skipping that, the systemd unit needs a PID in order to gracefully terminate the process:

https://github.com/kmansoft/VictoriaMetrics/blob/master/package/victoria-metrics.service

SystemD docs are pretty vague about $MAINPID - I'm not sure how exactly it's set for "simple" unit type, the docs only mention forking type units. It's also unclear if $MAINPID would be read by systemd from thge pid file if it's provided by the unit.

[kmansoft]

OK I did some testing - systemctl stop while watching journalctl from Victoria.

Jul 22 10:56:11 xandra systemd[1]: Stopping VictoriaMetrics is a fast, cost-effective and scalable time series database....
Jul 22 10:56:11 xandra victoria-metrics[13771]: 2019-07-22T07:56:11.288+0000        info        /home/kman/Android/src/VictoriaMetrics-fork/app/victoria-metrics/main.go:33        received signal terminated
Jul 22 10:56:11 xandra victoria-metrics[13771]: 2019-07-22T07:56:11.288+0000        info        /home/kman/Android/src/VictoriaMetrics-fork/app/victoria-metrics/main.go:35        gracefully shutting down webservice at ":8428"
Jul 22 10:56:11 xandra victoria-metrics[13771]: 2019-07-22T07:56:11.288+0000        info        /home/kman/Android/src/VictoriaMetrics-fork/app/victoria-metrics/main.go:41        successfully shut down the webservice in 29.884µs
Jul 22 10:56:11 xandra victoria-metrics[13771]: 2019-07-22T07:56:11.288+0000        info        /home/kman/Android/src/VictoriaMetrics-fork/app/vmstorage/main.go:125        gracefully closing the storage at /var/lib/victoria-metrics

I believe this means that the process is shut down gracefully and does receive the intended signal - as opposed to systemd killing the process using -KILL or some other way that's "external" and "ungraceful".

In other words, we can leave things as they are, and don't need to add -pidfile command line option.

I think this means that I am ready to submit my PR. @valyala please let me know if there is anything else you think needs to be done.

[oOHenry]

Is it also planed to package the cluster version?

[kmansoft]

Is it also planed to package the cluster version?

As far as I can tell, the cluster version is a separate branch (as opposed to a build target within the same code base)....

Let's wait for the developers to merge my changes so far - and if they decide to also cherrypick them into the cluster branch. If they do and if they then require more assistance from me - I'll be happy to help.

I suppose at the very least, the names of package files will need to be changed...

[kmansoft]

Created a draft PR: https://github.com/VictoriaMetrics/VictoriaMetrics/pull/116

[zonk1]

Created PR for vmagent and vmalert deb packages: https://github.com/VictoriaMetrics/VictoriaMetrics/pull/690