Rework the SMTP TLS dashboards onto the combined fields

Kibana/OSD: "SMTP TLS domains" replaces its stacked policy_domain ×
policy_type terms with one terms agg on policies_combined.keyword;
"SMTP TLS failure details" replaces six stacked terms spanning both
array levels with one on failure_details_combined.keyword; the
smtp_tls* index-pattern field cache gains the new fields. The
"reporting organizations" table only buckets on doc-level org_name and
needed no change.

Splunk: the base search now expands policies at the JSON level (spath +
mvexpand) so policy fields are scalars per event, and the failure
details panel expands the second level the same way — sums are the
detail's own failed_session_count, correctly paired. Verified via the
search REST API: a two-policy repro returns exactly one row per real
failure detail with per-detail counts.

kibana.md documents the per-policy/per-detail row semantics and the
honest caveat that session-count sums remain per report document.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Sean Whalen
2026-07-24 23:04:26 -04:00
co-authored by Claude Fable 5
parent 9be85409d0
commit 8f92a36622
3 changed files with 30 additions and 16 deletions
+12
View File
@@ -128,3 +128,15 @@ reporting organizations, the policy domains they report on, and the
specific failure types — certificate expiry, STARTTLS not supported,
STS policy fetch errors, validation failures, and similar — together with
the sending and receiving MTA addresses involved.
Like the DKIM and SPF details tables above, the "SMTP TLS domains" and
"SMTP TLS failure details" tables show one row per policy and one row per
failure detail, respectively, using combined `policy (domain / type)` and
`failure detail (domain / type / result / sending mta / receiving ip / mx)`
columns so that each policy's or failure detail's fields stay paired
together, rather than aggregating them as separate columns. The
`successful_sessions` and `failed_sessions` columns are summed per report
document, though, not per policy: when a single report carries multiple
policies, a row's session sums include the sibling policies from that
report as well as its own. Fully attributing session counts to a single
policy would require restructuring the stored documents.