Forum Discussion

V_P_S's avatar
V_P_S
Level 4
12 years ago

Unified logs and legacy logs

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

 

 

7.1.x and Earlier
Backup and Recovery
NetBackup
  • mph999's avatar
    mph999
    12 years ago

    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

6 Replies

Sort By
  • Marianne's avatar
    Marianne
    Level 6
    12 years ago

    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's avatar
    mph999
    Level 6
    12 years ago

    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's avatar
    mph999
    Level 6
    12 years ago

    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's avatar
    Faysal
    Level 3
    12 years ago

    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's avatar
    mph999
    Level 6
    12 years ago

    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