I love level 5 logs .... ;o)
"Not sure if Symantec Support staff have tools to read/analyse logs"
Yes, it is called a BackLine Engineer .... he he he ...
More seriously, yes and no.
The best tools for looking at logs are textpad and unix awk, oh, and I hate to say it but experience.
There are no magic tools, support have an internal only tool that helps when looking through the IRM logs (pem, jm, rb, emm) , but this is really the only script that I know of.
Legacy logs (found in /usr/openv/volmgr/debug and /usr/openv/netbackup/logs ) are fairly easy to read as they are single threaded. Quite conveniently, if you have an error you quite often have a <16> on the line.
Unfortunately easy to read does not mean 'easy to find the problem', just that it is easy to pull out the lines that refer to 'whatever' part of the job, as the lines will all have the same PID.
For support, most of us just get them at verbose 5 ( + general 2 if windows) although sometimes overkill, this ensures we definately have the details we need and avoids having to get the logs again, if we make a mistake and request them too low.
The lines contain a process ID, and as single threaded, if you pull out the lines with the same process id, you often have the details you need. There may be a child process, with a different PID, but quite often the parent process gives the PID of the child.
The best two tools for legacy logs are the unix 'awk' command and /or the program 'textpad' which can be purchasd for about $25.
How good is textpad, well, Symantec have a license to use it. It was once described to me as almost being written to read Netbackup logs.
If you are good with Unix awk, this can be good for pulling bit's out of logs, and other outputs from NBU commands.
You could also do simple things like a small unix script to automatically pull out all the lines for the different PIDs in a legacy log and place in a sepaare files - this could save vast amounts of time, and just makes things less stressful.
VX/ Unified logs are a nightmare because they are multi-threaded, as it happened I wrote some details about these the other day in another post which I have copied here.
vx logs are very difficult to read, because they are multithreaded. From example, if we look in say the bptm log (not a vx log and single threaded) you can read it like a book.
[1234] xxxx
[1234] xxxx
[1234] xxxx
[1244] yyyy
[1244] yyyy
[1244] yyyy
Where xxxx and yyyy are lines relating to a particular 'activity'
So if I search all the lines containing a given 'PID' (shown in [xxx] ) then those lines relate to a single activity, eg. mounting a tape.
With VX logs the PID (process ID ) is shown, and TID (Thread ID)
nbemm 111 PID:20454 TID:6
The problem, is that if xxx and yyy are lines relating to a particular activity ...
nbemm 111 PID:20454 TID:6 xxxx
nbemm 111 PID:20454 TID:6 yyyy
nbemm 111 PID:20454 TID:7 xxxx
One second, TID 6 could be dealing with the 'activity', the next moment, TID 6 is dealing with some other activity (yyyy) and TID 7 has taken over 'xxxx'.
That means if I search for all the TID 6 lines, I get multiple lines returned that could have nothing to do with each other,
Unfortunately, NBU is too complex for any one person to know exactly what the logs lines will be for every possibly thing NBU can do ... therefore the only way to read these logs:
1/ You need to know what NBU will do next and to be able to find the next line in the sequence.
or
2/ Run the job on a working machine and compare the logs line by line to spot the differencies.
Generally, I use both 1/ and 2/ when reading these logs. For something 'simple' like a backup, I know the main steps thet appear in the logs, so I canfind one line and then look for the next.
For example, NBPEM will start a backup ,and then submit the job to nbjm
So, I find the line in nbpem that shows the job starting, and I then know that the next line I have to look for is where nbpem gos to contact nbjm, which may, or may not be the same TID).
But...
If I have an issue I have never seen before, I have no idea what the logs should be showing, I then usually run the job on a working system to get the logs, and then compare these to the non-working logs.
With legacy logs (bptm etc ...) we don't have this issue, you can just spearate the logs out by searching for the individual PIDs.
Regards,
martin
