Data Collection delay
-
This is more of a general question.
When monitoring a Node - DCI Values I notice that the CPU Usage (for example) is monitoring values with timestamps that are close to real-time. When I look at the same CPU Usage example through Data Collections I noticed the timestamps are behind by 2 minutes. I thought at one point we were closer to real-time for Data Collection monitoring which ultimately drives the graph display.
What should the delay be? Is it adjustable?
Comments.
Tony.
-
Hi!
On "Last Values" page for node you see time stamp of last poll and last collected value, both cached in server's memory. When you are looking at DCI history (either as text or as graph), data shown taken from database. Inside NetXMS data collection going in two steps - at first step, data collected from agents and put into writer's queue. On second step, data is taken from writer's queue by separate background thread and written to database. Usually second step goes instantly after first one, and last value in database is last value collected, but some times there could be bottlenecks in writing data to database and some data may still wait in the writer's queue. In this case you will see that data in history is behind current time. You can check if this is the case by looking at database writer's queue size (either via DCI at monitoring server or via server's command line). If it is constantly large or even growing, then database writer is not able to write all data to database on time. In that case, you should first try to increase number of database writers (by increasing value of NumberOfDatabaseWriters configuration parameter) and, if this does not help, check your database engine for performance problems.
Best regards,
Victor -
Victor thanks for the reply.
I changed to NumberOfDatabaseWriters to 2 threads. Do I need to restart the NetXMS Core service?
As to monitoring the database writer's queue size I only see 2 options under the DCI collection (System I/O DiscQueueLength and System I/O BusyTime) under Windows. The value I see with System I/O DiscQueueLength is 8.000. With Average Disc Busy Time has peaks at 765.000. But under the Linux OS I do see additional System I/O options.
Hope this makes sense in how I have written this.
Thanks again for the support
Tony.
-
Hi!
Yes, you need to restart NetXMS Core.
For monitoring internal database writer queue, you should look at parameter with source "Internal" (not agent!) and name "Server.AverageDBWriterQueueSize". This parameter is only available for node object representing NetXMS server itself. DCI for this parameter should be created by default.
Best regards,
Victor -
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login