Zero-Instrumentation Dependency Discovery for Guided Microservice Migration Using eBPF

Zero-Instrumentation Dependency Discovery for Guided Microservice Migration Using eBPF Eshan Trivedi1 and Chandrahasa Pranava2

arXiv:2608.04413v1 [cs.DC] 5 Aug 2026

1

Independent researcher, San Francisco, USA, eshanntrivedi@gmail.com 2 Independent researcher, Dubai, UAE, vvscpranava@gmail.com

the same peak below 48% and reduces cumulative exposure by 27%. We did not execute the migrations themselves. The obstacle to doing better is that runtime dependency graphs are largely invisible. Service meshes such as Istio [3] and Linkerd [4] can expose this information, but they require sidecar injection, mutual Transport Layer Security (TLS) configuration, and ongoing operational overhead that many teams defer or avoid. Static analysis of configuration files misses dynamic behavior. Distributed tracing systems such as Jaeger [5] require application-level instrumentation. We take a different approach: observe the kernel’s Transmission Control Protocol (TCP) layer directly using the extended Berkeley Packet Filter (eBPF) [2], where every connect and accept syscall is visible regardless of the application stack. This requires no code changes, no sidecars, and no restart of running services. The probe attaches and detaches at the operator’s discretion. The technical challenge is attribution: when all microservices run as indistinguishable python3 processes under the same OS user (a common pattern in containerized or VM-hosted deployments), eBPF events carry no service identity. We solve this with a two-pass PID-port correlation algorithm that infers service identity from the ports each process listens on, then attributes outbound connections accordingly. This paper makes three contributions: 1) PID-port correlation: A two-pass algorithm that resolves service identity in shared-runtime environments using I. I NTRODUCTION only kernel-observable events, recovering the correct identity of all 20 services in our testbed as measured Cloud operators routinely migrate microservices across against the known ground-truth topology (§V-A). virtual machines to consolidate costs, satisfy service-level 2) Spectral clustering with Kernighan-Lin (KL) refineagreement (SLA) requirements, or respond to hardware failment: Application of spectral graph clustering to the ures [1]. The dominant practice is to move services one at a eBPF-derived dependency graph, augmented with KL time in an order determined by team ownership, alphabetical bisection refinement that directly minimizes the interconvenience, or rough intuition about which services are “less VM communication cut rather than Euclidean embedding important.” None of these approaches account for the runtime distance (§V-B). Both algorithms are long established; we communication graph: which service calls which, how often, claim no algorithmic novelty here, only their combination and how much traffic crosses VM boundaries at each step of and their application to an automatically derived graph. the migration. 3) ROI-ranked migration ordering: A per-service ROI Moving a high-fan-in hub service early immediately exposes score that balances traffic consolidation benefit against all of its callers to cross-VM network latency for the rest of dependency-depth risk and load variance, producing a the migration window. Moving leaf services last wastes the phased migration plan evaluated against naive baselines chance to co-locate them with their dependencies at low cost. in simulation (§V-C). In simulation over our 20-service testbed graph, the worst-case naive ordering sustains cross-VM traffic above 50% of total flow We report these as results on a single synthetic testbed. §VIII volume for seven of eleven migration steps; our approach keeps states plainly what that does and does not establish.

Abstract—Migrating microservices across virtual machines (VMs) without knowledge of their runtime communication patterns risks creating cross-VM hotspots and latency spikes that are difficult to predict from static analysis alone. We use extended Berkeley Packet Filter (eBPF) kernel-level network tracing to automatically discover inter-service dependencies at runtime, with no application instrumentation, and use the resulting dependency graph to produce a traffic-aware migration plan ranked by return on investment (ROI). A two-pass process-identifier (PID) to port correlation algorithm recovers the identity of all 20 services in a shared-runtime testbed where processes are otherwise indistinguishable, matching the known ground-truth topology. The system discovers 32 dependency edges from 13,615 network events captured in three minutes, and applies spectral graph clustering with Kernighan-Lin refinement to partition services into VM-coherent groups. In simulation over the discovered graph, our ROI-ranked migration order reduces cumulative cross-VM traffic exposure during the migration window by 27% relative to alphabetical ordering, a deterministic proxy for arbitrary dependency-blind ordering. Collection overhead is mixed: in a controlled A/B test at near-saturation load on a host with two virtual CPUs (vCPUs), throughput fell by only 4.4%, but median (p50) latency rose by 383% and 99th-percentile (p99) latency by 1,050%. We therefore recommend running captures off-peak or on dedicated sampling nodes rather than under production saturation. All results are from a single 20-service testbed that we authored; we make no claim about behavior on production dependency graphs. Index Terms—eBPF, microservice migration, dependency discovery, spectral clustering, service placement, cloud infrastructure

