Need investigation on how we read files and the way some collectors collect logs.

[Tatsinnit]

Writing this issue as workitem investigation, this tool collects logs as part of that process some collectors from day-1 are implemented with dependency in the size of those files.

Possible issue:

• Premise is that in case of really large cluster running this pod could cause memory issue. or possible abrupt behaviour but that use case is day-1 behaviour because of the way it works. For fixing we need right approach.

This leads to investigation in need.

Possible solution:

• For now, since this is the day-1 behaviour and nothing is reported so far we cannot drop the use of these collectors but to find a way for any other tool not to use it as it is. things like this should help any other tool which want to use some of the existing functionality of AKS-Periscope: https://github.com/Azure/aks-periscope/blob/master/cmd/aks-periscope/aks-periscope.go#L65
• Other option includes: removing of these log collectors, but that will be the functionality removal from a tool and needs input from wider folks like: @palma21 , @qpetraroia , @rzhang628 and @justindavies (cc: @arnaud-tincelin and @JunSun17 )

Thanks,

[Tatsinnit]

💡 No further ideas were added, so closing this as we already have a sample add helper for it, for example used here: https://github.com/Azure/aks-periscope/blob/master/pkg/collector/nodelogs_collector.go#L32 ; beside that we need to handle read file case-by-case basis aka if we can load the content via deployment file users have then use this ReadFileContent helper.

Closing this as no further specific action in need. Thanks 🙏☕️