How to permanently delete a channel from a sensor

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.

Hi,

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.

Best regards

Hi,

is there a technical reason why channels can not be deleted? If not, can you set it on the roadmap for a future release?

Best regards

Hi,

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?

Dear

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.

Hello Arne,

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.

Eric

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.

Hi!

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.

Dear Phil

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?

Dear critchlg

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.

Dear SethSND

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.

Dear Arne,

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.

Dear SethSND,

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?

Dear RussellCarr,

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?

Dear astender,

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.

Dear Matthias,

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.

Dear MilesONeal,

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

Dear JimLovePRTG,

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.

Dear thenorthwest,

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.

It's to bad you guys don't create more flexibility into your Sensors so Customers can modify them to meet there needs. I to, have a specific case where I want to remove one of the two channels specifically on a sensor on a specific handful of devices, and can not. Why is it you don't create flexibility into the sensors allowing us to delete a sensor channel on a device?

Dear brannonsweet,

the PRTG proprietary database is optimized for performance. Advantages include that no external database software is required, and that the historic data is stored in full resolution for the whole time, instead of condensing it to hourly averages.

In order to get this performance, trade-offs were made regarding flexibility. PRTG is developed as standard software, we look at the standard use case. Hiding sensor channels as an alternative to removing them is usually sufficient. This is why we see this as good solution for most cases.

We are working on PRTG improvements driven by overall demand, and other considerations (some feature require others first, those are implemented first).

Where is direction/documentation on "hiding" a sensor channel so I can see if it will work for what I'm trying to achieve. The sensor is reporting a alert on 1 of the two channels that, in reality, isn't accurate. If I hide the channel, will the sensor only report status on the remaining channel?

Dear brannonsweet,

most sensor types don't alert on hidden channels. There are sensor types which however can return a sensor-wide error (for example, one can do it for custom Exe/Script sensors.)

In order to hide a channel, open the channel from the sensor overview, either by clicking on its gauge, or its name in the sensor's channel list, then select "Hide from Graphs" and "Hide from Tables".

The channel then remains only in the aforementioned channel list, but is otherwise hidden.

Recently there war a bug that the effect of channel hiding takes effect only after restarting the PRTG Core service, but this got fixed with the 20.1.57 release.

I did what you said in the sensor is still in alarm status. The channel that's in alarm his Hidden from Graphs and tables.

It's the Cisco Health alert (System Health Power Supplies) sensor. It has 2 channels. Each channel is watching a different power bay on the Cisco switch. The whole sensor is going into alarm because of the status on 1 power bay. It happens to be a cisco bug, so I don't want the sensor in alarm status for the affected power bay. I want it green for the other channel/power bay that is working....

Argh.

Dear brannonsweet,

hiding channels for status should work with this sensor. Please contact us at [email protected], you can mention me (Arne Seifert). Please include screenshots of the sensor, of

• the "Overview" tab of a single sensor
• the "Log" tab of that sensor
• the "Settings" tab (multiple screenshots if necessary to cover all options.)

Please capture the whole PRTG user interface in any screenshot and send them as email file attachment. (Please capture the full interface in any screenshot, because if parts are cut off, important context would be missing.)

Hello PRTG team,

Like many other users, I'm also waiting for this feature. I realize that "deletion" is not possible due to the reasons you've already repeated so many times. However, there is something that will satisfy user requirement without requiring deletion:

The feature we're really looking for is "permanently hide". This goes beyond hiding it from graphs and tables - it hides it from everywhere. This accomplishes the same functionality as "delete" without having to delete anything. The data is still in the PRTG database, but the user will never see it displayed anywhere.

So, it's misleading for PRTG to keep saying that deletion is impossible, while at the same time there is a solution that accomplishes the same functionality for users without invoking deletion at all. No one is asking PRTG for "deletion" they are asking to a result that is satisfactory, a result that "works just as good as deletion", and that is achievable with "permanent hide".

This is like going to a restaurant and politely asking a waiter to "get rid of" empty plates from your table. Then the waiter answers "I'm not allowed to destroy any plates, so I can't comply with your request". All we want is for those plates to be gone, we don't care about the method.

Some call it get rid of, some call it delete, some call it disable, it doesn't matter, we want the channel gone from our sight. If this is still not on PRTG's timeline, that's understandable, you are probably working on 100 other requests first before this one. But then at least say so instead of hiding behind a technical excuse that doesn't apply. Maybe one day when enough users have asked for this "permanent hide" feature you'll get to it.

Thank you

Jumping in to suggest the same thing as tflorian. I would really like this feature, as everyone has already said for custom sensors. I wrote a script that had a channel named "Active Sessions". It collected data for a week, then my managers wanted it added onto where there a more specific breakdown of Sessions. I renamed the original one, and now I have all this channel I cannot delete and stays there forever. I had to delete it and add it again, which is unfortunate for the data that we had collected.

