A metrics collector belongs to the service lifecycle
Swift System Metrics makes collection a service task. Follow backend startup, shutdown ownership and exporter limits before relying on the final sample.
By 
Paul. Architecture and infrastructure
A periodic metrics collector needs an owner who can start it, observe its failure and stop it with the application. Otherwise, adding instrumentation also adds a background activity whose relationship to the service is unclear. The useful architectural lesson in Swift System Metrics is that collection can join the same lifecycle as the work being observed. The exporter needs to belong to that design too.
Looking back at the week of 18 February 2026, the relevant source is Swift's 20 February introduction. That is the article's date, not the package version's release date: the 1.0.0 release record places the release on 21 January. Separating those events matters when explaining which example prompted a design discussion and when a dependency became available.
Start the destination before collection
The example creates an OpenTelemetry service through OTel.bootstrap, creates the application service and constructs SystemMetricsMonitor. It then includes all three in a ServiceGroup and awaits the group's run method. The monitor reports through Swift Metrics; the backend provides the path from that metrics API towards an external destination. These are separate responsibilities, even when their startup appears together in a short example. Swift's example makes that separation visible.
An application should therefore decide who owns backend configuration before deciding where to construct the monitor. A collector can produce perfectly meaningful observations while the intended exporter is absent or misconfigured. Putting collection in the application does not establish that the receiving system has accepted anything. The design review should trace an observation across that boundary rather than stop at the point where the monitor exists.
Consider a hypothetical server with an HTTP service and a periodic collector. If the HTTP service fails during startup, leaving a detached collection task alive would make the process's remaining activity hard to interpret. Composing service tasks gives the application a place to coordinate those lifetimes. The exact response to a child failure still depends on the lifecycle configuration; membership alone should not be described as a universal recovery policy.
Shutdown has more than one meaning
The February example assigns .sigint to gracefulShutdownSignals and .sigterm to cancellationSignals. Those names describe distinct paths. A reader should not turn the example into the claim that every termination signal gives every component a graceful closing phase. The signal policy belongs to the application, and the deployment environment has to agree with it. The published configuration is specific on this point.
That distinction becomes practical during replacement of a running instance. The operator may allow a limited interval before stopping the process forcibly. Within that interval, the application may need to stop accepting work, finish requests and close telemetry resources. A coherent policy assigns responsibility for each step and explains what happens when the available interval expires. It cannot assume that a process receives unlimited time because one task supports graceful shutdown.
Collection and export can also end at different moments. Stopping a collector prevents later observations. Draining an exporter concerns observations already handed to it. A final measurement may still be waiting in memory, in a transport operation or at the receiving system. These are different states, and a service group's existence does not prove delivery across all of them.
Define the promise around the final sample
The strongest objection to lifecycle composition is that it can make shutdown look more complete than it is. A neat list of services is easy to mistake for a guarantee that the last sample arrives. Network failures, an unavailable receiver and forced termination remain possible. The appropriate conclusion is narrower: shared ownership makes coordination explicit, while delivery requires its own contract and evidence.
For ordinary operational metrics, occasional loss at shutdown may be an acceptable tradeoff. For a business event that must be retained, treating a periodic metric as the authoritative record would need a different justification. The application should separate diagnostic observations from records whose loss changes a business outcome. That decision concerns the meaning of the data, not the visual completeness of a dashboard.
A useful shutdown review asks what counts as successful export and who reports failure. It also asks whether the application can tell the difference between handing a sample to an exporter and receiving confirmation from a remote system. Where that distinction is unavailable, documentation should state the weaker promise. A timeout should be described as a limit on waiting, rather than evidence that delivery completed.
An external collector can be the better owner
In-process collection is not automatically the best choice. A deployment may already have an external collector with independent configuration and a different lifetime. Reusing that arrangement can reduce duplicated operational responsibility, particularly when several services need the same collection policy. Conversely, an in-process monitor can keep application integration explicit. The choice depends on what the deployment already owns and which observations it needs.
Neither arrangement removes failure boundaries. An external collector can remain alive after the application stops, but that does not let it recover every observation that never left application memory. An in-process collector knows its application context, but shares the process's abrupt failures. Compare those limits against the operational question before choosing where collection belongs.
For a custom software project, the useful deliverable is a written lifecycle policy alongside the instrumentation: who starts the backend, who owns collection, which shutdown path applies and what can be lost. Swift's February example offers a concrete starting point. The final decision should make those responsibilities understandable to the person who will operate the service after its first deployment.