Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - kghammond

#16
General Support / Process.UserTime, Process.KernelTime
February 08, 2008, 05:31:16 PM
I was looking at trying to collect the CPU time for individual processes via the agent.  The supported agent paramaters are Process.UserTime and Proccess.KernerlTime.

Perfmon lists three different Process counters:
Process.% Priveleged Time
Process.% Processor Time
Process.% User Time

It appears that Process.% Processor Time = Process.% Privelaged Time + Process.% User Time.

Do you know if my understanding is correct and is there a reason the agent does not collect the Process.% Processor Time value?  Also the doucmenation states that the Process.UserTime and Proccess.KernerlTime are both listed in miliseconds instead of a percentage.

Is there a way to graph the Process total CPU time as a percentage?  Would you be able to add in support to have a 1/5/15 minute average for process CPU time as well?

Thank you,
Kevin
#17
Yes you may publish it.  Thank you for asking and I am glad I can help.
#18
I updated teh spreadsheet to include support for one table per node.  The results were almost identical in the size versus one big table.  I attached the updated spreadsheet.  There are two tabs.  You should be able to use either tab to do any space planning.

The center column is the one that mimics your database enviornment.  The space planning still estimates that you could reduce your database close to 3.6 GB if you used int's over varchar's in the SQL tables.

Kevin
#19
I updated the spreadsheet to include the sizing of the clusted index and the nonclustered indexes.  I pulled the index definitions from one of the idata_nnn tables.

This should be a lot more realistic comparison and this should be a lot more useful for SQL server space planning.

One estimate this is still ignoring is that I think you create a table per dci.  This spreadsheet still assumes that you have one table that holds all the rows of data.  I think the size will go up slightly if I modify the spreadsheet to include one table per dci, but this spreadsheet should get within 5-10% accuracy with the avg size varchar assumed from your database size.

Kevin
#20
The non-clustered index will add some size to the database.  I will try to add that into my spreadsheet to account for the non-clustered index to get a more accurate average usage.

Thank You,
Kevin
#21
Thank you for the feedback.  I have put together a quick spreadsheet showing the estimated row size based on a average row size from your database.  I am sure the average row size estimate is probably a little off but it should be useful as a guide in scaling and capacity planning.

I had to do a few estimates.  I am sure we could get a more accurate number from your SQL database but everyone's average varchar size will change depending on what they are polling.

Also for comparison, I put in a comparison column to the space required if you stored integer values as int instead of varchar.  Assuming all data could be stored as int (which I am sure not all records could be stored as int), the estimated database size for 1769 dci's at 60 second polling for 30 days would be 1.7 GB.

See the attached spreadsheet for more details.  I created the calculations based on the information from the Microsoft MSDN page using a few assumptions stated above.

Also on a side note, are you creating a clustered index or any non-clustered indexes on the tables that store the rows of data?

