This package provides an interface for reporting metrics to statsd, along with Echo middleware for use with HTTP APIs.

Include the metrics-go package in your project:

import (
    "github.com/lob/metrics-go"
)

Create a new Metrics client:

cfg := metrics.Config{
    Namespace: "myapp",
}
m := metrics.New(cfg)

The metric Namespace must be provided.

All metrics reported from the instance will have the environment, container, and release added as tags.

You may also pass additional tags to all metrics methods as variadic string arguments.

You may wish to embed the metrics.Config struct in your applications configuration struct for convenience.

m.Count("event-counter", 1)

m.Gauge("num-workers", 5)

m.Histogram("queue-depth", 10)

m.Close()

t := metrics.NewTimer("api-call")

err := apiCall()
if err != nil {
    // End also takes tags that are added to the timer metric
    t.End("state:failed")
} else {
    t.End("state:success")
}

This package includes middleware suitable for use with Echo servers.

m := metrics.New(cfg)
e := echo.New()
e.Use(metrics.Middleware(m))

The server-less AWS Lambda Service allows us to do expensive computations without having to manage extra infrastructure. However, without control of the actual server the code is running on, it's impossible to run a Datadog agent on or alongside the host. This makes using a normal StatsD client unfeasible. Instead, we can write metrics to logs that Datadog reads through an AWS account integration as detailed here.

The only differences in configuring this library for a lambda function instead of a standard Go library are:

1. You must set Lambda: true in the metrics.Config.
2. You must set LambdaLogger to a struct that implements the io.WriteCloser interface in the metrics.Config.

# Install necessary dependencies for development
make setup

# Ensure dependencies are safe, complete, and reproducible
make deps

# Run tests and generate test coverage report
make test

# Run linter
make lint

# Remove temporary files generated by the build command and the build directory
make clean

After new commits have been added, a new git tag should also be created so that tools like go mod and dep can utilize it for more semantic versioning.

If there is a breaking change introduced in this new version, then it should be a major version bump. If there are no breaking changes and only new features, then it should be a minor version bump. And if there are no breaking changes, no new features, and only bug fixes, then it should be a patch version.

After determining what the next version should be, make sure you're on an up-to-date master branch and run make release. The v in the version tag is important for tools to recognize it.

$ git checkout master
$ git fetch
$ git rebase
$ make release tag=v1.0.0 # replace 1.0.0 with the next version