This PR cleans up docblocks and makes a couple formatting changes based on PSR1, PSR2, and PEAR coding standards. (PEAR changes limited to nicer formatting of docblocks.)

EDIT: Updated this PR to also install PHPCS.

EDIT: Updated this PR to drop support for PHP versions lower than 5.6.

This PR

• [x] uses declared private fields when assigning values in constructor

💁‍♂️ Running

$ phpstan analyse --level=1 src

yields

 2/2 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

 ------ ---------------------------------------------------------------------------
  Line   src/DogStatsd.php
 ------ ---------------------------------------------------------------------------
  72     Access to an undefined property DataDog\DogStatsd::$apiCurlSslVerifyHost.
  73     Access to an undefined property DataDog\DogStatsd::$apiCurlSslVerifyPeer.
 ------ ---------------------------------------------------------------------------


 [ERROR] Found 2 errors

Hello,

I noticed you have a composer.json in your repo, but the package has not been submitted to packagist.org.

It would be great if you can submit it, then it can be easily used as a composer package. http://packagist.org/packages/submit

Or perhaps I am missing something?

Thanks.

is this function still working? Because I trying to use increment from example or by my self is not working. But the event function is working nicely.

I try to use increment, but nothing happen to my metric

This takes the global_tags concept from the nodejs datadog library and adds equivalent support to the PHP library.

It also refactors the internals of tag handling a bit, since there are currently three (!) different formats that constitute a valid tag. The output is unchanged, but it will now de-duplicate any repeated tags. If a tag has a different value in a direct metric vs the global one, it will apply the tag provided in the metric, replacing the global one.

*725 FastCGI sent in stderr: "PHP message: PHP Fatal error: Class 'DataDogStatsD' not found in XXXXXXXX on line XXX"

This despite the inclusion of the file require_once(...)

Might it have something to do with socket?

Hi. I'm using this client and it's working fine with Datadog agent ( v5.22 ) but when I upgrade to Datadog v6, the timing metrics doesnt work.

More details: PHP: 7.0 OS: Ubuntu 16

Thanks in advance!

the implementation of tags in the client is inconsistent (and probably broken)

the official dogstatsd states this:

metric.name:value|type|@sample_rate|#tag1:value,tag2

so tags are attached via # and separated via ,

this implementation can be found in the ruby client for example.

it looks like this is also implemented correctly for service-checks.

but it looks like it's wrong in the metrics implementation as it will separate by ,#!

/cc @bonko @fungusakafungus

Hello there!

I am a very happy user of the PHP Datadog library that you've got here =)

Currently I am on a project where we need to utilize the UDP events that are outlined here: http://docs.datadoghq.com/guides/dogstatsd/#events

To utilize this I added the ability to send events via both UDP and TCP since I feel both are highly valuable in different scenarios (my companies use both). I have made UDP the default here so-as to just work "out of box" without needing an API configuration. If you call the "configure" method it is assumed you are utilizing the API. There are also a couple of cURL SSL configuration options that are important if folks are using self-signed certificates with reverse-proxies.

I have also greatly improved the API events call by swapping out the "file_get_contents" strategy with a cURL one. This checks for things like response codes, empty bodies, malformed JSON, etc. to get down to checking the "status" field passed back by Datadog. If we want verification that our event went out (via TCP) we may as well ensure that the web request was properly handled =)

I have kept in-line with your development practices to the best of my ability. If you wish to swap the default method for event communication from UDP to TCP let me know and I will re-submit a pull-request with that change.

Otherwise thank you for your time in reviewing these improvements! They will make a HUGE difference in our adoption of this library =)

Sincerely,

• John Parks

At least the pwillcode one which fixes the composer package psr-0 autoloading. I am using that fork in production now specifically because of the autoloading.

Thanks.

This PR installs and configures PHPUnit. In addition, it adds unit tests.

Thanks, looking forward to your feedback!

EDIT: I am now running PHPUnit tests in Travis. However, in order to support versions of PHP all the way back to PHP 5.3, I installed a rather old version of PHPUnit. This isn't ideal; some code in the older version of PHPUnit calls deprecated functions. See https://travis-ci.org/DataDog/php-datadogstatsd/jobs/423273440 for an example of the deprecation warnings.

