The Operating System value not the same when I pull it via an alert template

Help
1

Hi,

I’m trying to get the same nice Operating System value when you look at a device; in my case i see on the firewall the following value in the GUI:

Operating System Fortinet Fortigate v6.0.3 (build0200)

When i try to get the same in my alert template, i doesnt seem to be the same.

I tryd the following in order and on the same line, but still it isn’t the same:

{{ $alert->os }} ({{ $alert->hardware }} version {{ $alert->version }})

The above results in the following:
System: fortigate (FGT_400D version v6.0.3)

is there a way to get the same value nicely formated value from the GUI in my alert template?

Thanks in advance!

2

For the first part I think you are looking for os_text , i’m not sure whether it is supported in the alerting like {{ $device['os_text'] }} worth a try :slight_smile:

I think it extracts the text from the /includes/definitions/fortigate.yaml file,

os: fortigate
text: 'Fortinet Fortigate'

Then it’s pretty much just adding {{ $alert->version }} ({{ $alert->features }}) afterwards.

3

Well the OS_Text doesn’t work. also when i try the features pull, it tells me the following:
features is not a valid $alert data name

Anybody else a idea ?

4

Yep can’t find a way to grab os_text, and $alert->features doesn’t seem to be valid anymore (there was an old format %features that was converted )

All the placeholders available are mentioned in here #https://docs.librenms.org/Alerting/Templates/

5

Ok; is there maybe a way to get the sysDescr a little bit shorter; like the first 25 characters?

6

Is there any further news regarding the full descriptive Operating system name not being available in alerts?

I’m also trying to get the exact text shown in the “Operating System” column in the device list in the GUI in the alerts but no luck. Different device types populate different fields that are available in alerts in ways that are not very convenient or easy to parse.

For example, for a Windows server the available alert variables will show:

System Description: Hardware: Intel64 Family 6 Model 45 Stepping 7 AT/AT COMPATIBLE - Software: Windows Version 6.3 (Build 17763 Multiprocessor Free)
OS: windows
Version: Server 2019 1809 (NT 6.3)
Type: server
Hardware: Intel x64

Here I would just want to concatenate os and version variables - I’m not interested in the System description.

However on a Meraki AP the fields are:

System Description: Meraki MR42 Cloud Managed AP
OS: merakimr
Version: 
Type: wireless
Hardware: Meraki MR42 Cloud Managed AP

So I would want either the System Description or Hardware field. A third example is a Mac OS machine:

System Description: Darwin MacServer.staloysius.local 19.6.0 Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05 PST 2021;
root:xnu-6153.141.16~1/RELEASE_X86_64 x86_64
OS: macosx
Version: 
Type: server
Hardware:

Version is not even set here and the System Description is not very useful as its just the Darwin kernel version.

So I can’t think of any simple coding in an alert template that will nicely show what I want across a variety of device types. The closest I can come is {{ $alert->os }} {{ $alert->version }} {{ $alert->hardware }}

7

Hi @DBMandrake

Two different issues are mixed in your post.

The field you would like to see in your alert are on thing. {{ $alert->os }} {{ $alert->version }} {{ $alert->hardware }}.
The nicely formated OS is not currently available in the $alert hash. You could submit a Pull Request to add it, or use a piece of PHP code in the alert to get it at runtime. Something like should do the trick for the OS “nice text description”:

{{ LibreNMS\Config::getOsSetting($alert->os, 'text') }}

And then you also want to ensure that all of your devices get a value for those fields. That part is completely independant of the alerting. It is a matter of LibreNMS supporting the devices. For instance, if version is missing, one need to correct/improve the detection process to collect the version from the device (either extract it from sysDescr, or from any other SNMP OID). And then it will be visible everywhere.

8

Thanks - that looks like it might do the job. I’m guessing that this approach is something that is not officially support and may break in future since it is reaching into the internals a bit?

So $alert->os, ‘text’ is the exact text in the “Operating System” field in the device list? Do you also know which one would give the exact text in the “Platform” field ? Or is this identical to the already available $alert->hardware field in alerts?

9

Yes and no. Yes, it does reach the internals but it is not planned to export every piece of data for performance reasons so this is the recommended way to access whatever is missing.

10

Ok cool. I can always update the templates in the future if something did change.

Is there a list of other internal variables for devices which can also be reached this way, or can you point me at the right source file(s) to look at? I’m also interested in the pretty version of the “Platform” field in the devices list and have had a bit of a browse through the source but have been unable to find how to reference it.

Edit: Now that I’ve tried using it, I’ve noticed that the Operating System “Field” in the device list is actually two fields on separate lines. The first line is {{ LibreNMS\Config::getOsSetting($alert->os, 'text') }} and the second line is just {{ $alert->version }} ?

And the “Platform” field in the devices list is just {{ $alert->hardware }} ?

11

@DBMandrake You can virtually access any object, meaning any DB element. You can even extract values from RRD files to display it if you like (this is a little bit verbose to do, but can be done). Any PHP code can run between {{ and }}.

12

Thanks - yes, I relatively recently figured out that you could just put raw php code inside {{ }} - I use number_format() in one of my templates for example. (which I just posted over in another thread)

The fact this is just embedded PHP code isn’t made clear on the template page. (Or mentioned at all I think?) Perhaps something that should be advertised more as being able to embed PHP code in the templates makes them very powerful.

Although I used to program a bit in PHP we’re talking about 15 years ago so I’ve forgotten more than I knew… :slight_smile: (These days Python is my go to for any scripting above Bash) I’ve also tried to read some of the laravel docs in relation to templates but have found it very impenetrable to be honest and have not even heard of laravel prior to LibreNMS let alone used it before.

While being able to embed php code makes almost anything possible unless you know the data structures that you’re trying to pull data from it doesn’t help much - I was mainly trying to find more info on those data structures even if it just means looking at the source code.

In any case I’ve managed to find the data I’m looking for in this particular thread now, thanks. :slight_smile:

13

Yep. More exemples would be welcomed, but as you already said, there is also a risk for the internals to change, so advertising too much might end up in a non-working template after an upgrade (meaning no more alert sent …). The balance is difficult to find.
Glad you found your data, and feel free to submit a PR in github to edit the doc and make it a way that would have saved time to you. (You can directly press the “edit” button in the documentation).