Tone Down Logging

There have been a few mentions of this, and at least two whole threads in the past few months. Here’s 2 that I can find on short notice:

Extra log entries (warning) | Community

SQLSERVER Reader type generates unnecessary warnings | Community

I’m a fan of information in the existing transaction log content. Important to learn  strategies and methodology in Debugging for Workspaces when troubleshooting  

• I would support modes similar to ArcGIS with Normal versus Detailed or Verbose logging.

You have a number of existing options to filter how you Viewing the Log. See Interpreting the Log for information on interpreting the contents of the log.

My tips to reducing log length

1. Reduced feature rejection logging by adding duplicatefilters and tester has a value, prior to any FeatureMerger, Joiner key based operation
2. When promoting to production, reduce excess loggers,
3. Remove excess featuretypes
4. Don’t expose attributes on a read unless you manipulate them in a transformer
5. Changing feature loggers to “Message Only”, adding your own syntax for the message, rather than defaulting them all to “Log Only” with a max message to log of 20… this too can be reduced
6. Fix warnings rather than ignore them!

Advanced: FME Flow Debugging Toolbox: Logging Tools – FME Support Center 

I’m not sure why you posted this, because this is not about warnings that we can deal with ourselves. This is about warnings that are generated by FME,  which only serve to clutter my dashboards, and which I can’t do anything about. I have some workspaces that use an SQLExecutor. Since the consolidation of SQL Server database types into one, these (depending on the sql statement) generate the warning that no geometry will be read because it wasn’t found in the sql statement. Yes, I know that, and that’s fine. I do not need a warning about that, since I wrote that sql myself. What it does do, is cause a workspace to generate 63045 warnings. And it is entirely possible that warning 27843 is actually an error in the database that I need to fix - but  don’t know until I’ve looked at all of them. THAT is what this idea is about, and the threads I linked. And no amount of filtering the log is going to help that either. 

BTW: The default filtering is not always helpful. You filter on Errors, then you miss the actual warning that caused the error - since that’s on the lines just before the error, and to see everything, you’ll need to unfilter again. 

I agree with ​@j.botterill that warnings should be fixed and I agree with ​@s.jager that some of the warnings we see are unfixable as the workspace author. 

Ideally, when I look at an FME Flow jobs list, I only want to see warnings when something is up that an admin or author should do something about. It's all too often when I look at a client's FME Flow and see many jobs with x warnings they say “yeah that's ok, it always does that”, but it's not okay because it may lead you to a false sense of security you may very easily overlook a serious warning.