How to read and understand kernel reports?
There is a deluge of info in a kernel panic log. I have had some problems lately so I was looking at kernel panics on my macbook and can offer the following hints based on some .panic logs I have.
First the name of the log is important. you need to look for files of the following form in your system diagnostic folder:

kernel-**(some personal data like name of my pc)****.panic

(unfortunately i got some .gpuRestart and .hang ones on mine too..)

Anonymous UUID:       F******************************* &lt;-personal data

Sun Aug  9 22:23:37 2015

*** Panic Report ***
panic(cpu 0 caller 0xffffff800c617cc2): Kernel trap at 0xffffff800c5d0395, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000000000000009, CR3: 0x0000000423b7f051, CR4: 0x00000000000626e0
RAX: 0xffffff800cce0cd0, RBX: 0x000000000000003f, RCX: 0xffffff800cce08e0, RDX: 0x0000000000000001
RSP: 0xffffff81f4cb2f80, RBP: 0xffffff81f4cb2f90, RSI: 0xffffff8019059000, RDI: 0x000000000000003f
R8:  0x00000000000001c0, R9:  0xffffff80190e6fc0, R10: 0x0000000000000100, R11: 0x0000000000000000
R12: 0xffffff80383643c0, R13: 0xffffff803e95c200, R14: 0xffffff801919e040, R15: 0x0000000000000000
RFL: 0x0000000000010296, RIP: 0xffffff800c5d0395, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x0000000000000009, Error code: 0x0000000000000002, Fault CPU: 0x0


the first part shows the state of the registers . I dont think that this is info that you can personally act upon

However after that the good stuff comes...
some other register info 

Backtrace (CPU 0), Frame : Return Address
...
0xffffff81f4cb3420 : 0xffffff800c736c01 
0xffffff81f4cb35e0 : 0xffffff800c733202 
...
0xffffff81f4cb3fb0 : 0xffffff800c635068 


and then:

      Kernel Extensions in backtrace:
         com.sophos.kext.sav(9.2.50)[D9AF65D9-4A18-3B20-86BB-17DEBC7D5852]@0xffffff7f8cc18000-&gt;0xffffff7f8cc1cfff
         com.apple.filesystems.exfat(1.4)[6B0642D6-786C-323D-A762-9FFE6BFABFAF]@0xffffff7f8fa74000-&gt;0xffffff7f8fa81fff

BSD process name corresponding to current thread: InterCheck


this is info that maybe is important. It shows the last kexts (kernel extensions) loaded into your system. Most of the times they are the culprit for kernel panics... or at least the usual suspects.A good first move is to disable temporarily one of these kexts and see if the frequent kernel panics stop.

PS. it should be noted that the link offered as a comment by a fellow SE-er is very good if a bit verbose. However sometimes (eg. in a development situation) that amount of detail is just what is needed so you should definitely consult it