Merge remote-tracking branch 'upstream/master' into lperkins/issue-750-sample-term

Signed-off-by: lucperkins <lucperkins@gmail.com>

.gitignore

@@ -11,7 +11,11 @@ tmp/
 # Crash Log
 crash.log
 
-# OS X file
-static/.DS_Store
+# macOS artifacts
+.DS_Store
 
 prometheus_rsa
+
+# Ruby artifacts
+.bundle/
+vendor/

Makefile

+NANOC      = bundle exec nanoc
+GUARD      = bundle exec guard
 DOWNLOADS := prometheus alertmanager blackbox_exporter consul_exporter graphite_exporter haproxy_exporter memcached_exporter mysqld_exporter node_exporter pushgateway statsd_exporter
 
 build: clean downloads compile
 
+bundle:
+	bundle config build.nokogiri --use-system-libraries
+	bundle install --path vendor
+
 clean:
 	rm -rf output downloads repositories
 
 compile:
-	bundle exec nanoc
+	$(NANOC)
 
 downloads: $(DOWNLOADS:%=downloads/%/repo.json) $(DOWNLOADS:%=downloads/%/releases.json)
 
@@ -20,4 +26,10 @@ downloads/%/releases.json:
 	@echo "curl -sf -H 'Accept: application/vnd.github.v3+json' <GITHUB_AUTHENTICATION> https://api.github.com/repos/prometheus/$*/releases > $@"
 	@curl -sf -H 'Accept: application/vnd.github.v3+json' $(GITHUB_AUTHENTICATION) https://api.github.com/repos/prometheus/$*/releases > $@
 
-.PHONY: build compile deploy
+guard:
+	$(GUARD)
+
+serve:
+	$(NANOC) view
+
+.PHONY: build bundle clean compile downloads serve

README.md

@@ -15,12 +15,12 @@ As a guideline, please keep the documentation generally applicable and avoid use
 
 ## Prerequisites
 
-You need to have a working Ruby environment set up and then install the
-necessary gems:
+You need to have a working Ruby environment set up (including [bundler](https://bundler.io/))
+and then install the necessary gems:
 
 ```bash
 cd docs
-bundle
+make bundle
 ```
 
 ## Building
@@ -39,9 +39,9 @@ To run a local server that displays the generated site, run:
 
 ```bash
 # Rebuild the site whenever relevant files change:
-bundle exec guard
-# Start the local development server:
-bundle exec nanoc view
+make guard
+# Start the local development server in a separate shell:
+make serve
 ```
 
 You should now be able to view the generated site at

content/docs/instrumenting/pushing.md

@@ -16,7 +16,7 @@ makes it easy to instrument even shell scripts without a client library.
 [README.md](https://github.com/prometheus/pushgateway/blob/master/README.md).
 
  * For use from Java see the
-[PushGateway](https://prometheus.io/client_java/io/prometheus/client/exporter/PushGateway.html)
+[PushGateway](https://prometheus.github.io/client_java/io/prometheus/client/exporter/PushGateway.html)
 class.
 
  * For use from Go see the [Push](http://godoc.org/github.com/prometheus/client_golang/prometheus#Push) and [PushAdd](http://godoc.org/github.com/prometheus/client_golang/prometheus#PushAdd) functions.

content/docs/instrumenting/writing_clientlibs.md

@@ -312,15 +312,8 @@ descriptions, to lead by example.
 
 ## Exposition
 
-Clients MUST implement one of the documented [exposition
-formats](/docs/instrumenting/exposition_formats).
-
-Clients MAY implement more than one format. There SHOULD be a human readable
-format offered.
-
-If in doubt, go for the text format. It doesn’t have a dependency (protobuf),
-tends to be easy to produce, is human readable and the performance benefits of
-protobuf are not that significant for most use cases.
+Clients MUST implement the text-based exposition format outlined in the
+[exposition formats](/docs/instrumenting/exposition_formats) documentation.
 
 Reproducible order of the exposed metrics is ENCOURAGED (especially for human
 readable formats) if it can be implemented without a significant resource cost.
@@ -368,12 +361,12 @@ unit-test their use of the instrumentation code. For example, the
 ## Packaging and dependencies
 
 Ideally, a client library can be included in any application to add some
-instrumentation, without having to worry about it breaking the application.
+instrumentation without breaking the application.
 
 Accordingly, caution is advised when adding dependencies to the client library.
-For example, if a user adds a library that uses a Prometheus client that
-requires version 1.4 of protobuf but the application uses 1.2 elsewhere, what
-will happen?
+For example, if you add a library that uses a Prometheus client that requires
+version x.y of a library but the application uses x.z elsewhere, will that have
+an adverse impact on the application?
 
 It is suggested that where this may arise, that the core instrumentation is
 separated from the bridges/exposition of metrics in a given format. For

content/governance.md

@@ -63,7 +63,7 @@ The current team members are:
 * Matthias Rampke
 * Max Inden
 * Richard Hartmann
-* Simon Pasquer
+* Simon Pasquier
 * Steve Durrheimer
 * Stuart Nelson
 * Tobias Schmidt