Proposed feature-set for 6.1:

• Set(key, val, Condition.IfNotExists)
• Ditch custom synchronization code in favor of built-in concurrent collections

Method steps support overloads while subclasses of Kekiri.Step do not support constructor overloads. It would be nice if both types of steps worked the same way (either neither supporting overloads, or both supporting overloads). I'd vote for both supporting overloads. What do you think @chris-peterson ?

Currently on latest (5.0.0-beta11). Shadowing their version numbering until it is released.

This can currently be achieved by:

    {
        public static EventContext IncludeStructure(this EventContext eventContext, object structure, string keyPrefix = null, bool includeNullValues = true)
        {
            if (structure != null)
            {
                foreach (var property in from property in structure.GetType().GetProperties().Where(p => p.CanRead)
                                         let sensitiveDataAttribyte = property
                                                                          .GetCustomAttributes(typeof (SensitiveDataAttribute), false)
                                                                          .FirstOrDefault() as SensitiveDataAttribute
                                         where sensitiveDataAttribyte == null
                                         select property)
                {
                    try
                    {
                        var val = property.GetValue(structure, null);
                        if (val == null && !includeNullValues)
                        {
                            continue;
                        }
                        string key = string.IsNullOrEmpty(keyPrefix)
                                         ? property.Name
                                         : string.Format("{0}_{1}", keyPrefix, property.Name);
                        eventContext[key] = val;
                    }
                    catch // intentionally squashed
                    {
                    }
                }
            }

            return eventContext;
        }
    }```

It looks like only the Message field surrounds the value with double quotes. That can be a problem on multi-value fields in splunk.

For example
context["ImportantStuff"] = string.Join(",", arrayOfGoodies) ;

For splunk, I have to change this to
context["ImportantStuff"] = "\"" + string.Join(",", arrayOfGoodies) + "\"";

Don't forget NOT to add quotes if they're already there.

Sorry I couldn't do this myself.

Problem

EventContext.IncludeException automatically sets Level=Error. Most of the time, this is desirable, but there are times when it is not (e.g. you've handled an exception, but still want to log details).

Implementation Suggestion

EventContext.IncludeInformationalException that would require a string key, and exception value.

Sometimes, a given method will have need to create EventContext in different circumstances, e.g. error handling.

Provide a convenience method EventContext.AppendOperation.

Example:

   void DoStuff() {
     using (var normalContext = new EventContext()) {
       // do normal stuff
     }

     if (errorsDetected) {   
        using (var errorContext = new EventContext()) {
          errorContext.AppendOperation(":HandleErrors");
      }
   }
}

errorContext would publish an event with Operation=DoStuff:HandleErrors

Should the Console logging behavior use Console.Error.WriteLine(…) if the level is Level.Error?

When using IncludeStructure, it would be nice to be able to deny certain fields from getting logged. e.g.

class Customer
{
   public string Name { get; set; }
   
   [NeverLog]
   public CreditCardNumber { get; set; }
}

Use "duck" typing to allow client to define the attribute in their own code base.

NLog targets 1.3, can probably match this. This would make the project more universally compatible (i.e. not require .NET 4.6)

In a situation where a log is overlong and the underlying log capture ssystem is forced to cut off the log, prioritizing "short" values in favor of "long" ones will maximize the count of KV pairs that are included in the log message.

Addressed by #26

I created an NLog.config file for an app, but it is completely ignored. The only way to configure spiffy appears to be the Initialize(Action<NLogConfigurationApi>) method.

Scenario

A library package Foo periodically does something "notable". The application developers for Foo want to generate event messages to provide visibility to code that would otherwise be invisible. Spiffy.Monitoring seems like a good fit.

An application named Bar discovers Foo. The application developers for Bar are too busy (reckless?) to be concerned with "logging". When running Bar, they are confused by periodic log emission as Foo performs its duties.

Proposed Change

Remove default publishing behavior, require application entry-point to Initialize either a provider assembly, or one of the built-ins ("trace" / "console").

Potential Changes in v7.0

Breaking Changes

• default to shorter, snake_case field names. Provide configuration options to retain existing behavior and/or further customize field naming
• changes to default behavior: RemoveNewLines: true
• don't log Count_ automatically when using Time/Timers.Accumulate -- require some sort of opt-in
• default precision for ms is whole numbers only. can opt-in for fractional values

Enhancements

• Add ability to control precision for timings -- with this provide a minimum threshold under which fields are automatically suppressed
• Ensure non-standard SI units are explicit in field names, e.g. ms in TimeElapsed
• Add Warn/Error methods that default to appending. Consider removing SetToX methods
• Introduce a concept of "essential fields". This set can be extended by callers and is used by a new Summarize() method that will shrink a logged message to just the essential fields. This is useful to manage logging volumes, e.g. for a web request that is fast and successful, don't log a ton of granular timings, etc; but rather, the "essential fields"

Add an IncludeJson method

While JSON is a pretty human-infriendly representation of log data, there are times when you might want to emit JSON as part of a log entry (e.g. debugging corner cases)