* examples: Follow best practices and established naming conventions
This is a nitpick but from my experience and understanding the best
practice for label key naming is to use one word, otherwise using an
underscore. Since this is an example users tend to copy, I think
correcting it might be a good idea.
Signed-off-by: Lili Cosic <cosiclili@gmail.com>
* examples: Switch custom labels example
Signed-off-by: Lili Cosic <cosiclili@gmail.com>
---------
Signed-off-by: Lili Cosic <cosiclili@gmail.com>
Co-authored-by: Kemal Akkoyun <kakkoyun@users.noreply.github.com>
* remove extra go module
Signed-off-by: Max Lowther <lowther.max@gmail.com>
* sort imports
Signed-off-by: Max Lowther <lowther.max@gmail.com>
---------
Signed-off-by: Max Lowther <lowther.max@gmail.com>
* collectors/version: Move to collectors directory and remove unrelated code.
Signed-off-by: Arthur Silva Sens <arthur.sens@coralogix.com>
* examples: Add Version Collector example
Signed-off-by: Arthur Silva Sens <arthur.sens@coralogix.com>
---------
Signed-off-by: Arthur Silva Sens <arthur.sens@coralogix.com>
This intends to avoid confusing users by the subtle difference between
a native histogram and a sparse bucket.
Signed-off-by: beorn7 <beorn@grafana.com>
* Fix convention violating names for generated collector metrics
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
* Add new Go collector example
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
This seem what OTel is converging towards, see
https://github.com/open-telemetry/oteps/pull/149 .
I see pros and cons with base-10 vs base-2. They are discussed in
detail in that OTel PR, and the gist of the discussion is pretty much
in line with my design doc. Since the balance is easy to tip here, I
think we should go with base-2 if OTel picks base-2. This also seems
to be in agreement with several proprietary solution (see again the
discussion on that OTel PR.)
The idea to make the number of buckets per power of 2 (or formerly 10)
a power of 2 itself was also sketched out in the design doc
already. It guarantees mergeability of different resolutions. I was
undecided between making it a recommendation or mandatory. Now I think
it should be mandatory as it has the additional benefit of playing
well with OTel's plans.
This commit also addresses a number of outstanding TODOs.
Signed-off-by: beorn7 <beorn@grafana.com>
This is, sadly, the only way to avoid a breaking change. The cost is
that anyone using exemplars has to perform a type assertion. This is,
however, a common pattern where interfaces turn out to need additional
methods in a stable library or only some implementations can provide
the additional methods (AKA "interface upgrade").
Needless to say that in v2 of this library, we'll do things in a more
straight forward way.
Signed-off-by: beorn7 <beorn@grafana.com>
When those are published on Dockerhub, people will be able to start those
examples in fewer steps than the current documentation:
https://prometheus.io/docs/introduction/getting_started/#starting-up-some-sample-targets
While relying on Docker may not be always wished, giving the possibility to
quickly start a daemon that exposes metrics can be useful in many tutorials.
The simple and random example are build as static binaries and packaged as
single binaries in Docker images.
This commit tries really hard to limit the number of per-example maintenance
work by sharing most of the Makefile to build the Docker images. The tiny top
level Makefiles in each example directory are strictly identical.
Updates: #347
This also updates all tests and examples to use explicitly set
objectives.
In v0.10, DefObjectives will be completely removed, and the default
Summary will have no objectives then.
Fixes#118
I intentionally left out the Makefile infrastructure that we had
previously for this, as it's not strictly needed and adds
complexity/maintenance burden.
This rewrite had may backs and forths. In my git repository, it
consists of 35 commits which I cannot group or merge into reasonable
review buckets. Gerrit breaks fundamental git semantics, so I have to
squash the 35 commits into one for the review.
I'll push this not with refs/for/master, but with refs/for/next so
that we can transition after submission in a controlled fashion.
For the review, I recommend to start with looking at godoc and in
particular the many examples. After that, continue with a line-by-line
detailed review. (The big picture is hopefully as expected after
wrapping up the discussion earlier.)
Change-Id: Ib38cc46493a5139ca29d84020650929d94cac850
Lili Cosic