Description
Group adjacent log source observations with original run indexes and first/last timestamps; no sorting or clock monotonicity assumptions.
Structured log records need an explicit ordering, time unit and label convention. A sequence gap can be measured in supplied record order without proving loss, and grouping adjacent messages differs from grouping all equal messages. The record tools here operate on caller-supplied structured data rather than collecting logs.
Group adjacent log source observations with original run indexes and first/last timestamps; no sorting or clock monotonicity assumptions.
When to use this tool
Use this tool to group adjacent log source observations with original run indexes and first/last timestamps; no sorting or clock monotonicity assumptions.
How to use the tool and how it works
- Enter recordsJson using the field definitions below. For JSON text, serialize the explicit records in the shown shape.
- Run the operation. Correct input errors before interpreting an output.
- Read result.runs. Use the ordering, boundary rules and absence conditions described below.
Group adjacent records with the same exact source and return half-open record spans plus each run’s first and last stored times.1
| Input field | Meaning and units | Accepted input |
|---|---|---|
| recordsJson | JSON array of {id, time, source, level, message, sequence} records. Time and gap units are caller-defined; sequence is a nonnegative integer. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
These are the decoded structures used in the example’s JSON text fields. Supply the corresponding serialized JSON strings as input.
{
"recordsJson": [
{
"id": "a",
"time": 1,
"source": "s",
"level": "info",
"message": "x",
"sequence": 1
},
{
"id": "b",
"time": 3,
"source": "s",
"level": "info",
"message": "x",
"sequence": 3
}
]
}| Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.runs | Adjacent source runs with half-open record spans and stored endpoint times. |
{
"input": {
"recordsJson": "[{\"id\": \"a\", \"time\": 1, \"source\": \"s\", \"level\": \"info\", \"message\": \"x\", \"sequence\": 1}, {\"id\": \"b\", \"time\": 3, \"source\": \"s\", \"level\": \"info\", \"message\": \"x\", \"sequence\": 3}]"
},
"output": {
"result": {
"runs": [
{
"key": "s",
"start": 0,
"end": 2,
"firstTime": 1,
"lastTime": 3
}
]
}
}
}Limitations and assumptions
- Separated runs of the same source remain separate; firstTime and lastTime are not computed minima and maxima.
- Structured log records have id, time, source, level, message and sequence fields. time is a finite caller-defined numeric scale; sequence is an integer from 0 through 1,000,000,000,000. Use the same time units for windows and gap edges.
- Every declared top-level input field is required and unexpected fields are rejected. Ordinary strings are limited to 8,192 UTF-16 code units and lists to 128 entries, with tighter operation-specific bounds where stated. JSON text has bounded nesting and node counts.
- Numeric outputs must be finite and no larger in absolute magnitude than the safe-integer limit; operations returning exact large integers use decimal text. Positions are zero-based and spans end exclusively unless the operation explicitly states a different convention.
Alternative or Complementary methods
Keep original record order and provenance alongside summaries. Sort, partition by source or normalize aliases explicitly before applying a rule that depends on those choices.
References
Similar or alternative tools
- Log Level Order Selector
Select supplied severity tokens at or above an explicit least-to-most ordered level bank; retain unknown tokens instead of assuming rank.
- Log Level Token Normalizer
Normalize a log-level token through explicit caller aliases with cycle/path evidence; no universal severity vocabulary.