II. BACKGROUND A. eBPF and Network Tracing

eBPF Probes NDJSON events

Extended Berkeley Packet Filter (eBPF) allows verified PID Correlation programs to run inside the Linux kernel in response to windowed edges events such as system calls, tracepoints, and kprobes, without modifying kernel source or loading kernel modules [2]. Spectral Cluster For network dependency discovery, the relevant hooks are VM assignment tcp_v4_connect (outbound TCP connection attempts) and inet_csk_accept (accepted incoming connections). Each ROI Scorer event yields the source/destination Internet Protocol (IP) phased plan address and port tuple, the process thread-group identifier (TGID, the kernel’s identifier for a process), and a nanosecond timestamp, which is enough to reconstruct service-to-service Fig. 1. Four-phase pipeline. Phases are decoupled; each writes a file consumed by the next, enabling incremental reruns. communication graphs at any desired granularity. The eBPF verifier enforces termination and memory safety, making probes safe to attach to production kernels. The works at the kernel layer, requires no application changes, and probe fires once per TCP connection establishment rather than can be applied to legacy or third-party services that cannot be once per packet, which bounds the event rate even for highmodified. bandwidth services holding persistent connections. Bounding VM and container migration. Live VM migration has been the event rate is not the same as bounding cost, however: §VI-C studied extensively [9], [10], as has container placement [11]. shows that draining those events competes for CPU with the These works focus on minimizing downtime during the move of application itself on a resource-constrained host under load. a single service; they do not address the multi-service ordering B. The Microservice Migration Problem problem. Commercial tools such as AWS Migration Hub and Azure Migrate operate on inventory and cost data rather than Given n services initially co-located on a source VM, and a runtime traffic graphs. target topology of k VMs, the migration planning problem has Graph partitioning for service placement. Spectral partwo subproblems: (1) partition: assign each service to a target titioning is a standard technique for balanced graph bisecVM to minimize cross-VM traffic, and (2) ordering: determine tion [12], [13]. Prior work has applied it to data-center network the sequence in which to move services to minimize cross-VM topology [14] and microservice placement [15]. We extend traffic during the migration window, not just at its end. this line of work by (a) deriving the input graph automatically Both subproblems are NP-hard in general [16]. Spectral from eBPF telemetry and (b) adding KL refinement to directly methods provide effective polynomial-time approximations for optimize the cut metric relevant to migration cost. the partition problem [12]. The ordering problem appears to have received considerably less attention than the partition IV. S YSTEM D ESIGN problem, and we did not find prior work treating it as a dependency-aware optimization target. We note that our survey The system comprises four decoupled phases (Fig. 1): is not exhaustive, and that commercial migration tooling is Phase 1: eBPF capture. A lightweight nettrace not documented in enough detail to rule out similar heuristics daemon attaches kprobes to tcp_v4_connect and being used in practice. inet_csk_accept. Each event is emitted as a JSON record III. R ELATED W ORK containing timestamp (nanosecond), source/destination port, Service dependency discovery. Dependency maps have been direction flag, and process TGID. The daemon writes appendinferred from distributed tracing systems such as Dapper [6] only newline-delimited JSON (NDJSON); it can be attached and Jaeger [5]. These approaches require instrumentation at the and detached without restarting any service. Phase 2: PID-port correlation and windowing. Raw events application layer, whether through modified shared libraries are parsed by the two-pass algorithm described in §V-A. The or explicit span annotation. eBPF-based dependency discovery output is a set of windowed edge comma-separated value has been demonstrated in the context of security monitoring [7] (CSV) files (edges_{ts}.csv), each recording aggregated and performance profiling [2], but not, to our knowledge, for flow counts between named service pairs over a configurable migration planning. time window (default: 60 seconds). Service mesh observability. Istio [3] and Linkerd [4] expose Phase 3: Spectral clustering. Windowed edge files are agrich service graphs via their data planes, but require sidecar gregated into a weighted undirected graph. Spectral embedding injection and place a proxy on the data path, which consumes followed by k-means and KL refinement assigns each service CPU per proxy and adds per-request latency. Istio publishes to a VM partition (§V-B). per-version benchmark figures for this cost [8]; the magnitude depends on release, configuration, and traffic pattern, so we Phase 4: ROI scoring and plan generation. Given the VM do not quote a single number. Our approach is orthogonal: it partition and the dependency graph, the ROI scorer computes

