Downloading Log Messages

[Guest]

I would like to be able to download the messages I have logged. I cannot get to the text/plain message I have attached to the LogMessages under Log Family. I would also like to be able to download all log messages (in chronological order as seen here) grouped by session and installation for further evaluation/processing. Finally, I would like to instrument the code using the Eqatec Profiler, distribute it to clients, and log the details of their experience without having to write my own instrumentation. If you are working on this feature let me make one suggestion: Only instrument the code to trace out and provide a default trace listener which sends the data to your servers. This way I can build a proxy which allows me to tweak filtering out messages. I could also remove the listener.dll if customers performance is dramatically worsened or they are concerned about privacy. Are these features available now? Thanks

[Guest]

Hi Thomas I hope I understand your questions correctly, otherwise feel free to correct me. 1) It is correct that the Sessions view does not offer a way to download any attached messages. For that, you'll have to find the specific message using the LogMessage view. I see how this is a less than optimal approach and I'll add your feature request to our backlog 2) We do not have support for a full download of all log messages. Our logmessage view does not a little love, featurewise. Howvere the log message functionality was not initially designed to be an upload mechanism for large quantities of files but more for one-shot uploads of very specific issue data for e.g. attaching files to a support incident or similar. I'll add a request for a full download, but'll the basic premise for the logmessage functionality may drive our prioritization. 3) At the moment we have no synergy with the EQATEC Profiler in terms of using the IL injection to perform (semi)automatic instrumentation of analytics measuring points. This is largely by design as we feel the process of integrating measuring points cannot be automated. Considerations like "when do we consider a feature to be used", "at what point should we start measuring" and "we only track the feature is X" cannot be instrumented by a tool but needs to be implemented directly with integration to our monitor library. Further to your question, our monitor library has a bit more advanced semantics for sending data to our servers than a "simple" tracelistener, such as caching data clientside if no internet connectivity, limitations of the cached data, enforcing data policies and internal limitations on payload content and sizes. So pushing data through a tracelistener is not really an option at this point. If you are worried about performance or privacy, our monitor library has zero-impact if you do not call the Start method. If Start is not called, all calls on the monitor library are essentially no-ops and return immediately. Hope this helps in terms of answering your questions. I'll be happy to elaborate more on specific issues if needed and I encourage you to send all questions and feedback to us going forward. Best regards Soren EQATEC Team