From 5973acd65d265e4864fbb3d954cb15f3567c126b Mon Sep 17 00:00:00 2001 From: beorn7 Date: Tue, 2 Jul 2019 13:23:20 +0200 Subject: [PATCH] Clarifying honor_labels documentation Previously, the wording could be misunderstood as setting honor_labels to "false" for federation. This also adds scraping the Pushgateway as a typical use case for honor_labels=true. Signed-off-by: beorn7 --- docs/configuration/configuration.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/configuration/configuration.md b/docs/configuration/configuration.md index 054832144..dbaa95bfe 100644 --- a/docs/configuration/configuration.md +++ b/docs/configuration/configuration.md @@ -127,8 +127,11 @@ job_name: # If honor_labels is set to "false", label conflicts are resolved by renaming # conflicting labels in the scraped data to "exported_" (for # example "exported_instance", "exported_job") and then attaching server-side -# labels. This is useful for use cases such as federation, where all labels -# specified in the target should be preserved. +# labels. +# +# Setting honor_labels to "true" is useful for use cases such as federation and +# scraping the Pushgateway, where all labels specified in the target should be +# preserved. # # Note that any globally configured "external_labels" are unaffected by this # setting. In communication with external systems, they are always applied only