Accessing Bottleneck info via Veeam.Backup.Model.CBottleneckInfo.Bottleneck

[Philenst]

Hello,

I currently have a script that gathers all the information of a job and pushes it to Discord dependant on success/failure

Currently I have an issue when accessing

Code: Select all

Veeam.Backup.Model.CBottleneckInfo.Bottleneck

for the bottleneck information.
My current code contains:

Code: Select all

$session.GetTaskSessions()[0].progress.BottleneckInfo.Bottleneck

However, it seems to always return NotDefined, even if the interface specifies a bottleneck.

Am I possibly accessing the wrong object for this?

Log when printing

Code: Select all

$session.GetTaskSessions()[0].progress.BottleneckInfo.Bottleneck

2022-03-31T19:24:48.084Z [INFO] NotDefined

However in the GUI:



Would appreciate any thoughts or feedback.

Edit: My $session variable is obtained by passing SessionID to Get-VBRSessionInfo

Code: Select all

$session = (Get-VBRSessionInfo -SessionId $id -JobType $jobType).Session

Running build 11.0.1.1261 P20211211

[david.domask]

Hi @Philenst,

Regrettably this internal method has some challenges right now and was never meant as an official source of data, so I'm afraid you're out of luck on this one. @oleg.feoktistov, I believe this came up in an RND discussion and you mentioned that we had some plans for this later? (I can PM you the requirement you mentioned)

Philenst, I'm afraid right now aside from checking the Sessions tables in the DB there's not a good way to do this, and you have to do some maths on your own We had some luck checking with the CalcBottleneck() method on that object, but to be clear, the methods themselves just weren't intended to be used, so might have to just have to pull from the DB directly with Invoke-SQLCMD. The [backup.model.backupjobsessions] table records the bottlenecks in INT:

Code: Select all

    NotDefined = 0,
    None = 1,
    Source = 2,
    Proxy = 3,
    Network = 4,
    Target = 5,
    Throttling = 6,
    SourceWan = 20, 
    TargetWan = 30, 
    SourceNetwork = 40, 
    SourceProxy = 42, 
    TargetProxy = 44,
    TargetNetwork = 46, 
    TargetDisk = 48,

[oleg.feoktistov]

Hey,

@david.domask, correct. The plans are to gradually get rid of core classes bindings in powershell, thus, making classes with fixed properties so that issues like with bottleneck either won't happen or can be easily tracked and fixed. As for the session classes particularly, it is about making new ones with the most demanded properties, including bottleneck info.
@Philenst, as a workaround, I found it possible to calculate bottleneck on backup session level manually based on comparison between source, proxy, network and target values (where the higher the value, the more likely it to be a bottleneck). Have a look at the example:

Code: Select all

$sessions = Get-VBRBackupSession
foreach ($session in $sessions) {
  $source = $session.Progress.BottleneckInfo.Source
  $proxy = $session.Progress.BottleneckInfo.Proxy
  $network = $session.Progress.BottleneckInfo.Network
  $target = $session.Progress.BottleneckInfo.Target
  $maxSourceTarget = [Math]::Max($source, $target)
  $maxProxyNetwork = [Math]::Max($proxy, $network)
  $maxFinal = [Math]::Max($maxSourceTarget, $maxProxyNetwork)
  switch ($maxFinal) {
    $source {
        $bottleneck = 'Source'
    }
    $proxy {
        $bottleneck = 'Proxy'
    }
    $network {
        $bottleneck = 'Network'
    }
    $target {
        $target = 'Target'
    }
  }
  $session | select Name, CreationTime, EndTime, @{n='Bottleneck';e={$bottleneck}}
  
}

Hope it helps,
Oleg

[Philenst]

Hi Guys,

Thank you both for the ideas. @david.domask I may not have certainty if the host contains SQLCMD, otherwise I see this as an ideal solution. Thank you for this.

@oleg.feoktistov I have tested your provided solution and it seems to give the correct result for all the runs I've attempted with it. Will use this as it doesn't require any 3rd party tools, such as SQLCMD. Also thank you fo rthis.

Is there any plans in the future perhaps to populate this class? May be ideal for it to be removed if there's no plans to populate this, as it may cause confusion not only for myself, but for others who may be trying to achieve the same result.