cancel
Showing results for 
Search instead for 
Did you mean: 

Unified logs and legacy logs

V_P_S
Level 4

Hello All,

Can someone plz explain me that what is unified logs and legacy logs..

And what is the diff. between them..

 

An interviewer ask me this question and i am not able to give ans..

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

mph999
Level 6
Employee Accredited

This is some details I posted previously about the problems with reading vx logs.   For your info ...

 

 

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.
 
Martin

View solution in original post

6 REPLIES 6

Marianne
Level 6
Partner    VIP    Accredited Certified

See Chapter 3 of NBU Troubleshooting Guide

 

Using logs
This chapter includes the following topics:
■ About logs
■ About UNIX system logs
About unified logging
About legacy logging
■ About global logging levels
■ Logs to accompany problem reports for synthetic backups
■ Setting retention limits for logs on clients
■ Logging options with the Windows Event Viewer
■ Troubleshooting error messages in the NetBackup Administration Console for UNIX

mph999
Level 6
Employee Accredited

http://www.symantec.com/docs/TECH75805 is everything you need to know ...

... almost

The clever answer ...

Legacy logs are single threaded

VX logs are multi-threaded (with a couple of exceptions).

Martin

mph999
Level 6
Employee Accredited

This is some details I posted previously about the problems with reading vx logs.   For your info ...

 

 

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.
 
Martin

Faysal
Level 3
Partner Accredited

Here is the complete detail........

Daemons that use Unified Logging

A listing of processes and originators that use Unified logging include, but are not limited to:
 
NetBackup Policy Execution Manager (nbpem)
NetBackup Job Manager (nbjm)
NetBackup Resource Broker (nbrb)
NetBackup Enterprise Media Manager (nbemm)
NetBackup Service Layer (nbsl)
NetBackup Generic Job (nbgenjob)
NetBackup Notification Service (nbnos)
NetBackup for NDMP and ndmpagent
NetBackup avrd and robotic processes
NetBackup Operations Monitor (NOMTRS, NOMClient and NOMServer)
Bare Metal Restore daemons (bmrd, bmbbd, bmrc, bmrs, bmrconfig, bmrsavecfg, bmrsrtadm, bmrprep, bmrsetupmaster, bmrsetupboot, bmrpkg, bmrcreatepkg, bmrcreatefloppy.exe, bmrrst.exe and bmrmap.exe)
VERITAS Private Branch Exchange (VxPBX)

Daemons that continue to use Legacy logging

A listing of daemons that use Legacy logging include, but are not limited to:
 
NetBackup Master Server daemons (bprd, bpdbm, bpjobd, bpdbjobs, admin)
NetBackup Media Server daemons (bpbrm, bptm, bpdm)
NetBackup Robotic daemons (vmd, avrd, ltid and robotic daemons)
NetBackup Client daemons (bpcd, bpbkar, tar)



Create the legacy log folder on all applicable hosts

 1. Run th following on both the master and media servers

Solaris : /usr/openv/netbackup/logs/mklogdir
Windows: install_path\netbackup\logs\mklogdir.bat

2. open the netbackup administration console
 
    Select Host properties > master server/media > right-click > properties > Logging > global logging level > 5 maximum > ok

 
To set the maximum logging level for all daemons run:

#/usr/openv/netbackup/bin/./vxlogcfg -a -p 51216 -o Default -s DebugLevel=5 -s DiagnosticLevel=5

#grep DebugLevel /usr/openv/netbackup/nblog.conf
Default.DebugLevel=5
116.DebugLevel=2        (for example you add another process)

check the originators id      (if you want)
#grep LogDirectory /usr/openv/netbackup/nblog.conf

111 - Enterprise Media Manager (nbemm)
116 - NetBackup Policy Manager (nbpem)
117 - NetBackup Job Manager (nbjm)
118 - NetBackup Resource Broker (nbrb)
153 - NetBackup Generic Job Daemon (nbgenjob)

#/usr/openv/netbackup/bin/./vxlogcfg -a -p 51216 -o 117 -s DebugLevel=5
#/usr/openv/netbackup/bin/./vxlogcfg -a -p 51216 -o 118 -s DebugLevel=5
#/usr/openv/netbackup/bin/./vxlogcfg -a -p 51216 -o 111 -s DebugLevel=5

#/usr/openv/netbackup/bin/goodies/netbackup stop   (stop)
#/usr/openv/netbackup/bin/goodies/netbackup start   (start)

To view logs  (The default log directory is /usr/openv/logs & you can check sapratly by cat cammand)

 #/usr/openv/netbackup/bin/./vxlogview -t 00:01:00

vxlogview -p 51216 -o 111 -d all >/tmp/emm.txt  (for saving the logs in one file.)
 
To disable logging for all daemons run:
 
# cd /usr/openv/netbackup/bin
# ./vxlogcfg -a -p 51216 -o Default -s DebugLevel=0 -s DiagnosticLevel=0

mph999
Level 6
Employee Accredited

I would not recommend every running :

/usr/openv/netbackup/bin/./vxlogcfg -a -p 51216 -o Default -s DebugLevel=5 -s DiagnosticLevel=5

It is fairly certain that on an average size system, this would cause you to run out of disk space very very quickly.

The same promle would happen with /usr/openv/netbackup/logs/mklogdir

It creates many logs, it is very likely to cause disk space issues, but, this script is useful to look in to see what logs are available, then you can create just the ones you require.

Martin

V_P_S
Level 4

Thanks to all soo much...