Introduction 

StatsD is among the most popular monitoring solutions used to instrument code with the help of custom metrics. It has become very popular over the course of the last few years and emerged as the industry standard for open source inside-the-app monitoring. It has a host of advantageous features that makes it perfect for application performance measurements.

StatsD helps in swiftly and cost-effectively assessing how applications, services, and systems perform, thereby enabling IT professionals to fix and prevent issues much faster.

With MetricFire you can add StatsD metrics to your applications with just a single line of code. We also provide hosted StatsD if you don’t have the luxury of running a server yourself. Request a demo to get a better understanding of our services or start a free trial with MetricFire.

What is StatsD?

StatsD was developed and launched by Etsy for the purpose of aggregating and summarizing application metrics. It was initially created as a simple daemon for instrumenting applications in order to pull metrics and gain visibility. Developers can easily instrument their apps with StatsD by using distinctive client libraries that are language-specific. Such libraries would subsequently communicate through a simple protocol to connect to the StatsD daemon. The daemon would then generate aggregate metrics, and relay them to just about any monitoring or graphing backend. At that time, most developers chose Graphite.

Over the last decade, the popularity of StatsD stack has increased considerably. It is now considered to be a key unifying protocol meant for metrics collection of apps. You can use this daemon for gathering, as well as sending, data to other backends like and Graphite. Graphite and StatsD typically form the basis of monitoring infrastructure, while providing advantages of low memory footprint and high network efficiency. We at MetricFire can help you to monitor StatsD so that you can configure, analyze, and visualize your application performance with ease. 

StatsD ideally poses as a proxy between the long term database and the client, and decreases the amount of I/O operations to disk. StatsD has the capacity to manipulate metrics data on-the-go, which may reduce the imperfection of backends like Graphite in particular cases.

How does StatsD work?

To understand how StatsD works, it is important to get to grips with the steps involved in its functioning. These steps have been underlined in the points below:

• The process begins at the application code of the developer, who instruments this daemon with one of the various StatsD libraries that correspond to their application language. Through the StatsD stack, the developers capture diverse types of metrics, based on their distinctive needs. These metrics include Timing Summary Statistics, Gauges, Counters and sets. 
• The client library of the daemon would subsequently send each and every call to the StatsD server through the UDP datagram. UDP is a non-connected protocol where the datagram’s recipient does not send any kind of acknowledgement to the sender, and therefore there is no need for the library to block the messages as it would with HTTP or TCP-based protocols while submitting data. There is also no need for the library to buffer data between calls, making the process quite simple. 
• After this, the daemon listens to UDP traffic from all of the app libraries, aggregates data over time, and “flushes” it at required intervals to the backend selected by the developer.  Based on the backend used, the protocol used between the StatsD daemon and the backend can vary. The majority of the backend is HTTP-based.
• The Metrics then turn into usable charts with the help of the monitoring backend, from a stream of numbers on the wire, and alert the developers whenever needed. 

To monitor with StatsD, it is imperative to gain a good understanding of how this system works. 

What sets StatsD apart?

Even though several StatsD alternatives are available, a great number of developers tend to prefer using StatsD owing to its many unique features and advantageous characteristics. Here are some factors that set this system apart from its alternatives, and make seeking out services to monitor StatsD a prudent option for companies: 

• Simplicity: The StatsD protocol is based wholly on text, and is quite straightforward to read and write. It is extremely easy to implement on an app as well. 
• Decoupling app from its instrumentation: As StatsD tends to run outside the app, and UDP features a fire-and-forget protocol, there is no upstream dependency maintained between the app itself and metrics collection. This daemon cannot crash an app and is not even required to run on the same machine or written in the same language.
• Small footprint: StatsD clients add negligible overheads, do not require threads, carry no state and are quite thin. It also supports sampling the developer’s calls to arbitrarily reduce network usage.
• Ubiquity and ecosystem: One can find StatsD clients available for Node, Scala, Go, Haskell, Ruby, Python, Java and almost any other language.  Many developers even write alternative servers with the aim of maximizing output and meeting special needs. There are multiple backends supporting StatsD, both commercial and open-source, which implies that there is no vendor lock-in. 

