Make sense of your GLF logs by converting them to meaningful tables.

Problem:

Extract structured data from semi-structured logs.

Now you can do it in seconds.

Solution:

Filter logs by text, severity, importance... (GLF record has 36 fields).

Don’t know what to filter? Just check available values.

Still not sure? Check the cheat sheet or just filter, for example, for lines that have numbers and then narrow down.

Or filter by error severity and check their frequency to start working on the most frequent one.

Extract useful data (durations, number of rows, user names, report names, …) from filtered lines in one or several columns, just by using regular expressions.

Analyze results in place: sort, count, summary, jump back to tree structure to get a detailed or short stack trace, visualize duration distribution between hosts/processes/threads/… or export to Excel.

Example:

WEBI refresh.

E2E (end-to-end) GLF log set for 38k lines if you know how to filter them from potentially millions, but BiWhy will do it for you.

E2E duration: 306 seconds.

JAVA/HANA execute: 409 calls, sum time: 77.8 sec.

JAVA/HANA fetch: 409 calls, sum time: 110.3 sec.

We already see where the problem is. No need to be an expert in GLF logs reading to find it.

Can you find it manually in a reasonable time? Even knowing where to look, when the longest call is just 5sec?

Just cherry on the top:

Fetched rows: 1,225 with 245 trips

JAR Search

There are several reasons you might need to know from which JAR(s) file class is loaded.

Now it is quick and easy with BiWhy.

Problem:

There is a leftover from a private fix or previous version causing problems in the current version.

A frequent cause for this is an old file renamed as original_backup.jar

DON’T do this! Change extension instead, for example: original.jar_backup

JAVA is not looking for JARs by their names unless they are listed in MANIFEST.

It loads everything from CLASS_PATHs till it finds the class it needs.

original_balckup.jar is still a valid JAR file; if it is anywhere in CLASS_PATH, for example, next to original.jar, the class will be loaded from the first JAR that JAVA has found.

The process is not deterministic, so next time it might be loaded from another JAR, or different class loaders might load it from different JARs files.

As a result, we might have an assortment of problems, including intermittent.

Solution:

With BiWhy, you can quickly index your JARs.

Search multiple times in results with instant response.

Save, reopen index results or send them to remote support.

Index performance (whole BOBJ installation folder) test: ~2min on small sandbox (depends on the number of CPUs and disk).

WER (Windows Error Reporting)

When troubleshooting intermittent or stability issues and not checking WER is like leaving money on the table.

https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps

Problem:

Collect WER files (3-4 typical locations) from BOBJ nodes (could be dozens).

Too much work.

Trade-off – collect samples from each tier (CMS DB, Audit DB, CMS node, Production node, Web node), multiply by locations, still 5*~4=~20

Ok, WER does not that often give helpful information, so maybe check CMS DB or just one CMS node or Production node, depending on the problem.

Let’s collect WERs from one node, and we have, well… 50 folders!

Solution:

BiWhy will collect WERs from all machines (with logs, configurations, and other desired files, filtered by file type and timestamp) and give you an excellent summary with just a few clicks.

Have you found a helpful lead? Good!

Haven’t? You spent only a few minutes and can continue with calm in your heart troubleshooting with other approaches.