Thank you,
Kevin
#22
We are using MS SQL server for the database server for NetXMS.  Do you know how much space each polling interfaval takes up per DCI?  I assume this varies based on int, bigint, float, string (are you using varchar's?).

It would be nice to have a table of the various DCI polling and how much space that will use up for the specified database server.  We are trying to determine how often to poll and how long to set the retention times on our DCI's but it feels like guesswork right now.

We expect to have somewhere around 100 switch ports with at a minimum of in/out and errors for now, and then 30-40 servers with a minimum of network activity, cpu, memory, disk space, disk activty.

Right now we have about 40 GB of RAID 10 drive spaces set aside for NetXMS.

Any kind of guidance you have would help.

Thank you,
Kevin
#23
General Support / Re: Changing the name of switch ports
February 05, 2008, 04:30:50 PM
Thank You, we are just starting to use NetXMS and it seems great so far and we are looking forward to the improvements of the next version.

Any rough idea when you may finish the next release?

Thanks again,
Kevin
#24
General Support / Re: Can't compile DELL 5224 MIB
February 05, 2008, 04:29:00 PM
Thank you the corrected MIB file worked perfectly.

Kevin
#25
In addition to the above, bandwidth utilization per port would be cool as well:

(IfInOctets+IfOutOctets)*8*100/ time*IfSpeed IfSpeed is an estimate of the current bandwidth in bits per second. IfSpeed = 1.3.6.1.2.1.2.2.1.5

Kevin
#26
We would like the ability to monitor  Switch ports in more depth.  Below I listed a group of OID's that we would like to monitor for threshold alerts.  Most of these would need some form of a template, macro or table based ability to manage SNMP interfaces.  I know you have talked about adding table support.  I don't know exactly what that means, but we would like to be able to customize the OID's that require an interface to include some or all of the below and to be able to easily customize a threshold for these.  For instance most of the error and collisions OID's we would want an alert if they increment at all.

So on a 24 port switch, if say only 16 ports are active at the time, it could monitor those 16 ports for any increase in the appropriate OID's from below.  Now another interesting thought, is do you dynamically or statically define which interfaces you monitor?  You could dynamically gather the "up" interfaces and apply these to that by default and then override that setting with any specific entries.  Then you could maybe monitor the whole array of interfaces and alert separately whenever an interface goes up or down.  In our particular case, we are talking about switches full of server ports, some of them teamed and some on LAG groups.  So we in particular went 0 errors and no interfaces should be going up or down unless we are rebooting or doing maintenance on a server.

At the same time, you could also monitor the configuration OID's to see if the speed, or duplex setting or some other setting has been changed.  That shouldn't happen, but it would be nice to know right away if somehow one of the interface had its speed setting changed.  We also noticed on one of our switches that a gigabit nic was only linked at 100Mbps.  That would be nice to have a way of detecting the currently active speed against a threshold of what it should be.

I know most of these can be done right now, but to do all of this right now, it would take somewhere in the range of 500 DCI's for a 24 port switch.

One last thought, the data retention for these would most likely be significantly different than in/out bandwidth so these system would need to easily support separate data retention rates for groups.

It almost seems like you need to build a dynamically growing table where you can assign the interface on one side and then the OID's to be applied on the other side and then checkboxes or something of what you want to monitor for each interface and then have the correct DCI parameters applied behind the scene.  You could maybe have a second tab that is a configuration tab, where you could then select multiple interfaces/OID's and apply common DCI parameters to them...

Just some thoughts.

   .1.3.6.1.2.1.10.7.2.1.2  AlignmentErrors
   .1.3.6.1.2.1.10.7.2.1.3  FCSErrors
   .1.3.6.1.2.1.10.7.2.1.4  SingleCollisions
   .1.3.6.1.2.1.10.7.2.1.5  MultipeCollisions
   .1.3.6.1.2.1.10.7.2.1.6  SQETestErrorrs
   .1.3.6.1.2.1.10.7.2.1.7  DeferredTransmissions
   .1.3.6.1.2.1.10.7.2.1.8  LateCollisions
   .1.3.6.1.2.1.10.7.2.1.9  ExcessiveCollisions
   .1.3.6.1.2.1.10.7.2.1.10 InternalMacTransmitErrors
   .1.3.6.1.2.1.10.7.2.1.11 CarrierSenseErrors
   .1.3.6.1.2.1.10.7.2.1.13 FrameTooLong
   .1.3.6.1.2.1.10.7.2.1.16 InternalMacReceiveErrors
   
   .1.3.6.1.2.1.16.1.1.1.3  DropEvents
   .1.3.6.1.2.1.16.1.1.1.8  CRCAlignErrors
   .1.3.6.1.2.1.16.1.1.1.9  undersize Packets
   .1.3.6.1.2.1.16.1.1.1.10 oversize Packets
   .1.3.6.1.2.1.16.1.1.1.11 Fragments
   .1.3.6.1.2.1.16.1.1.1.12 Jabbers
   .1.3.6.1.2.1.16.1.1.1.13 Collisions
   
   .1.3.6.1.2.1.31.1.1.1.15  Inteface Speed (1000, 1000, 10)
   .1.3.6.1.4.1.674.10895.4.1.2.1.1.8 Current Duplex Status(Might be an integer)
#27
Quote from: Victor Kirhenshtein on March 23, 2007, 06:29:58 PM
Hello!

Currently, you have only one way: define two DCIs for each port, and configure threshold for each DCI. Of course, it can be very time consuming for large number of ports. In one of the next versions (0.2.16 or 0.2.17, depending on my free time) we plan to implement "table" DCIs which will allow you to define parameters which differs only in instance only once, and system will automatically generate actual DCIs for each parameter's instance (for each port in your case).

Best regards,
Victor


Has this been implemented yet?  We are trying to setup inteface bandwidth per switch port on DELL switches to start, Cisco switches later.  I tried using a template and putting in the OID's  .1.3.6.1.2.1.2.2.1.10 and .1.3.6.1.2.1.2.2.1.16  But it seems the template needs to know the instance ID for each of the DCI's. :(

It would be nice if you could dynamically assign the instance number based on table of some sort.

I guess this kind of breaks the way you have templates setup.  Say you have 4 switches that are all the same, so you want a template for each of the switches.  Then you might want another template for each switch that defines the port monitoring on that specific switch.  It is almost like you need nested templates.

Thank you,
Kevin
#28
General Support / Re: Changing the name of switch ports
February 04, 2008, 08:19:43 PM
There is also a DELL MIB OID for port name:
.1.3.6.1.4.1.674.10895.4.1.2.1.1.2
#29
General Support / Re: Changing the name of switch ports
February 04, 2008, 08:17:06 PM
Quote from: kghammond on February 04, 2008, 07:20:15 PM
Thank you, I did manually force a configuration poll before posting.  But, after doing a SNMPWALK, it seems that the names being returned via SNMP are hardcoded interface names, not the names we assigned each port  :(

I am guessing that we will need to manually name each port, since NetXMS will not be able to query a differnet name for the port.

I will post to the wishlist.

Thank you, and I just want to reiterate that this product seems to be well done and it seems to fit a nice niche.  We have been searching for a tool similar to this for awhile.  Most of the monitoring tools will either monitor or they will track performance, but few can do both relatively well.

Thanks again,
Kevin


Actually, after doing a more comprehensive SNMPWALK, I found the correct inteface names lised under the SNMP OID:
.1.3.6.1.2.1.31.1.1.1.18

Is there a way to use this name for each port instead?

Thank you,
Kevin
#30
Feature Requests / Refresh reverse DNS PTR names
February 04, 2008, 07:22:19 PM
We would like to see NetXMS be able to refresh the dns name displayed as the reverse DNS PTR names are updated.  In our case, we had some stale reverse DNS records and now the display names in NetXMS are not very accurate.  So instead of just cleaning up the reverse DNS entries, we also need to clean up the NetXMS display names.

Thank You,
Kevin