a per-service migration priority score and emits a phased migration plan ranked by ROI (§V-C). V. I MPLEMENTATION A. PID-Port Correlation When microservices run as identically-named processes (e.g., all as python3 on the same host), eBPF events carry no usable service identity in the comm or service_id fields. All 20 services in our testbed exhibited this pattern. We solve the attribution problem with a two-pass algorithm over the raw event stream: Pass 1: Build TGID to port map. For every accepted connection on a known service port, we record a vote for that port against the accepting TGID. After processing all events, each TGID is assigned to the port it accepted on most often. Pass 2: Attribute outbound calls. For every dir=0 (connect) event to a known service port d, we look up the originating TGID in the map from Pass 1 to obtain the source service name, and emit the edge port(tgid) → d. In our 20-service testbed, Pass 1 recovers all 20 TGIDs within the first 200 accept events, and attribution stays stable for the rest of the capture. No service configuration files or process labels are needed. Because we authored the testbed, the correct mapping was known in advance, so this establishes that the attribution mechanism works rather than that it discovers an unknown topology.

spectral embedding alone. In our evaluation the target topology is two VMs: all 20 services begin co-located on the source VM, and the partition assigns each service either to remain there or to move to the second VM, so the clustering and refinement operate on a two-way cut (k = 2) throughout. C. ROI-Ranked Migration Ordering The partition from §V-B determines which VM each service should occupy; the ordering problem determines when to move each service to minimize cross-VM traffic during the migration window. We define the ROI score for service S moving from Vsrc to Vdst as: benefit(S) − cost(S) ROI(S) = (1) depth(S) × variance(S)

where: • benefit(S): total flows between S and services already assigned to Vdst (these become intra-VM after the move). • cost(S): total flows between S and services remaining on Vsrc (these become cross-VM after the move). • depth(S): in-degree of S in the dependency graph (number of distinct callers); high depth indicates greater blast radius if the move disrupts service availability. • variance(S): standard deviation of S’s total flow volume across time windows; high variance indicates unpredictable load and higher migration risk. B. Spectral Clustering with KL Refinement Services are migrated in descending ROI order. High-ROI Given the weighted dependency graph G = (V, E, w), we services have large benefit, small cost, few callers, and stable compute the normalized Laplacian L = I − D−1/2 AD−1/2 load, so they are safe to move early. Low-ROI services (hubs, and embed each service into R16 using the first 16 non- high-variance services) move last, once their dependencies are trivial eigenvectors of L [12]. k-means is then applied to this already on the target VM. embedding to produce an initial k-partition. With |V | = 20, a VI. E VALUATION 16-dimensional embedding is only a modest reduction, so the embedding step contributes less here than it would on a larger A. Experimental Setup graph; most of the partition quality comes from the refinement We deploy a 20-service microservice stack on two Digipass below. talOcean droplets (2 vCPU / 4 GB RAM each). All services Standard spectral clustering minimizes the ratio cut in run as Python 3 processes on ports 8001–8020, representing the embedding space rather than directly minimizing inter- security, analytics, business, and infrastructure tiers. Services partition edge weight. We add a Kernighan-Lin (KL) refinement communicate via the Hypertext Transfer Protocol (HTTP); the pass [17] that operates on the original graph: gateway service (port 8020) acts as the primary entry point for 1) For each pair of clusters (Ci , Cj ), compute the D-value external load. for each node v: For dependency capture, we attach the nettrace eBPF daemon and drive load against each service’s /workflow endpoint, D(v) = w(v, C̄v ) − w(v, Cv \ {v}) which triggers realistic fan-out calls to downstream services. where Cv is the current cluster of v and C̄v is the other We capture 13,615 events over three minutes, yielding 2,400 cluster in the pair. attributed flow records across 4 time windows. 2) Iteratively select the swap (a ∈ Ci , b ∈ Cj ) maximizing For overhead measurement, we use a single-stack A/B D(a) + D(b) − 2w(a, b), accumulating swaps without design: 5 minutes of warmup, followed by a 3-minute baseline applying them. phase (collector off) and a 3-minute measurement phase 3) Apply the prefix of swaps with maximum cumulative (collector on, no restart). Load is generated by wrk2 [18] gain. at a fixed rate of 200 requests per second (RPS) against the 4) Repeat until no improving swap exists or a pass limit is MoveGroups application programming interface (API) stack reached. (nginx + Gunicorn + PostgreSQL + Redis). KL refinement directly minimizes the inter-partition edge We measure overhead against this stack rather than against weight (cut%), making it better suited to our objective than the the Python testbed because it is closer to a production

