Merge pull request #42 from prometheus/instance-id

Update docs with regard to instance label change.

content/docs/concepts/jobs_instances.md

@@ -12,10 +12,10 @@ same type (replicated for scalability or reliability) is called a _job_.
 For example, an API server job with four replicated instances:
 
    * job: `api-server`
-      * instance 1: `http://1.2.3.4:5670/metrics`
-      * instance 2: `http://1.2.3.4:5671/metrics`
-      * instance 3: `http://5.6.7.8:5670/metrics`
-      * instance 4: `http://5.6.7.8:5671/metrics`
+      * instance 1: `1.2.3.4:5670`
+      * instance 2: `1.2.3.4:5671`
+      * instance 3: `5.6.7.8:5670`
+      * instance 4: `5.6.7.8:5671`
 
 ## Automatically generated labels and time series
 
@@ -23,7 +23,7 @@ When Prometheus scrapes a target, it attaches some labels automatically to the
 scraped time series which serve to identify the scraped target:
 
 * `job`: The configured job name that the target belongs to.
-* `instance`: The URL of the target's endpoint that was scraped.
+* `instance`: The `<host>:<port>` part of the target's URL that was scraped.
 
 If either of these labels are already present in the scraped data, Prometheus
 does not replace their values. Instead, it adds new labels with an `exporter_`
@@ -32,6 +32,6 @@ same pattern holds true for any labels that have been manually configured for a
 target group. This enables intermediary exporters to proxy metrics.
 
 For each instance scrape, Prometheus stores a sample of the form
-`up{job="<job-name>", instance="<instance-url>"}` with a value of `1` if the
+`up{job="<job-name>", instance="<instance-id>"}` with a value of `1` if the
 instance was scraped successfully or a value of `0` if the scrape failed. This
 time series is useful for instance availability monitoring.