Docs: fix grammar and spelling (thanos-io#4224)

Signed-off-by: Aman Dwivedi <[email protected]>

CONTRIBUTING.md

@@ -8,7 +8,7 @@ First of all please follow the [CODE_OF_CONDUCT](/CODE_OF_CONDUCT.md) in all you
 
 The philosophy of Thanos and our community borrows heavily from UNIX philosophy and the Golang programming language.
 
-* Each sub command should do one thing and do it well.
+* Each subcommand should do one thing and do it well.
   * eg. thanos query proxies incoming calls to known store API endpoints merging the result
 * Write components that work together.
   * e.g. blocks should be stored in native prometheus format

README.md

@@ -68,7 +68,7 @@ Deployment with Receive:
 
 The philosophy of Thanos and our community is borrowing much from UNIX philosophy and the golang programming language.
 
-* Each sub command should do one thing and do it well
+* Each subcommand should do one thing and do it well
   * eg. thanos query proxies incoming calls to known store API endpoints merging the result
 * Write components that work together
   * e.g. blocks should be stored in native prometheus format

docs/components/query-frontend.md

@@ -33,7 +33,7 @@ is `24h`. When caching is enabled it should be greater than `0`.
 
 There are some benefits from query splitting:
 
-1. Safe guard. It prevents large queries from causing OOM issues to Queries.
+1. Safeguard. It prevents large queries from causing OOM issues to Queries.
 2. Better parallelization.
 3. Better load balancing for Queries.
 
@@ -62,7 +62,7 @@ config:
 
 **_NOTE:** If both `max_size` and `max_size_items` are not set, then the *cache* would not be created.
 
-If either of `max_size` or `max_size_items` is set, then there is not limit on other field.
+If either of `max_size` or `max_size_items` is set, then there is no limit on other field.
 For example - only set `max_size_item` to 1000, then `max_size` is unlimited. Similarly, if only `max_size` is set, then `max_size_items` is unlimited.
 
 Example configuration: [kube-thanos](https://github.com/thanos-io/kube-thanos/blob/master/examples/all/manifests/thanos-query-frontend-deployment.yaml#L50-L54)

docs/components/query.md

@@ -48,7 +48,7 @@ even if those clusters runs multiple Prometheus servers each. Querier will know
 ### Run-time deduplication of HA groups
 
 Prometheus is stateful and does not allow replicating its database. This means that increasing high availability by running multiple Prometheus replicas is not very easy to use.
-Simple loadbalancing will not work as for example after some crash, replica might be up but querying such replica will result in small gap during the period it was down. You have a
+Simple load balancing will not work as for example after some crash, replica might be up but querying such replica will result in small gap during the period it was down. You have a
  second replica that maybe was up, but it could be down in other moment (e.g rolling restart), so load balancing on top of those is not working well.
 
 Thanos Querier instead pulls the data from both replicas, and deduplicate those signals, filling the gaps if any, transparently to the Querier consumer.
@@ -144,7 +144,7 @@ Now it supports two strategies:
 * "warn"
 * "abort" (default)
 
-NOTE: Having warning does not necessary means partial response (e.g no store matched query warning).
+NOTE: Having a warning does not necessarily mean partial response (e.g no store matched query warning).
 
 Querier also allows to configure different timeouts:
 

docs/components/receive.md

@@ -6,7 +6,7 @@ menu: components
 
 # 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 TSDB and retains their usefulness while extending their functionality with long-term-storage, horizontal scalability, and downsampling. It exposes the StoreAPI so that [Thanos Queriers](./query.md) can query received metrics in real-time. The [Thanos Sidecar](./sidecar.md) is not sufficient for this, as the system would always lag the block length behind (typically 2 hours).
+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 TSDB and retains its usefulness while extending its functionality with long-term-storage, horizontal scalability, and downsampling. It exposes the StoreAPI so that [Thanos Queriers](./query.md) can query received metrics in real-time. The [Thanos Sidecar](./sidecar.md) is not sufficient for this, as the system would always lag the block length behind (typically 2 hours).
 
 We recommend this component to users who can only push into a Thanos due to air-gapped, or egress only environments. Please note the [various pros and cons of pushing metrics](https://docs.google.com/document/d/1H47v7WfyKkSLMrR8_iku6u9VB73WrVzBHb2SB6dL9_g/edit#heading=h.2v27snv0lsur).
 
@@ -63,7 +63,7 @@ The example content of `hashring.json`:
     }
 ]
 ```
-With such configuration any receive is listens for remote write on `<ip>10908/api/v1/receive` and will forward to correct one in hashring if needed
+With such configuration any receive listens for remote write on `<ip>10908/api/v1/receive` and will forward to correct one in hashring if needed
 for tenancy and replication.
 
 ## Flags

docs/components/sidecar.md

@@ -13,7 +13,7 @@ In details:
 * It implements Thanos' Store API on top of Prometheus' remote-read API. This allows [Queriers](./query.md) to treat Prometheus servers as yet another source of time series data without directly talking to its APIs.
 * Optionally, the sidecar uploads TSDB blocks to an object storage bucket as Prometheus produces them every 2 hours. This allows Prometheus servers to be run with relatively low retention while their historic data is made durable and queryable via object storage.
 
-  NOTE: This still does NOT mean that Prometheus can be fully stateless, because if it crashes and restarts you will lose ~2 hours of metrics, so persistent disk for Prometheus is highly recommended. The closest to stateless you can get is using remote write (which Thanos supports, see [Receiver](./receive.md). Remote write has other risks and consequences, and still if crashed you loose in positive case seconds of metrics data, so persistent disk is recommended in all cases.
+  NOTE: This still does NOT mean that Prometheus can be fully stateless, because if it crashes and restarts you will lose ~2 hours of metrics, so persistent disk for Prometheus is highly recommended. The closest to stateless you can get is using remote write (which Thanos supports, see [Receiver](./receive.md). Remote write has other risks and consequences, and still if crashed you lose in positive case seconds of metrics data, so persistent disk is recommended in all cases.
 
 * Optionally Thanos sidecar is able to watch Prometheus rules and configuration, decompress and substitute environment variables if needed and ping Prometheus to reload them. Read more about this in [here](./sidecar.md#reloader-configuration)
 
@@ -29,7 +29,7 @@ If you choose to use the sidecar to also upload data to object storage:
 * Must specify object storage (`--objstore.*` flags)
 * It only uploads uncompacted Prometheus blocks. For compacted blocks, see [Upload compacted blocks](./sidecar.md/#upload-compacted-blocks).
 * The `--storage.tsdb.min-block-duration` and `--storage.tsdb.max-block-duration` must be set to equal values to disable local compaction on order to use Thanos sidecar upload, otherwise leave local compaction on if sidecar just exposes StoreAPI and your retention is normal. The default of `2h` is recommended.
-  Mentioned parameters set to equal values disable the internal Prometheus compaction, which is needed to avoid the uploaded data corruption when Thanos compactor does its job, this is critical for data consistency and should not be ignored if you plan to use Thanos compactor. Even though you set mentioned parameters equal, you might observe Prometheus internal metric `prometheus_tsdb_compactions_total` being incremented, don't be confused by that: Prometheus writes initial head block to filesytem via its internal compaction mechanism, but if you have followed recommendations - data won't be modified by Prometheus before the sidecar uploads it. Thanos sidecar will also check sanity of the flags set to Prometheus on the startup and log errors or warning if they have been configured improperly (#838).
+  Mentioned parameters set to equal values disable the internal Prometheus compaction, which is needed to avoid the uploaded data corruption when Thanos compactor does its job, this is critical for data consistency and should not be ignored if you plan to use Thanos compactor. Even though you set mentioned parameters equal, you might observe Prometheus internal metric `prometheus_tsdb_compactions_total` being incremented, don't be confused by that: Prometheus writes initial head block to filesystem via its internal compaction mechanism, but if you have followed recommendations - data won't be modified by Prometheus before the sidecar uploads it. Thanos sidecar will also check sanity of the flags set to Prometheus on the startup and log errors or warning if they have been configured improperly (#838).
 * The retention is recommended to not be lower than three times the min block duration, so 6 hours. This achieves resilience in the face of connectivity issues to the object storage since all local data will remain available within the Thanos cluster. If connectivity gets restored the backlog of blocks gets uploaded to the object storage.
 
 ## Reloader Configuration

docs/components/store.md

@@ -242,7 +242,7 @@ Check more [here](https://thanos.io/tip/thanos/sharding.md/).
 ## Probes
 
 - Thanos Store exposes two endpoints for probing.
-  - `/-/healthy` starts as soon as initial setup completed.
+  - `/-/healthy` starts as soon as initial setup is completed.
   - `/-/ready` starts after all the bootstrapping completed (e.g initial index building) and ready to serve traffic.
 
 > NOTE: Metric endpoint starts immediately so, make sure you set up readiness probe on designated HTTP `/-/ready` path.
@@ -258,7 +258,7 @@ Thanos Store Gateway supports an index cache to speed up postings and series loo
 
 The `in-memory` index cache is enabled by default and its max size can be configured through the flag `--index-cache-size`.
 
-Alternatively, the `in-memory` index cache can also by configured using `--index-cache.config-file` to reference to the configuration file or `--index-cache.config` to put yaml config directly:
+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:
 
 [embedmd]:# (../flags/config_index_cache_in_memory.txt yaml)
 ```yaml
@@ -275,7 +275,7 @@ All the settings are **optional**:
 
 ### Memcached index cache
 
-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 to the configuration file or `--index-cache.config` to put yaml config directly:
+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:
 
 [embedmd]:# (../flags/config_index_cache_memcached.txt yaml)
 ```yaml
@@ -353,12 +353,12 @@ Following options are used for metadata caching (meta.json files, deletion mark
 - `metafile_content_ttl`: how long to cache content of meta.json and deletion mark files.
 - `metafile_max_size`: maximum size of cached meta.json and deletion mark file. Larger files are not cached.
 
-The yml structure for setting the in memory cache configs for caching bucket are the same as the [in-memory index cache](https://thanos.io/tip/components/store.md/#in-memory-index-cache) and all the options to configure Caching Buket mentioned above can be used.
+The yml structure for setting the in memory cache configs for caching bucket is the same as the [in-memory index cache](https://thanos.io/tip/components/store.md/#in-memory-index-cache) and all the options to configure Caching Buket mentioned above can be used.
 
 Note that chunks and metadata cache is an experimental feature, and these fields may be renamed or removed completely in the future.
 
 ## Index Header
 
-In order to query series inside blocks from object storage, Store Gateway has to know certain initial info from each block index. In order to achieve so, on startup the Gateway builds an `index-header` for each block and stores it on local disk; such `index-header` is build downloading specific pieces of original block's index, stored on local disk and then mmaped and used by Store Gateway.
+In order to query series inside blocks from object storage, Store Gateway has to know certain initial info from each block index. In order to achieve so, on startup the Gateway builds an `index-header` for each block and stores it on local disk; such `index-header` is build by downloading specific pieces of original block's index, stored on local disk and then mmaped and used by Store Gateway.
 
 For more information, please refer to the [Binary index-header](../operating/binary-index-header.md) operational guide.

docs/components/tools.md

@@ -676,7 +676,7 @@ Flags:
 
 ### Bucket Rewrite
 
-`tools bucket rewrite` reewrites chosen blocks in the bucket, while deleting or modifying series.
+`tools bucket rewrite` rewrites chosen blocks in the bucket, while deleting or modifying series.
 
 For example we can remove all non counters from the block you have on your disk (e.g in Prometheus dir):
 
@@ -820,7 +820,7 @@ Flags:
 #### Probes
 
 - The downsample service exposes two endpoints for probing:
-  - `/-/healthy` starts as soon as initial setup completed.
+  - `/-/healthy` starts as soon as the initial setup is completed.
   - `/-/ready` starts after all the bootstrapping completed (e.g object store bucket connection) and ready to serve traffic.
 
 > NOTE: Metric endpoint starts immediately so, make sure you set up readiness probe on designated HTTP `/-/ready` path.

docs/contributing/mentorship.md

@@ -54,7 +54,7 @@ There are certain rules you can follow to make the MOST from your time with us!
 - Try to be independent and responsible for the feature you want to deliver. The sooner you start to lead your task, the better for you! It's hard in the beginning but try to think about the user experience.
   Is it hard or easy to make mistake using it? How difficult is it to migrate to this feature? Is there anything we can do to reduce data loss errors?
 - Try to help others by **reviewing** other contributors, mentees or mentors' Pull Requests! It sounds scary, but this is actually the best way to learn about coding practices, patterns and how to maintain high quality codebase! (GIFs on PRs are welcome as well!)
-- Try using an [iterative process for development](https://en.wikipedia.org/wiki/Iterative_and_incremental_development). Start with small and simple assumptions, and once you have a working example ready, keep improving and discusing with the mentors. Small changes are easy to review and easy to accept 😄.
+- Try using an [iterative process for development](https://en.wikipedia.org/wiki/Iterative_and_incremental_development). Start with small and simple assumptions, and once you have a working example ready, keep improving and discussing with the mentors. Small changes are easy to review and easy to accept 😄.
 - Try working out a [proof of concept](https://en.wikipedia.org/wiki/Proof_of_concept), which can be used as a baseline, and can be improved upon. These are real-world projects, so it's not possible to have a deterministic solution everytime, and proof of concepts are quick way to determine feasibility.
 
 ### Thanos Mentoring Office Hours

docs/governance.md

@@ -147,7 +147,7 @@ The subject must be prefixed with `[VOTE]`. In the body, the call to vote must s
 
 Votes may take the form of a single proposal, with the option to vote yes or no, or the form of multiple alternatives.
 
-A vote on a single proposal is considered successful if at least two thirds of those eligible to vote vote in favor.
+A vote on a single proposal is considered successful if at least two thirds of those eligible to vote, vote in favor.
 
 If there are multiple alternatives, members may vote for one or more alternatives, or vote “no” to object to all alternatives.
 A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from at least two thirds of those eligible to vote. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
@@ -183,7 +183,7 @@ Should the decision be in favor, your new membership will also be announced on t
 
 As a team member, propose the new project on the [Thanos GitHub Issue][issues]. However, currently to maintain project in our organization you have to become Thanos Maintainers.
 
-All are encourage to start their own project related to Thanos. Thanos team is happy to link to your poject in appriopriate page e.g https://thanos.io/tip/thanos/integrations.md/
+All are encourage to start their own project related to Thanos. Thanos team is happy to link to your poject inappropriate page e.g https://thanos.io/tip/thanos/integrations.md/
 
 ### How do I remove a Maintainer or Triage member?
 

docs/operating/binary-index-header.md

@@ -76,4 +76,4 @@ The Store Gateway stores each block's index-header on the local disk and loads i
 
 Given an index-header, the Store Gateway does **not** fully load the entire content in memory, but it only loads 1/32 of postings offsets. At query time, postings offsets are then looked up both from memory (1/32 offsets) and from the mmap-ed index-header files, which could hit the disk or not whether the requested file block has been cached by the OS.
 
-The trade-off picked by this optimization technique allows to significantly reduce the Store Gateway memory utilization while increasing CPU and disk read OPS. The Store Gateway has an hidden CLI flag `--store.index-header-posting-offsets-in-mem-sampling` to control the ratio of postings offsets loaded into memory; larger values will lower memory usage and increase CPU and disk read OPS, while lower values will increase memory and lower CPU and disk read OPS. A value of `1` will keep all in memory.
+The trade-off picked by this optimization technique allows to significantly reduce the Store Gateway memory utilization while increasing CPU and disk read OPS. The Store Gateway has a hidden CLI flag `--store.index-header-posting-offsets-in-mem-sampling` to control the ratio of postings offsets loaded into memory; larger values will lower memory usage and increase CPU and disk read OPS, while lower values will increase memory and lower CPU and disk read OPS. A value of `1` will keep all in memory.