TABLE I T OP DEPENDENCY EDGES DISCOVERED BY PID- PORT CORRELATION Source

Destination

search-service auth-service catalog-service catalog-service catalog-service fraud-detection gateway-service shipping-service cart-service gateway-service

catalog-service fraud-detection cache-service image-service inventory-service analytics-engine auth-service order-service pricing-service cart-service

Flows 86 85 85 85 85 85 85 85 66 17

TABLE II E BPF COLLECTION OVERHEAD ( CONTROLLED A/B, SINGLE STACK )

Metric RPS p50 latency p99 latency Socket errors Non-2xx

Baseline (OFF)

Collector ON

Delta

199.6 112 ms 688 ms 0 0

190.7 542 ms 7,910 ms 0 0

−4.4% +383% +1,050% — —

deployment in its process model and connection behavior, and we wanted the overhead number to mean something outside the testbed. The tradeoff is that the two workloads differ in connection establishment rate, which is precisely the quantity eBPF collection cost scales with. The figures in §VI-C therefore characterize this stack, and should not be read as the overhead the testbed of §VI would have incurred. B. Dependency Graph Discovery

Fig. 2. Simulated cross-VM traffic (cut%) at each migration step for our ROI-ranked order versus three naive baselines, over the dependency graph discovered from our 20-service testbed. Lower area under curve = less crossVM traffic exposure during the migration window. In simulation, our approach reduces cumulative exposure by 27% versus alphabetical ordering and 30% versus most-called-first; no services were actually migrated.

attribute this to CPU contention between the eBPF ring-buffer drain and the Gunicorn worker threads under near-saturation load (200 RPS against a 2-vCPU host). If that mechanism is the right one, the effect should diminish where the host has spare CPU headroom. We did not measure any lower load level, so this remains a hypothesis that our data does not test, and the numbers above should be read as characterizing the saturated case only. eBPF collection is not free under load. Operators should run dependency captures during off-peak periods or on dedicated sampling nodes rather than under production saturation.

Pass 1 of the PID-port correlation algorithm recovers all D. Migration Ordering Comparison 20 service TGIDs within the first captured accept events. Fig. 2 shows the cut% trajectory for four migration orderings Table I shows the 10 highest-flow edges; the full graph applied to our 20-service dependency graph. We define cut% contains 32 edges spanning all 20 services. Notable structural as the fraction of total observed flow volume that crosses features: catalog-service is the highest in-degree node VM boundaries at each step. The orderings are evaluated by (6 distinct callers), audit-service serves as a logging hub simulating each migration sequence over the discovered graph; for operational services, and analytics-engine is the no services were actually moved, and the simulation assumes analytics sink for the fraud, pricing, and recommendation tiers. the graph is static across the migration window. These relationships were reconstructed automatically from We compare: three minutes of runtime observation, without reading any • ROI-ranked (ours): services ordered by Eq. (1). service configuration. Two caveats apply. We wrote the testbed, • Alphabetical: lexicographic order by service name, a so the call graph was documented by construction; the result common default in runbook-driven migrations. Because shows the pipeline recovers a known graph from kernel events, service names carry no information about the communot that it surfaces relationships nobody knew. And the flow nication graph, this baseline serves as a proxy for an counts in Table I are near-uniform (85–86 on most edges) arbitrary (random) ordering, with the advantage of being because load was driven at a fixed rate against each service’s deterministic and reproducible. /workflow endpoint. Real dependency graphs are heavily • Most-called first: services ordered by in-degree descendskewed, with long tails and code paths that fire rarely or only ing, representing an intuitive but incorrect heuristic (move under specific conditions; we have no evidence about coverage busy services to their new home early). or attribution accuracy in that regime. • Reverse-ROI: deliberately worst case. C. eBPF Collection Overhead Table III reports the area under the cut% curve (AUC), so that Table II shows the overhead results. Throughput impact is lower values indicate less cumulative cross-VM traffic exposure. negligible (−4.4%). Tail latency, however, increases substan- Our approach achieves an AUC of 301.7, representing a 27.1% tially at saturation: p50 rises by 383% and p99 by 1,050%. We reduction versus the alphabetical proxy for arbitrary ordering

