apitech/loki - loki - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Callum Styan	46b40a5582	Hardcode ring.WriteNoExtend for distributor push operations (#7517 ) With zone awareness enabled we allow restarting multiple ingesters within a single zone at the same time, this means that for many more write requests there's potentially only 2 of the 3 replicas for a stream up at the time the write request is received. This lead to a large increase in 500s during rollouts. My suspicion is that the 500s on rollouts was always related to the following; the replica set ring code has something referred to as "extending the replica set". This essentially is the adding of ingesters in the ring that are not in an ACTIVE state (for example, are in LEAVING) to the set of replicas considered valid for an operation. Adding of the instance in a state other than ACTIVE can be controlled by using a different operation type, which Mimir was using but we were not. Here are the relevant functions, [ring.Get](`8d6d914ef6/ring/ring.go (L335-L403)`) (particularly these lines [1](`8d6d914ef6/ring/ring.go (L381-L389)`) and [2](`8d6d914ef6/ring/ring.go (L394-L397)`)) and [replicationStrategy.Filter](`789ec0ca4a/ring/replication_strategy.go (L22-L71)`) (particularly these lines [1](`789ec0ca4a/ring/replication_strategy.go (L32-L36)`) and [2](`789ec0ca4a/ring/replication_strategy.go (L54-L67)`)) The tl; dr of the above code snippets is that we seem to always have required a minSuccess from replicationFactor/2 + 1 except we overwrite replicationFactor to be the # of instances which is likely always going to be more than just 3 ingester replicas because of the replica set extension. At least for zone aware rollouts this seems to be the case. This is because many ingesters will be in the LEAVING state. We can avoid this by just using `WriteNoExtend` operations instead of `Write` operations ([here](`789ec0ca4a/ring/ring.go (L83-L93)`)) In this PR I've hardcoded our call to the ring in `distributor.Push` to always use `ring.WriteNoExtend`. IMO this is the better option to allowing `ring.WriteNoExtend` to be used optionally and defaulting to `ring.Write`. Extending the replication set on writes feels like a footgun for write outages and there's even some feelings internally that allowing that extension is a bug. For more background information see: https://github.com/grafana/mimir/issues/1854 Signed-off-by: Callum Styan <callumstyan@gmail.com> Signed-off-by: Callum Styan <callumstyan@gmail.com>	3 years ago
Cyril Tovena	7b01864a91	Improves performance of distributor validations (#7534 ) Most of the time we don't need to create those strings which create an alloc per entry.	3 years ago
Ed Welch	45caba4459	Loki: Remove the bypass for "limited" queries (#7510 ) What this PR does / why we need it: Limited queries are queries which don't have a filter expression. Now all log queries will be handled by the LogFilterTripperware which will result in them being split by time (they previously were not) Signed-off-by: Edward Welch <edward.welch@grafana.com> Which issue(s) this PR fixes: We've found that very large timeframe `limited` queries will be sent to queriers and then ingesters and can stall out the read path because of the large time ranges. Splitting these by time avoids this problem by keeping any subquery limited in length to the `split_by_interval`. It's important to note that this will likely increase some extra work done by limited queries as more work for these will be parallelized and can result in extra data being processed. This will be the same as how filter queries are handled now, so it will be no worse than that. In fact this was an optimization based on the premise that it's advantageous not to split/shard limited queries but we are seeing this not be the case when limited queries are run over very large time ranges matching streams with huge volumes and combined with parsers like `\| json` Special notes for your reviewer: Checklist - [ ] Reviewed the `CONTRIBUTING.md` guide - [ ] Documentation added - [x] Tests updated - [x] `CHANGELOG.md` updated - [ ] Changes that require user attention or interaction to upgrade are documented in `docs/sources/upgrading/_index.md` Signed-off-by: Edward Welch <edward.welch@grafana.com>	3 years ago
Sandeep Sukhani	bb2927172a	tsdb post compaction cleanup (#7502 ) What this PR does / why we need it: Previously when we were reading the whole tsdb index in memory, there was not much cleanup required after we were done with the index. Now that we are mmaping the tsdb index, we need to close the mmap. I had missed calling `index.Close()` on the compacted-away multi-tenant index. This causes the compactor to retain the files on disk, leading to the compactor running away from disk space. This PR takes care of it. While doing the changes, I noticed that some of the tests failed due to `LabelValues` tsdb implementation returning strings valid only until the underlying byte slice stays valid. Since the underlying byte slice could become invalid when we close the tsdb, we should return a copy instead of yolostring. This can also happen on the query path when a sync closes the index before we get to return the response. This PR also fixes that.	3 years ago
Ed Welch	23cc448881	Loki: log when a query starts in the logql engine (#7469 ) Signed-off-by: Edward Welch <edward.welch@grafana.com> What this PR does / why we need it: There are cases where a query cannot finish (OOM of a querier/ruler) and most of our logs are emitted upon completion of a query. This can help us find queries which are OOM crashing a component. Note: It only covers queries executed by the engine, so only instant and range queries. Another PR will be necessary to cover labels/series endpoints. However this approach seemed the best to be able to get this information from ruler executed queries. Which issue(s) this PR fixes: Fixes #<issue number> Special notes for your reviewer: Checklist - [ ] Reviewed the `CONTRIBUTING.md` guide - [ ] Documentation added - [ ] Tests updated - [ ] `CHANGELOG.md` updated - [ ] Changes that require user attention or interaction to upgrade are documented in `docs/sources/upgrading/_index.md` Signed-off-by: Edward Welch <edward.welch@grafana.com>	3 years ago
Owen Diehl	70f6bf2e45	Index gw lock bugfix (#7497 ) While I'm still in favor of a longer refactor to address the complexity described in https://github.com/grafana/loki/pull/7490, I'm opening this PR as a shorter, more immediate alternative that should fix the deadlocks. This also reduces the number of total lock calls in many cases as we lock to act over entire groups rather than individual items.	3 years ago
Travis Patterson	45d59ba571	Improve rate store refresh latency (#7492 ) Rather than iterating streams and getting rates per stream, keep all necessary information in the rate calculator and just hand back the current rates when asked. This change took p99 latencies from ~1.8s to ~400ms and p50 latences from ~1s to 6ms.	3 years ago
Travis Patterson	b4ed595461	Remove groupcache (#7126 ) As discussed during the caching retro, this PR removes the experimental distributed cache based on Mailgun's fork of groupcache. Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com> Co-authored-by: Kaviraj <kavirajkanagaraj@gmail.com>	3 years ago
Dylan Guedes	da5378c927	Loki: Remove RatelimitedStream proto (#7235 ) What this PR does / why we need it: Remove an unused proto (RateLimitedStream). It was only used for an older approach to deal with rate-limited streams but since we changed approaches this isn't necessary anymore.	3 years ago
Mohamed-Amine Bouqsimi	7debe7c235	Ruler: enable Loki to configure Alertmanagers per tenant (#7359 )	3 years ago
Dylan Guedes	28e192f22e	Loki: Implement random entries assignment when sharding (#7427 ) What this PR does / why we need it: Modify sharding to assign random shards when the number of shards is bigger than the number of entries. This helps us to avoid hot-spotting the first shards. By randomizing the entries assignment we help spread the load between all shards.	3 years ago
Pablo	5f665651d5	Promtail: Add basic tracing support (#7414 ) We've been using Promtail's HTTP/gRPC server-based targets with real workloads for some weeks now. The server that these spin out is based on [weaveworks commons](https://github.com/weaveworks/common) HTTP/gRPC servers. These include by default some middlewares that if enabled, inject tracing support. We found this useful when tracking down request handling time, or even more, if the caller also support Jaeger tracing support, cross-correlated requests between the upstream server and Promtail's. This PR adds support for enabling tracing the same way Loki does. At the moment, this will just generate traces for the before-mentioned targets. In the future, the quality and completeness of tracing support can grow organically to enrich spans.	3 years ago
Robert Fratto	2208ea7147	Update Prometheus dependency to latest release (v2.39.1) (#7425 )	3 years ago
Periklis Tsirakidis	4176de17d1	Add compactor delete client tls client config (#7426 )	3 years ago
Periklis Tsirakidis	26d2989086	Expose ring and memberlist handlers through internal server listener (#7436 )	3 years ago
Travis Patterson	c1bccac141	Results cache fix improvements (#7444 ) Move middleware to someplace more sensible and incorporate feedback missed in the review for this.	3 years ago
Owen Diehl	b59277b472	Revert "Revert "Update Thanos dependency to latest version"" (#7372 ) Reverts grafana/loki#7371 PR re re-enable Thanos dependency bump.	3 years ago
Travis Patterson	f2297d3d2a	Fix result cache misses on sharded queries (#7429 ) Headers weren't being propagated from query responses on sharded queries causing result cache misses. This PR: - Adds headers to `logproto.Result` so we can save response headers as they come back from queries - Metric-query results are turned into numbers well away from where responses are sent to the frontend: save all headers in the context so they can be pulled out when the final result is calculated - Propagate headers in the final responses	3 years ago
李国忠	8dcc4b3ec8	Do not log 'unable to read rules directory' at startup if directory hasn't been created yet (#7434 )	3 years ago
Periklis Tsirakidis	9c8a827576	Fix enable of internal server for modules (#7423 ) What this PR does / why we need it: Makes adding the internal server modules to the module map more robust. The previous implementation accidentally dropped other modules. Which issue(s) this PR fixes: Fixes #<issue number> Special notes for your reviewer: Checklist - [x] Reviewed the `CONTRIBUTING.md` guide - [ ] Documentation added - [x] Tests updated - [ ] `CHANGELOG.md` updated - [ ] Changes that require user attention or interaction to upgrade are documented in `docs/sources/upgrading/_index.md`	3 years ago
李国忠	435c055488	log panic full stack in boltdb recover block (#7410 )	3 years ago
Travis Patterson	8c84ee8b7a	Fix stream sharding (#7393 ) Promtail doesn't add a stream hash to push requests. As a result, we weren't accounting for the current rate in our sharding calculation and only sharding on individual large pushes. This PR ensures that streams have a hash as they're ingested. It also add a couple of metrics that were useful in debugging this issue.	3 years ago
Danny Kopping	33bf36aa21	Promtail: flush logs on exit (#7400 ) Promtail is using the line-buffered logger (https://github.com/grafana/loki/pull/6954), and log messages were not being printed on exit	3 years ago
Travis Patterson	543ea78b7a	Add metrics to the distributor about stream sharding (#7390 ) This PR adds some more metrics to the steam sharding interactions from the Distributor. 1. `rate_store_stream_count`: The total number of streams 2. `rate_store_max_stream_shard_count`: The stream with the largest number of shards 3. `rate_store_max_stream_rate_bytes`: The largest stream seen by a distributor 4. `rate_store_refresh_duration_seconds`: A histogram of the latency to query all the ingesters and process their rates	3 years ago
Travis Patterson	5dc27e8064	Fix Flaky Distributor Test (#7391 ) Use eventually for async tests	3 years ago
Travis Patterson	3e7adb2c34	Measure Per-Stream rates (#7370 ) This PR implements the ability for ingesters to measure per-stream rates at 1/s resolution. It also fixes bugs in the kind of Limits used in the RateStore and the Ingester API	3 years ago
Dennis Szczepanski	4e61c60296	Loki: Renames metric 'loki_log_messages_total' to 'loki_internal_log_messages_total' (#7361 ) What this PR does / why we need it: Renames the metric 'loki_log_messages_total' to a more descriptive name. Keeps and deprecates the previously existing metric to not break functionality. Which issue(s) this PR fixes: Fixes #7088 Special notes for your reviewer: Checklist - [x] Reviewed the `CONTRIBUTING.md` guide - [x] Documentation added - [x] Tests updated - [x] `CHANGELOG.md` updated - [x] Changes that require user attention or interaction to upgrade are documented in `docs/sources/upgrading/_index.md`	3 years ago
Bryan Boreham	74d206bf28	chunks: improve readability of compression benchmarks (#7246 ) What this PR does / why we need it: ### BenchmarkWrite Use Go runtime facilities to report MB/s for each operation and compression ratio. Before: ``` BenchmarkWrite/ordered-none-4 1018 1104885 ns/op 1431962 B/op 33 allocs/op BenchmarkWrite/ordered-gzip-4 12 87333201 ns/op 3516699 B/op 696 allocs/op BenchmarkWrite/ordered-lz4-64k-4 51 21483048 ns/op 3095117 B/op 649 allocs/op ``` After: ``` BenchmarkWrite/ordered-none-4 841 1202007 ns/op 1054353.53 MB/s 101.9 %compressed 1569953 B/op 34 allocs/op BenchmarkWrite/ordered-gzip-4 13 86299699 ns/op 3357.25 MB/s 6.891 %compressed 3778896 B/op 702 allocs/op BenchmarkWrite/ordered-lz4-64k-4 49 22332214 ns/op 34107.61 MB/s 9.880 %compressed 3407522 B/op 661 allocs/op ``` Stop collecting all compressed chunks, as this blows up the memory of the benchmark and creates unrealistic test conditions for the later encoding. Before: `4724260 maxresident KB`; after: `375804 maxresident KB` ### BenchmarkRead Replace reporting of MB/s which gave several values for each encoding as Go hunted for the right number of benchmark iterations. Add stats to the context for decoding, otherwise a new stats object is created each time round the loop. Re-order so all unsampled results come before all sampled results. Before: ``` BenchmarkRead/none_66_kB-4 278 4555157 ns/op 131744 B/op 717 allocs/op BenchmarkRead/sample_none_66_kB-4 142 8238861 ns/op 129771 B/op 717 allocs/op BenchmarkRead/gzip_66_kB-4 6 179445187 ns/op 2100498 B/op 15010 allocs/op BenchmarkRead/sample_gzip_66_kB-4 4 261040057 ns/op 2076030 B/op 15028 allocs/op BenchmarkRead/lz4-64k_66_kB-4 19 62855240 ns/op 1722979 B/op 14219 allocs/op BenchmarkRead/sample_lz4-64k_66_kB-4 10 115577796 ns/op 1706040 B/op 14220 allocs/op BenchmarkRead/lz4-256k_66_kB-4 18 66144317 ns/op 1880851 B/op 15078 allocs/op BenchmarkRead/sample_lz4-256k_66_kB-4 9 118405993 ns/op 1800396 B/op 15077 allocs/op BenchmarkRead/lz4-1M_66_kB-4 18 67832189 ns/op 1821806 B/op 15076 allocs/op ... none_524 kB: 1828.92 MB/s none_524 kB: 1809.33 MB/s none_262 kB: 1790.79 MB/s none_66 kB: 1673.84 MB/s ... gzip_66 kB: 647.35 MB/s ... ``` After: ``` BenchmarkRead/none_66_kB-4 286 4377585 ns/op 1725.23 MB/s 41896 B/op 600 allocs/op BenchmarkRead/gzip_66_kB-4 6 180770638 ns/op 655.82 MB/s 723426 B/op 13265 allocs/op BenchmarkRead/lz4-64k_66_kB-4 19 65380524 ns/op 1296.10 MB/s 727571 B/op 12925 allocs/op BenchmarkRead/lz4-256k_66_kB-4 16 63737292 ns/op 1409.75 MB/s 786994 B/op 13707 allocs/op BenchmarkRead/lz4-1M_66_kB-4 18 65963825 ns/op 1362.17 MB/s 770441 B/op 13707 allocs/op BenchmarkRead/lz4_66_kB-4 18 64955415 ns/op 1383.31 MB/s 1003277 B/op 13707 allocs/op BenchmarkRead/snappy_66_kB-4 20 51588959 ns/op 1273.38 MB/s 361872 B/op 5020 allocs/op BenchmarkRead/flate_66_kB-4 6 172147502 ns/op 691.74 MB/s 715706 B/op 13242 allocs/op BenchmarkRead/zstd_66_kB-4 3 359473273 ns/op 390.07 MB/s 427247248 B/op 18551 allocs/op ... BenchmarkRead/sample_none_66_kB-4 135 8533283 ns/op 885.04 MB/s 39866 B/op 600 allocs/op BenchmarkRead/sample_gzip_66_kB-4 5 243016949 ns/op 487.84 MB/s 686358 B/op 13212 allocs/op BenchmarkRead/sample_lz4-64k_66_kB-4 10 114330032 ns/op 741.18 MB/s 707104 B/op 12926 allocs/op BenchmarkRead/sample_lz4-256k_66_kB-4 9 117294928 ns/op 766.05 MB/s 778461 B/op 13709 allocs/op ... ``` Note "MB" in previous code was 2^^20 while Go uses 10^6. Checklist - [x] Reviewed the `CONTRIBUTING.md` guide - NA Documentation added - [x] Tests updated - NA `CHANGELOG.md` updated - not user-facing - NA Changes that require user attention or interaction to upgrade are documented in `docs/sources/upgrading/_index.md`	3 years ago
Sandeep Sukhani	18da26e668	use a channel to signal completion of index read operation for tsdb and boltdb shipper (#7381 ) What this PR does / why we need it: In PR #7367, I was relying on cancellation of context to detect if the index read operation has finished or not, but it is error prone since a cancelled or timed-out query could cancel the context while we are still reading the index. Since `tsdb` doesn't can't check the context for each read operation, we could still panic in this scenario. I am adding a channel where the consumer of the index would explicitly signal the completion of the read operation to the `indexshipper` Checklist - [x] Tests updated	3 years ago
Owen Diehl	8331785a23	Revert "Update Thanos dependency to latest version" (#7371 ) Reverts grafana/loki#7348 I expect we'll merge this again in the future, but we'll need some more time for downstream projects to be ready for this change.	3 years ago
Sandeep Sukhani	bbe68802d1	lock boltdb and tsdb index while queries are in process (#7367 ) What this PR does / why we need it: We noticed ingesters and index-gateways panicking when using `tsdb` as an index store with the latest build. This is caused by closing `mmap` while the index queries are still being processed. This PR takes care of it by locking the index until we are done querying the index. Checklist - [x] Tests updated	3 years ago
Owen Diehl	f4e2cf1993	TSDB explicit fingerprint (#7362 ) This PR does two things: * Includes the series fingerprint in TSDB WALs. Doing this ensures we recover fingerprint used in chunk addresses after restart even if loki is upgraded and the label hashing algorithm changes. * Removes much of the extra hashing in the TSDB write path + manager. Occasionally, the fingerprint may be different than the hash of labels. Historically this has happened in a few places: * When the `__name__="logs"` label was injected for non-tsdb indices (not applicable to TSDB) * When building a multitenant tsdb index and adding a synthetic `__loki_tenant__` label * In a previous bug(https://github.com/grafana/loki/pull/7355) when empty label values altered calculated fingerprints. Explicitly storing/retrieving the desired fingerprint throughout helps avoid calculating it in error.	3 years ago
Travis Patterson	7979cfbe07	Implement Distributor Rate Store (#7349 ) The `RateStore` concurrently queries all ingester `GetStreamRate` APIs and stores the results. `RateStore` deduplicates replicas and combines sharded streams so a caller of `RateFor` gets an unsharded view of a stream's rate.	3 years ago
Travis Patterson	e89c30ce6b	Fix Flaky Integration Tests (#7360 ) Allow the OS kernel to decide what's an open port instead of trying to guess	3 years ago
Owen Diehl	289190ee26	removes unused tsdb files (#7353 ) These were introduced in an earlier revision of the TSDB work, but are unused now.	3 years ago
Owen Diehl	eaa0919e53	Use labelbuilder in syntax.ParseLabels to remove empty label values (#7355 ) There's a bug in TSDB where empty label values alter the series fingerprints used in chunk addresses, but are stripped out and create different fingerprints in our TSDB based index. I plan to open a PR to Prometheus, but I also prefer normalizing labels here by removing empty label values. According to [Prometheus](https://prometheus.io/docs/concepts/data_model/), > A label with an empty label value is considered equivalent to a label that does not exist. Our bug comes from the Prometheus model `LabelBuilder` stripping out empty label values, [here](https://github.com/grafana/loki/blob/main/vendor/github.com/prometheus/prometheus/model/labels/labels.go#L419-L423). This means that `Labels.NewBuilder({job="foo",bar=""}) => {job="foo"}`. The [labels.Hash()](https://github.com/grafana/loki/blob/main/vendor/github.com/prometheus/prometheus/model/labels/labels.go#L136-L182) function does not skip empty label values, meaning it's easy to end up with different fingerprints for effectively the same series (an empty label value is supposed to be equivalent to a missing label in prometheus, but they generate different label hashes).	3 years ago
Robert Fratto	c657857e95	Update Thanos dependency to latest version (#7348 )	3 years ago
Dylan Guedes	b1d4efab12	Loki: Per-tenant stream sharding (#7311 ) What this PR does / why we need it: - Move stream sharding configuration to its own package to avoid cyclic imports - Change stream sharding to be a per-tenant configuration - Change ingesters to reject whole streams due to rate-limit based on per-tenant stream sharding - Change stream sharding flags prefix from `distributor.shard-stream` to `shard-stream`	3 years ago
Travis Patterson	e3e4e27c8c	Implement ingester API to return stream rates (#7176 ) This PR introduces an API on the Ingester that reports all current streams in memory and their current rate in bytes/second. The reponse from the API contains a slice of `StreamRate` structs: ```go type StreamRate struct { StreamHash uint64 `protobuf:"varint,1,opt,name=streamHash,proto3" json:"streamHash,omitempty"` StreamHashNoShard uint64 `protobuf:"varint,2,opt,name=streamHashNoShard,proto3" json:"streamHashNoShard,omitempty"` Rate int64 `protobuf:"varint,3,opt,name=rate,proto3" json:"rate,omitempty"` } ``` In the interest of space on the caller and in transmission, only hashes and rates are sent. - `StreamHash` will be used to deduplicate replicas - `StreamHashNoShard` will be used to aggregate a sharded stream's total rate. Co-authored-by: Dylan Guedes <djmgguedes@gmail.com>	3 years ago
Dylan Guedes	da7acb49e5	Loki: Add sharding support for negative/zeroed desired rate (#7342 ) What this PR does / why we need it: Adds the handling of negative/zeroed desired rate to our distributor stream sharding. Without this, invalid desired rates results in a -Inf number of shards. This also adds a log line to report that such a thing happened. Signed-off-by: Danny Kopping <danny.kopping@grafana.com> Co-authored-by: Danny Kopping <danny.kopping@grafana.com>	3 years ago
Danny Kopping	c3e92b876c	Restoring lint checks that were previously disabled (#7340 ) I removed these checks in https://github.com/grafana/loki/pull/7337 to not make https://github.com/grafana/loki/pull/7243 overly complex to review. Refactored code to fix valid lint issues, ignored the irrelevant/dangerous ones. I also removed `unused` and `unparam` as these produce low-quality results that are largely useless.	3 years ago
Sandeep Sukhani	10d3fa0029	mmap tsdb index file while opening it for querying (#7338 ) What this PR does / why we need it: In PR #7321, we re-introduced mmap for reading tsdb index, but it does not cover all the paths where we open the index. This PR takes care of it. I have also removed the code for decompressing the index file since we always get a decompressed file from the `indexshipper`.	3 years ago
Danny Kopping	355175ff89	Upgrade to Go 1.19 (#7243 ) Upgrade Loki and all related components to Go 1.19.2.	3 years ago
Periklis Tsirakidis	e9419747c9	Fix internal server bootstrap for query frontend (#7328 ) Adds a fix for setting up the internal server module	3 years ago
Danny Kopping	6bf5b5d8c1	Use a line-buffered logger to deamplify write syscalls (#6954 ) We initialise a global logger in `pkg/util/log/log.go` and use it extensively throughout the Loki codebase. Every time we write a log message, a `write` syscall is invoked. Syscalls are problematic because they transition the process from userspace to kernelspace, which means: - a context-switch is incurred, which is inherently expensive ([1-2 microseconds](https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/)) - the goroutine executing the code is blocked - the underlying OS thread (_M_ in the go scheduler model) is also blocked - the goroutine has to be rescheduled once the syscall exits - the go scheduler may need to spawn additional OS threads if all are blocked in syscalls - which can also be expensive This change introduces the use of a line-buffered logger. It has a buffer of [256](https://gist.github.com/dannykopping/0704db32c0b08751d1d2494efaa734c2) entries, and once that buffer is filled it will flush to disk. However, a situation will arise in which that buffer remains somewhat empty for a period of time, so there is a periodic flush mechanism, configured to flush every 100ms. There is also a preallocated bytes slice of 10MB which is reused, to avoid excessive slice resizing & garbage collection. This does mean that we could lose up to 256 log messages in case of an ungraceful termination of the process, but this would need to be precisely timed within the 100ms flushes - in other words, the likelihood is low, and generally we shouldn't `kill -9` any Loki process.	3 years ago
Florian Lehner	4861914c81	pkg/ruler/rulestore/configdb: Preallocate memory (#7326 ) Preallocate memory instead of enforcing an incremental growth. This will result in less work for the garbage collector.	3 years ago
Owen Diehl	044d06015d	adds result cache key version comparison metrics (#7323 ) Followup to https://github.com/grafana/loki/pull/7300 which gives more metric visibility into the underlying errors when comparing cache key versions on the queriers vs query frontends.	3 years ago
Owen Diehl	2bfe626605	reintroduce mmap for tsdb indices (#7321 ) This reverts a [previous decision](`b45efd4c2d (diff-e3f5966d58063d2852aa51899b5aae14e65bb05f29fec7302eb982c3d18c60ab)`) which removed `mmap` support when loading TSDB indices. I did this primarily for simplicity, but since then have reneged on my original choice for two reasons: 1) Retention in Loki is variable and can be very long. Requiring we keep all loaded tsdb indices in memory creates a cost burden in terms of memory required to hold all queried indices at once. 2) A high number of tenants also exacerbates the memory claims which mmap helps alleviate.	3 years ago
Owen Diehl	2bd9c91564	Bugfix include cache generations on querier response (#7300 ) We check the cache number (incremented by deletes) after executing a query with the value returned by the queriers which executed it. If they’re different, we know we can’t safely cache. However, we’re never actually returning a number from the queriers. This means that as soon as this cache number is incremented by a delete, it’ll disable the results cache for that tenant completely. I suspect this has been a latent bug since we forked cortex (goes back to missing some code from this [PR](https://github.com/cortexproject/cortex/pull/2279) into cortex from @sandeepsukhani back in the day!). It just showed itself once we started using deletes.	3 years ago
wilfriedroset	8886800bf6	Add support for username to redis cache configuration (#7270 ) What this PR does / why we need it: Add support for username to redis cache configuration Which issue(s) this PR fixes: Fixes #<issue number> Special notes for your reviewer: Checklist - [x] Reviewed the `CONTRIBUTING.md` guide - [x] Documentation added - [ ] Tests updated - [x] `CHANGELOG.md` updated - [ ] Changes that require user attention or interaction to upgrade are documented in `docs/sources/upgrading/_index.md` Signed-off-by: Wilfried Roset <wilfriedroset@users.noreply.github.com>	3 years ago

1 2 3 4 5 ...

1778 Commits (b523ff336e91e1e8a607073551b8a3525b6ba917)