RFC: Event Log, Exceptions table

Request For Comments.

Please review the problem and suggested solution and provide your comments to help drive this feature implementation into a future platform release.

Description of problem

We have an Exceptions table which computes a hash of each exception. The idea behind this table is we could display which exceptions are occurring frequently compared to the exceptions which only happen a small handful of times.

Description of possible solution 1

When expanding an exception, we currently list the exception hash. We should also display and offer the option to sort by the number of occurrences of that exception hash. Since this is only valid for exceptions, we need to make sure it doesn’t cause any issues with the other event log types.

Description of possible solution 2

We remove this feature/table if people do not find it valuable.

[WillStrohl]

I definitely think we need to keep the exceptions abstracted into a new table to allow us to use the data for the original intent. This way, folks like us can do better analysis of what is affecting a DNN instance. We just need to fix the data and have a UI for it.

[bdukes]

Yeah, it looks like that FIPS-compliant issue was the cause of the issue I was seeing. (Some government computers have a FIPS-compliant setting which causes programs to crash when they try to use the MD5 function or other non-compliant algorithms, so even though it’s not being used in a security context, it’s important not to use it).

I found this out when I used this code as the basis for a function I was using and realized it didn’t work. Here’s what I ended up with:

using (var hasher = SHA1.Create())
{
    var byteArray = hasher.ComputeHash(Encoding.Unicode.GetBytes(data));
    var hashedToken = Convert.ToBase64String(byteArray);
    return hashedToken;
}

Personally, I don’t know that I’ve ever used the data in the table to look at exceptions in the aggregate, but if there were a view of aggregate exceptions, I would think it was useful.