From 3bd76145c25c589310390647f36224b88740f75d Mon Sep 17 00:00:00 2001 From: Coleen Iona Quadros Date: Wed, 4 Sep 2024 15:29:35 +0200 Subject: [PATCH] update docs Signed-off-by: Coleen Iona Quadros --- docs/components/receive.md | 2 - docs/components/sidecar.md | 2 - docs/components/store.md | 8 - docs/components/tools.md | 6 - .../202301-distributed-query-execution.md | 197 ------------------ .../202304-query-path-tenancy.md | 133 ------------ docs/storage.md | 16 -- 7 files changed, 364 deletions(-) delete mode 100644 docs/proposals-accepted/202301-distributed-query-execution.md delete mode 100644 docs/proposals-accepted/202304-query-path-tenancy.md diff --git a/docs/components/receive.md b/docs/components/receive.md index 82b4ca8b9de..677c5e142be 100644 --- a/docs/components/receive.md +++ b/docs/components/receive.md @@ -72,8 +72,6 @@ where `` is an IP address reachable by Prometheus The example content of `bucket.yml`: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=gcs.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: GCS config: bucket: "" diff --git a/docs/components/sidecar.md b/docs/components/sidecar.md index 855c79621ee..d41a920aa29 100644 --- a/docs/components/sidecar.md +++ b/docs/components/sidecar.md @@ -52,8 +52,6 @@ thanos sidecar \ The example content of `bucket.yml`: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=gcs.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: GCS config: bucket: "" diff --git a/docs/components/store.md b/docs/components/store.md index d4d9e192847..63cdbbd50d5 100644 --- a/docs/components/store.md +++ b/docs/components/store.md @@ -11,8 +11,6 @@ thanos store \ The content of `bucket.yml`: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=gcs.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: GCS config: bucket: "" @@ -328,8 +326,6 @@ The `in-memory` index cache is enabled by default and its max size can be config Alternatively, the `in-memory` index cache can also be configured using `--index-cache.config-file` to reference the configuration file or `--index-cache.config` to put yaml config directly: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=storecache.InMemoryIndexCacheConfig" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: IN-MEMORY config: max_size: 0 @@ -350,8 +346,6 @@ All the settings are **optional**: The `memcached` index cache allows to use [Memcached](https://memcached.org) as cache backend. This cache type is configured using `--index-cache.config-file` to reference the configuration file or `--index-cache.config` to put yaml config directly: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=cacheutil.MemcachedClientConfig" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: MEMCACHED config: addresses: [] @@ -405,8 +399,6 @@ While the remaining settings are **optional**: The `redis` index cache allows to use [Redis](https://redis.io) as cache backend. This cache type is configured using `--index-cache.config-file` to reference the configuration file or `--index-cache.config` to put yaml config directly: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=cacheutil.RedisClientConfig" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: REDIS config: addr: "" diff --git a/docs/components/tools.md b/docs/components/tools.md index fe8a7f610c9..7732ffc193b 100644 --- a/docs/components/tools.md +++ b/docs/components/tools.md @@ -106,8 +106,6 @@ thanos tools bucket verify --objstore.config-file=bucket.yml The content of `bucket.yml`: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=gcs.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: GCS config: bucket: "" @@ -678,8 +676,6 @@ thanos tools bucket downsample \ The content of `bucket.yml`: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=gcs.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: GCS config: bucket: "" @@ -782,8 +778,6 @@ thanos tools bucket mark \ The example content of `bucket.yml`: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=gcs.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: GCS config: bucket: "" diff --git a/docs/proposals-accepted/202301-distributed-query-execution.md b/docs/proposals-accepted/202301-distributed-query-execution.md deleted file mode 100644 index c4d6984df7e..00000000000 --- a/docs/proposals-accepted/202301-distributed-query-execution.md +++ /dev/null @@ -1,197 +0,0 @@ ---- -type: proposal -title: Distributed Query Execution -status: accepted -owner: fpetkovski -menu: proposals-accepted ---- - -## 1 Related links/tickets - -* https://github.com/thanos-io/thanos/pull/5250 -* https://github.com/thanos-io/thanos/pull/4917 -* https://github.com/thanos-io/thanos/pull/5350 -* https://github.com/thanos-community/promql-engine/issues/25 - -## 2 Why - -Thanos Queriers currently need to pull in all data from Stores in memory before they can start evaluating a query. This has a large impact on the used memory inside a single querier, and drastically increases query execution latency. - -Even when a Querier is connected to other Queriers, it will still pull raw series instead of delegating parts of the execution to its downstreams. This document proposes a mode in the Thanos Querier where it will dispatch parts of the execution plan to different, independent Queriers. - -## 3 Pitfalls of current solutions - -We have two mechanisms in Thanos to distribute queries among different components. - -Query pushdown is a mechanism enabled by query hints which allows a Thanos sidecar to execute certain queries against Prometheus as part of a `Series` call. Since data is usually replicated in at least two Prometheus instances, the subset of queries that can be pushed down is quite limited. In addition to that, this approach has introduced additional complexity in the deduplication iterator to allow the Querier to distinguish between storage series and PromQL series. - -Query Sharding is a execution method initiated by Query Frontend and allows for an aggregation query with grouping labels to be distributed to different Queriers. Even though the number of queries that can be sharded is larger than the ones that can be pushed down, query sharding still has a limited applicability since a query has to contain grouping labels. We have also noticed in practice that the execution latency does not fall linearly with the number of vertical shards, and often plateaus off at around ~4 shards. This is especially pronounced when querying data from Store Gateways, likely due to amplifying `Series` calls against Store components. - -## 4 Audience - -* Thanos users who have challenges with evaluating PromQL queries due to high cardinality. - -## 5 Goals - -* Enable decentralized query execution by delegating query plan fragments to independent Queriers. - -## 6 Proposal - -The key advantage of distributed execution is the fact that the number of series is drastically reduced when a query contains an aggregation operator (`sum`, `group`, `max`, etc..). Most (if not all) high cardinality PromQL queries are in-fact aggregations since users will struggle to sensibly visualise more than a handful of series. - -We therefore propose an execution model that allows running a Thanos Querier in a mode where it transforms a query to subqueries which are delegated to independent Queriers, and a central aggregation that is executed locally on the result of all subqueries. A simple example of this transformation is a `sum(rate(metric[2m]))` expression which can be transformed as - -``` -sum( - coalesce( - sum(rate(metric[2m])), - sum(rate(metric[2m])) - ) -) -``` - -### How - -The proposed method of transforming the query is extending the Thanos Engine with a logical optimizer that has references to other query engines. An example API could look as follows: - -``` -type DistributedExecutionOptimizer struct { - Endpoints api.RemoteEndpoints -} - -type RemoteEndpoints interface { - Engines() []RemoteEngine -} - -type RemoteEngine interface { - NewInstantQuery(opts *promql.QueryOpts, qs string, ts time.Time) (promql.Query, error) - NewRangeQuery(opts *promql.QueryOpts, qs string, start, end time.Time, interval time.Duration) (promql.Query, error) -} -``` - -The implementation of the `RemoteEngine` will be provided by Thanos itself and will use the gRPC Query API added in [https://github.com/thanos-io/thanos/pull/5250](https://github.com/thanos-io/thanos/pull/5250). - -Keeping PromQL execution in Query components allows for deduplication between Prometheus pairs to happen before series are aggregated. - -Distributed query execution - -The initial version of the solution can be found here: https://github.com/thanos-community/promql-engine/pull/139 - -### Query rewrite algorithm - -As described in the section above, the query will be rewritten using a logical optimizer into a form that is suitable for distributed execution. - -The proposed algorithm is as follows: -* Start AST traversal from the bottom up. -* If both the current node and its parent can be distributed, move up to the parent. -* If the current node can be distributed and its parent cannot, rewrite the current node into its distributed form. -* If the current node cannot be distributed, stop traversal. - -With this algorithm we try to distribute as much of the PromQL query as possible. Furthermore, even queries without aggregations, like `rate(http_requests_total[2m])`, will be rewritten into - -``` -coalesce( - rate(http_requests_total[2m]), - rate(http_requests_total[2m]) -) -``` - -Since PromQL queries are limited in the number of steps they can evaluate, with this algorithm we achieve downsampling at query time since only a small number of samples will be sent from local Queriers to the central one. - -### Time-based overlap resolution - -Thanos stores usually have a small overlap with ingestion components (Prometheus/Receiver) due to eventually consistency from uploading and downloading TSDB blocks. As a result, the central aggregation needs a way to deduplicate samples between ingestion and storage components. - -The proposed way to do time-based deduplication is by removing identical samples in the `coalesce` operator in the Thanos Engine itself. In order for data from independent Queriers to not get deduplicated, aggregations happening in remote engines must always preserve external labels from TSDB blocks that are being queried. - -To illustrate this on an example, we can assume that we have two clusters `a` and `b`, each being monitored with a Prometheus pair and with each Prometheus instance having an external `cluster` label. The query `sum(rate(metric[2m]))` would then be rewritten by the optimizer into: - -``` -sum( - coalesce( - sum by (cluster) (rate(metric[2m])), - sum by (cluster) (rate(metric[2m])) - ) -) -``` - -Each subquery would preserve the external `cluster` label which will allow the `coalesce` operator to deduplicate only those samples which are calculated from the same TSDB blocks. External labels can be propagated to the central engine by extending the `RemoteEngine` interface with a `Labels() []string` method. With this approach, local Queriers can be spread as widely as needed, with the extreme case of having one Querier per deduplicated TSDB block. - -Distributed query execution - -## Deployment models - -With this approach, a Thanos admin can arrange remote Queriers in an arbitrary way, as long as TSDB replicas are always queried by only one remote Querier. The following deployment models can be used as examples: - -#### Monitoring different environments with Prometheus pairs - -In this deployment mode, remote queriers are attached to pairs of Prometheus instances. The central Querier delegates subqueries to them and performs a central aggregation of results. - -Distributed query execution - -#### Querying separate Store Gateways and Prometheus pairs - -Remote Queriers can be attached to Prometheus pairs and Store Gateways at the same time. The central querier delegates subqueries and deduplicates overlapping results before performing a central aggregation. - -Distributed query execution - -#### Running remote Queriers as Store Gateway sidecars - -Remote Queriers can be attached to disjoint groups of Store Gateways. They can even be attached to individual Store Gateways which have deduplicated TSDB blocks, or hold all replicas of a TSDB block. This will make sure penalty-based deduplication happens in the remote querier. - -Store groups can be created by either partitioning TSDBs by time (time-based partitioning), or by external labels. Both of these techniques are documented in the [Store Gateway documentation](https://thanos.io/tip/components/store.md/#time-based-partitioning). - -Distributed query execution - -### Distributed execution against Receive components - -We currently lack the mechanism to configure a Querier against a subset of TSDBs, unless that Querier is exclusively attached to Stores that have those TSDBs. In the case of Receivers, TSDBs are created and pruned dynamically, which makes it hard to apply the distributed query model against this component. - -To resolve this issue, this proposal suggests adding a `"selector.relabel-config` command-line flag to the Query component that will work the same way as the Store Gateway selector works. For each query, the Querier will apply the given relabel config against each Store's external label set and decide whether to keep or drop a TSDB from the query. After the relabeling is applied, the query will be rewritten to target only those TSDBs that match the selector. - -An example config that only targets TSDBs with external labels `tenant=a` would be: - -``` -- source_labels: [tenant] - action: keep - regex: a -``` - -With this mechanism, a user can run a pool of Queriers with a selector config as follows: - -``` -- source_labels: [ext_label_a, ext_label_b] - action: hashmod - target_label: query_shard - modulus: ${query_shard_replicas} -- action: keep - source_labels: [query_shard] - regex: ${query_shard_instance} -``` - - - -This approach can also be used to create Querier shards against Store Gateways, or any other pool of Store components. - -## 7 Alternatives - -A viable alternative to the proposed method is to add support for Query Pushdown in the Thanos Querier. By extracting better as described in https://github.com/thanos-io/thanos/issues/5984, we can decide to execute a query in a local Querier, similar to how the sidecar does that against Prometheus. - -Even though this approach might be faster to implement, it might not be the best long-term solution due to several reasons. To some extent, Query Pushdown misuses the `Series` API and the Querier requesting series is not aware that the query was actually executed. This can be problematic for distributing something like `count(metric)` since the distributed version should end up as: - -``` -sum( - coalesce( - count(metric), - count(metric) - ) -) -``` - -The root querier would need to know that downstream queriers have already executed the `count` and should convert the aggregation into a `sum` - -A similar problem can happen with a `sum(rate(metric[2m]))` expression where downstream queriers calculate the `sum` over the metric's `rate`. In order for the values to not get rated twice, either the downstream queriers need to invert the rate into a cumulative value, or the central querier needs to omit the rate and only calcualte the sum. - -Managing this complexity in Thanos itself seems error prone and hard to maintain over time. As a result, this proposal suggests to localize the complexity into a single logical optimizer as suggested in the sections above. - -Depending on the success of the distributed execution model, we can also fully deprecate query pushdown and query sharding and replace them with a single mechanism that can evolve and improve over time. diff --git a/docs/proposals-accepted/202304-query-path-tenancy.md b/docs/proposals-accepted/202304-query-path-tenancy.md deleted file mode 100644 index 498810c7230..00000000000 --- a/docs/proposals-accepted/202304-query-path-tenancy.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -type: proposal -title: Tenancy awareness in query path -status: accepted -owner: douglascamata -menu: proposals-accepted ---- - -## Tenancy awareness in query path - -* **Owners:** - * [@douglascamata](https://github.com/douglascamata) - -* **Related Tickets:** - * [Querier: Added native multi-tenancy support](https://github.com/thanos-io/thanos/pull/4141). - * [Proposal: Native Multi-tenancy Support](https://github.com/thanos-io/thanos/pull/4055) - -* **Other docs:** - * [Multi-tenancy in Thanos](https://thanos.io/tip/operating/multi-tenancy.md/) - -This design doc proposes to add tenancy awareness in the query path. - -## Why - -In a multi-tenant environment, it is important to be able to identify which tenants are experiencing issues and configure (e.g. with different limits) each one of them individually and according to their usage of the platform so that the quality of service can be guaranteed to all the tenants. - -### Pitfalls of the current solution - -The current lack of tenancy awareness in Thanos' query path makes it impossible to investigate issues related to multi-tenancy without the use of external tools, proxies, or deploying a full dedicated query path for each tenant (including one Query Frontend if the setup needs it, one Querier, and one Storage Gateway, to be as complete as possible). For example, it's impossible to determine which tenants are experiencing high latency or high error rates - -## Goals - -* Allow the query path components to be configurable to identify tenants, opening the way to the implementation per-tenant features on the query path without needing to run multiple copies of the components, each dedicated to a single tenant. These features include, but aren't limited to, the following: - * Per-tenant observability. - * Per-tenant settings. For example, having different limits per tenant, which is a common request. - * Per-tenant billing. - * Ensure a tenant's query does not end up returning data from a different tenant, through enforcing presence of one or more tenant labels in queries. -* Strive for being compatible with other tools, such as Cortex, as much as possible. This make adoption, migration, and collaboration between projects to become easier. - -### Tenancy model - -The tenancy model for queries differ from the one used in Thanos Receive, where the tenant indicates who owns that data. From a query perspective, the tenant will indicate who is initiating such query. Although this proposal will use this tenant to automatically enforce a tenant label matcher into the query, whenever cross-tenant querying is implemented (not part of this proposal) this behavior could likely change. - -### Audience - -Any team running Thanos in a multi-tenant environment. For example, a team running a monitoring-as-a-service platform. For example, a team running a monitoring-as-a-service platform. - -## Non-Goals - -* Add multi-tenancy to Thanos Ruler. -* Implement cross-tenant querying. It poses the question about how to track metrics of a multi-tenant query, probably requiring new logic for query splitting and/or separation of the concepts of query initiator tenant and query target tenants. To exemplify: if tenant A executes a query touching their own data and tenant B data (imagine a label matcher `tenant_id=~"A|B"`), how does Thanos export a request duration metric about this query? This is out of scope and an specific proposal can be created for it. - -## How - -* Implement a mechanism to allow incoming requests to specify the tenant triggering the query using an HTTP header. This only needs to be configurable at the Query Frontend and Querier. - * This is needed in the Query Frontend because it needs per-tenant observability and configuration. -* We follow the example of Thanos Receive, which uses the `--receive.tenant-header="THANOS-TENANT"` flag to configure the tenant header, adapting its name to each component. So in the Querier, the flag name will be `--querier.tenant-header="THANOS-TENANT` and in the Query Frontend it will be `--query-frontend.tenant-header="THANOS-TENANT"`. This ensures we have consistency across components and make adoption easier for those already using a custom header name in Receive or coming from other alternative tools, like Cortex. -* The tenant header value from a given request should travel downstream to all the components being called, so that it can be added to their metrics, traces, and logs without requiring duplicated/extra work to re-parse the query. This applies to gRPC calls in a different fashion, where gRPC metadata should be used. - * In this case, the header name should be hardcoded and standardized between the components. -* Implement a command line flag in the Querier component that will turn on the enforcement of a tenant label selector in queries. Name suggestion for the flag: `--querier.tenancy="false"`. - * The label verification and enforcement should be done by reusing prom-label-proxy's [Enforce.EnforceMatchers](https://github.com/prometheus-community/prom-label-proxy/blob/main/injectproxy/enforce.go#L141). There's no reason to (re)implement something specific and special for Thanos. - * This behavior should be implemented as part of the base logic of both the HTTP and gRPC query APIs, before the query is handed to the query engine. This allows users managing complex Querier trees can choose where they want this logic to be enabled. -* Implement a command line flag in the Querier component that will indicate with label name that should be used to enforce tenancy. - * Following the example of Thanos Receive for consistency, and use `--query.tenant-label-name="tenant_id"` flag to identify the tenancy label. -* Update metrics exported by the components in the query path to include the tenant label when it's available. -* Implement a tenant selector in the Query Frontend UI, which should communicate the tenant to Query Frontend using the HTTP header. - -### TL;DR: - -Identifying and transporting tenant information between requests: - -* Happens in Query Frontend (optional component to help scale queries) and Querier. -* Customizable header name for picking up the tenant of incoming queries. Use `THANOS-TENANT` as default value. Consistent with the behavior of Thanos Receive. -* Hardcoded opinionated header to carry tenant information in internal communication between components, reducing configuration flags. -* In gRPC requests propagate tenant identification using gRPC metadata. - -Enforcing tenancy label in queries: - -* Happens in Querier only. -* Enabled by a single configuration flag if using default values for tenant label name and tenant header name. -* Uses tenant identified through the header. -* Enforces the presence of the configured tenant label name and matches with the identified tenant. Uses `tenant_id` as default label name. Consistent with the behavior of Thanos Receive. - -
- -
Diagram also available online.
-
- -## Alternatives - -### Alternative implementations - -#### Apply verification and enforcement logic in the Query Frontend instead of Querier. - -The Query Frontend is an optional component on any Thanos deployment, while the Querier is always present. Plus, there might be deployments with multiple Querier layers where one or more might need to apply tenant verification and enforcement. On top of this, doing it in the Querier supports future work on using the [new Thanos PromQL engine](https://github.com/thanos-community/promql-engine), which can potentially make the Query Frontend unnecessary. - -#### Add the tenant identification as an optional field in the Store API protobuffer spec instead of an HTTP header. - -Pros: - -* There's no guessing where the tenant information is passed through. It would be passed always through the same field in the gRPC message. - -Cons: - -* It's still needed to identify the tenant from incoming requests sent to Query Frontend and Querier via HTTP headers. -* Creates inconsistency between components on how the tenant information is passed through. In Receive, for example, it's passed through a header. This hurts code reusability and understanding. -* Creates inconsistency between APIs. We have other APIs besides the Store API. We can set the standard of an internal and hardcoded header for the HTTP requests and gRPC metadata for the gRPC requests. -* Even though Thanos itself doesn't implementation authentication, the query tenancy can be seen as result of authentication. Semantically, headers are often used to convey results of authentication. -* Incompatible with other tools and projects. Using a header in the HTTP communication allows Thanos to be compatible with Cortex and other monitoring tools. This is a plus for adoption, migration, and collaboration between the projects. - -### Alternative solutions - -#### Use a proxy to enforce and identify tenants in queries. - -While this could work for some of the features, like exporting per-tenant metrics, it would have to be inserted in front of many different components. Meanwhile, it doesn't solve the requirement for per-tenant configuration. - -### Use a separate query path for each tenant. - -This incurs in a lot of wasted resources and demands manual work, unless a central tenant configuration is used and a controller is built around it to automatically manage the query paths. - -## Action Plan - -1. Query Frontend - 1. Add `--query-frontend.tenant-header="THANOS-TENANT"` flag to forward the tenant ID from incoming requests to downstream query endpoints. - 2. Use `Thanos-Tenant` (hardcoded) as the internal header name for these downstream requests. - 3. In the Query Frontend UI, add a textbox for entering tenant names to be sent with the configured tenant header name. - 4. Update Query Frontend metrics to include a tenant label based on the header. -2. Querier - 1. Add flags `--querier.tenant-header="THANOS-TENANT"`, `--querier.default-tenant="default-tenant"` to identify and forward tenant ID in internal communications. - 2. Add flags `--querier.tenant-label="tenant-id"` and `--querier.tenancy="false"` to enable tenancy, identify the tenant, verify and enforce the tenant label in queries using [prom-label-proxy's Enforce.EnforceMatchers](https://github.com/prometheus-community/prom-label-proxy/blob/main/injectproxy/enforce.go#L141). - 3. Update Querier metrics to include a tenant label based on the header. -3. Store Gateway - 1. Use the internal tenant header to identify tenant in requests and include it in Store Gateway metrics. diff --git a/docs/storage.md b/docs/storage.md index 0ff5ebc6fa3..14b311230e8 100644 --- a/docs/storage.md +++ b/docs/storage.md @@ -61,8 +61,6 @@ You can configure an S3 bucket as an object store with YAML, either by passing t NOTE: Minio client was mainly for AWS S3, but it can be configured against other S3-compatible object storages e.g Ceph ```yaml mdox-exec="go run scripts/cfggen/main.go --name=s3.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: S3 config: bucket: "" @@ -284,8 +282,6 @@ To configure Google Cloud Storage bucket as an object store you need to set `buc For example: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=gcs.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: GCS config: bucket: "" @@ -378,8 +374,6 @@ To configure Azure Storage account as an object store you need to provide a path Config file format is the following: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=azure.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: AZURE config: storage_account: "" @@ -440,8 +434,6 @@ Below is an example configuration file for thanos to use OpenStack swift contain By default, OpenStack Swift has a limit for maximum file size of 5 GiB. Thanos index files are often larger than that. To resolve this issue, Thanos uses [Static Large Objects (SLO)](https://docs.openstack.org/swift/latest/overview_large_objects.html) which are uploaded as segments. These are by default put into the `segments` directory of the same container. The default limit for using SLO is 1 GiB which is also the maximum size of the segment. If you don't want to use the same container for the segments (best practise is to use `_segments` to avoid polluting listing of the container objects) you can use the `large_file_segments_container_name` option to override the default and put the segments to other container. *In rare cases you can switch to [Dynamic Large Objects (DLO)](https://docs.openstack.org/swift/latest/overview_large_objects.html) by setting the `use_dynamic_large_objects` to true, but use it with caution since it even more relies on eventual consistency.* ```yaml mdox-exec="go run scripts/cfggen/main.go --name=swift.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: SWIFT config: auth_version: 0 @@ -494,8 +486,6 @@ To use Tencent COS as storage store, you should apply a Tencent Account to creat To configure Tencent Account to use COS as storage store you need to set these parameters in yaml format stored in a file: ```yaml mdox-exec="go run scripts/cfggen/main.go --name=cos.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: COS config: bucket: "" @@ -536,8 +526,6 @@ In order to use AliYun OSS object storage, you should first create a bucket with To use AliYun OSS object storage, please specify following yaml configuration file in `objstore.config*` flag. ```yaml mdox-exec="go run scripts/cfggen/main.go --name=oss.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: ALIYUNOSS config: endpoint: "" @@ -554,8 +542,6 @@ Use --objstore.config-file to reference to this configuration file. In order to use Baidu BOS object storage, you should apply for a Baidu Account and create an object storage bucket first. Refer to [Baidu Cloud Documents](https://cloud.baidu.com/doc/BOS/index.html) for more details. To use Baidu BOS object storage, please specify the following yaml configuration file in `--objstore.config*` flag. ```yaml mdox-exec="go run scripts/cfggen/main.go --name=bos.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: BOS config: bucket: "" @@ -572,8 +558,6 @@ This storage type is used when user wants to store and access the bucket in the NOTE: This storage type is experimental and might be inefficient. It is NOT advised to use it as the main storage for metrics in production environment. Particularly there is no planned support for distributed filesystems like NFS. This is mainly useful for testing and demos. ```yaml mdox-exec="go run scripts/cfggen/main.go --name=filesystem.Config" -# command-line-arguments -ld: warning: ignoring duplicate libraries: '-lproc' type: FILESYSTEM config: directory: ""