Table of Contents

Class MailDeliveryTelemetry

Namespace
MailFathom.Infrastructure.Observability
Assembly
MailFathom.Infrastructure.dll

Reports what a deployment's outbox is doing, as the questions an operator actually asks of it.

public sealed class MailDeliveryTelemetry
Inheritance
MailDeliveryTelemetry
Inherited Members

Remarks

The first is whether mail is leaving, which the attempt counter answers by account and by outcome. The second is whether one particular submission is the slow part, which the span answers by covering the exchange with the server and nothing else — the claim, the record movements, and the backoff are local work and would blur what the span is for.

The third is whether the owner can see what they sent in their own mail client, which the filing counter answers by account, by the place a copy was meant for, and by outcome. It is a counter of its own rather than a dimension of the attempts, because the two say different things about the same message: a copy that could not be filed never means the message failed to reach anybody, and summing them would produce a failure rate nobody could act on.

The fourth is whether the drafts folder shows what this deployment holds, which the draft counter answers by account and by outcome. A counter of its own again, and for a sharper form of the reason: a draft was never offered to anybody, so folding it into either of the two above would put an act that cannot fail a recipient into a rate an operator reads as mail not arriving.

The one outcome worth alerting on is the unknown one, and it is a dimension of the same counter rather than an instrument of its own: a send whose server never answered is neither a success nor a failure, and separating it would let a dashboard summing successes and failures report a total that quietly omits it.

Two instruments beside those answer questions no rate can. The retries say how much of the attempt count is work being repeated, which is what separates an instance that is sending a lot from one that is failing and trying again; the depth is the level all of them are a rate against, so a stalled outbox is visible while it is still small and long before anybody is told about a message that never arrived. The depth is a gauge over the last figure a pass measured rather than a live count, for the reason the queue's own is: an exact live count is a query, and making it a gauge would put that query on whatever interval a collector happened to be configured with.

Nothing recorded here is mail. The account alias is MailFathom's own configured name, the outcome and the stage are closed sets of words this system chose, and the one identifier a span carries is the record's own, which is what an operator types into mfctl to read the send a slow trace belongs to. No address, subject, reply text, or recipient count reaches a span, a log, or an exporter.

Constructors

MailDeliveryTelemetry(TimeProvider)

Initializes the instruments every delivery attempt reports through.

Methods

Report(MailAccountId, MailOutboxPassReport)

Publishes what one pass over an account's outbox did.