1 Reply Latest reply on Sep 7, 2016 12:51 PM by nicole pauls

    LEM nDepth Results vs Result Details


      I'm searching raw log messages using text input mode in the ndepth window.  I put in my search terms, define a time range and send off the search.  When the search completes, the histogram shows some number of results across the time period, and in the Result Details pane I see the log messages.  My issue is that the Histogram result counts never match up to what's displayed in the Result Details.  Is this expected?  What's even more odd to me, is that the result details seems to grab log messages randomly from within the search time range.


      Here's an example:




      This is making it hard to export the full results to a CSV, as the CSV only ever gets the events from Result Details.


      Thanks for your help.

        • Re: LEM nDepth Results vs Result Details
          nicole pauls

          Interesting. The histogram is drawn from index data - basically aggregate counts that are stored separately and contribute to the left and the top panels. Result details is pulled from the actual data stored on disk. The CSV will always match result details, since those are the actual results retrieved for that time frame.


          The question as to why they differ is totally valid, though. One possibility is in cases where LEM couldn't pull the right timestamp it puts them in "current time" as to when they were read, which could make them out of sorts. Unlike with normalized data where we have multiple timestamps, raw data ends up having to trust and store the timestamp from only the log (or time the log was read if one is missing). CiscoFirewalls is NOT usually one of those cases, usually the timestamps there are pretty reliable.


          Another possibility is that the histogram isn't accurately refining data to match your search and is showing more results, but that would be a bug IMHO.


          Log messages doesn't get used as much as normalized search, so you might want to log this as a bug anyway. The assumption that result details should match the histogram is absolutely fair.