A permanent hide feature can pose certain issues, here are just some:

• Assigning data by channel name gets more complex because an additional check has to be done for every channel. With thousands of sensors, this piles up and can impact the performance
• A permanently hidden channel would still bloat the data base
• Some users would then ask to have an undelete/unhide function

PRTG is optimized to read hardware statuses, not to show table-like structures with possibly different columns each scan. With that architectural decision, we are able to offer PRTG running on consumer-grade hardware yet still providing good performance including keeping the data in full resolution (no averaging after a month).

Wow, this thread is now +10 years old, and this need seems to still not have been addressed.

Here's my vote for the ability to delete existing channels!

A possible reasonable workaround would be ability to clone an existing custom SNMP sensor WITHOUT taking the existing data in the process. Basically this would be like going to the moment in time where the custom SNMP sensor with multiple custom channels is created - literally the moment when the "Create" button is pressed. Right after such sensor is created, the channel list is still empty, waiting do be filled with the retrieved data related from the multiple assigned channels - and this "clean" state is exactly the base that would be used for later cloning procedures

@Paessler team: would the implementation of a "snapshot of the moment of sensor's creation" be feasible? This way one would be at least able to clone complex custom sensors to dozens of devices without carrying over the all the accumulated data from the previous/original devices.

This would probably be a cleaner approach than just flagging data as invisible forever - even if performance wouldn't be affected, it would create way too much garbage/unneeded data, specially in environments with hundreds of custom sensors with multiple channels.

Regards

Hello Johann,

such snapshot function would not integrate with the database approach. The only way here would be if the user itself keeps an unmodified sample sensor for further cloning.

Hello Arne,

thanks for the feedback, that's actually a good suggestion. We'll create a dummy device with template custom sensors ready for cloning, this should help with keeping all the channels clean.

Best Regards

Please add this feature!!!

I would also appreciate it if there was the option to hide or channels.

I also have sensors (e.g. SSL) that spit out warnings or errors. Hiding on graphs and tables doesn't help. The alarm or warning remains ....

Please add the function (hiding would also be sufficient).

And can you tell me a temporary solution? Is it possible to clone and adapt a sensor template (like removing channels)? I can't find the sensors in install dir. At example: take ssl-certificate sensor and make a new (custom) sensor "ssl-certificate-expiration"

Too bad, in the past there was a "http ssl certificate expiry sensor", but it was replaced with the "ssl certificate sensor"...

Hello Robert,

with the status evaluation, PRTG is a bit inconsistent across the sensors. Normally, hidden channels are excluded from the the overall status. But there are a couple of sensors where any channel processed impacts the status, even if those channels are hidden.

In the long run, with overhauling sensors (or offering a version 2 of them) we aim for consistency. With the SSL Certificate sensor, hidden channels are still evaluated (which is one of the aforementioned inconsistent behaviors). In this case, you cannot create a template removing such channels, but you can use a different lookup value in order to no longer trigger the error status for such channel.

So when you create a map for a customer, you have to delete every morning all the unwanted channels from hundreds of sensors? There is no way to stop this or lock this? Really dissapointed over this... We live in 2022....

Hello,

what is the sensor type here? I ask because most sensors come with a fixed set of channels. A handful of sensors add channels if they find new components, like new CPU cores.

I kindly request this feature too. Specifically, I don't need to delete a channel but if I could disable it on a given sensor, that would be perfect. Simply "hiding" them as suggested doesn't address the concern, which is that hidden sensors still trigger and alert. We have several that are on permanent warning state because of hidden channel that is totally irrelevant.

One of many examples: the SSL sensor checks for valid CA and revocation list. Many systems at many companies use an internal CA, and sometimes no revocation list. I can hide these two channels from graph view but the sensor is forever in a warning state.

PRTG, just curious but when you see a thread with regular requests for the same thing over and over for 10+ years, doesn't that lead someone (anyone?) over there to question that maybe, just maybe, your customers might have a valid request worth implementing?

Hello,

when development time is assigned, we look at the greatest benefit for most users. The PRTG database was designed without channel deletion in mind. Adding that feature requires changes on many ends. As of now, other features are preferred.

With reworking many parts of PRTG, the database could be changed at some point in the future, allowing to actually delete channels.

If you hide a channel both from graphs and tables, they should no longer be evaluated for the sensor status.

Hi

Would really like the ability to delete channels on sensors, please keep this alive on your dev roadmap.

Hello,

such option would imply decreased performance with historic data access. When technology progresses, we might get away with it. Until then, hiding a channel (instead of truly deleting it) is the best option.