Products | Versions |
---|---|
TIBCO LogLogic Log Management Intelligence | all versions |
shm->currentTime = Wed Mar 2 16:27:12.812918 (1299112032)
and comparing it with the next line:
RTDebug=0 BFQ 0/1571101510 1299112020.1059
These two UNIX timestamps should be separated by no more than a couple minutes with the timestamp on the first line always being a little ahead of the timestamp on the second line, as shown above.
If the timestamp (i.e. cursor) on the 2nd line is increasing (it updates every 30-60 seconds) versus being static but is lagging behind the other timestamp then this means the parser is working but it has fallen behind. And it's possible it's continuing to fall behind.
Ideally, for any given rawdata (not filedata) BFQ file, the amount of time it takes for the LX parser engine to parse the data should be no longer than the timespan of the file. By default BFQ rawdata files span 60 seconds so the LX parser should not take any more than 60 seconds to parse it. If it does take longer and this continues to occur then this will cause the parser to fall further and further behind. If this continues for days without addressing the problem then the parser will eventually be more than a day behind. This will cause a parsed report for the last 24 hours, for example, to not contain any data. Essentially, the further the 2nd timestamp lags behind the top timestamp the more data will be missing from parsed reports.
In some cases the cursor may not be increasing at all. When this occurs the engine_lx_parser process may be running at the moment but is probably repeatedly restarting; this will be noticeable if viewing page 1 of watchqueue for a few minutes. This is evidence there is data in a file that the parser cannot process and it would be causing the parser to crash and restart at the same point in time, thus never moving forward.
The long term solution for when the cursor is falling further and further behind is to contact TIBCO LogLogic Support so we can analyze the LMI appliance to determine the best course of action. Typically, in these situations it's evidence the appliance is collecting more data than is recommended for the appliance model.
If the cursor isn't changing and the parser is repeatedly restarting then contact TIBCO LogLogic Support so we can perform further troubleshooting.
In the short term if the cursor is stuck at some old timestamp, you can move the cursor to any recent timestamp by doing the following steps:
1. vi /loglogic/status/lx_parser.bfq.cursor
2. Delete the UNIX timestamp and add new UNIX timestamp where you want to start parsing.
3. mtask stop; mtask start
4. Check watchqueue screen 2 and see if the parser is parsing data from the new timestamp.
By doing these steps, you can skip parsing data for a given time slice. If the parser is repeatedly restarting there is no guaranteed way of knowing, without further troubleshooting, how far to skip ahead the cursor but typically the next file (about 60 seconds) is sufficient. But the parser could encounter the same type of data again that caused it to get stuck. This is where Support can help identify the data causing the behavior.