design doc/ordering constraint removal #3268
Conversation
|
Should file name be |
|
|
||
| In order to mitigate this, there are a few options (not mutually exclusive): | ||
| 1) Lower the valid acceptance range | ||
| 2) Create an _active_ validity window, such as `[most_recent_sample-max_chunk_age, now() + creation_grace_period]`. |
There was a problem hiding this comment.
Could someone work around this by ingesting samples in decreasing order of timestamp?
But I think this is a good enough approach for now without adding a lot of complexity.
|
Addresses #1544 |
| 2) Create an _active_ validity window, such as `[most_recent_sample-max_chunk_age, now() + creation_grace_period]`. | ||
|
|
||
| The first option is simple, already available, and likely somewhat reasonable. | ||
| The second is simple to implement and an effective way to ensure Loki can ingest unordered logs but maintain a sliding validity window. I expect this to cover nearly all reasonable use cases and effectively mitigate bad actors. |
There was a problem hiding this comment.
We should do that. If we don't restraint the boundary of a chunks, it will appear too often for queries and will lead to bad performance.
As of today the only way to have overlapping time between chunk of the same stream is replication. I believe this won't be true anymore. (Not a big problem just a statement.)
There was a problem hiding this comment.
Yes, I fully intend to use the second strategy here to slowly cinch the validity window. This will allow relatively out of order writes while preventing bad actors from writing samples i.e. one week apart over and over.
|
It would be really useful to have this implemented. Currently Loki is limited to use cases where log sources guarantee time stamp ordering. |
|
This would be a game changer as far as allowing Loki to fit into complex log aggregation scenarios. We've had to break our |
|
Intending to work on this as soon as scheduling permits 🎉 |
This contains a proposed design doc for removing the ordering constraint in Loki.