What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

How do we keep acknowledgments from clearing?

Votes:

0

PING sensors keep loosing their acknowledgments at random times ( though usually after a day around 6-7:30 AM ). The server has not been reset, there has been no changes in their state ( they're still down ) and nothing else I can find in the debug, system and webserver logs to show why they have cleared their acknowledgments.

I can see why the acknowledgment clears. It is in part caused by a new alarm which shouldn't be happening because the state has not changed. The only suspect I can find is it tends to happen around when PRTG validation occurs but that may just be a coincidence.

Anyone have any idea what's causing these issues and what we can do to prevent it? It's quite the pain to have to redo acknowledgments just about every day.

/ Ping Example Log:

9/2/2010 7:27:06 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
9/2/2010 7:05:58 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 9/2/2010 7:05:58 AM by Jeremy: Down in LW, Left VM with 2 People
8/31/2010 7:24:01 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/30/2010 7:20:18 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/29/2010 7:17:12 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/28/2010 7:14:29 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/27/2010 9:37:12 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/27/2010 9:37:12 AM by Jeremy: Down in LW, Left VM with 2 People
8/27/2010 7:12:35 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/27/2010 6:32:36 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/27/2010 6:32:36 AM by Jeremy: Down in LW, Left VM with 2 People
8/26/2010 6:50:06 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/26/2010 6:48:17 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/25/2010 6:45:51 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/24/2010 6:44:43 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/24/2010 7:10:29 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/24/2010 7:10:29 AM by Jeremy: Down in LW. EU emailed.
8/24/2010 6:43:20 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/24/2010 6:09:29 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/24/2010 6:09:29 AM by Jeremy: Down in LW. EU emailed.
8/23/2010 10:00:36 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/23/2010 10:00:29 AM	
PING 125 73
Warning	Request timed out (ICMP error # 11010)
8/23/2010 10:00:20 AM	 	Active	
8/23/2010 10:00:20 AM	 	Resuming	Requested by Jeremy
8/23/2010 9:29:00 AM	 	Paused	Paused by User
8/23/2010 9:28:30 AM	 	Created	See history for details.
8/23/2010 9:28:30 AM	
PING 125 73
Created	See history for details.

/ System Info

Software Version and Server Information
PRTG Network Monitor 7.3.5.5747
Operating System: Windows Server 2003 (5.2.2 Build 3790 Service Pack 1), 4 CPUs, Intel Pentium, on "MAXTOR 7L250S0"
Server Time: 9/2/2010 8:10:14 AM
Server CPU Load: 7%
Last Error Message: 
Username: Logged in as ( Removed )
© 2010 Paessler AG, Burgschmietstrasse 10, 90419 Nuremberg, Germany
Browser:  (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4)
Licensing
... ( Removed )
Edition: Enterprise Unlimited Edition
Number of Sensors: unlimited
Number of Netflow/xFlow Sensors: 2
Number of Probes: 30
Activation Status: Activation OK

 
Need more sensors? Click here to upgrade!
System Startup Log
8/27/2010 7:11:47 AM - 0% - Starting PRTG Core Server
8/27/2010 7:11:47 AM - 1% - Read OSK Definitions: OK
8/27/2010 7:11:48 AM - 2% - Initialize Sensor Types: OK
8/27/2010 7:11:48 AM - 5% - Load Configuration: Read File
8/27/2010 7:12:02 AM - 10% - Load Configuration: Parse XML
8/27/2010 7:12:17 AM - 25% - Load Configuration: OK
8/27/2010 7:12:17 AM - 30% - Initialize System Options: OK
8/27/2010 7:12:17 AM - 35% - Start Notification Manager: OK
8/27/2010 7:12:22 AM - 40% - Check Database Integrity: OK
8/27/2010 7:12:22 AM - 41% - Initialize RawData Store: OK
8/27/2010 7:12:22 AM - 43% - Initialize Probes: OK
8/27/2010 7:12:22 AM - 45% - Initialize DataSync: OK
8/27/2010 7:12:22 AM - 47% - Initialize Schedules: OK
8/27/2010 7:12:22 AM - 50% - Load Cache
8/27/2010 7:12:23 AM - 60% - Cache Loaded
8/27/2010 7:12:23 AM - 70% - Calculate Historic Data: 2242/2242
8/27/2010 7:12:28 AM - 75% - Scan For Last Data:  1412/1412
8/27/2010 7:12:29 AM - 80% - Initialize Background Tasks: OK
8/27/2010 7:12:29 AM - 85% - Initialize Notification Engine: OK
8/27/2010 7:12:29 AM - 90% - Initialize Sensor State: OK
8/27/2010 7:12:29 AM - 99% - Starting PRTG Core Engine
8/27/2010 7:12:29 AM - 100% - PRTG Core Server is Started
 	
Database Objects
1 probe(s)
43 group(s)
1410 device(s)
2270 sensor(s)
24 user group(s)
29 user(s)
25 notification(s)
8 schedule(s)
60 Requests/Second
Create Database Snapshot
Probes
Probe #1 "Local probe":
connected from 127.0.0.1:4852
Last Data: 9/2/2010 3:10:14 PM (0 sec ago) [Restart]
Write Probe Status File
Restart All Probes
System Settings
Web server URL: https://192.168.1.2
Web server IPs: 192.168.1.2
Web server ports: 443
Web server port usage: 1
Incoming probe connection binding: 192.168.1.2:23560 127.0.0.1:23560
Incoming probe connection IPs: 192.168.1.2,127.0.0.1
Incoming probe connection port: 23560
Probe Allow IPs: any
Probe Deny IPs:
DataPath: C:\Documents and Settings\All Users\Application Data\Paessler\PRTG Network Monitor\V7\
Synchronization
Last synchronization with a probe: 
9/2/2010 8:10:00 AM (Nothing to do)
Probe/Core Message Count: 31432326 (< 1/sec)
Sync Cycle Speed: 3531msec (OK)
2270 of 2270 configuration requests sent
0 configuration requests deleted
0 configuration requests with response
Background Tasks
Historic data: done
Toplist buffer: 0
System Warnings
None
Core System Memory
Committed: 600320 KByte
Allocated: 472512 KByte
Unused: 102424 KByte
Free Physical: 4128360 KByte
Total Physical: 5241944 KByte
Free Virtual: 5241944 KByte
Total Virtual: 2097024 KByte
Object Count: 3831
Base: 54325 KByte
Datasets: 162556 KByte
State: 6279 KByte
Interface: 34502 KByte
IndexCache: 134 KByte
TreeTotal: 257797 KByte
DatasetCache: 0 KByte (0)
Sessions: 9 KByte (59)
Write Core Status File
Thread Information
LogManagerCore (#248, 0.03 sec) EventStorage (#4900, 18.47 sec) EventStorage (#5672, 0.00 sec) SystemMain (#4196, 1.25 sec) LogManagerAutodiscovery (#5016, 0.02 sec) LogManager (#4776, 3.13 sec) NotificationManager (#4548, 0.03 sec) FactoryManager (#3816, 0.00 sec) ProbeManager (#3684, 0.13 sec) ScheduleManager (#3896, 1591.48 sec) RawDataManager (#5196, 22.94 sec) BackgroundManager (#3624, 8849.06 sec) BackgroundCalculator (#220, 0.00 sec) DataSynchronizer (#4180, 1831.58 sec)

acknowledge acknowlegment clear logs ping prtg sensor validation

Created on Sep 2, 2010 3:28:28 PM

Last change on Sep 3, 2010 7:48:40 AM by Daniel Zobel [Product Manager]



Best Answer

Accepted Answer

Votes:

0

Hello,

yes, as said, an UP State seems out of the question as it would be mentioned in the sensors log, however, a grey (status unknown) for a very short time could have been the reason. It would resolve the acknowledged state and would not be mentioned in the log.
But, also to be honest, we have only seen such an unknown state very rarely when ping sensors were set to a very low scanning interval (5s and lower). Could you try a small test setup of PRTG 8 (beta), to see if the issue persists in the coming version 8 as well (we did some tests, and could not reproduce the issue).

Best Regards.

Created on Sep 8, 2010 2:08:02 PM by Torsten Lindner [Paessler Support]

Last change on Sep 9, 2010 2:53:08 PM by Torsten Lindner [Paessler Support]



7 Replies

Votes:

0

Hello,

normally the only reason to resolve an acknowledged down state is a state change to anything that is not down. That could be that the sensor was UP for a very short time (which then however should be in the sensors log), or if the sensor was grey (status unknown) for a short time, which would not be mentioned in the log. We suspect that might have happened here. What are the explicit settings of this ping sensor (interval, ping count, timeout)?

Best Regards.

Created on Sep 3, 2010 2:23:17 PM by Torsten Lindner [Paessler Support]



Votes:

0

None of the devices/ping sensors that are having this problem show an up state in the logs. They have not returned to a working state. They just re-evaluate as down after 24-48+ hours which gets rid of the acknowledgment.

/// Ping Settings ( for example above )

Priority: ***** Highest
Timeout (seconds): 2
Packet Size (Bytes): 32
PING Count: 3
Primary Channel: Average (msec)
Scanning Interval: 30 Seconds

-----

Other log examples of other ping sensors having this issue.

  1. 2

Info: This one is another prime example.

FYI: This was created using the API along with quite a few others. The next 2 examples were not created using the API, just in case you suspect that as being the cause. 

/// Log for Ping #2

9/3/2010 7:30:28 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
9/2/2010 7:29:01 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
9/2/2010 7:04:55 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 9/2/2010 7:04:55 AM by Jeremy: Down in LW, sent email
9/1/2010 7:26:16 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/31/2010 7:24:02 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/31/2010 7:22:46 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/27/2010 7:13:24 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/27/2010 9:38:27 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/27/2010 9:38:27 AM by Jeremy: Down in LW, sent email
8/27/2010 7:12:35 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/27/2010 6:28:44 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/27/2010 6:28:44 AM by Jeremy: Down in LW, sent email
8/26/2010 6:50:06 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/26/2010 6:48:18 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/25/2010 6:46:48 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/25/2010 6:45:51 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/24/2010 6:44:43 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/24/2010 7:11:10 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/24/2010 7:11:10 AM by Jeremy: EU internal outage.
8/24/2010 6:43:20 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/24/2010 5:26:05 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/24/2010 5:26:05 AM by Jeremy: EU, known customer outage.
8/23/2010 10:03:46 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
8/23/2010 10:03:34 AM	
PING 125 73
Warning	Request timed out (ICMP error # 11010)
8/23/2010 10:03:25 AM	 	Active	
8/23/2010 10:03:25 AM	 	Resuming	Requested by Jeremy
8/23/2010 9:34:00 AM	 	Paused	Paused by User
8/23/2010 9:33:30 AM	 	Created	See history for details.
  1. 3 & 4

Info: Both of these are actually bouncing, you can see when it comes up it does what it's supposed to and clears the acknowledgment. However you can also see that it too is having the same issue as those other ping examples when it show another down state when there's been no up state.

/// Log for Ping #3

9/3/2010 7:30:28 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
9/3/2010 7:13:54 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
9/3/2010 7:13:47 AM	
PING 125 73
Warning	Request timed out (ICMP error # 11010)
9/3/2010 7:07:11 AM	
PING 125 73
Up	144 msec
9/2/2010 11:57:41 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
9/2/2010 11:57:34 PM	
PING 125 73
Warning	Request timed out (ICMP error # 11010)
9/2/2010 11:05:55 PM	
PING 125 73
Up	73 msec
9/2/2010 3:45:58 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
9/2/2010 3:45:51 PM	
PING 125 73
Warning	Request timed out (ICMP error # 11010)
9/2/2010 3:05:14 PM	
PING 125 73
Up	76 msec
9/2/2010 7:04:37 AM	
PING 125 73
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 9/2/2010 7:04:37 AM by Jeremy: Pingable even though it's failing here.
9/2/2010 12:15:46 AM	
PING 125 73
Down	Request timed out (ICMP error # 11010)
9/2/2010 12:15:39 AM	
PING 125 73
Warning	Request timed out (ICMP error # 11010)
9/1/2010 11:02:36 PM	
PING 125 73
Up	76 msec
9/1/2010 7:26:16 PM	
PING 125 73
Down	Request timed out (ICMP error # 11010)

/// Log for Ping #4

8/24/2010 6:43:25 AM	
PING 125 1
Down	Request timed out (ICMP error # 11010)
8/24/2010 6:43:20 AM	 	Resuming	Resumed by Dependency
8/24/2010 6:43:20 AM	 	Active	
8/16/2010 6:25:10 AM	
PING 125 1
(Unknown Event)	Request timed out (ICMP error # 11010) / Acknowledged at 8/16/2010 6:25:10 AM by Jeremy: Flood damage?
8/14/2010 11:11:20 AM	 	Paused	Paused by Dependency
8/14/2010 11:11:20 AM	
PING 125 1
Down	Request timed out (ICMP error # 11010)
8/14/2010 11:11:12 AM	
PING 125 1
Warning	Request timed out (ICMP error # 11010)
8/13/2010 6:55:42 AM	 	Resuming	Resumed by Dependency
8/13/2010 6:55:42 AM	 	Active	
8/13/2010 6:55:42 AM	
PING 125 1
Up	73 msec
8/13/2010 6:55:26 AM	 	Paused	Paused by Dependency
8/13/2010 6:55:26 AM	
PING 125 1
Down	Request timed out (ICMP error # 11010)

Created on Sep 3, 2010 4:39:36 PM

Last change on Sep 8, 2010 11:49:04 AM by Torsten Lindner [Paessler Support]



Accepted Answer

Votes:

0

Hello,

yes, as said, an UP State seems out of the question as it would be mentioned in the sensors log, however, a grey (status unknown) for a very short time could have been the reason. It would resolve the acknowledged state and would not be mentioned in the log.
But, also to be honest, we have only seen such an unknown state very rarely when ping sensors were set to a very low scanning interval (5s and lower). Could you try a small test setup of PRTG 8 (beta), to see if the issue persists in the coming version 8 as well (we did some tests, and could not reproduce the issue).

Best Regards.

Created on Sep 8, 2010 2:08:02 PM by Torsten Lindner [Paessler Support]

Last change on Sep 9, 2010 2:53:08 PM by Torsten Lindner [Paessler Support]



Votes:

0

I've got the beta installed. I will let you know if I find the same results.

One other question for you.

Since you could reproduce the issue, did you see this issue reproduced on a small test setup or on a larger scale setup?

We have more than 1000 sensors on or main production PRTG server. I'm asking the above question because I'm wondering if the issue will reproduce itself on smaller scale systems to see if may have more to do with the load on the probe itself.

Created on Sep 9, 2010 1:15:13 PM



Votes:

0

I am sorry, I made I typo, we could not reproduce the issue with tests with PRTG 8. Generally, if you can reproduce it with PRTG 8, please let us divert the issue to a regular support ticket by sending an email to [email protected].

Created on Sep 9, 2010 2:55:02 PM by Torsten Lindner [Paessler Support]



Votes:

0

So far it has not happened again with version 8. I guess that leads to the question, is there any update on a projected time when this will be officially released?

Created on Sep 13, 2010 12:17:59 PM



Votes:

0

We hope to release PRTG 8 within the next 2-3 weeks. Please bear with us.

Created on Sep 13, 2010 3:21:19 PM by Torsten Lindner [Paessler Support]




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.