Is it possible to permanently delete a channel from a sensor so the data is no longer stored? I know it can be removed from the tables and graphs but it still seems to be collected and shows up in various toplists. Specifically I don't need a downtime channel for every ethernet port.
Once they're created, single channels cannot be removed from a sensor, sorry. As you already noticed they can, however, be hidden in graphs and tables.
I want to create report from the sensor which I have hide one of its channels, but the report shows all channels! is there any way to get the report from those channels that we want. in this case I have hide the "Total" channel from bandwidth, and I want my report to show just bandwidth in and out not total.
You can choose which channel is shown in the report. Click on the "Select Sensors Manually" tab of your report and uncheck the Traffic Total channel. Additionally you can hide the Traffic Total channel from the graphs and tables by clicking on the channel gauge and marking Hide from Charts and Tables option, this will affect the reports as well.
is there a technical reason why channels can not be deleted? If not, can you set it on the roadmap for a future release?
Sorry, we do not plan to add a feature which allows the deletion of channels. Hidden channels will not cause load on the core server. Due to the internal structure of the PRTG database, which stores the sensor results of the same device in single files, this would be a larger intervene as expected.
Deleting a single channel of a sensor would be on my request list too, especially for custom sensors.
As you wrote, you will not add this feature, please consider alternatives, i.e. -) cloning a sensor and optionally keep (copy, clone) existing historic data -) add option to export and import data to / from cvs file thus enabling to export a sensor, readd / clone it with different channels and inport data for existings channle (i.e. by previously converting the csv file)
Another option would be to ass an option to realy hide the channel from ALL displays, Top List, etc.
As a variation on this, I have tried to clone a custom sensor in order to totally reset the channel data, because the channel names had all been changed. What I found is that it kept all of the channels from the parent sensor.
I presume there is no functionality to duplicate an existing sensor without keeping all the sensors? I would like to be able to clone a totally clean version of the sensor without having to manually replicate all the settings.
I'm afraid that this will not be possible, since cloning will indeed clone the exact sensor with all channels, sorry.
I also would appreciate the deletion of channels. Especially for custom sensors.
Deleting a Channel from a Sensor is also a hot one in my whish list!
I would enjoy this feature as well
We also would like this. We use a storage device and use Powershell as Custom sensor to add volumes in channels with the percentage full as result. But after renaming or deleting a volume (which happens regularly), the old name still exists, with a 'No Data' message. This makes the list of volumes (channels in the Volume Sensor) almost impossible to check manually.
If this is not possible, it would be nice to be able to create a sensor on the result of a powershell script. What i mean: Instead of making channels as part of a custom sensor, i would like to add 1 custom sensor to the device. That custom sensor (powershell script) will return info (volume names and percentage full and some other info) and this info will be used to make a new custom sensor with channels. So if we use this script and it returns 7 volumes, there would be 7 new sensors made as result of this script. In this case it could be possible to remove volumes since it is a sensor now. And maybe it could be removed even from the original running script?
This is not directly possible. It is possible though to use meta-scans to create custom sensors through the auto-discovery. The process is rather complex, but it is possible. Deleting objects is possible via the API, but not easy to do via a sensor name. However it is possible to generate a list of sensor names with their according ID and use that ID to delete an object.
It might be an option to address this in reverse: Run the script and push the data via the HTTP Push Data Advanced Sensor. While it is still not possible to delete existing channels, and the logic of distributing the data to the sensors has to be implemented in the script, it is easier to 'create' HTTP Push Data Advanced sensors with cloning a master sensor and change its properties via the PRTG API.
Ik will take a look at the options you name. But at first glance i have the feeling it does not solve the problem. The problem is removing a channel or sensor that does not get any data anymore, because the source (a volume in my example) does not exist any more.
But maybe i can use this. Will take a look in the coming weeks. It seems a rather complicated way though.
I would also add this to my wish list, especially when it comes to cloning. I did discover that if you create it and clone it before it does it's first round of scanning then it is saved in a somewhat empty state.
This feature would be really helpful! Please check, if this can be added. If a custom sensor sends one charset-error, the type stays in PRTG. Thats not nice.
Deleting channels is not something we address in the foreseeable future. It is possible though to hide channels from a sensor.
Hi, Just to add to this, I monitoring the toner of a printer. Each time I add a new printer toner cartridge PRTG adds the new toner ID but also shows the old toner ID as another channel. Do I need to delete this sensor and creating it again?
That happens when the toner's description actually include it's serial number. It will always create a new channel since PRTG sees it as a "new consumable"
And yes, creating a new sensor this is the only way to 'delete' channels.
I also want the ability to delete channels.
As this request was originally submitted 2010, 7 years ago, I have to ask... does PRTG listen to the community? 7 years is a long time, should be plenty long enough to allow us to delete/edit channels.
Please allow me to go a bit more into the details. Yes, we do listen to the community of PRTG users. But no, channels cannot be deleted still.
The reason is that the proprietary database we developed for PRTG, is optimized for performance. In order to allow this, we had to sacrifice flexibility. Channels can added, existing channels can be hidden in PRTG, but not deleted from the sensor nor from the database. If PRTG would be conceived today, perhaps a different decision would be made.
If we would implement this community request now, we would have to rework large parts of PRTG, having some developers work through a lot of existing code, breaking compatibility with existing historic data, and said developers could not work on other things. That means a lot of other features and sensors could not be implemented. In addition, the database management would be slower, it would not be possible to use PRTG in larger setups.
PRTG is rather unique in allowing to store all historic data in full resolution, without averaging, for the time set. This is only possible with a high-performance database. We decided, years ago, that foregoing the option to actually delete channels, is worth that performance.
I understand that problem, but an alternative for deleting a channel is hiding it. Your developers can implement an option "hide channel" and another option in the menu "show hidden channels" to re-enable it.
If you really think about that alternative and implement it, please add also another tag for custom sensors like <hideoldsensors>1</hideoldsensors>, that I don't have to hide the old ones manually.
the PRTG developers are working on a lot of features which have higher priority. I am sorry, a new feature which allows to hide channels from a custom sensor result has very little chance to be implemented in the foreseeable future. We want to communicate the status of requests honestly.
Would also like to see the ability to hide an unused / unwanted / obsolete channel.
I'd like to add my name to the feature request list please. In my instance... I'm trying to setup graphs on a Maps for one of the VMware Host Performance channels that displays 'Datastore Total WriteLatency' and 'Datastore Total ReadLatency' which would be an excellent view of potential issues with a view on the past few hours. To make this work I need to re-add the same VMware Host Performance an additional two times and change the Primary Channel on each so that the Map Graph would reference the correct channel. This particular sensor has 17 channels that makes me concerned with performance excessive monitoring on the same the same channels could lead to performance issues. Is there a way to take a copy of a built in sensor... strip out all the channels that are not required and use it as a Custom sensor?
while that is not exactly possible, you can do this:
- Configure a sample device, hide unwanted sensor channels
- Create a device template
- Use it for further sensor creation via template-based auto-discovery
Hi, we have ghost disks drives which once existed but no more.
The channel needs to be removed.
When are you going to implement channel deletion please?
channels cannot be deleted, but a channel can be hidden from graphs and tables, which effectively removes it, though it still appears in the sensor's channel list on the overview tab in case one wants to enable it again.
Please open the channel (click on its gauge) and select Hide from Graphs, and Hide from Tables.
For us it would also be a huge relief if there was the possibility to delete unused channels. I also can not understand why Paessler does not make an effort.
PRTG allows to roll back to older configuration files. This only works if existing channel data cannot be actually deleted (but it can be hidden!) We don't want to lose the ability to roll back configurations. In order to hide channels from graphs and from tables, please select the according option in the channel configuration.
The ability to delete a channel would be a very useful feature.
if you don't want to see certain channels anymore, please hide them from graph and table. This can be done via the channel configuration dialogue (on the sensor overview tab, click on the channel gauge.) The channel is still listed on the sensor overview tab's channel list, but otherwise no longer visible.
I'll add my name too..
I think it's a big oversight. Here is a scenario where it's annoying: I have auto discovery on some areas of the net. We added servers running Ubuntu 18.04. The auto-discovery added sensor for disk space (good) but included channel for each of the "disk". The thing is, it included channels for these too:
/dev/loop0 91M 91M 0 100% /snap/core/6350 /dev/loop1 92M 92M 0 100% /snap/core/6531
They will always have 100% usage. Now i'm stuck with big red alerts for no real reason, for each of the new servers.
I too would like to see ability to delete individual channels. Or if cant delete them, then some ability to totally ignore them from future monitoring and alerts (im aware of ability to hide from graphs and tables, does not resolve issue we encounter often though). tks
there are a couple of sensors which determine the status using all channels no matter if they are hidden or not. Most sensors however should only use the visible channels to set the overall sensor status.
I agree, that especially on larger setups, the current approach is not optimal. We are aware of this, but there is no ETA for when we can provide a different solution.
Yet another person looking to FULLY hide/remove channel. In my case CPU sensor at one time at 5, now has 4. 5th channel hangs around forever unless I delete the whole sensor and re-add. How about a simple tool that allows us to run our own queries against the DB in an offline nature and then recompile/reorganize(insert internal term here) to get the DB back stable.
with a tool as widely used as PRTG, there are admittedly a number of things which can be improved. We currently work on some parts of the architecture, but not on the database.
While the database has some drawbacks like not being able to delete individual sensor channels, it is a high-performance database run by the core service, so no external database has to be operated or licensed. Overall we see this as more advantageous than disadvantageous.