-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ts-free records are excluded from span when mixed with time-having points #2088
Comments
We discussed this one as a group today and it seen as a
Likewise, for the case where we simultaneously imported
|
Changes have made it such that this is no longer a problem. Some of the concepts described above are no longer in the software (e.g. "Spaces") but if we up-level, the original symptom of problems when mixing The attached video was taken with Zui commit Verify.mp4Therefore, I'm closing this one as fixed. Thanks @jameskerr! |
A community user spotted this issue while working with logs from the Zeek SPL-SPT package as described in the
join
cookbook (#1430). Repro is with a nightly build based on Brim commit664840a8
.One of the quirks of the SPL-SPT package is that it generates points that lack a
ts
timestamp field. It's for this reason that I used it as an example in thejoin
cookbook, since it's a good candidate for joining to other records that do havets
timestamps. However, not all users will know thatts
-free records currently pose a unique challenge in Brim. They just think of Brim as the app that can handle all Zeek TSV logs you throw at it.What we observed is that if only the spl.log.gz (attached) is dragged into Brim, the time picker defaults to "epoch zero" time and the points show up ok.
However, if we drag that
spl.log.gz
as well as another Zeek log such as conn.log.gz (attached) now the time picker is set to the range of that log and thespl
events effectively become invisible.If I happen to know what's going on and manually set the start point of the time picker to epoch zero, then I get to see them. But I would not expect our users to know about this.
We know we need to do other work to make these kinds of
ts
-free events easier to work with in the app. But since at least one user has already bumped into it, we might want to see if we can take some interim step to reduce the likelihood of users floating it as a bug.The text was updated successfully, but these errors were encountered: