Nms current design

Design Information

All systems are deliberately being designed on UNDER POWERED machines.

• Frontend + Backend + Daemons running on a 2 core, 2 Gig RAM, 100GB Drive KVM Guest
• as of 07-15-23, ~80 hosts, and several hundred checks end up with 300MB RAM use with little to no IO wait
• 4.5% userland and 3.5% system in use
• Currently using Apache for frontend and backend on different ports. SSL enabled on API but not frontend

Backend

The backend is PHP 7.X using the Slim4 framework. Composer is used for additional functionality, however most of the installed packages are not actually being used. These are going to have to be removed and get down to the core packages needed before posting the code publicly.

• This is going to be migrated to PHP 8.3 as soon as reasonable to test

Frontend

Frontend is Bootstrap5 and PHP7.x

1. No database connections will EVER be allowed from the frontend. Anything to do with the DB must use an API.
2. Attempting to keep complex PHP out of the frontend. Mostly specific to rendering and curl calls
3. RRD graphs are rendered on the API server, not on the frontend. Do not pass unnecessary things to the frontend for security
4. AFAIK all icons and images are copyright free. If any are found not to be pull ASAP or create your own
5. No passwords stored directly on frontend
   1. single exception is a failsafe that will alarm anytime it is used
   2. This will be hard-coded so it cannot be silenced as it is last resort only
   3. API keys will be leveraged beyond user auth. Only "blessed" UI's will be able to talk to the APIs for sensitive data
      1. Making the assumption that there could be a kiosk UI that is different than an Ops UI outside of User access levels
6. User auth is still in the thinking phase, nothing implemented yet.

Database

• Currently using MySQL 5.7.
  • This is a deliberate choice follow a KISS principle where there are not new features in on version making it mandatory to upgrade to version X every time there is an upgrade. It also makes it easier to transfer between MySQL, MariaDB, and Postgres, or really ANY database that follows a SQL format.
• Old Ubuntu 12.10 host 4core, 1GB RAM, 40GB Drive, KVM Guest (many, many! multiple other services running on this as well)

1. Next plan is MariaDB latest stable
2. can almost guarantee a simple upgrade due to the way the database was designed
3. investigate a versioning path for upgrades on the software.
   1. basically apply patches that reflect if they were applied or not.
   2. think newznab and how they update the database on patch and version changes
   3. consider possibility of user bypass for patches as well. There may be reasons for a user to say no, not going to happen.
4. begin investigation of PostgreSQL support.
   1. May be less painful than anticipated due to classes.
   2. Begin building a default class to deal with Postgres, as what I use now is MySQL specific

Metrics

1. RRD stored locally on the API server. API will generate and display the images for the frontend to consume. Raw data is NEVER sent to the frontend for rendering unless there is no other option. JavaScript will be the death of me. I suck at it so badly, and really it seems to make the site SO MUCH SLOWER to have client side work done for complex things.
2. Graphite is running on 4core, 4GB RAM, 100GB drive KVM Guest with other apps running on it. Initially my thought was to use Graphite as the main graph engine, but thinking about small business, as well as being able to do future predictions I felt RRD was the best way to start this, and have Graphite supported but not the default graph engine.
   1. The graphite support I have in place currently is going to have to be redone in the "template"style so that adhoc stuff can be more easily added in the future. right now it is a series of regexes and database hacks that I am not happy with.

Templates

These all live on the API host within the templates directory. These are going to have to be expanded much further. Additionally the "templates" table is going to have to be leveraged more going forward. Currently templates exist to push metric data to rrd, graphite, and the database. Additional templates are in place for rendering RRD files. I prefer this route so that we can change templates easier going forward.

Daemons

Daemon controls have all been written in PHP. This likely is not the best language to write a daemon in, but I wanted consistency with what the rest of the application is written in. If I ever get additional support, I will likely have this revamped to Python.

SNMPTRAP

The snmptrapd system forwards all SNMP traps to a PHP script which parses and forwards events into the system after being processed.

NRPE

Leveraging the Nagios Plugin system for adhoc or external checks to add additional functionality. Currently supports a basic metric ingestion into RRD, but does not have a good rendering tie-in yet.

SNMP

Currently using the net-snmp package via shell exec. I wanted more control over how SNMP responded than I could get with SNMP Classes or composer installed support applications. Also I FIRMLY believe if a machine is doing something a human MUST be able to duplicate the behavior. Using shell commands makes this easier to work with.