Home

Running OpenNMS components in various environments and workloads, makes it complicated to size and scale. Especially when you want to size it for extremely large deployments. There are various challenges that make this a complicated task:

External critical service dependencies that OpenNMS relies on and doesn’t fully control. Typical services are:

• PostgreSQL database
  • Apache Kafka for distributed deployments, e.g. Minion and Sentinel or optional
  • Apache Kafka as a northbound integration layer using the kafka-producer
  • Elasticsearch for Flows or Events and Alarm forwarding
  • Underlying storage systems and capabilities
  • Network reliability and latency
• Mixture of different monitoring requirements and applied workloads, e.g. Syslog, Trap reception, Flows, service Monitoring, data collection

Beside external services there are other variables influencing performance characteristics of the monitoring system:

• Responsiveness and reliability of the underlying network infrastructure.
• Physical hardware specifications, cores, thread per cores, RAM and IOPS
• Running on shared resources where policies + hardware specs influencing heavily the base line performance
• Running in a container environment, the container resource policies + hardware specs influencing heavily the base line measurement. If the nodes running containers run on virtual machines, the factors of the VM resource sharing policies are added.

Efficient use of hardware resources can be achieved with container deployments in combination of slicing large hardware services with VM's. From a sizing perspective there are now a lot of variables affecting the base line performance which makes it hard to predict how much of a workload a given deployment can handle.

This document is providing an approach how you can get some performance baselines for a given target deployment.