I have been scouring the documentation trying to find a way to throttle the VLC. In many cases the VLC may be undersized - cpu, disk, memory, etc because one size typically does not fit all. Depending on the deployment and log verbosity, it is extremely fluid.
That said, I like to look at the log ingest in a mechanical way. The VLC is typically the first device the logs hit, from there they are sent to the decoder and from there a portion manages to make it to the concentrator. I have seen various instances where a VLC and Decoder pair have issues. Lets say, someone accidently leaves the ESX logs in debug over the weekend and you come in on Monday to find your decoder buried.
My question is do we have a throttling mechanism for the VLC? Say, x amount of rdp files are sent per cycle. This cycle is a function of time and volume... so if I could adjust the time to send to a lower value then the frequency of data sent increases, which could still bury a decoder. The best solution is to have the volume backup on the VLC to protect the core (decoders and concentrators). This way, it only affects a single VLC. not several VLCs by burying the decoder. A flush batch or similar setting would be ideal... maybe rabbitmq has something on this but I wanted to see what everyone has to say about it from our product perspective.
Please let me know your thoughts... maybe I am way off but I have scoured the VLC --> explore settings and I am not seeing anything that is in a terminology I am familiar with that represents data flow control.
Please let me know.