cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Log4j Log File Viewer

BjoernRueegg
17-Peridot

Log4j Log File Viewer

Hi there

What kind of log viewer do you use for programming and monitoring (without System Monitor) Windchill? I'm using LogExpert and I'm happy with it but I'm pretty sure, there are some better ones around.

One more question is, how do you open the methodserver logs? Because they contain the PID number after every Windchill restart, the log name changes. I know, that you can rename the log-files, but if you have multiple method servers, it's not recommended to redirect everything into one file.

Thanks for any tips

Björn

10 REPLIES 10
jessh
5-Regular Member
(To:BjoernRueegg)

A couple of suggestions:

  1. For a low-level file viewing approach, use wtcore/jsp/jmx/logFiles.jsp (Site -> Utilities -> Server Status -> Monitoring Tools -> Log File Viewer) to browse and search Windchill and Apache log files.
  2. For a higher-level log-event viewing approach, use wtcore/jsp/jmx/logEvents.jsp (SIte -> Utilities -> Server Status -> Monitoring Tools -> Persisted Log Events) to view (warning and error) log events which have been persisted to the database.
    • On a related note, one might check out wtcore/jsp/jmx/logEventsHistogram.jsp (SIte -> Utilities -> Server Status -> Monitoring Tools -> Log Event Histogram), which provides a summary of recent persisted log events by logger, severity, and exception type.

logFiles.jsp and logEvents.jsp both operate across cluster nodes and have existed since Windchill 10.0.

logEvents.jsp also contains links to search log files via logFiles.jsp. These links and other Monitoring Tools links (e.g. from logEventsHistogram.jsp to logEvents.jsp) were recently improved in 10.2 M020.

That's not to say not to use various log4j log viewers. There are some downsides to such viewers, though. For starters, you have to teach them about the PatternLayout used and they then have to parse the logs. Also, they don't necessarily understand following a directory of log files rather than single files with well known names. Finally, they don't understand Windchill clusters -- you have to explicitly configure for each node's log directory. You can get around these by introducing a SocketAppender to send events to a central location, but that's essentially how logEvents.jsp operates already (in conjunction with Windchill's AsyncJDBCAppender).

The persisted log events behind logEvents.jsp (and many of the other Monitoring Tools pages) are stored in non-modeled database tables and should be fairly easy to query.

jessh
5-Regular Member
(To:jessh)

P.S. There's also a Free Form SQL Query page on the Monitoring Tools page that you can configure to enable. There's an article on it somewhere floating around on the tech support site, I believe....

Thanks for the tip.

The Log File viewer seems to be quicker as well.

The regular expresion search in there doesn't seem to support word negation. Is this something known(10.1 M30) or user error ?

jessh
5-Regular Member
(To:NandaPamidi)

Word negation? Can you explain? Are you talking about something more complex like find all lines matching xxxx but not matching yyyy? Or about regular expression features not provided by Java's Pattern class?

The regular expression syntax itself is simply that built into Java (http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html) and is unlikely to change except as Java itself changes (as this would require using another regular expression library). According to the Java documentation:

The Pattern engine performs traditional NFA-based matching with ordered alternation as occurs in Perl 5.

It then goes on to denote a omissions and additions with respect to Perl 5's regular expression feature set.

When used with the regular expression option, the "whole word" and "match case" options simply adjust the regular expression used.

I was trying to find all lines not matching xxxxx. Not simple I guess

I can find all lines matching xxxx or yyyyyy followed by zzzzz using .*(xx|yy).*zz.*

jessh
5-Regular Member
(To:NandaPamidi)

In general I don't know of a good way to do negations within regular expressions themselves.

Certainly we could add something like grep's -v, i.e. find all lines not matching a given expression. That would be easy enough if that's all you're looking for. I'm not sure how useful that would be in practice, though.

Doing anything more complicated, like (expr A matches) and !(expr B matches gets to be messy from a UI perspective.

FYI, the options that are currently present are closely modeled after what I've seen in modern programming IDE's.

Makes sense.

For a cluster install, there is no easy way to search unless we merge logs from different nodes using a 3rd party tool I guess. I was hoping to piggy back on the Log File viewer even if it is from command prompt.

I am using powershell scripting to do some of this. Prior to any search, we need to get the fluff out (echo/ping lines etc..) to get meanuingful results. So grep -v would do it, but messy from UI.

For the job it is doing the log file viewer is fast though !

jessh
5-Regular Member
(To:NandaPamidi)

Well, there are lots of ways of approaching this. You could share the logs directories and have your script address search each and unify the results.

You could look at the JSP source of Log File viewer and do something like it yourself.

Or you could do something substantially different, e.g. use the Dumper MBean's executeScript() operations along with MethodServers MBean broadcast as in the Log File viewer to execute a log file search and collation script on each node. [The script can be in JavaScript or, if you install add another javax.scripting-compatible script engine library, numerous other scripting languages.]

And as far as command-line access, you could do all of this from the command-line, of course, in Java or in a javax.scripting language (try "windchill wt.util.jmx.RunScript" and "windchill wt.util.jmx.RunSMScript"...). This is just done in a JSP to provide easy browser access.

jessh
5-Regular Member
(To:jessh)

P.S. In case it's not clear, one reason all the Monitoring Tools pages in wtcore/jsp/jmx are implements as JSPs with inline Java scriptlets is so that all the source is present for anyone to see.

There are well documented downsides to this approach, of course, but this is an upside -- you can see all the Java calls necessary to do the same thing yourself, whether or not you're in a JSP.

Thanks for all the answers. I do start to like the "online" log file viewers. Unfortunately sometimes it would be easier to have the logfiles tailed open and see what that moment the output is.

Björn

Top Tags