I have a properly running WF Reporting Server thats doing e...

[John Edwards 2]

I have a properly running WF Reporting Server thats doing everything its supposed to, except for recording records in the ETL Log. A review of what was in the current file indicates that it records for a day or two, then stops for a few months, then starts again, then stops in fits and starts.

I made a copy of etllog.foc and then went to the console and recreated logs and statistics. It blew away the old etllog.foc like I would expect it to, but is not writing to the new file.

Am I fundamentally mistaken Does etllog.foc only record Data Migrator statistics I could have sworn its always worked for a WF Reporting Server in the past as well. Its labeled as Data Migrator Log and Statistics in the console menu, in spite of it being 8121.

[Joanna Swiggett]

Hi John,

Not sure if this will help, but I had a case open about etllog.foc in Nov 2018 and they told me it contained the following things which arent related to Data Migrator:

 

scheduled jobs on the Reporting Server directly (not ReportCaster)

deferred reports that have -SET &ECHO = ALL

 

We ended up changing a setting so nothing gets stored in the etllog file. We had a user run a report deferred with &ECHO on and they had an endless loop in their fex which caused the etllog file to get very large which took up valuable space on the server.

Joanna

[John Edwards 2]

I do a lot of ETL work, maybe Im just projecting its behavior onto the WF server. Because those two things wouldnt kick off very often on my WF system, so it matches the results Im seeing. Thanks for the word maam.

We have a job that captures the name and user of each report that is run, so I can glean some information from there. But I have a job that runs on a connection that is going away soon, and I cant find it. Hoped to see connections in the ETLLog.

[Doug Shartzer]

We definitely collect etllog records on our reporting server. However, ETL items are only written to our logs on a submit, which we initiate typically through CMRUN. Its pretty solid for us except for when it becomes corrupted via a bad job run.

For the report side of things, if I understand you correctly, were able to collect a lot of the info youre collecting via Resource Analyzer.