Created attachment 169018 [details] port file
I'm working on latest version and additional rc.d script
Created attachment 174362 [details] Datadog port Updated port with latest version, add dogstatsd rc.d script. Portlint output WARN: Makefile: possible use of absolute pathname "/opt/datadog-agent/e...". WARN: Makefile: possible use of absolute pathname "/var/run/${PORTNAME}". WARN: Makefile: possible use of absolute pathname "/var/log/${PORTNAME}". 0 fatal errors and 3 warnings found.
Anything to fix here while I'm working on upgrade to the latest release?
Is there anything this port is waiting on at the moment? It's been sitting here for 2 years. I'm sure the maintainer would like to see some movement, or a response to their question. We don't look very good when a new maintainer submits and sees no feedback for years. I'm happy to help test the new port if need be, and if Koobs is too busy, let's get this reassigned to another committer once it's good to go.
(In reply to uros from comment #3) I'll take a look at the shar you submitted when I can, try and build the port, and provide what feedback I'm able to :) I'm not a committer, so I can't actually get your port in the tree, but I can help make sure it's ready for commit once a committer is available.
Apologies, not sure how I missed this, thanks for the ping Rainbow. Reset assignee so someone else can take it, I'll stay CC'd in case I can take care of it. Port needs review and QA confirmation. I note also that the datadog agent is now at 6.x and build using golang, though it appears the 5.x versions is still supported.
I started to work on 6.x but then stopped. I'll do my best to finish it and upload new version. I'm a bit swamped atm so it might take a few days.
Hi, I really would like to see this port in port tree as well :-) I'm now using version 5.9.1 taken from GH and it works like a charm for regular system metrics. # svn info /usr/ports/net-mgmt/dd-agent Path: /usr/ports/net-mgmt/dd-agent Working Copy Root Path: /usr/ports/net-mgmt/dd-agent URL: https://github.com/urosgruber/dd-agent-FreeBSD.git/trunk Relative URL: ^/trunk Repository Root: https://github.com/urosgruber/dd-agent-FreeBSD.git Repository UUID: f6cc8bd2-c0a5-2bbb-7d4e-ce57b7db7bff Revision: 65 Node Kind: directory Schedule: normal Last Changed Author: jan.lehnardt Last Changed Rev: 63 Last Changed Date: 2017-09-05 09:12:10 +0200 (Tue, 05 Sep 2017) # pkg info datadog datadog-5.9.1 Name : datadog Version : 5.9.1 Installed on : Tue Jan 8 12:15:59 2019 CET Origin : sysutils/dd-agent Architecture : FreeBSD:11:amd64 Prefix : /usr/local Categories : sysutils Licenses : BSD4CLAUSE Maintainer : uros@gruber.si WWW : https://www.datadoghq.com Comment : Data Dog agent Options : DOCS : on Annotations : FreeBSD_version: 1102000 flavor : py27 Flat size : 2.77MiB Description : Cloud-Scale Monitoring The Datadog Agent faithfully collects events and metrics and brings them to Datadog on your behalf so that you can do something useful with your monitoring and performance data. WWW: https://www.datadoghq.com
Why is it not in ports ATM? Works like a charm on my Machine.
^Triage: Someone should QA (portlint, poudriere) attachment 174362 [details] and confirm it passes, updating the patch to address any issues if necessary See Also: https://github.com/urosgruber/dd-agent-FreeBSD https://github.com/urosgruber/dd-agent-FreeBSD/pull/18
^Triage: Looks like it needs updating to 6.x at least
The source repo now works with 6.X - worth updating this port, or is starting a new one the best approach?
I'm happy to pick this up, precisely which version/repo/branch should I pull from? https://github.com/urosgruber/dd-agent-FreeBSD/issues/19 mentions a v7.
thanks uros for the work here! Other than a few tidy-ups this is a fantastic port. I'm tweaking it for v7 & USES=go:modules but other than that LGTM. on v7, there's 1 (docker related) dependency that doesn't fetch correctly; help wanted on figuring out how to manage that. Is it sufficient to remove the line from modules, and the invoke ... command parameters? https://git.sr.ht/~dch/ports/tree/feature/datadog I'll add a patch tomorrow from this branch after some further work. Assuming that works, it needs to respect hier(7) to land in ports. Hopefully we can do this with some gentle patches in the source. assuming /usr/local/bin/dd-agent or similar, does it make more sense to use /var/run/datadog/... or /var/db/datadog/... for example for its runtime files?
I tried building this Port and it fails, because it has got python2'isms that won't work with python3. Also I tried to build Version7 from the official repo and I have got the same problems as you Dave with things depending on cgroups. Help would be appreciated, if possible, because we have got a customer, who wants to use datadog on our proServer and I'd like to give him a different answer than "not possible in FreeBSD". Do you think it might be worth approaching the project on github and ask for help? I'd be willing to do that.
Asked in both github both repos for help: https://github.com/DataDog/datadog-agent/issues/6623 https://github.com/urosgruber/dd-agent-FreeBSD/issues/19#issuecomment-715285566
Thanks Dave for moving this forward. I've done some work myself over the weekend and was able to prepare working version 7.18.1. I'll open PR on github repo so if you're ok to move conversation there just to clear some of my questions. I'll do my best to upgrade it even further until I hit this cgroup issue. I believe it was included in 7.20.x or something.
A commit references this bug: Author: dch Date: Wed Nov 11 20:25:35 UTC 2020 New revision: 554912 URL: https://svnweb.freebsd.org/changeset/ports/554912 Log: sysutils/datadog: new port of datadog agent The eponymous server and application monitoring agent from DataDogHQ.com Additional agent integrations will be submitted in a further port. PR: 208561 Submitted by: Uros Gruber <uros@gruber.si> Sponsored by: SkunkWerks, GmbH Differential Revision: https://reviews.freebsd.org/D27182 Changes: head/GIDs head/UIDs head/sysutils/Makefile head/sysutils/datadog/ head/sysutils/datadog/Makefile head/sysutils/datadog/distinfo head/sysutils/datadog/files/ head/sysutils/datadog/files/datadog-agent.in head/sysutils/datadog/files/datadog-process-agent.in head/sysutils/datadog/files/datadog-trace-agent.in head/sysutils/datadog/files/patch-cmd_agent_common_common__nix.go head/sysutils/datadog/files/patch-pkg_collector_corechecks_system_file__handles.go head/sysutils/datadog/files/patch-pkg_collector_corechecks_system_file__handles__freebsd.go head/sysutils/datadog/files/patch-pkg_collector_corechecks_system_file__handles__freebsd__test.go head/sysutils/datadog/files/patch-pkg_metadata_v5_v5__other.go head/sysutils/datadog/files/patch-rtloader_common_rtloader__mem.h head/sysutils/datadog/files/patch-rtloader_rtloader_CMakeLists.txt head/sysutils/datadog/files/patch-rtloader_rtloader_api.cpp head/sysutils/datadog/files/pkg-message.in head/sysutils/datadog/pkg-descr head/sysutils/datadog/pkg-plist
many many thanks Uros for his patience on this patch, which was submitted long before I was even a committer, and migrating the patch from python to golang in the meantime. Tested OK on poudriere 13.0-CURRENT amd64, 12.2R amd64 Failed hard on arm64 due to various missing cgo plumbing bits. If somebody is interested in addressing that I can make the log and suitable h/w accessible.