Heroku is a popular platform-as-a-service that simplifies application deployment by automating and abstracting much of the underlying infrastructure required to run those applications. One of those abstractions is Heroku’s buildpack. Buildpacks are discrete, chainable bundles of code that are often used to modify the runtime environment for the application that will be deployed. Rather than performing complex installation and configuration tasks for a particular application or service, users can simply add the buildpack to their project.
We’re pleased to share a new Heroku buildpack that installs the latest version of the Datadog Agent, with added support for distributed tracing and APM in Heroku.
In 2014, Mike Fiedler wrote the first Heroku buildpack to run a Python-based DogStatsD server, enabling applications on Heroku to send custom metrics to Datadog. As the Datadog Agent evolved to become a pre-compiled Go binary rather than a package of Python scripts, it became clear that the buildpack would need to be rewritten.
Heroku uses a container model to package, deploy, and scale applications. Unlike some container-based platforms, however, Heroku does not allow root access or the ability to write to standard application and configuration directories such as /usr/bin or /etc. This limitation ensures that a slug (Heroku’s term for a container image) deployed to a dyno (a running container) remains isolated from the host machine and other dyno tenants sharing the host. However, this security isolation comes at the cost of some convenience.
The new buildpack and Mike’s original buildpack take a similar approach to the limited-access file system by downloading and installing the Datadog Agent to a non-standard but accessible directory.
Once you have your application running on Heroku, you can use the buildpack to begin collecting application metrics, system metrics, and traces. To learn how to install the buildpack, see the documentation.
The Heroku buildpack automatically adds tags for your application name (appname), the dyno name, and the dyno type. The application name and dyno name are particularly helpful for filtering and aggregating metrics. Summing a particular metric by the provided dyno name tag provides visibility into the dyno’s aggregate activity and performance, similar to graphing metrics on a per-host basis when monitoring physical hosts. This helps provide better monitoring continuity as dynos move to new hosts.
If your application cycles dynos frequently, you may see a large number of hostnames emitting metrics to Datadog, which can increase your costs. To prevent this, you can configure the buildpack to report the hostname in the form of app-name.dyno-name, which is a more stable construction since it does not use the name of the ephemeral host. The installation instructions show you how you can do this by setting the DD_DYNO_HOST environment variable to true.
When you use the buildpack to install the Agent, you’ll see host system metrics including CPU, memory, and disk metrics. If you need system metrics from individual dynos, see the documentation.
Heroku is a fantastic service that simplifies deploying applications to a robust and scalable platform. The Datadog buildpack makes it easier to monitor those applications with custom application metrics and distributed tracing. If you’re already a Datadog customer, you can install and deploy the buildpack to monitor your Heroku applications today. If you’re not yet using Datadog, give it a try with a free 14-day trial.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。