Troubleshooting keeps coming back to one question: what is this machine actually talking to? The dependencies drawn in an architecture diagram and the ones that exist in production right now are rarely the same thing — a service is retired but stays on the diagram, a new call is added and nobody updates it, and after containers move around it stops matching entirely. So you end up on the host, reading connections one at a time.
ServiceMap (Beta) takes a different route: instead of relying on a hand-maintained diagram, it builds the dependency topology among hosts, processes, containers, and workloads directly from the real network connections monit-agent observes through eBPF. It shows what is communicating right now, not what the documentation says should be.
Turning "a connection" into "a service dependency"
The raw fact the Agent observes is "this process connected to this ip:port". ServiceMap matches that target endpoint against known listeners within the same network scope to recover a service-level dependency, and labels how much you can trust it: a unique match is Confirmed; a match against several possible counterparts is Candidate, which you resolve with context; an endpoint that matches no listener is Unresolved and stays off the canvas by default, so external addresses and short-lived connections don't bury the real dependencies.
On the canvas you can filter by resolution status, adjust the upstream and downstream hop range, and double-click any node to focus on just its neighborhood. Open a node or a dependency and the side panel gives you entity identity, executable, container and workload, target endpoint, resolution reason, candidate count, and confidence — these are exactly what tells you whether a dependency is trustworthy.
Unresolved connections aren't hidden
Endpoints with no matching counterpart are grouped by reason in their own panel, filterable by endpoint or source service, and exportable to CSV for offline reconciliation. From there you can also locate the source, jumping back to the canvas with the originating entity highlighted.
It tells you how much to trust the picture first
A topology is built from evidence within a recent observation window — it is not a live snapshot and it is not guaranteed to be complete. So the query info explicitly reports the capture mode, evidence freshness, the projection state of the listener inventory and Kubernetes metadata enrichment, and whether this query hit any truncation. If freshness isn't fresh, or a truncation notice appears, the graph can't be read as a complete real-time dependency set — showing you the basis for that judgment is more useful than handing you a graph that merely looks certain.
Get started
Go to Flashduty console → Monitors → Monitoring objects and click Topology on a host row, or use ServiceMap Hosts in the toolbar to browse every reporting host.
ServiceMap is in beta, so its behavior and interface may still change. It relies on monit-agent's eBPF observation — if the Agent is too old, the runtime doesn't support it, or ServiceMap isn't enabled, there is no topology data.
For details, see the product documentation.