Then – new types of logs or existing ‘known’ types that are already defined in the system – then comes the part of defining where do I find the log to ingest in the first place – would you store it in Azure storage, do you expect to ‘upload’ it via the portal on demand for troubleshooting? We have appetite for something like polling from a storage account (we do it for WAD already anyway) – but still mostly from an ‘ongoing’ pulling of data for warehousing or monitoring.
Now, this said, for Microsoft support scenarios specifically, we are having some conversations with the CSS organization with regards to how in the future a customer who is using OpInsights could be using it to give a support engineer temporary and constrained access to the workspace with the logs he is already collecting essentially (to speed up investigations, we hear from you guys in CSS during reactive cases it often takes a long time to get the logs in the first place).
We need to make sure all this is secure and regulated and respects everybody’s requirements for privacy and the like, but this is something we are looking into to make support cases ore efficient for engineers and for cusomers – albeit the way we think of it differs from the implementation you are suggesting, in that we’d leave the logs in the customer’s workspace and delegate access securely, rather than making yet another copy on another file and disseminating important information in more places than needed.
Then – new types of logs or existing ‘known’ types that are already defined in the system – then comes the part of defining where do I find the log to ingest in the first place – would you store it in Azure storage, do you expect to ‘upload’ it via the portal on demand for troubleshooting? We have appetite for something like polling from a storage account (we do it for WAD already anyway) – but still mostly from an ‘ongoing’ pulling of data for warehousing or monitoring.
Not sure about the removal part either – all our billing and…
Any update from 2015 on this?