Packet Capture for Real-Time Server Performance Diagnosis

Real-time evidence wins. The stem asks for real-time identification of the cause of a performance problem tied to one server. The governing troubleshooting principle is to observe the actual traffic path at the moment of impairment rather than infer from summaries. Packet capture, option D, records and decodes live frames and packets between the user and the server, exposing retransmissions, out-of-order segments, TCP window changes, resets, and latency. That is the direct way to see why access to a specific server is slow.

What packet capture provides. The substantive comment on the question notes that tools such as Wireshark or tcpdump let an administrator inspect live packets and isolate latency, retransmissions, TCP windowing problems, or dropped packets between the user and the server. This aligns with Network+ troubleshooting doctrine: gather information, establish a theory, test it, and use the appropriate tool. The tool must observe the problem directly rather than merely enable observation or summarize it.

Why the other options fall short. Port mirroring (A) is a supporting mechanism: it copies selected traffic to another port so a capture device can analyze it, but mirroring alone does not identify the cause. Syslog reports (B) are event and log records; they may show an interface flap or error, but they are not a real-time packet-level view of this server conversation. Baseline metrics (C) establish normal behavior and help detect deviation, but they describe trends and thresholds rather than dissect the live exchange causing the current slowdown. Thus B and C are after-the-fact or aggregate views, and A is only the traffic-copying step.

Verdict. The real-time diagnostic action is to capture and inspect packets, so D is correct. In exam terms, choose the tool that directly observes packets on the path; do not select the plumbing that enables capture or the records that summarize it.