GithubHelp home page GithubHelp logo

go-metrics's Introduction

go-metrics GoDoc Badge Badge

This package is small wrapper around the prometheus go client to help enforce convention and best practices for metrics collection in Docker projects.

Best Practices

This packages is meant to be used for collecting metrics in Docker projects. It is not meant to be used as a replacement for the prometheus client but to help enforce consistent naming across metrics collected. If you have not already read the prometheus best practices around naming and labels you can read the page here.

The following are a few Docker specific rules that will help you name and work with metrics in your project.

  1. Namespace and Subsystem

This package provides you with a namespace type that allows you to specify the same namespace and subsystem for your metrics.

ns := metrics.NewNamespace("engine", "daemon", metrics.Labels{
        "version": dockerversion.Version,
        "commit":  dockerversion.GitCommit,
})

In the example above we are creating metrics for the Docker engine's daemon package. engine would be the namespace in this example where daemon is the subsystem or package where we are collecting the metrics.

A namespace also allows you to attach constant labels to the metrics such as the git commit and version that it is collecting.

  1. Declaring your Metrics

Try to keep all your metric declarations in one file. This makes it easy for others to see what constant labels are defined on the namespace and what labels are defined on the metrics when they are created.

  1. Use labels instead of multiple metrics

Labels allow you to define one metric such as the time it takes to perform a certain action on an object. If we wanted to collect timings on various container actions such as create, start, and delete then we can define one metric called container_actions and use labels to specify the type of action.

containerActions = ns.NewLabeledTimer("container_actions", "The number of milliseconds it takes to process each container action", "action")

The last parameter is the label name or key. When adding a data point to the metric you will use the WithValues function to specify the action that you are collecting for.

containerActions.WithValues("create").UpdateSince(start)
  1. Always use a unit

The metric name should describe what you are measuring but you also need to provide the unit that it is being measured with. For a timer, the standard unit is seconds and a counter's standard unit is a total. For gauges you must provide the unit. This package provides a standard set of units for use within the Docker projects.

Nanoseconds Unit = "nanoseconds"
Seconds     Unit = "seconds"
Bytes       Unit = "bytes"
Total       Unit = "total"

If you need to use a unit but it is not defined in the package please open a PR to add it but first try to see if one of the already created units will work for your metric, i.e. seconds or nanoseconds vs adding milliseconds.

Docs

Package documentation can be found here.

HTTP Metrics

To instrument a http handler, you can wrap the code like this:

namespace := metrics.NewNamespace("docker_distribution", "http", metrics.Labels{"handler": "your_http_handler_name"})
httpMetrics := namespace.NewDefaultHttpMetrics()
metrics.Register(namespace)
instrumentedHandler = metrics.InstrumentHandler(httpMetrics, unInstrumentedHandler)

Note: The handler label must be provided when a new namespace is created.

Additional Metrics

Additional metrics are also defined here that are not available in the prometheus client. If you need a custom metrics and it is generic enough to be used by multiple projects, define it here.

Copyright and license

Copyright © 2016 Docker, Inc. All rights reserved, except as follows. Code is released under the Apache 2.0 license. The README.md file, and files in the "docs" folder are licensed under the Creative Commons Attribution 4.0 International License under the terms and conditions set forth in the file "LICENSE.docs". You may obtain a duplicate copy of the same license, titled CC-BY-SA-4.0, at http://creativecommons.org/licenses/by/4.0/.

go-metrics's People

Contributors

crosbymichael avatar edwardbetts avatar ijc avatar jcarter3 avatar lk4d4 avatar milosgajdos avatar samwhited avatar stevvooe avatar tifayuki avatar waynr avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

go-metrics's Issues

Inconsistent reference to license for docs

Hello,

The README.md and LICENSE.docs files are inconsistent about which license applies to the go-metrics documentation.

The README.md file says that docs are:
"...licensed under the Creative Commons Attribution 4.0 International License under the terms and conditions set forth in the file "LICENSE.docs". You may obtain a duplicate copy of the same license, titled CC-BY-SA-4.0, at http://creativecommons.org/licenses/by/4.0/."

The bolded items say that the docs license is CC-BY-SA-4.0, but the italicized items say that it is CC-BY-4.0 (which is a different license).

If the intent is for the docs license to be CC-BY-4.0, could the following changes be made?

1. The LICENSE.docs file should likely be replaced with the CC-BY-4.0 license text, available from https://creativecommons.org/licenses/by/4.0/legalcode.txt

2. The bolded reference above to **CC-BY-SA-4.0** in README.md should likely be changed to CC-BY-4.0.

(I've noted a similar issue for docker/spdystream at moby/spdystream#70, and for docker/swarm at docker-archive/classicswarm#2833)

Thank you!

Sync with Prometheus best practices

Hi,

It's great to see you're looking to use Prometheus monitoring. I noticed a few things that are out of line with Prometheus best practice, which will cause friction in future and limit the benefits you'll get.

In https://github.com/docker/go-metrics/blob/master/suffix.go: The _count suffix is used by Summary and Histogram metrics, it should not be be used elsewhere. Seconds are the standard, no other units should be offered. We also generally go for seconds rather than s as it tends to be more readable.

In https://github.com/docker/go-metrics/blob/master/namespace.go: The initial comment says "allows const labels to be added to all metrics created in this namespace and are commonly used for data like application version and git commit". This is an anti-pattern as it makes it much harder to work with the metrics, you should have a single metric with the value 1 and all the labels you need. See http://www.robustperception.io/how-to-have-labels-for-machine-roles/ for the general approach.

In
https://github.com/docker/go-metrics/blob/master/namespace.go#L53 you're putting a _count suffix on Counters. The convention is _total for Counters.

There's also a variety of other issues that limit what the user should be able to do with a Prometheus client library, per https://prometheus.io/docs/instrumenting/writing_clientlibs/ Rather than losing this functionality and semantics, I'd recommend using the Prometheus client library directly and filing bugs for anything you find lacking (the lack of timing utilities in Summary/Histogram being the obvious one).

No longer builds against Prom master

Getting

../../docker/go-metrics/timer.go:39: cannot use lt.m.WithLabelValues(labels...) (type prometheus.Observer) as type prometheus.Histogram in field value:
	prometheus.Observer does not implement prometheus.Histogram (missing Collect method)

? About exposing Registerer & Gatherer

Right now the library is using the default registry (which is also a Gatherer). Is a goal of this library to not expose the underlying prometheus objects by wrapping them? I want to submit a PR that exposes the registerer & gatherer being utilized by the library. The gatherer is particularly useful because it enables us to do things with the metrics beyond just exposing them on /metrics; like sending task metrics from the daemon to managers using protobuf.

You can see what I'm talking about here for the gatherer and here for registerer

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.