docs: Add receive command docs #2726
Conversation
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
docs/components/receive.md
Outdated
|
|
||
| # Receiver | ||
|
|
||
| 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. |
There was a problem hiding this comment.
I don't think the last sentence describes this particularly good.
I'm not even fully grasping what you're trying to say.
There was a problem hiding this comment.
I've cheated and copied that over proposal document 😅 Happy to remove or paraphrase it.
There was a problem hiding this comment.
Hmm for the sentence starting with It builds on top of existing Prometheus servers... I think is a little bit fuzzy for people new to Thanos and who aren't familiar with everything. Also if Thanos builds on top of Prometheus. Maybe we should collaborate on a Google doc so we can iterate faster. Wdyt?
There was a problem hiding this comment.
@squat Yes, please. Great idea. https://docs.google.com/document/d/1H4psm3ancNRyUfg4UilroAEKb96zm_dldH6UnVoLB6A/edit#
docs/components/receive.md
Outdated
|
|
||
| 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. | ||
|
|
||
| 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). |
There was a problem hiding this comment.
| 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). |
We we really need to touch on multi-tenancy here?
There was a problem hiding this comment.
We don't I can remove it. From the proposal as well.
There was a problem hiding this comment.
I think it is awesome Kemal touched multitenancy, but I would elaborate more on this part... This sentence might be confusing
from @metalmatze Co-authored-by: Matthias Loibl <mail@matthiasloibl.com> Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
Signed-off-by: Kemal Akkoyun kakkoyun@gmail.com
Changes
receivecommandVerification
make docsmake check-docscc @brancz @squat
ref: #1093