TABLE III A REA UNDER CUT % CURVE ( LOWER = BETTER ) Ordering

AUC

ROI-ranked (ours) Alphabetical Most-called first Reverse-ROI (worst)

301.7 413.9 432.9 440.1

and a 30.3% reduction versus most-called-first. These are single numbers from one graph, one target topology (k = 2), and one migration granularity; we did not vary any of these, so the magnitude should not be expected to transfer. The improvement is concentrated in the first half of the migration window (steps 1– 6), where our approach moves leaf services with zero cross-VM cost first, while naive orderings immediately expose high-traffic hub dependencies. The first three services in our ranked order (image-service, search-service, metrics-collector) have zero callers on the source VM; moving them creates no new cross-VM edges. Naive orderings move analytics-engine or audit-service early due to alphabetical precedence, immediately creating 4–6 cross-VM edges that persist for the remainder of the migration. VII. D ISCUSSION

does not demonstrate discovery of unknown dependencies, and it does not exercise the conditions that make real dependency discovery hard, namely skewed traffic, rare code paths, and services whose behavior varies with input. Simulated migration outcome. The 27% figure comes from simulating orderings over the discovered graph, not from performing migrations. The simulation holds the graph fixed across the window and ignores migration duration, partial availability, and retry traffic during cutover. We have not varied the topology, the number of target VMs, or the graph size, so we cannot say how sensitive the result is to any of them. Overhead measured on a different stack and one load level. Overhead was measured against the MoveGroups API stack rather than the testbed, at a single rate of 200 RPS on a 2-vCPU host. Connection establishment rate differs between the two workloads, and we have no measurements at lower utilization, so the overhead profile across the operating range is unknown. Scale. Twenty services across two VMs is small. Spectral partitioning and KL refinement are both well characterized at larger scales. The parts that worry us are the ones we measured: eBPF event volume, the ring-buffer pressure behind the tail latency effect, and whether PID-port voting stays stable when hundreds of processes contend for the same well-known ports. No comparison against existing dependency sources. We argue that our approach avoids the operational cost of a service mesh, but we never put the two side by side. Running Istio or Jaeger against the same workload and diffing the resulting graphs against ours is the obvious way to show that kernel-level observation misses nothing important. It is also the experiment we would run first if we continued this work.

Generalizability. The PID-port correlation algorithm assumes each service consistently listens on a stable port. This holds for the vast majority of containerized and VM-hosted deployments. It would not hold for services using dynamic port binding or multi-port services where the same TGID accepts on multiple well-known ports; in those cases, the voting heuristic would need augmentation with container metadata. IX. C ONCLUSION Capture duration. Three minutes of targeted load was We built an end-to-end system for dependency-aware misufficient to discover 32 dependency edges in our testbed. In production environments with more complex call graphs or croservice migration planning using eBPF network tracing. Its infrequent code paths, longer captures or endpoint-directed three core pieces are PID-port correlation for service attribution, synthetic load may be necessary to achieve complete coverage. spectral clustering with KL refinement for VM partitioning, Tail latency under saturation. The p99 latency spike and ROI-ranked migration ordering. Together they replace adobserved in §VI-C is a real operational concern. We recommend hoc migration sequencing with an approach grounded in live running eBPF captures during scheduled maintenance windows runtime behavior. On a 20-service testbed, the pipeline recovers the full or using sampling (capture 1-in-N connections) to reduce ringinter-service dependency graph from three minutes of traffic buffer pressure under load. Dynamic graphs. Microservice dependency graphs change observation, and in simulation its ROI-ranked ordering reduces as services are updated or traffic patterns shift. The pipeline cumulative cross-VM traffic exposure by 27% relative to supports incremental recapture; re-running Phases 1–2 on a alphabetical ordering. Collection overhead is asymmetric: at new capture and comparing the resulting graph against the near-saturation load on a 2-vCPU host, throughput dropped 4.4% while p99 latency rose by an order of magnitude, which previous partition can detect drift and trigger replanning. is a real constraint on when captures can be run. VIII. L IMITATIONS The pipeline needs no code changes, no service mesh, and no We report a working end-to-end pipeline evaluated on one help from service developers. Any operator with root access to synthetic testbed. The following constraints bound what that the host can attach the eBPF probe and get a dependency-aware evaluation supports. migration plan in under 10 minutes. Whether the planning Authored ground truth. We wrote the 20-service testbed, benefit survives contact with a production dependency graph, chose its topology, and generated its load. Recovering that and whether the overhead profile improves with CPU headroom, topology validates the attribution and clustering machinery; it are the two questions we would want answered next.

