What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Sensor always executed twice

Votes:

0

Your Vote:

Up

Down

I've got a problem with the execution of a custom sensor by PRTG: Whenever the sensor is executed, it's immediately re-executed 1 second later, so that it's always executed twice. Not considering the double execution, it executes correct. What might be the reason for such a behavior? How can I stop the sensor from being re-executed?

custom-sensor execution prtg

Created on Dec 9, 2014 10:54:42 AM by  ages (1,008) 5 1



9 Replies

Votes:

0

Your Vote:

Up

Down

What version of PRTG are you using? Could you paste the code of the script here? What does it say in the sensors log tab?

Created on Dec 9, 2014 8:40:47 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

PRTG version is 14.4.12.3331. The sensor log tab shows both executions of the sensor within the interval of 1 second, this is how I actually know the sensor ran twice.

Code:

param (
	[string]$h = $(throw "-h missing"),
	[string]$user = $(throw "-user missing"),
	[string]$pass = $(throw "-pass missing"),
	[string]$Contains,
	[string]$LogFile = $(throw "-LogFile missing"),
	[string]$Source,
	[int]$SensorID = $(throw "-SensorID missing"),
	[string]$rcpt # recipient(s) for email alerts
)

$StateOK = 0
$StateError = 2
$StateWarning = 1
$ELERROR = 1
$ELWARNING = 2

$RegKey = "HKLM:SOFTWARE\Wow6432Node\Paessler\PRTG Network Monitor\Probe\Sensors\EventLogMsg\" + [string]$SensorID
$LastRecord = 0
if (!(Test-Path $RegKey))
{
	try
	{
		New-Item $RegKey
		New-ItemProperty -Path $RegKey -Name LastRecord -PropertyType DWord
		$LastRecord = 0
	}
	catch
	{
		$e_xml = "<prtg><error>1</error><text>Configuration Error: Could not access registry key: " + $_.Exception.Message + "</text></prtg>"
		Write-Host $e_xml
		Exit
	}
}
else
{
	$LastRecord = (Get-ItemProperty -Path $RegKey).LastRecord
}

try
{
	# create credentials
	$pw = ConvertTo-SecureString $pass -AsPlainText -Force
	$cred = New-Object System.Management.Automation.PSCredential($user, $pw)
}
catch
{
	$e_xml = "<prtg><error>1</error><text>Credential error: " + $_.Exception.Message + "</text></prtg>"
	Write-Host $e_xml
	Exit
}

$State = $StateOK
$Msg = ""
$RCount = 0

# prepare filter string
$Filter = "LogFile='$LogFile' AND RecordNumber > $LastRecord"
if ($Source)
{
	$Filter += " AND SourceName='$Source'"
}
if ($Contains)
{
	$Filter += " AND Message LIKE '%" + $Contains + "%'"
}
# Receive events
try
{
	Get-WmiObject -Class Win32_NTLogEvent -ComputerName $h -Filter $Filter -Credential $cred | ForEach-Object {
		if ($_.EventType -eq $ELERROR)
		{
			# Error
			$State = $StateError
			$Msg += "ERROR: " + $_.Message + "; "
		}
		elseif ($_.EventType -eq $ELWARNING)
		{
			# Warning
			if ($State -ne $StateError)
			{
				$State = $StateWarning
			}
			$Msg += "WARNING: " + $_.Message + "; "
		}
		else
		{
			$Msg += "INFO: " + $_.Message + "; "
		}
		$RCount = $_.RecordNumber
	}
}
catch
{
	$e_xml = "<prtg><error>1</error><text>Error receiving log events: " + $_.Exception.Message + "</text></prtg>"
	Write-Host $e_xml
	Exit
}

# prepare output
$xml = "<?xml version=`"1.0`" encoding=`"UTF-8`" ?>`n<prtg>"
if ($State -eq $StateError)
{
	$xml += "`n`t<error>1</error>"
}
else
{
	$xml += "`n`t<result>`n`t`t<channel>EventLog State</channel>`n`t`t<value>" + $State + "</value>`n`t</result>"
	if ($State -eq $StateWarning)
	{
		$xml += "`n`t<warning>1</warning>"
	}
}
# remember last record number read and set message
if ($RCount -gt $LastRecord)
{
	Set-ItemProperty -Path $RegKey -Name LastRecord -Value $RCount
	$xml += "`n`t<text>" + $Msg.TrimEnd("; ") + "</text>"
}

$xml += "`n</prtg>"
Write-Host $xml
Exit

