In the first case, W4 is the "VM backup result" (enterprises.31023.1.1.107). In the second example, W3 is the "Backup job result" (enterprises.31023.1.1.103). With every other product we monitor, the Status variable is always in the same place and as far as I see it is always W4. We can then look for specific text in the specific variable (e.g. W4). What is really annoying is that a different variable is used within the same product, which makes monitoring it more complex. Is this a configuration mistake on our part or does Veeam use a different Trap variable in different contexts to report the status?
All the variables should be described in the MIB file. Do you have this imported? As regards, the status reported in 103 instead of 107, then I agree it should be in the same variable, unless it is a different job that might not have all the options available. Do you see different variables used all the time for all job types?
I am getting the description of the OID (e.g. "VM backup result" ) out of the MIB file. Whether the MIB is important should not have any effect on what variables Veaam writes the data. IMO, if there is no value to write to a given variable then that variable should empty and the type of information in each variable should not be mixed. For example, W1 should *always* be "Backup job id" and not not sometimes ""Backup job name.", W4 should always be the "Source host name." and not sometimes "Backup job result.", as we see here. What OIDs and Variables are being displayed seems to be consistent. That is the same OIDS and variables for every backup job, and the same OIDS and variables Vm Backup.
James, we have just verified this behavior: backup status for VMs in the job and the job itself is indeed returned in different variables, however these variables are consistent among all job types.
Thank you for your assistance. I am not sure what you mean by "these variables are consistent among all job types." Are you saying that regardless of the type of job, W3 will always contain the status of that job and regardless of the type of job W4 will be the status for the VMS?
Yes, if you want to monitor job state, then you should ignore traps containing VMs info. Every processed VM generates its own event and status is contained in the same variable all the time. The status variable is the same for the job, but different for the VM task within the job. This can help you differentiate whether you've received a trap for a VM task or for the entire job. Hope this helps!
I am not trying to be difficult, but I see no easy way of "ignoring" one type of trap or another. As far as I can tell, there is no specific variable that says what type of job it is . If W4 is empty, then it is a "Backup job" otherwise it is a "VM backup" (but a "VM backup" is not a "backup job"). If so, that presents a danger should W4 be used for something in the future. Other than W4 being empty or not, I seem nothing clearly and definitively indicting what type of backup it is, at least not in a way that would be easy to automate.
Yes, it is not trivial, but at least these traps are persistent through all releases of Veeam B&R, and we do not expect any dramatic changes in the variables list (order) because many customers are already relying on the existing structure.
Other than passing the entire trap to a script with all of the logic, how do these "many customer" differentiate between a "VM backup" and a "Backup Job"?
Some service providers that I talk to, monitor the job state only. If there is a failed job, then they pull a report with all the details on the failed VMs. If you're using per-VM backup chains and you really need the backup state for each VM, then monitoring SNMP trap for VMs should be a way to go.
What kind of tool do you use to receive traps? I was under impression that most of the monitoring tools allow filtering SNMP traps.
Sorry, but saying that customers "monitor the job state only" does not tell me how to *differentiate* between a "VM backup" and a "Backup Job". At this point all we are interested in is the "job state only", but the job state is sent in different variables depending on the type of job. Plus the name of the job is sent in different variables depending on the type of job.
We are using a propriatary tool called ZIS. It can do all sorts of filtering and can react different depending on the information in the trap variables. However, you obviously need to tell the software how it is supposed to filter. That is, what variable or OID to use. How do you know if a "job" failed? In one case you used the W4 variable, in another you use the W3 variable. I can configure the monitoring software to look for "Failed" or "Success" in *any* of the variables, but the trap still needs to be processed further. Again, if W4 is empty, then it is a "Backup job" otherwise it is a "VM backup" (but a "VM backup" is not a "backup job"). That means to me that in order to *differentiate* between a "VM backup" and a "Backup Job" I need to either simply accepted that the only way to differentiate between the job types is whether W4 is empty or not, and I need to send all of the variables to a extra scripts to figure out the job name (sometimes it's in W1, sometimes W2)
jamesmohr wrote:the job state is sent in different variables depending on the type of job. Plus the name of the job is sent in different variables depending on the type of job.
No, it should not be the case. Variables are re-used (consistent) for all job types. In your example above you see a trap for VM task session and the entire job. Can you please double check this behavior and share the screenshots from ZIS?
Vitaliy S. wrote: Variables are re-used (consistent) for all job types.
Not according to the Veeam MIB and your own comment:
Vitaliy S. wrote: backup status for VMs in the job and the job itself is indeed returned in different variables.
If the "indeed returned in different variables" they are obviously not "re-used (consistent) for all job types."
"W4 is the "VM backup result" (enterprises.31023.1.1.107). In the second example, W3 is the "Backup job result" (enterprises.31023.1.1.103)." Different OIDs and different variables are used for the job result (i.e. the status). The description in the Veema MIB matches what ZIS is reporting. So what is correct, the MIB and your first post or your last post?
My statement above is still correct. Let me try to put it this way: in your example there is a trap for VM session and job session. These have different variables, but all backup, replication, backup cop, backup to tape etc jobs display status in the same variable. Keep in mind that each job has VM sessions, these are created for every VM in the job. In other words, if you have 100 VMs in the job, you will have 1 trap for the job state and 100 for individual VMs. These traps (for VMs and jobs) were created for different objects, that's why they display in different variables.
Unfortunately, I'm not familiar with ZIS, but can you catch traps that contain status in W3 only?