ACKNOWLEDGMENT AI-based writing assistance was used in drafting and editing the text of this paper. The system design, implementation, experiments, and all reported measurements are the authors’ own work; every reference was verified against its source by the authors prior to submission. R EFERENCES [1] C. Pahl and P. Jamshidi, “Microservices: A systematic mapping study,” in Proc. CLOSER, 2016. [2] B. Gregg, BPF Performance Tools. Addison-Wesley, 2019. [3] L. Calcote and Z. Butcher, Istio: Up and Running. O’Reilly, 2019. [4] Buoyant, “Linkerd,” https://linkerd.io, 2024. [5] Uber Technologies, “Jaeger: Open Source, End-to-End Distributed Tracing,” https://www.jaegertracing.io, 2024. [6] B. Sigelman et al., “Dapper, a Large-Scale Distributed Systems Tracing Infrastructure,” Google Technical Report, 2010. [7] The Falco Authors, “Falco: Cloud-Native Runtime Security,” https://falco. org, 2024. [8] Istio, “Performance and Scalability,” https://istio.io/latest/docs/ops/ deployment/performance-and-scalability, 2024. [9] C. Clark et al., “Live Migration of Virtual Machines,” in Proc. NSDI, 2005. [10] M. Nelson, B.-H. Lim, and G. Hutchins, “Fast Transparent Migration for Virtual Machines,” in Proc. USENIX ATC, 2005. [11] B. Burns et al., “Borg, Omega, and Kubernetes,” ACM Queue, vol. 14, 2016. [12] A. Y. Ng, M. I. Jordan, and Y. Weiss, “On Spectral Clustering: Analysis and an Algorithm,” in Proc. NeurIPS, 2001. [13] J. Shi and J. Malik, “Normalized Cuts and Image Segmentation,” IEEE Trans. Pattern Anal. Mach. Intell., vol. 22, no. 8, 2000. [14] R. N. Mysore et al., “PortLand: A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric,” in Proc. SIGCOMM, 2009. [15] L. Luo et al., “Characterizing Microservice Dependency and Performance: Alibaba Trace Analysis,” in Proc. SoCC, 2021. [16] K. Andreev and H. Räcke, “Balanced Graph Partitioning,” in Proc. SPAA, 2004. [17] B. W. Kernighan and S. Lin, “An Efficient Heuristic Procedure for Partitioning Graphs,” Bell System Technical Journal, vol. 49, no. 2, 1970. [18] G. Tene, “wrk2: A Constant Throughput, Correct Latency Recording Variant of wrk,” https://github.com/giltene/wrk2, 2024.

Related documents

• NFSv4.0 Migration: Specification Update#166287
• Monotonicity-Guided Bottom-Up Petri Net Discovery: The SPECpp Framework#441893
• Characterizing the eBPF-Based Data Plane for Multi-ClusterKubernetes: A Systematic Evaluation of Cilium Cluster Meshand KVStoreMesh#1142836
• Characterizing the eBPF-Based Data Plane for Multi-ClusterKubernetes: A Systematic Evaluation of Cilium Cluster Meshand KVStoreMesh#1136804
• CVE-2026-61674 — CRITICAL 9.2#1040106