Created on Dec 10, 2014 1:08:45 PM by  ages (1,008) 5 1



Votes:

0

Your Vote:

Up

Down

Sorry, that's way too complex to debug for us. Try simplifying the script (or with a way more simpler script). Also, please update to the latest version available (14.4.13.3721) and see if the problem persists.

Created on Dec 11, 2014 7:31:31 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I've stripped the script down to the example below, which shows the same behavior: If the result indicates an error state, the sensor is re-executed immediately. Furthermore, I've set the sensor to immediately go into error state on first run instead of going into warning state first. However, the protocol indicates that the sensor still goes into warning state first.

$ErrorActionPreference = "Stop"

$RegKey = "HKLM:SOFTWARE\Wow6432Node\Paessler\PRTG Network Monitor\Probe"

$FlagValue = (Get-ItemProperty -Path $RegKey).Flag
if ($FlagValue -eq $null)
{
	try
	{	
		New-ItemProperty -Path $RegKey -Name Flag -PropertyType DWord
		$FlagValue = 0
	}
	catch
	{
		$retstr = "2:Configuration Error: Could not access registry key: " + $_.Exception.Message
		Write-Host $retstr
		Exit 2
	}
}

if ($FlagValue -eq 0)
{
	Set-ItemProperty -Path $RegKey -Name Flag -Value 1
	Write-Host "4:ERROR"
	Exit 4
}
else
{
	Write-Host "0:OK"
	Exit 0
}

The script checks the value of a registry key and return OK if the value is 1 or returns an error and sets the value to 1 if it is 0. Therefore, on the first run, the state is error. Afterwards, it is OK.

The protocol of the sensor shows this:

15.01.2015 11:40:34	TEST	Ok		0 #
15.01.2015 11:40:34	TEST	Warnung		Inhaltsfehler: ERROR (Code: PE024)

Created on Jan 15, 2015 10:48:08 AM by  ages (1,008) 5 1



Votes:

0

Your Vote:

Up

Down

Any idea why this behavior might occur? How can I have the sensor enter the error state immediately and keep this this state until the next scheduled check?

Created on Jan 20, 2015 9:35:39 AM by  ages (1,008) 5 1



Votes:

0

Your Vote:

Up

Down

Sorry for the delay. The "warning state first" is normal to avoid false positives. Internally, a rescan is triggered after a few seconds in case the sensor goes into a warning state. If it's still in a errorneous condition, it will go into a down state.

As for the double execution - if the sensor receives a warning state, the sensor will immediately rescan to compensate network fluctuations. Thats why it runs twice. This behavior can't be changed. Hence that, because your sensor is basically self healing in the script upon execution, it can't stay in a warning state. Only if you outsource the

New-ItemProperty -Path $RegKey -Name Flag -PropertyType DWord
$FlagValue = 0

...part into a notification object that runs as soon as the sensor is in a down state.

Created on Jan 20, 2015 11:37:22 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

The "self-healing part" is only a more simple example of what happens in the actual sensor in order to provide a minimum example. What we actually want is a sensor that reads log messages from a file and go into error state whenever an error message is read from said file. Since every message is only read once, there won't be an error state on the next scan. The reception of an error message by the sensor will never be the result of a "network fluctuation", so there is no need for a rescan here, it rather is destructive behavior.

Unfortunately also the suggested solution of putting this part of the sensor logic into a notification object doesn't seem to fix this. We'd want to read all log messages from the file, no matter the severity, but we certainly don't want all of them to spit out a notification. So in case of no notification, the log message "counter" wouldn't be updated an all the messages would be re-read until a notification occurs.

If I'm not mistaken, your sensors such as file content sensor does also handle this type reading before-unread parts. Can you tell me how this is managed?

Created on Jan 20, 2015 12:45:03 PM by  ages (1,008) 5 1



Votes:

1

Your Vote:

Up

Down

The sensor works like this:

  1. Check last modify time
  2. Check size
  3. Check last line of the file

If all three differ, the sensor fires :) As for the other problem. You could modify the script to only heal on every second run (write a lock file or something like that) - then you will see the error in PRTG and it will heal itself on the next run.

Created on Jan 23, 2015 4:02:25 PM by  Stephan Linke [Paessler Support]

Last change on Jan 23, 2015 4:02:50 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

This seems to make the sensor actually work as expected. Unfortunate requirement though. But thanks for providing a workaround :)

Created on Jan 26, 2015 3:13:31 PM by  ages (1,008) 5 1



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.