When I look at the channel of the EventLog API sensor I see two values returned: Volume and Speed - on the same channel. For some reason, the value that is used to disaply and to notfiy is the Speed value (and NOT the Volume value) - which doesn't correspond correctly to Event Log changes and thus doesn't trigger the change notification. I'm trying to find a way to edit the channel setting so the primary value returned would be the Volume. Is it possible or is it something that has been overlooked by design?
Article Comments
I can't seem to understand. I'd like to send a notification each time there's an Application Log error. The Volume counter, counts those errors - that's how I see it for the time being. The Speed counter, can't see how it can help me with notifications. You note that the Volume value would return abnormal values, while now it acts fine.
How else would I use On Change notifications for the Event Log sensor if the value that changes is Speed? The whole point in Event Log notification is notifying when an actual Error is logged. Forgive me if I miss something here, I'd like to know of an alternative way to notify about Errors being logged.
Jan, 2011 - Permalink
Has there been any update on this issue ?
I want to trigger a notification if there is an eventlog entry missing since the last sensor update, thus i think this might be the same topic. Correct me if i'm wrong.
Thanks a lot in advance.
May, 2011 - Permalink
Dear Thorsten, for that, please check out the following article: How can I check the Windows Event log using extended filter options?.
best regards
May, 2011 - Permalink
This is still a problem. I would like to switch the primary channel from #/s to volume. Why isn't the volume not chosable in the settings?!
Apr, 2022 - Permalink
Hello,
volume itself would be undefined without knowing the time span for that volume. This would it make especially confusing if the sensor scanning interval gets changed.
Also with data averaging for reports, a volume channel would be difficult to process. Bandwidth on the other hand allows all such processing and works with changes in the scanning (or average) interval.
May, 2022 - Permalink
Hello NewCom,
is the question about the sensor scanning interval? That setting would be available on the "Settings" tab of the sensor. One can also define custom scanning intervals, which subsequently appear as a choice in the sensor settings.
May, 2022 - Permalink
No it's not about the scanning intervals. I want to change the graphing of the scanned values. So it shows as exmaple #/24h not #/s.
May, 2022 - Permalink
Hello,
only certain units can be configured, like traffic (kb/MB per s/h/d), via the channel configuration in the device's settings tab. Event bandwidth always uses the base unit, seconds.
May, 2022 - Permalink
Via sensor setting I can only set #/s or downtime. Via the channel setting I can only choose how it is shown in the graph (by maximum or by #/s).
May, 2022 - Permalink
Hello,
that is correct. Some units can be configured, like traffic. Event bandwidth cannot have its unit changed.
May, 2022 - Permalink
I think u don't understand. We want just show volume in the graph, why isn't there an option to show it? The sensor is tracking two values volume and #/s, but in the graph I can only show #/sec, that doesn't make sense at all.
May, 2022 - Permalink
Hello,
Regarding the Event Log sensor, I'm afraid that the channel only monitors the speed here, despite that the volume is visible. Therefore, PRTG can only display the values per second in the graphs because those data are stored.
To get these data in the graphs too, I invite you to open an official feature request for it, by following our guideline here: https://helpdesk.paessler.com/en/support/solutions/articles/76000063572-how-can-i-propose-new-features-or-sensors-for-prtg.
Regards.
Jun, 2022 - Permalink
Afraid that isn't possible, seeing as the volume value would be dependant on the scanning interval. Each time a "scan now" is triggered, a probe is restarted, a sensor is edited, etc. would return abnormal values. This would not be an issue in the tables per se, but it would certainly cause very strange graphs.
Jan, 2011 - Permalink