Formal NISCA To-Do List
This is a place to keep my thoughts organized about what I'm working on for NISCA
and what I'll have to do to bring them about. Notes To Myself. This is also meant to be
the final word, the ultimate repository, for all To Do items. Just about everything listed
here can be considered "vaporware" for the moment; until life stops beating me about the head,
I won't have time to do most of them. Anyway, here are all my ideas so far.
- First and foremost: abandon all limitations and inflexibility. Rigidity is the hallmark
of a dying product. NISCA must be liquid, able to fill any crack, do anything the user
requires of it... and it must do it quickly and efficiently, and be easy... nay,
TRIVIAL
to install, set up, configure, use, and even uninstall (but nobody will want to uninstall
it once I'm finished with it).
- Automate, automate, automate! Everything! All of it! Mwahahahahahahahaha!
- Make it able to collect data of any kind, from any source.
- This includes other SNMP MIBs/OIDs as well as "anything which generates data points."
For example, you might want to monitor how much disk space you use over time.
NISCA should let you use the output of a "df" command instead of an OID, and give you
a flexible way (regexp?) to parse the output of said command so you can pick out which
fields (delimited by any character imaginable) you want to collect. Something like the
way Apache does its logfile formatting (% commands to denote fields, you know).
Oh, I know; when you define the data source, it does a test-run of it and presents you
with the output from it, then asks "Which fields do you want, and from which lines?"
<not_sarcastic>Oh, God, that's gonna be fun.</not_sarcastic>
- Some data is running totals (bandwidth usage). Some is individual points (temperature).
Some needs to be averaged over a certain time (bandwidth). Some shouldn't be (disk space
should be graphed as-is, for example, but you might also want a graph of how much
it changed in a certain time, which isn't averaging; it's friggin' Calculus).
Some data is even Boolean (administrative up/down status on an interface, for example).
It'll have to know which is which during reporting, but not collection.
- You should be able to view the data in a report any way you want to; if you want
to see your CPU usage as a running total, who am I to argue?
- Calculations and graphs will have to be more customizable to accomodate this.
- makegraph() in particular will need more features:
- Custom axis labels.
- User-definable units ("M" for megabytes, "F" for Fahrenheit, "C" for Celsius, "%", "", etc).
- Different watermarks for a particular data source(s)? Maybe?
- Not assume you have to divide the data by 8 if it's bytes. YKWIM.
- More than two traces per graph. Ugh.
- More of an "MRTG" look & feel; like, filled-in traces for outgoing,
ability to graph the time axis backwards, etc. Some people have, erm, gotten used to
the way MRTG graphs look, and actually don't like NISCA graphs. Go figure.
- Whatever happens, don't get rid of the Truetype font support.
- Don't Forget: the primary concern is to keep it easy to configure!!!
- Two words: "Better GUI." (Or is that four words?) All these extra features are going to
require a substantially-improved GUI for report options and admin functions and such.
- The GUI must be all-HTML; I want Nisca usable from any browser anywhere in perpetuity.
- Frames? No.
- Javascript? Where appropriate.
- DHTML? Hmmmm... mayyyyyyyyyybe.
- CSS? Already being worked on, but it can't enhance the usability of the GUI,
only its colors and font sizes and such. What's being worked on is a standard CSS style
sheet that's loaded into every Nisca page's <head>. (Like that metaphor? :)
You just define styles you like for the various
types of tags, and that's what you get on every page. Neat, huh? Oh, and it's a tossup
whether the styles you define will go into an actual file or a database table... but
I'm leaning towards database. Any thing that means there's one less file to edit by hand
from pico or something else shell-ish is a good thing. What do you all think?
(I really resisted saying "y'all" there, I really did... I'm from Texas, you see.
You can't tell by looking... or listening... but some things kinda stick in you after
thirty years of constant exposure to them.)
- Probably, what is now Nisca's main menu will be replaced with a more general menu,
or rather moved to another filename. The new main menu will be like a choice between
viewing a stored report, setting up the options for a custom report (what is now the
index.phtml file), setting up the options for a trending report, setting up a cost
report, err... just have a dropdown list for "Select desired report type" and list
the choices in there. And also a link to the admin menu. But of course, the user will
first have to get through the no doubt formidable security to get to the menu.
- Oh, might as well mention I won't be packaging every previous update script with
the Nisca distribution. It just seems... silly now. They'll be available for download,
of course, and they're very small. Usually.
- Make it so the graph images can be streamed onto a page, rather than being saved
to a file first (so there's a lot less disk I/O and cleanup's a snap).
- Make it so there isn't a separate $stamps[] array (just get keys from cnt_rbytes, etc).
Unless that would make calculations more intensive... speed is more important than memory
usage. I think.
- Change the stats re-averaging utility so you can re-average more than one IF at once
using the same selection/interval criteria.
- Change both the stats deletion and re-averaging utilities so they list hosts first, then
data sources, if you have more than, ohhh, 30 data sources altogether or so, to make it
friendlier for people with 10,000 sources to sift through.
- Make it detect incorrect date/time settings somehow, so if you change your system clock
accidentally it doesn't insert a thousand entries into the database dated sometime in 2016.
This may, please note, be entirely impossible to do; it may only be possible to clean up
after the fact should this occur.
- Redo the collectors in a non-PHP language so they actually work right.
- Perl or C are the options.
- If it's done in C, might as well do all of NISCA in C.
- I don't know C well enough to program in it yet.
- I'd have to write my own C API routines to access mysql, libgd, and net-snmp libraries.
- Perl collectors for NISCA already exist.
- If a third-party SNMP PHP module can be found, it might be a solution. I know some people
are working on it... but that would mean everyone would have to get that module and
custom-install/compile it into PHP themselves. Hmmmmm...
- Redoing some of NISCA's functions in C would be good too; much faster, at least. For things
like the multiple-interface calculations, which take forever.
- Make the data collection interval non-global. You might want to collect data on one thing
every minute and only once an hour on other things. This won't affect graphing much; NISCA
already expects data to be at odd intervals.
- Make it able to collect data down to the protocol/address/port level. So you can tell how
much of your bandwidth is going to HTTP, how much to FTP, how much to the Nimda Worm, etc.
This, I suppose, will require perhaps some kind of interface to iptables or some such...
but, of course, only Linux uses iptables. How could port-level data be collected from
a router, machine, or network? Promiscuous-mode packet sniffing? Sounds almost Orwellian...
"Now with optional ftp and telnet user/password logging support!" Heh. Probably make NISCA
illegal under the Glorious Ashcroft Subjugation Act of 2001 or something...
- Make it simultaneously support all SNMP versions. And hey! This is already done!
- This eliminates PHP completely for any page that uses SNMP (barring a 3rd-party SNMP module).
Back to "C or perl" again. I may end up making my own net-snmp interface... ha...
- Make a (non-PEAR) database abstraction layer so it works with other RDBMSes, like Postgres,
Oracle(c), and Excel(tm).
- This means making different versions of the SQL commands to create and update NISCA's
database structure, too (installation).
- I doubt I can do this one alone.
- Redo user authentication:
- Add authentication checks to all Nisca pages. I guess I might as well
merge functions.php and security.php into just functions.php, and have a config toggle
that turns non-admin-page-viewing authentication on or off. Mas flexibile.
- Make High Admins and Low Admins.
- Make Groups; assign a User to a Group and they can see/do whatever the Group can see/do.
- Users/Groups can be given permission to only view certain data sources, hosts, and
reports... or all of them, even if they're not an Admin.
- Make ability to assign different admin privileges for a given Group; e.g., a customer
has a Low Admin which administers the Users in his Group.
- Perhaps have a 1-10 scale of "adminosity"? 10's can do anything, 1's almost nothing?
Or just have a list of all possible admin functions on a user's page and say "Turn on
the ones you want this user to have access to" with safe defaults filled in (like Bugzilla).
- The High Admins can do anything anywhere, of course, including creating the Low Admins.
- Logging might also be a good idea. Every time an admin function is performed, log it.
Every time a collector fails to reach a particular data source, log it. And so on.
In a distributed environment, though, this would mean the log data would have to be cacheable
like SNMP data should a collector's database link fail.
- Redo NISCA's basic internal structure.
- The whole SQL structure will undoubtedly change. It must be kept in such a way
that all existing data can be seamlessly ported into the new structure with a minimum of fuss.
- The $interfaces array of arrays of arrays is hopeless.
- The way communities are stored is ridiculous.
- The OID array creation function, however, is bloody flawless. :)
- Add an "active" flag to the interfaces table; if set, the data source is monitored.
If not, it isn't. Don't just delete data source info; let people shut them off instead.
- Different kinds of reports:
- Trending to any point in the future. Predictions, that is.
- Things like "how much, at $x.xx per megabyte, did this link cost me in October, 2000?"
(in the form of a graph or text). Also with trending. And remember, not everyone uses dollars.
- Multiple collectors running at multiple sites saving to multiple databases as a single system.
This means the ability to cache data in case a collector's link to the database goes down.
- Maybe, possibly, sell plug-N-play pre-installed NISCA server machines of some kind?
Or just a distribution of everything you need for it in one CD/ISO/tarball, maybe?
Would the owners of apache, php, net-snmp, libgd, etc, etc allow that? I kinda doubt
Mr. Boutell would... for free, at least... meaning I'd have to charge for NISCA
distributions... sigh.
- Whoa! Here's an idea: animated graphs! With the Flash library in PHP, you can
actually generate dynamic SWF animations, with clickable buttons and controls and all,
without having to pay $10,000 for Macromedia Generator(tm).
Got a sales meeting? Just run a report on a browser in their conference room and there's
a graph of the last year, separated by months with little sparkly things all over it...
of course, it'd probably be huge, and take forever to generate, but you could create it
beforehand and save it somewhere... and it would be impressive enough to make it worth
the effort. Good thing I learned Flash... and how certain managers think. This could be
the one selling point that makes all the difference.
- Start really taking NISCA seriously.
Estimated time of completion:
Years and years and years unless someone HIRES ME!!!