Cacti and command line
Moderators: Developers, Moderators
I do understand your request, and have heard it from a few people so far. I do think this would be a very valuable feature to cacti, but I cannot garentee when I would be able to impliment such a feature. Ideally it would be a small php script that could be run at the command line. It could also be perl; but that would require DBI-MySQL to access cacti's database.
If anyone else has any further thoughts on possible command line support for cacti, please voice them here.
-Ian
If anyone else has any further thoughts on possible command line support for cacti, please voice them here.
-Ian
Sure, there are many ways this can be done, but frankly, you'll save yourself a lot of time and headaches and do everyone a favor if you implement this in PHP using the same code as for the web UI. There is no sense in duplicating code/effort!raX wrote:I do understand your request, and have heard it from a few people so far. I do think this would be a very valuable feature to cacti, but I cannot garentee when I would be able to impliment such a feature. Ideally it would be a small php script that could be run at the command line. It could also be perl; but that would require DBI-MySQL to access cacti's database.
raX wrote:If anyone else has any further thoughts on possible command line support for cacti, please voice them here.
-Ian
In my mind, it is absolutely critical to have. The web UI is pretty okay, but could be a lot better with some subtle use of javascript or whatever trick that would spare us having to submit/reload pages for every small thing. (Note the "subtle", i'm not a big fan of broken scripts that only work on 1 version of 1 browser )
Example: Try adding couple items near the top of the list of a graph with 20 items. Total nightmare. (For this particular thing, top/bottom options would help)
But beyond this, and my general distate of GUI, cacti is actually pretty decent in that regard, and a useful way to get started.
But let me get back on track.
a CLI interface for configuration purposes is an absolute must. Instead of this, i already know people messing around directly with the SQL and having recommended that i do the same if i have many systems.. but while it would certainly work, it is just plain wrong. By not developing the CLI yourself and giving it to us, you're causing many separate implementations which all depend on the current DB schema.. not a good thing.
a CLI is a MUST for anyone to be able to sanely deal with:
- a large number of monitored entities
keep configurations consistent between systems
audit/validate the configuration
Hi
Let's see how do I make a new graph now if I have custom data input with an input parameter, multiple output parameters and a working graph as example:
1) create datasource: always I must select rra-s, maximum value and so on (duplicate is not possible with multiple output parameters);
2) set input parameters;
3) duplicate similar graph;
4) rename graph;
5) reselect datasource for each graph item (not needed for gprints, thank god);
6) add graph to tree;
If I plan to create 4-5 different performance graphs for 100 servers, I need master degree of mouse clicking...
Solution 1:
To make feature to save a datasource-graph pair as template. When I need similar graph for another host, application will ask only datasource and graph name and input parameters in one page.
Solution 2:
I made a perl script for inserting all data to mysql database directly.
aldo (@microlink.ee)
Let's see how do I make a new graph now if I have custom data input with an input parameter, multiple output parameters and a working graph as example:
1) create datasource: always I must select rra-s, maximum value and so on (duplicate is not possible with multiple output parameters);
2) set input parameters;
3) duplicate similar graph;
4) rename graph;
5) reselect datasource for each graph item (not needed for gprints, thank god);
6) add graph to tree;
If I plan to create 4-5 different performance graphs for 100 servers, I need master degree of mouse clicking...
Solution 1:
To make feature to save a datasource-graph pair as template. When I need similar graph for another host, application will ask only datasource and graph name and input parameters in one page.
Solution 2:
I made a perl script for inserting all data to mysql database directly.
aldo (@microlink.ee)
Umm http://www.raxnet.net/board/viewtopic.php?t=655
cacti_inject is a commandline insert script for cacti that either automatically imports an RRD file's datasources, and RRAs OR allows you to manually enter stuff.
I posted this a long time ago, and was wondering why no one really replied. The version that's up right now supports parent datasources, child datasources, rras, graphs, and graph items. I've added support for cdefs, cdef items, and am right now working on hierchy and adding a couple of features like checking to make sure you're not inserting a duplicate record, and fixing my graph_item parent problem. I'll post the updated version when I finish with those, soon.
Adding graph_items (and all of the *_items for that matter) is a little trickier, because you'd need to know the id of the graph to put the item in (or of the datasource, or the cdef, or the heading...), so I have you use the exact graph title, or datasource name, etc. The same goes for children's parents. There's some basic usage info if you follow the link. More detailed help can be gotten using the -h option. The script requires perl 5.005+, DBI, and DBD-mysql.
I use cacti_inject extensively in a shell script. When I add a host (with between 10 and 50 graphs per hosts), I just run my script. Right now I still have to create my hierarchy manually, but I should be done soon (I think next week).
Aaron
cacti_inject is a commandline insert script for cacti that either automatically imports an RRD file's datasources, and RRAs OR allows you to manually enter stuff.
I posted this a long time ago, and was wondering why no one really replied. The version that's up right now supports parent datasources, child datasources, rras, graphs, and graph items. I've added support for cdefs, cdef items, and am right now working on hierchy and adding a couple of features like checking to make sure you're not inserting a duplicate record, and fixing my graph_item parent problem. I'll post the updated version when I finish with those, soon.
Adding graph_items (and all of the *_items for that matter) is a little trickier, because you'd need to know the id of the graph to put the item in (or of the datasource, or the cdef, or the heading...), so I have you use the exact graph title, or datasource name, etc. The same goes for children's parents. There's some basic usage info if you follow the link. More detailed help can be gotten using the -h option. The script requires perl 5.005+, DBI, and DBD-mysql.
I use cacti_inject extensively in a shell script. When I add a host (with between 10 and 50 graphs per hosts), I just run my script. Right now I still have to create my hierarchy manually, but I should be done soon (I think next week).
Aaron
Thanks for the reply, i had not seen this!yid wrote:I guess I should add: If you have any suggestions on how to make this script easier to use, Let me know, please!
Aaron
this sounds like a great start, i guess i'm stuck having to install the necessary perl module (*grumble*), too bad it isn't in PHP i guess.
you'll most certainly hear from me as i start using it, unless it's already incredibly good. Two comments already:
(1) knowing the exact graph title and such is not a problem for scripts.
(2) all that's lacking now is a way to query/delete. (In particular for graphs: If all graphs are standard, it must then be easy to make a change to all graphs.. the easiest way sounds like it'd be to just delete and recreate?) [PS: if that's there already, then i have missed it and will find out soon enough.]
I've been working on cacti_inject like mad for the last couple of days (just finished some other code), and am finding ways to make it a lot better. A new cleaner version will be out soon.
What modules are you having trouble with? I left Data::Dumper in there by accident, so you can remove that. Getopt::Std should be standard. As for the RRD shared libs (RRDs) look at the line above:
modify that to fit the location of the RRDs.pm (comes with RRD).
I'll start thinking about changes/deletes/queries...
Aaron
What modules are you having trouble with? I left Data::Dumper in there by accident, so you can remove that. Getopt::Std should be standard. As for the RRD shared libs (RRDs) look at the line above:
Code: Select all
use lib qw( /opt/rrd/lib/perl ../lib/perl );
I'll start thinking about changes/deletes/queries...
Aaron
I've finished the new version a little later than I thought.
here's where I posted info about it
http://www.raxnet.net/board/viewtopic.php?t=655
here's where you can get to it directly
http://www.birch.net/~spiegela/cacti_inject
No support for queries or deletes yet...
Aaron
here's where I posted info about it
http://www.raxnet.net/board/viewtopic.php?t=655
here's where you can get to it directly
http://www.birch.net/~spiegela/cacti_inject
No support for queries or deletes yet...
Aaron
Who is online
Users browsing this forum: No registered users and 1 guest