Open jryburn opened 4 years ago
@jryburn, are you referring to the "service" file which would allow starting/stopping it as a service using systemctl? I think that is really needed.
@jryburn, are you referring to the "service" file which would allow starting/stopping it as a service using systemctl? I think that is really needed.
Correct. Most (all?) users that deploy kprobe will want to run it as a service that starts when the server boots up so that it starts collecting flow data without someone having to log into the server and start kprobe.
240418: @dpajin-kentik @jryburn Is this on the roadmap? If so is there an expected completion date?
240418: @dpajin-kentik @jryburn Is this on the roadmap? If so is there an expected completion date?
I will have to defer to Dusan on the roadmap question. My thought would be we "fix" this by rolling the kprobe capabilities into universal agent. Not ideal for customers in the interim but they have lived this long without a startup script.
Charter asked about this today when installing kprobe on their DNS servers.
"Ryan – do you have a recommended systemd or init script so these daemons restart on a reboot ?"
One thing though - and apologies for invading this thread - I've recently read feedback from a customer complaining that they lost a ton of visibility because kproxy
upgrades didn't trigger a restart of it, I think there's an FR for it - someone was comparing to kbgp
where there was an actual restart order as part of the upgrade process.
CC @dpajin-kentik
I created a PR with service file that is waiting to be merged. https://github.com/kentik/kprobe/pull/41 This PR is focused on starting kprobe service for doing host monitoring, not OTT workflow.
I understand that there might be need for service file for DNS mode. You can create one for DNS mode, and we can potentially have a separate packaging process and package for kprobe DNS mode that would include that file. cc @kagawaa
I approved the PR that adds the service file to the package. Another way we could address the DNS mode (OTT enrichment) is to just have a note in the README file or a comment in the kprobe.service
file that changes the ExecStart
line to include the --dns
flag. IMO, that should get us by until these capabilities become part of the universal Kentik agent.
I think we could largely base a startup script on what we have with kproxy.
https://packagecloud.io/kentik/kproxy/packages/debian/wheezy/kproxy-latest-debian-7_7.17_amd64.deb
Just rename the files to kprobe and make sure the options are correct.