Laravel & DataDog Timeseries Metric data using their API via TCP

James Mills > Code & Development > Laravel & DataDog Timeseries Metric data using their API via TCP

We recently started to trial some of the DataDog services for a recent project I have been working on. One of the things that jumped out at me was the ability to use one account for many services. Monitoring, uptime, API testing, application profiling, live dashboards…. the list goes on.

The setup is simple, you just install their Agent on your server and you are done. One problem for us is that all our servers are managed by our infrastructure management team and they build all our servers using FreeBSD… and there isn’t a FreeBSD compatible DataDog Agent.

What if you cannot install the DataDog Agent?

My initial reaction was to stop the payments and quit the trial. I would come back to DataDog in the future if the opportunity ever materialised. But then I saw they had an API.

One of the main things I wanted to do was start to log things from our application as and when they happen so I could monitor them on a live graph and set alerts for times when it looked like something was wrong. DataDog has Metrics for this and they work really nicely.

I had a quick Google around and searched Packagist but there wasn’t anything out there which did what I needed so I built jamesmills/laravel-datadog.

A simple package for Laravel to wrap DataDog’s API for Timeseries metrics making sure the jobs are queued.

jamesmills/laravel-datadog

One of the main things which the DataDog Agent does is use StatsD to collect data and then submit it over UDP protocol. This is none-blocking and is obviously a much better way of doing things than hitting an API over TCP and waiting for a reply when you are simply logging a metric.

Queue Everything

Building a new package for Laravel meant that I would be able to utilise the queue so I could put the sending of the metric into a Job and then queue it and wrap all this behind a hand Facade.

Tag Everything

I recently added tagging to the package too. DataDog’s system allows you to do a lot of things so being able to tag things is a real help. In our application, we are using it’s multi-domain (multi-tenant), so it’s helpful for me to be able to add a tag for each domain.

Other Packages

I also found this package chaseconey/laravel-datadog-helper. If you are able to install the DataDog Agent and you are using Laravel I would strongly recommend you take a look at this package. It ads middleware so you can log response times of various things in your application. I really like this.

It’s worthing pointing out that DataDog have their own PHP package (DataDog/php-datadogstatsd) which you can install and use without the Agent. Unfortunately, this is still no good for our situation.

What’s Next?

I am not 100% convinced that I am using the Metric collection properly. With the Agent using StatsD it collecting data and then sending the data to DataDog after a set period. For example, it will collect everything locally using StatsD and then every 10 seconds it will send the data. This means that DataDog is expecting data every 10 seconds. When using the API method I have set up in the package I don’t do this I send a metric in real-time to their API. What this means is I end up with a very odd graph which looks like there is a constant “hit”

I met with a couple of guys from the DataDog team here in Dubai this week and discussed this issue with them so I hope I will be able to update this article soon with what’s happening and maybe “fix” the package.

Demand for the package

What has surprised me was how many downloads the package has had. I wrote this package to help us with something I thought was going to be quite unique. However, with over 300 installs in a month of it’s release, it looks like others might be finding themselves in a similar situation?

Leave a Reply

Your email address will not be published. Required fields are marked *