Is it possible to do this?
Moderators: Developers, Moderators
Is it possible to do this?
Hi, im new to Cacti and so far it runs fine in my test install.
I was wondering if this can be done before bothering more into exploring and putting Cacti into a production,
Is it possible to change the Inbound/Outbound Data Sources interfaces in a Graph via some API, the command line or even editing directly a configuration file?
I need to constantly change the source of some devices, which have a state which changes, this means their SNMP interface changes all the time, and even while at first look I see I can select manually in Cacti which I want for a graph, I assume if I do this, the graphic output will continue as normal with the new data source selects. If yes, this is nice, but I need to automated this.
This means, with a script that changes this on a config file, an API command or in the command line.
Also, what are the biggest installations running Cacti on a single server or even distributed? My point is, could Cacti handle 1000 ethernet cards still running fine at 5 minutes intervals? How much is to much? I saw someone here in the forums that said his install has 5000 devices and he has problems. I don´t need that number at all but just wondering what are its limits.
Thanks guys.
I was wondering if this can be done before bothering more into exploring and putting Cacti into a production,
Is it possible to change the Inbound/Outbound Data Sources interfaces in a Graph via some API, the command line or even editing directly a configuration file?
I need to constantly change the source of some devices, which have a state which changes, this means their SNMP interface changes all the time, and even while at first look I see I can select manually in Cacti which I want for a graph, I assume if I do this, the graphic output will continue as normal with the new data source selects. If yes, this is nice, but I need to automated this.
This means, with a script that changes this on a config file, an API command or in the command line.
Also, what are the biggest installations running Cacti on a single server or even distributed? My point is, could Cacti handle 1000 ethernet cards still running fine at 5 minutes intervals? How much is to much? I saw someone here in the forums that said his install has 5000 devices and he has problems. I don´t need that number at all but just wondering what are its limits.
Thanks guys.
Re: Is it possible to do this?
With Autom8 (check the manual) and SNMP Query Re-Indexing set at Verify All Fields you could get new graphs automatically in theory. What do you mean interface changes though new one added, coming Up etc?
Check out the /cli/ dir it has a bunch of tools for automation but I realised I'm better off with Autom8.
With my tuning I've got one cacti instance with 1600 devices about 20 000 data sources polling every minute all of them in 12 seconds with Boost (check the manual on that as well it's very good) All that within 4GB ram and 12 cores (virtual but I hardly see load go over .10 so the cores was an overkill by the guy who provisioned the Virtual. I only see a load over 1 when I flush to disk every 30 min)
So to answer your question it's very capable indeed.
Check out the /cli/ dir it has a bunch of tools for automation but I realised I'm better off with Autom8.
With my tuning I've got one cacti instance with 1600 devices about 20 000 data sources polling every minute all of them in 12 seconds with Boost (check the manual on that as well it's very good) All that within 4GB ram and 12 cores (virtual but I hardly see load go over .10 so the cores was an overkill by the guy who provisioned the Virtual. I only see a load over 1 when I flush to disk every 30 min)
So to answer your question it's very capable indeed.
Re: Is it possible to do this?
I actually purchased the Cacti book on my Kindle, but I will read it later.
So far I understand almost everything out of the box but of course I don´t know the insights yet or what its capable fully in terms of features. If it requires some tweaks, coding, hack, im ok with it, my concern was mainly if its possible or not, since other platforms I tested where not so customizable or hackable.
From what you just said there could be a couple of ways to it.
When the interface changes I mean this.
When you add a new device, lets see it detects 10 Ethernet cards. Each with its own number, eth0, eth1, eth3, etc.
I create a device named "ServerX" for example and assign it to graph "eth3"
Then after 7 days, eth3 is plugged off and I need ServerX to continue its pooling, in this case, ServerX actually changed to eh12
So in order to keep things working, I need to:
Cacti detect when "eth3" does down, Actually I don´t need Cacti to do this, since I can do this externally.
All I actually need is automate some way to tell Cacti
"Hey Cacti, ServerX will now be using "eth12" in its graph.
So this is what I assume.
Cacti will auto discover all eth cards via SNMP as they added and graph them.
Now what I just said this can be done, at least from a first glimp. I can change the ethercard for the graph selecting from the drop list. At least what I see from my Cacti install this is a simple click
So I would just to automate this, via a script or some other way. That is what I asked if its possible, because my other software, actually does not let me do this. I cannot change the source data of a device without recreating it from scratch and losing historical data.
So far I understand almost everything out of the box but of course I don´t know the insights yet or what its capable fully in terms of features. If it requires some tweaks, coding, hack, im ok with it, my concern was mainly if its possible or not, since other platforms I tested where not so customizable or hackable.
From what you just said there could be a couple of ways to it.
When the interface changes I mean this.
When you add a new device, lets see it detects 10 Ethernet cards. Each with its own number, eth0, eth1, eth3, etc.
I create a device named "ServerX" for example and assign it to graph "eth3"
Then after 7 days, eth3 is plugged off and I need ServerX to continue its pooling, in this case, ServerX actually changed to eh12
So in order to keep things working, I need to:
Cacti detect when "eth3" does down, Actually I don´t need Cacti to do this, since I can do this externally.
All I actually need is automate some way to tell Cacti
"Hey Cacti, ServerX will now be using "eth12" in its graph.
So this is what I assume.
Cacti will auto discover all eth cards via SNMP as they added and graph them.
Now what I just said this can be done, at least from a first glimp. I can change the ethercard for the graph selecting from the drop list. At least what I see from my Cacti install this is a simple click
So I would just to automate this, via a script or some other way. That is what I asked if its possible, because my other software, actually does not let me do this. I cannot change the source data of a device without recreating it from scratch and losing historical data.
Re: Is it possible to do this?
in linux you could rename the new eth12 in eth3 if you want. You could write a bash script to do so every time you change a card, so in Cacti graph will go undisturbed..
look for 70-persistent-net.rules
look for 70-persistent-net.rules
Re: Is it possible to do this?
Well first I see Cacti is a bit different from what I used before.
The first thing I noticed is that it does not automatically rescan interfaces when using SNMP.
I had to hit "Reload Associated Query" and there it was.
This does not seems to be a problem, since from reading it seems you can just change the Indexing method to "Index Count Changed"
Did not tested yet, but I assume this will rescan the SNMP device automatically. Its not actually needed but I did not find how to do this manually via the API or some command when I need it, so I will just tell Cacti to do it.
I actually do have a script that does what you said already, but it does this with my other monitoring software. I want to adapt it to Cacti.
The changes needs to be done in Cacti, I was looking the SQL database and it seems its somewhere there, but I prefer not to do this in the database directly.
Cacti seems to create different rrd files for each interface, I can already detect changes and execute some action but my question is rather regarding Cacti.
I need to tell Cacti to update its source when this happens. I basically need to inform Cacti to switch its graphic source to the new SNMP Index device.
This is my question. In SNMP I have several index devices, each with its own Name (IF-MIB). I need to be able to switch to a different one for a specific graphic so it does not continue blank which is exactly what is happening now.
The first thing I noticed is that it does not automatically rescan interfaces when using SNMP.
I had to hit "Reload Associated Query" and there it was.
This does not seems to be a problem, since from reading it seems you can just change the Indexing method to "Index Count Changed"
Did not tested yet, but I assume this will rescan the SNMP device automatically. Its not actually needed but I did not find how to do this manually via the API or some command when I need it, so I will just tell Cacti to do it.
I actually do have a script that does what you said already, but it does this with my other monitoring software. I want to adapt it to Cacti.
The changes needs to be done in Cacti, I was looking the SQL database and it seems its somewhere there, but I prefer not to do this in the database directly.
Cacti seems to create different rrd files for each interface, I can already detect changes and execute some action but my question is rather regarding Cacti.
I need to tell Cacti to update its source when this happens. I basically need to inform Cacti to switch its graphic source to the new SNMP Index device.
This is my question. In SNMP I have several index devices, each with its own Name (IF-MIB). I need to be able to switch to a different one for a specific graphic so it does not continue blank which is exactly what is happening now.
Re: Is it possible to do this?
I don´t want to mess around in the node with this, its not advised to change them to have fixed persistent names. I need and prefer to do this in the monitoring side, this means in Cacti. I know the new name and I know when they change, I just need to find a way to automate this in Cacti instead of doing it in the web interface.LeonM wrote:in linux you could rename the new eth12 in eth3 if you want. You could write a bash script to do so every time you change a card, so in Cacti graph will go undisturbed..
look for 70-persistent-net.rules
Re: Is it possible to do this?
I'm not an expert, but in my opinion you have 3 possibility's:
1. write a bash script that alter the *.pl script that gets the data, based on the irq of the pci port
2. write some if/elseif/else statements directly on the .pl script (could loose the modification after an update of cacti)
3. write some script that alter the database of the cacti (if you find where are those settings)
...for nether one i don't think someone could give you a hand, because you alter the sources, so you must do it as a DIY project.
But as i say'd i'm not an expert and i could be wrong.
1. write a bash script that alter the *.pl script that gets the data, based on the irq of the pci port
2. write some if/elseif/else statements directly on the .pl script (could loose the modification after an update of cacti)
3. write some script that alter the database of the cacti (if you find where are those settings)
...for nether one i don't think someone could give you a hand, because you alter the sources, so you must do it as a DIY project.
But as i say'd i'm not an expert and i could be wrong.
Re: Is it possible to do this?
Well, like I said I have such a script, but I assumed that since you can change the source in Cacti from the Web Interface, there should be an equivalent command line or API for it.
So I assume none exists and its not a standard feature to be able to change the source of a graphic then.
The feature is there in the web interface at least under "Graph Item Fields"
This is click and point in the web interface.
I guess its not a default feature then to be able to change the source of a graphic...
Changing each manually is not an option, reason why I wanted to send a command to Cacti automatically so it changes it since I need this for allot of graphics.
Does someone know if this setting is at least saved in the database somewhere? If yes, then I could maybe change this directly in the SQL table and hope its also updated in the web interface.
So I assume none exists and its not a standard feature to be able to change the source of a graphic then.
The feature is there in the web interface at least under "Graph Item Fields"
This is click and point in the web interface.
I guess its not a default feature then to be able to change the source of a graphic...
Changing each manually is not an option, reason why I wanted to send a command to Cacti automatically so it changes it since I need this for allot of graphics.
Does someone know if this setting is at least saved in the database somewhere? If yes, then I could maybe change this directly in the SQL table and hope its also updated in the web interface.
Re: Is it possible to do this?
Forget this. This will not work in Cacti.
I just tested this manually and it seems that option basically just reloads the whole .rdd file.
I had the impression the graphic and historical data would be merged, this means the graphic would show data from that point on for the new selection.
Not at all. It basically changes the whole data, from scratch.
I don´t think its even possible to do this in Cacti, merge historical data of devices. I'm sad because I really wanted to use Cacti
I even purchased the book for my Kindle...
I guess its impossible to do Xen machines with Cacti. I will have to stick with my current software.
I just tested this manually and it seems that option basically just reloads the whole .rdd file.
I had the impression the graphic and historical data would be merged, this means the graphic would show data from that point on for the new selection.
Not at all. It basically changes the whole data, from scratch.
I don´t think its even possible to do this in Cacti, merge historical data of devices. I'm sad because I really wanted to use Cacti
I even purchased the book for my Kindle...
I guess its impossible to do Xen machines with Cacti. I will have to stick with my current software.
- gandalf
- Developer
- Posts: 22383
- Joined: Thu Dec 02, 2004 2:46 am
- Location: Muenster, Germany
- Contact:
Re: Is it possible to do this?
We run 100,000 data sources in less than 100 sec. The polling time is a bit high, due to excessive use of scripts. Using mostly SNMP, hugest installation known runs about 2,000,000 data sources.nibb wrote:Also, what are the biggest installations running Cacti on a single server or even distributed? My point is, could Cacti handle 1000 ethernet cards still running fine at 5 minutes intervals? How much is to much? I saw someone here in the forums that said his install has 5000 devices and he has problems. I don´t need that number at all but just wondering what are its limits.
R.
- gandalf
- Developer
- Posts: 22383
- Joined: Thu Dec 02, 2004 2:46 am
- Location: Muenster, Germany
- Contact:
Re: Is it possible to do this?
The "index is changing permanently" issue is indeed a bit of pain in the ass.
A solution to merge data is IMHO not going to work well - you already said this.
A better solution is to
- use the "correct Index"
- re-index on that "correct index"
I recently did some work to better support exactly this, but it may still not work as you expect. There is not much feedback on this last "improvement". Here's the theory:
First, we need something "constant", which "moves" with the interface change as required. E.g. some ifAlias, which describes the server being plugged out from if_x and plugged into if_y. Without this, there's no way to know, that both data is related to the same source. In this case, obviously the ifDescr does not provide this. This use case is quite similar to the graphing of file systems, where any change to the fs configuration may move existing file systems around: thus renedering the fs index useless. We then need the fs description as a unique identification for the fs.
In your case, we thus need a different index, not ifDescr. E.g. ifAlias might work (depending on your company naming policy).
To reflect this change, the XML file has to be changed. The primary index now has to be e.g. ifAlias!
When watching at any data source, you will find the current index listed at "Supplemental Data Template Data" under "Custom Data" as "Output Type ID", "Index Value" and "Index Type". Currently, you will wind ifDescr here.
As this has been some months ago, I'm not sure that it is possible to apply such a change to existing data sources and rrd files. You might to have this implemented before creating a new data source. And yes, this is quite advanced stuff.
R.
A solution to merge data is IMHO not going to work well - you already said this.
A better solution is to
- use the "correct Index"
- re-index on that "correct index"
I recently did some work to better support exactly this, but it may still not work as you expect. There is not much feedback on this last "improvement". Here's the theory:
First, we need something "constant", which "moves" with the interface change as required. E.g. some ifAlias, which describes the server being plugged out from if_x and plugged into if_y. Without this, there's no way to know, that both data is related to the same source. In this case, obviously the ifDescr does not provide this. This use case is quite similar to the graphing of file systems, where any change to the fs configuration may move existing file systems around: thus renedering the fs index useless. We then need the fs description as a unique identification for the fs.
In your case, we thus need a different index, not ifDescr. E.g. ifAlias might work (depending on your company naming policy).
To reflect this change, the XML file has to be changed. The primary index now has to be e.g. ifAlias!
When watching at any data source, you will find the current index listed at "Supplemental Data Template Data" under "Custom Data" as "Output Type ID", "Index Value" and "Index Type". Currently, you will wind ifDescr here.
As this has been some months ago, I'm not sure that it is possible to apply such a change to existing data sources and rrd files. You might to have this implemented before creating a new data source. And yes, this is quite advanced stuff.
R.
Re: Is it possible to do this?
The problem is that the interfaces do not have any Alias, or unique identifier, or anything that can be identified as being unique except the Index number and the IF-MIBDescr
When a reboot is done on the monitored end side, the Index number increases by one count, but all of them are exactly the same. The only way to identify them is by the IF-MIBDescr, you cannot rely on the count number either because if 2 devices are rebooting it would increase the Index count in multiple units, 2 times in this case.
There is way to identify systems which is what I do, by the unique UID each device has on the hardware, but this has nothing to do with SNMP either or Cacti. I identify the VIF number which I then match to the correct IF-MIBDescr, and then get the correct count number.
The problem is then telling Cacti to use the new Index.
In my current monitoring systems this is possible and once I tell the monitored sensor the new Index it keeps monitoring data from that point on. The problem is that it’s a pain, because it requires a full reboot of the system and it take a few minutes.
So I planned to change this for something more flexible which lets me change the SNMP Index on a monitored device on the fly and keep making the graphic without severe cuts on it.
Now, I don´t know mean what you mean by “re-index” because as far as I tested it seems Cacti does not support this, you would need to recreate the graphic from scratch losing all the historical data which is not what I want. If that was the case I could set it to automatically discover and graph each new SNMP interface it discovers and I will end up with hundreds of different graphics all split in different time periods.
The question is to know if Cacti can keep making graphs of a different SNMP index interface and threat it like the same device in the same graphic.
From what I did see in my short tests, Cacti creates a .rdd database for each one, this is ok, but this database needs to take the input from somewhere else then, in this case from the SNMP packets it receives.
The reason I asked this on the forums was because its clear I don´t know all the internal working of Cacti vs someone using it for years or that knows how its build.
If I reboot a device, the SNMP index changes, so the effect is that the old interface is down, and so the graphic in Cacti is blank from that point on. If I could tell Cacti to use the new one, then it would keep making the graphic from the new interface, if its uses another database for it that is ok, all I want is the end graphic generated to be consistent.
When a reboot is done on the monitored end side, the Index number increases by one count, but all of them are exactly the same. The only way to identify them is by the IF-MIBDescr, you cannot rely on the count number either because if 2 devices are rebooting it would increase the Index count in multiple units, 2 times in this case.
There is way to identify systems which is what I do, by the unique UID each device has on the hardware, but this has nothing to do with SNMP either or Cacti. I identify the VIF number which I then match to the correct IF-MIBDescr, and then get the correct count number.
The problem is then telling Cacti to use the new Index.
In my current monitoring systems this is possible and once I tell the monitored sensor the new Index it keeps monitoring data from that point on. The problem is that it’s a pain, because it requires a full reboot of the system and it take a few minutes.
So I planned to change this for something more flexible which lets me change the SNMP Index on a monitored device on the fly and keep making the graphic without severe cuts on it.
Now, I don´t know mean what you mean by “re-index” because as far as I tested it seems Cacti does not support this, you would need to recreate the graphic from scratch losing all the historical data which is not what I want. If that was the case I could set it to automatically discover and graph each new SNMP interface it discovers and I will end up with hundreds of different graphics all split in different time periods.
The question is to know if Cacti can keep making graphs of a different SNMP index interface and threat it like the same device in the same graphic.
From what I did see in my short tests, Cacti creates a .rdd database for each one, this is ok, but this database needs to take the input from somewhere else then, in this case from the SNMP packets it receives.
The reason I asked this on the forums was because its clear I don´t know all the internal working of Cacti vs someone using it for years or that knows how its build.
If I reboot a device, the SNMP index changes, so the effect is that the old interface is down, and so the graphic in Cacti is blank from that point on. If I could tell Cacti to use the new one, then it would keep making the graphic from the new interface, if its uses another database for it that is ok, all I want is the end graphic generated to be consistent.
- gandalf
- Developer
- Posts: 22383
- Joined: Thu Dec 02, 2004 2:46 am
- Location: Muenster, Germany
- Contact:
Re: Is it possible to do this?
But them let's use that ifDescr. IMHO, this is the default. Verify this by looking at any data source related to the traffic template. Please post your results here.nibb wrote:The problem is that the interfaces do not have any Alias, or unique identifier, or anything that can be identified as being unique except the Index number and the IF-MIBDescr
And please post an snmpwalk before and after an index change
R.
Who is online
Users browsing this forum: No registered users and 3 guests