[chris-peterson]

Context

Spiffy.Monitoring.Aws installs a TraceListener into the AWS SDK's diagnostics pipeline, so anything the SDK reports shows up in the host application's structured logs as Component=AwsSdk Operation=Event. Everything the SDK emitted became a log event, minus a two-entry deny-list. This makes that filtering the library's job instead of every consumer's, and classifies each event from the severity the SDK actually reported rather than guessing from the message text. Closes #52.

The SDK reports a great deal at informational severity, and some of it repeats on every call while carrying nothing actionable. A production log query over one window returned 2.9M AwsSdk events, 94% of which were a single message restating the SDK's own user-agent string; a separate query put the request-signing canonicalization lines at 4.3M/day on their own. Consumers were each solving this by hand — a BeforeLogging callback hardcoding the same prefixes, or RemoveTraceListener, which runs too late to help because clients have already captured the listener.

Review guide

Critical path

• src/Spiffy.Monitoring.Aws/AwsProvider.cs:123 — the whole filter decision: severity short-circuits, prefixes decide the rest, Warning and above are never filtered
• src/Spiffy.Monitoring.Aws/AwsProvider.cs:52 — the severity is only available on TraceData; Write/WriteLine see a flattened string, which is why the old code had to guess

Public surface

• src/Spiffy.Monitoring.Aws/AwsConfigurationApi.cs:32 — SdkNoise names the seven kinds, so nothing is configured by magic string
• src/Spiffy.Monitoring.Aws/AwsConfigurationApi.cs:60 — kind → prefixes, ordered so the result is deterministic; RequestCanonicalization covers two
• src/Spiffy.Monitoring.Aws/AwsConfigurationApi.cs:91 — Add / Remove / Clear, plus the string overload of Add as the escape hatch

Tests

• tests/UnitTests/AwsListenerTests.cs:189 — the filtered cases use production message text verbatim, so a later prefix edit can't silently stop clearing this traffic
• tests/UnitTests/AwsListenerTests.cs:211 — the counterpart: throttling and failure notices arrive at Information and must survive
• tests/UnitTests/AwsListenerTests.cs:332 — guards the failure mode the enum introduces: a member added without a prefix mapping filters nothing, silently
• tests/UnitTests/Properties/AssemblyInfo.cs:8 — the listener builds its EventContext from the ambient Configuration, so capturing what it logs means installing a provider into Configuration.Default. Scoping that to a collection isn't enough, since xunit parallelizes across collections

Ancillary

• docs/setup.md:41 — the AWS provider had no docs section; this adds one
• docs/setup.md:59 — SDK v3 hands the exception to the listener and v4 discards it, so Exception_* fields appear only on v3
• tests/TestConsoleApp/Program.cs:84 — -- aws uses the defaults, -- aws unfiltered clears them, for eyeballing the delta against a live SDK

Mechanical — skim only

• src/Spiffy.Monitoring.Aws/Spiffy.Monitoring.Aws.csproj:15 — 2.0.3 → 2.1.0
• tests/UnitTests/UnitTests.csproj:17 and Properties/AssemblyInfo.cs — test wiring, so AwsEvent is reachable from the suite
• .github/workflows/ci.yml:22 — unrelated to the filtering, riding along: the three test/sample projects target net10.0 so dotnet test runs on a machine with only a current SDK installed. publish.yml and api-compatibility.yml move to 10.0.x as well, since each restores or builds the whole solution and an 8.0 SDK fails outright on a net10.0 project. The five library projects keep their target frameworks — netstandard2.0 on four, net6.0 on Prometheus

Approach & trade-offs

Deny-list, not allow-list. The SDK reports failures at informational severity as well as at Error — RetryHandler uses InfoFormat for … Attempting retry N of M. and Logger.Error for … Attempt N.. So an allow-list keyed on severity would have dropped the DynamoDB throttling notices, which is the signal most worth alerting on in the production sample. Filtering named noise keeps unrecognized messages flowing by default.

Kinds, not prefix strings. A consumer can't guess "Resolved DefaultConfigurationMode for RegionEndpoint", and the worst-served case was keeping one thing the defaults filter — previously that meant re-listing the other six. Remove(SdkNoise.UserAgentHeader) does it directly, and one kind can front several prefixes. Raw strings remain available via Add for noise SdkNoise can't name.

Prefix matching, not regex. Every message in the sample is distinguishable by its leading literal, and a prefix can't backtrack on a multi-megabyte-per-day path. The cost is that a message needing a mid-string match has to be handled by the consumer. One filter widened as a result: Description for table matched only alongside a loaded from SDK Cache suffix before, and now covers a description the SDK loaded as well as one it served from cache. Both are routine DynamoDB chatter, so the kind is TableDescription rather than TableDescriptionCache.

Severity replaces a text heuristic that had a real bug. The old classifier called IndexOf("exception", Math.Min(100, message.Length), …). The intent was to search the first 100 characters, but that parameter is a start index, so for any message shorter than 100 the search began at its own end and returned -1. The SDK's canonical error string is 76 characters, so it was logged at Info. (3d75010 added the Math.Min clamp to stop the original IndexOf(…, 100, …) from throwing on short messages; the clamp fixed the throw, not the semantics.)

Validation

• Classified against a production log query — 2.9M AwsSdk events — observed: 95.7% filtered, with every error, Received error response, and ProvisionedThroughputExceededException throttling event retained
• Anchored prefix query re-run against production — Message="Single encoded *" OR Message="Double encoded *" — observed: 4.3M events/day, confirming the canonicalization lines are the largest single class
• Exercised against a live SDK v4 client — TestConsoleApp -- aws vs -- aws unfiltered — observed: 9 events vs 27, error classification intact

Two default kinds are not covered by the production evidence above: BufferResizing and TableDescription aren't reachable through the STS path the harness exercises, so they rest on reading the SDK source. DefaultConfigurationMode is carried over unchanged and I couldn't locate it in current SDK source at all — an unmatched prefix is inert, so it's left in place.