Request:Job Log

[TheOnlyWizard17]

Sometimes, a job is doing weird, or just one VM is doing weird, and is taking a long time to progress (or will eventually fail)...
For these cases, it would be nice if you can just rightclick the job to open the currently processing job log in notepad or default text-editor or something like that...
Likewise, rightclicking the current VM that seems stuck to open that VM's current log, etc.
I don't know if such an option would be easy to implement, but it would very much help monitoring if there actually still is progress in the first place, or the VM/job/object is just hanging for some reason. If you then want to go look for the log in progress, it's very cumbersome to achieve: I open a process explorer, try to track/find the log of the job/vm I'm looking for in the live disk I/O tracking, and rightclicking it from there to open it to try to find out what's going on. Surely, above suggestion, if possible to implement, would be a much easier way for these cases...

Not to say this happens alot, but just sometimes it does, and then this little QOL improvement would be a huge help...

[PetrM]

Hi Bart,

We prefer to let our support team handle technical issues, including log analysis. Please open a support case and ask our engineers to troubleshoot this behavior.

Thanks!

[TheOnlyWizard17]

This is a request which ultimately can help in lowering volume support-cases and this is your answer ? Seriously...
I prefer to do my own analysis to handle most oddities myself before even considering bothering Veeam Support. Those guys are busy enough as it is...

[PetrM]

It definitely says a lot about your technical background, and I truly appreciate it. However, if you are comfortable troubleshooting technical issues on your own without help from our support team, then automating the three clicks required to access the job log (C:\ProgramData... → JobFolder → open job log) would be a very minor improvement compared to the overall amount of work involved. That’s why I have some doubts about the value of this request.

Nevertheless, we usually prioritize requests based on overall interest, and I cannot say that we have received many requests for this functionality.

Thanks!

[TheOnlyWizard17]

PetrM, the 3 clicks is not the problem. Figuring out which of the 100's of logs is the current one being processed by that job/VM is... And that's where this request would help alot...
I do assume the Job knows which VM's it is processing and which logs it is writing for that, so programmatically would be a very simple to implement request I reckon...

[PetrM]

Thanks for clarifying! In fact, there are many operations performed by the job manager that are not related to any specific VM. For instance, connecting to Backup Infrastructure nodes, interactions between internal components, and so on. Furthermore, information about job activity that can be crucial for troubleshooting is not found only in the job log or VM processing log, it is also present in service logs, logs on the guest OS, etc.

If we're talking about UI button, when I press this button:
1. The UI sends a command to the Veeam Backup Service: “Open the correct log.” In the case of the remote console, we would also need to copy this log to the console somehow.
2. The service needs to select the appropriate log. We have several options: job log, VM processing log, service log, guest agent log, proxy/repository Data Mover logs, etc. But even if we simplify and say we only need to open the job log or VM processing log, I still wouldn’t know which one to choose. Let’s imagine we do have clear selection criteria, but it seems some backend logic is needed, so it’s not just a simple click.

Even with these simplifications and assumptions, we would have at least two algorithms to develop and test (in addition to the UI work):
1. Sending and processing the command to open a log and retrieving its content in the case of the remote console
2. Selecting the correct log based on certain criteria

This would require resources from the engineering team, and the result would be an opened log which would only be useful in about 50% of cases. That’s why I’m saying we definitely need more requests for such functionality, so far, we do not have enough.

Thanks!