Among the diverse StatsD alternatives available, CollectD is one of the most popular ones. Both of them are open-source monitoring daemons. StatsD, however, has a simpler and more linear architecture structure. There are many who also tend to get confused between StatsD and Prometheus.

Prometheus is quite new to the metrics market and can be considered as an umbrella project that includes protocol, collection & time-series databases. While both StatsD and Prometheus are high-performing monitoring systems, StatsD uses relatively less memory and can be implemented with much less effort. 

If you are planning to monitor StatsD after exploring its major benefits, then you can easily do so through MetricFire. It is a hosted StatsD service, as well as hosted Graphite, Prometheus, and Grafana, where you can book a demo and free trial and easily start monitoring with StatsD.

What problem does StatsD solve?

StatsD is written in Node.js and was designed for collecting, aggregating, and sending developer-defined application metrics to a distinctive system for the purpose of graphical analysis. It was initially the job of the daemon to monitor a UDP port for incoming metrics data, and go on to extract this information. This data would additionally be sent to Graphite in an aggregated format periodically.

Among the many problems solved by StatsD, the key one is that it helps in collecting and sending data quite fast. This especially is true when the daemon is used with UDP. When used along with UDP, StatsD clients can simply send the metrics data and subsequently presume that it shall get to the daemon smoothly. Getting data competently from point A to point B is a core technical problem solved by StatsD.  

This daemon is quite popular for facilitating a culture where the developers do not have to seek out any permission to instrument their application, as well as where metrics can be captured prior to the deployment of applications in production. StatsD also helps in the creation of a process where resource utilization or abstract performance metrics can be linked directly to a product or application metric which are relevant directly to the business. StatsD even plays a major role in DevOps implementation.

StatsD & MetricFire

MetricFire is a monitoring platform built on open-source software such as StatsD, Graphite, Prometheus and Grafana. MetricFire's goal is to bring open source software to busy developers by offering a Hosted open-source monitoring platform. MetricFire began as a Hosted StatsD and Graphite service, where developers only needed to install an agent onto their server, and then metrics ingestion, storage, visualization, and alerting all get taken care of by MetricFire. Since then, MetricFire has expanded to also offer Prometheus and Grafana services.

When planning to monitor StatsD, it is important to know that MetricFire accommodates the ingestion of StatsD metrics. This is highly beneficial, as many of our customers have most of their infrastructure set up with StatsD. You won't need to change anything about your infrastructure to start monitoring with MetricFire.

You can easily use StatsD with MetricFire directly, or you can use the HostedGraphite Agent. The HostedGraphite Agent has the StatsD daemon embedded within it, to make pushing metrics to our Graphite back-end as easy as possible. The HostedGraphite allows you to automatically aggregate your metrics in 8 different ways, giving you further views on your data with no extra charge. It's a great option for users with StatsD data. The HostedGraphite Agent also allows for tagging, giving dimensionality to your StatsD data. 

It is seamless to push StatsD metrics in the MetricFire UI. Check out the Hosted StatsD docs here. See this quick tutorial on how to import StatsD metrics into MetricFire.

Conclusion

The many advantageous features and unique characteristics of StatsD make it perfect for measuring application, application, or systems performance. It is a lightweight text-based protocol, which supports multiple languages like Node, Scala, Go, Haskell, Ruby, and Python. Collecting metrics is among the vital goals of any agile focused firm, as it enables them to detect opportunities and problems.

StatsD allows them to do just that. MetricFire is your perfect stop for seeking services to monitor StatsD. We can provide you with a complete infrastructure and application monitoring platform from a suite of open source monitoring tools. Book a demo now to get a better insight into our services.