In the "show snmp" traps are being generated, 13 of them, and you have snmp-server enable traps syslog set.
Few things you can do is add a logging ip address if one doesn't already exist or an additional address and throw up a simple syslog server and do a few things to generate traps like conf t or add a vlan and delete a vlan as you have these set to trap. If you don't to use vlans then add a loopback and shut/no shut it a few times.
Appears you are dealing with these remotely. I always open two sessions to the box. Session one, I execute "no debug all" then arrow up then switch to the other session and do term mon and then debug snmp packet. The first session is a failsafe so I can turn off debugging with hitting return if for some reason debug is taxing the box. School of remote access hard knocks.
While debug is running do conf t and exit a few times and/or add delete vlans and you will see the traps being generated and if they are pointing to the desired ip.
Should see something similar to these below.
6506E#term mon
6506E#debug snmp packet
SNMP packet debugging is on
6506E#sh run
Building configuration...
...
6506E#
19:24:18: SNMP: Queuing packet to 10.198.28.80
19:24:18: SNMP: V3 Trap, reqid 2, errstat 0, erridx 0
sysUpTime.0 = 6981747
snmpTrapOID.0 = ciscoConfigManMIB.2.0.1
ccmHistoryEventEntry.3.100 = 1
!--- 1 -> commandLine. Executed via CLI.
ccmHistoryEventEntry.4.100 = 3
!--- 3 -> running
ccmHistoryEventEntry.5.100 = 2
!--- 2 -> commandSource. Show command was executed.
6506E#conf t
Enter configuration commands, one per line. End with CNTL/Z.
6506E(config)#exit
22:57:37: SNMP: Queuing packet to 10.198.28.80
22:57:37: SNMP: V3 Trap, reqid 2, errstat 0, erridx 0
sysUpTime.0 = 8261709
snmpTrapOID.0 = ciscoConfigManMIB.2.0.1
ccmHistoryEventEntry.3.108 = 1
In our shop we only use PI for wireless management controllers and users, not switches. Third party and open source for switches. We have logging for all available traps to dual syslog servers for compliance and redundancy so I understand your frustration when traps aren't working as expected.
Also if you aren't are the latest patches in the 2.0 train I would highly recommend it. 2.0 is not the most stable from our experience until the patches are added. fwiw
Best Answer
SSH into Prime and run 'root'. (You might need to enter 'root_enable" as a precursory task.
See here for more detils: http://www.cisco.com/c/en/us/td/docs/wireless/prime_infrastructure/3-0/command/reference/cli30/cli211_appendix_011.html#wp8104678890
Now you can view the linux shell.
Enter 'cd /opt/CSCOlumos/conf/ifm/template/inventoryTagsInTemplate' then 'ls'
Hey presto you can see the 'CLITemplateDbVariablesQuery.properties' file is here
From here you can type 'more CLITemplateDbVariablesQuery.properties' to view the contents of the file. :)