Switches, Hubs, and Modems
Showing results for 
Search instead for 
Did you mean: 

PCM+/NIM stat collection size over time

Occasional Visitor

PCM+/NIM stat collection size over time

PCM+/NIM must keep a list of statistics per offender somewhere. How do the sizes of those lists get managed? i.e., the lists must be recycled or cutoff in some way. Is that configurable?

Natasha Samoylenko
Trusted Contributor

Re: PCM+/NIM stat collection size over time

As I remember NIM events looks like general PCM+ event.
So general preferences may help you.

Setting Event Archive Attributes
1. Open the Preferences window and select the Events option to display the Global:Events (browser) configuration window (Tools > Preferences > Events).
All SNMP traps and PCM events are archived under /server/data/events/[CommonArchive|SyslogArchive|IDMArchive] with filename prefixes of EVT-. The default installation directory is:
/Program Files/Hewlett-Packard/PNM

5. To change how long events are held before being archived, select the Archive Events Older Than number of days. By default, events are moved to the archive file after 7 days. This setting affects both SNMP traps and PCM events.

6. To change the amount of disk storage that can be consumed by the Event Archive file, select Limit archive storage to and set the space (in gigabytes) available for storage. By default, PCM event archive space is limited to 1 gigabyte. This storage size is used for both SNMP trap archives and PCM
event archives.

This info is from PCM Admin Guide, chapter Setting Event Preferences.

I hope this helps you
Occasional Visitor

Re: PCM+/NIM stat collection size over time

Thanks for the reply.

I'd seen that section in the manual but I was thinking more about the offender-specific statistics (counts, etc.), rather than the initiating events -- or are they linked in some way? Does each event have a list of offenders tied to it, or does each offender have a list of events tied to them?

I've been assuming that the NIM state is persisted in some way -- separate from the PCM/SNMP event logging -- so that the machine can restore NIM state after a failure/reboot.
Steve Britt
Respected Contributor

Re: PCM+/NIM stat collection size over time


It is not possible to configure the period over which NIM tracks statistics to determine the offenders in various categories. NIM analyzers on the PCM/NIM agent track numerous lists that are built and maintained over a period of time based on incoming sFlow datagrams. The size of these lists is regulated by the fact that they're kept for a nonconfigurable time period rather than being cut off at a particular depth, but the nature of the lists is also such that they don't become unwieldly during that time period even with very large address spaces to track. Baselining algorithms are applied to most of the lists to detect anomalous traffic; establishment of the baselines takes a while (12 hours I think) as reported in the NIM panel of the PCM/NIM dashboard (this panel also indicates which NIM analyses do and don't rely on baselines). When an anomaly is detected by a NIM analyzer on the agent, the agent generates an event which is then fed to the NIM server component and can (optionally) be used to trigger policies against the identified offender based on the location of their edge port in the network.

The NIM analyzers' lists are persisted by the agent so that if the agent is shut down or crashes NIM can recover and continue baselining. However, due to the sensitivity of the baselining algorithms if the agent is inoperable (including not connected to a PCM server) for some period of time (10 or 15 minutes as I recall) the agent's baselines will be flushed and re-established anew when reconnecting to the server. The resultant events that were sent to the server are persisted and managed like any other events (e.g. those that may have resulted from an SNMP trap that came directly from a device) so those are protected if the server bounces.


Occasional Visitor

Re: PCM+/NIM stat collection size over time

Thank you for the detailed response.