From 27a3d6c18b23db1160b977b23ade73b2c8cce035 Mon Sep 17 00:00:00 2001 From: Kemal Akkoyun Date: Fri, 5 Jun 2020 16:24:57 +0200 Subject: [PATCH] Apply suggestions from code review from @metalmatze Co-authored-by: Matthias Loibl --- docs/components/receive.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/components/receive.md b/docs/components/receive.md index 38862f8c122..0a4c0d04e6c 100644 --- a/docs/components/receive.md +++ b/docs/components/receive.md @@ -8,11 +8,11 @@ menu: components The `thanos receive` command implements the [Prometheus Remote Write API](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write). It builds on top of existing Prometheus servers and retains their usefulness while extending their functionality with long-term-storage, horizontal scalability, and downsampling. The [Thanos Sidecar](./sidecar.md) is not sufficient for this, as the system would always lag the block length behind (typically 2 hours), which would prevent the most common query pattern of Prometheus: real-time queries of very recent data. -This component is only recommended for uses for whom pushing is the only viable solution, for example, analytics use cases or cases where the data ingestion must be client-initiated, such as software as a service type environments. +We recommend this component to users who can only push into a Thanos due to air-gapped environments. Examples are: analytic use cases or cases where the data ingestion must be client-initiated, such as software as a service type environments. -This component is not recommended in order to achieve a global view of data of a single-tenant, for those cases the sidecar based approach with layered Thanos Queriers is recommended. Multi-tenancy may also be achievable if ingestion is not user-controlled, as then enforcing of labels, for example using the [prom-label-proxy](https://github.com/openshift/prom-label-proxy) (please thoroughly understand the mechanism if intending to employ this mechanism, as the wrong configuration could leak data). +We don't recommend the Thanos Receiver in order to achieve a global view of data of a single-tenant. For such use cases, the sidecar based approach with layered Thanos Queriers is recommended. Multi-tenancy may also be achievable if ingestion is not user-controlled, as then enforcing of labels, for example using the [prom-label-proxy](https://github.com/openshift/prom-label-proxy) (please thoroughly understand the mechanism if intending to employ this mechanism, as the wrong configuration could leak data). -Also, users are asked to note the [various pros and cons of pushing metrics](https://docs.google.com/document/d/1H47v7WfyKkSLMrR8_iku6u9VB73WrVzBHb2SB6dL9_g/edit#heading=h.2v27snv0lsur). +Additionally, we would like to ask users to note the [various pros and cons of pushing metrics](https://docs.google.com/document/d/1H47v7WfyKkSLMrR8_iku6u9VB73WrVzBHb2SB6dL9_g/edit#heading=h.2v27snv0lsur). For more information please check out [initial design proposal](../proposals/201812_thanos-remote-receive.md). For further information on tuning Prometheus Remote Write [see remote write tuning document](https://prometheus.io/docs/practices/remote_write/).