If those deprecation warnings seem problematic, PHPUnit could be upgraded to a more recent version (say, to 5.7.x, which supports PHP5.6+), and then Travis failures could be suppressed on a per-version basis. For example: https://github.com/sebastianbergmann/phpunit/blob/master/.travis.yml#L16

Due to its heavy use of dynamically-declared properties, DogStatsd is largely incompatible with PHP 8.2 and will throw quite a few deprecation notices. Now might be a good opportunity to give this library some much-needed love.

We are using php with swooole - which automatically exposes swoole metrics in php array, json and openmetrics format.

https://openswoole.com/article/openswoole-4.9.0-released

I know there is an openmetrics integration for datatadog agent. The drawback - in that case I would have to add separate datadog agent container into ecs fargate task and configure it with openmetrics config - so custom container build is gonna be needed - which is why I would rather not go this route.
https://docs.datadoghq.com/integrations/openmetrics/

I would rather push metrics to datadogstatsd - however this client doesn't understand openmentrics format as a source... so one way out would be to write custom "api bulder" script (openmetrics -> builder).

so that's my feature request i supposed - kindly support openmetrics as a source.

If UDP is not being used, ->event returns true or false based on success. If UDP is used, ->event returns null. This can probably be fixed by seeing if ->packets_sent == 1 after the call to ->eventUdp, as that indicates success (and yes, I know UDP is send-and-pray).

Fixes #115

• Proposed code changes (minimal, interface based)
• Test fix (I was authoring on Windows, and it was a pain, I could not run tests. It's 2-liner)
• ~GitHub actions (until I'd fixed, I actually had a really slow feedback loop)~
• Editor config and git attributes
• Proposed Documentation (words are hard, forgive me if it's not perfect).
• Update to support PHP 8.0 & 8.1 thanks to Yoast
• Tests
• PHP 5.6 - PHP 8.1 (circleci missing 8.1-node-browsers image 🤷 )
• Linting, Code-Style

The actual guard portion of this, doesn't have to be owned by this repo. In the README.md I added a section with example to bypass the magic, re-using the Ipv4Udp transport that is part of this PR, so that an example of instrumenting the control I was looking for (bypassing the magic in current constructor) is available.

I'm not 💯 sure about the construct with single method interface, but felt that opening and closing the socket separately to the functionality; could make some future testing easier. I Also didn't want to open a long-lived socket (although the classes don't hint at that, the way they are used in one place enforces for-now).

The interfaces are pretty stripped-back to deal with PHP 5.6 minimum. Not sure where DataDog is going with that, but I think users would get a lot of benefit rolling up to only 7.4 & 8+ in a future release.

Why interfaces

Short answer. I Hate the array approach. It's too open a design, and leads to choices where spooky [mis]configuration can happen. While this one interface won't change the entire codebase, it nudges in a direction a lot of PHP coders are going.

I'm not sure that adding strict_mode to counteract the magic will make this code any more readable or be the right way to counteract the magic cascade. For an upstream vendor to us this, implement the interface, I believe is a far more intentional choice, that leaves the majority of users happy where they are now. Internal getenv may be a feature for people who have not had silent misconfiguration lead to confusing bugs.

Another reason for an interface based approach is that I think a test implementation that allows spy test-double would be a nice thing that this allows. Instead of using curl spy test class and the socket spy test class, which are namespace coordination dependent.

Lastly, This interface approach would enable any coder:

• To perform unit or integration level tests without needing to setup DataDog agent at all.
• Could also help if falling-back in cases where perhaps the transport might use a PSR Logger, and send using Datadog API key as a log message.

Due to a mis-configuration at work, our agent host was in some cases not being set.

This led to (luckily dev/qa time) discovering a PHP warning is thrown at runtime if the class is constructed with an incorrect value.

Like a lot of 12-factor apps, we get our value from ENV, which in our case resulted in no errors and a booting app. But warnings silently output.

I think the constructor of DogStatsTimer should throw if the host configuration is not a valid hostname or IP address. In our case it was false 😂

I Know people SHOULD NOT have warnings output in QA or production environments. But separate to that issue, I would be interesting in contributing this change if the authors are amenable.