Hi, On Thu, 18 Jul 2013 14:09:43 +0000 Marvin Nipper <[email protected]> wrote:
> Is there any simple way to test the viability of a supposed date-time > string, before attempting to use the parsedate function to convert it? > I'm attempting to avoid the overhead of some complex regex comparison (on > every log line) simply to look for potential garbage lines. Not that I'm aware of currently. > The problem > being that if I grab what I expect to be a date, at the beginning of the > log line, and then feed it to parsedate, the parsedate operation > (sometimes) fails, and all of the other lines behind it also fail (some > of which are involved in reformatting the output). I think a possible alternative would be to modify parsedate() to return an undef value in case of failure instead of barking and bailing out. The user could then check manually whether it succeeded or not. This would be pretty easy to fix. > Part of the issue with the above is that one might suggest breaking the > code snippets into multiple Exec blocks, but the current Exec block > starts by using drop() to kill off commented header lines in the logs, so > the rest of the existing code is all in an Else leg (within that Exec > block). And obviously, secondary Exec blocks, that follow a drop(), end > up generating other errors. Anyway, I had simply that that maybe there > was an "efficient" test that I'd missed. The drop() procedure has been a pain because of this behavior. There are intentions to modify this so that the execution is aborted altogether after a drop() without the need to put anything after that into an "else" block. There could be a drop_but_continue() for the rare cases when the user really wants to do something after the drop which does not deal with the log data. > Different question. I see that datetime's are stored in UTC, but I also > see that now() returns the TZ-adjusted value. Is there a way to ask for > the current time, in UTC (e.g. to easily "substitute that value" for log > file UTC date/time stamps that are corrupted)? now() returns a datetime type which is internally in UTC. What you probably see is this value converted to string, e.g. string(now()) or log_info(now()). When nxlog converts a datetime type to a string, it uses the local time without timezone information. There is strftime() to format a string representation of a datetime in any way you like. Unfortunately this function does not work uniformly across all systems, e.g. on windows the %z and %Z modifiers can produce funny output. Since this is again microsoft's standard compliance (linux/unix users should have no problem), we have no choice but to implement our own formatter function which could produce some well-known date formats (ISO6801 in localtime and UTC with timezone, RFC3339, and such). This would be another worthy addition to a future nxlog release. There was a similar thread earlier: https://sourceforge.net/mailarchive/message.php?msg_id=29535795 Regards, Botond ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ nxlog-ce-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nxlog-ce-users
