Why 'grep error' Fails: Link Browser Requests to Server Logs for Real Troubleshooting

Why Log Reading Is an Advanced Troubleshooting Prerequisite

Front-end reproduction only catches the tip of the iceberg. Real production issues occur before you can ask users to repeat them; the only trace is the system logs. Most companies do not provide GUI log viewers for field support, so you must log into servers and run commands yourself. Even when cloud log services exist, internal network policies often force manual server access.

Searching Only for "error" Misses 90% of Issues

Newcomers often run grep error, grab a few lines, and hand them to developers — only to find the problem persists or the logs are unintelligible. Worse, many cannot identify which service, interface, or business flow generated the error. Logs are the server's "backstage record"; browser requests are the "front-stage action." Troubleshooting is complete only when the two are correlated.

Step 1: Capture the Real Request with Browser Developer Tools (F12)

Open Developer Tools

Windows: F12 or Ctrl + Shift + I Mac: Command + Option + I Switch to the Network panel.

Reproduce and Capture

Clear the panel.

Keep the panel open and reproduce the failing action (e.g., click Save).

Stop immediately and inspect the listed requests.

Three Critical Data Points

Request URL — e.g., /am/user/query or /trade/order/save. This becomes the core keyword for log searches. The URL path often reveals the service name (first segment), controller (second), and specific interface (third). For /am/user/query, am is the service, user the controller, query the interface.

Status Code — 200 (OK), 400 (bad params), 401 (auth), 404 (not found), 500 (server error — 90% require log inspection).

Request Payload / Form Data — Shows parameters sent (IDs, names, timestamps). Many "system errors" are actually malformed, missing, or incorrectly formatted parameters.

Field Tip: When the page shows "System Exception" or "Operation Failed" with a 500 status, copy the interface URL — searching logs with it yields pinpoint accuracy.

Step 2: Distinguish "Service" from "Business"

What Is a Service?

A service is a program running on the server: Tomcat, Spring Boot JARs, MySQL, Redis, Nginx, middleware, API services, cron jobs. Services reside on servers, run continuously in the background, produce logs, and when they crash or time out, the front end reports errors. The browser request you captured invokes a specific service.

What Is a Business?

Business is the concrete function the system performs: user login, permission config, device registration, data collection, work-order dispatch, report generation, order saving, workflow approval. Business maps to page features, corresponds to one or more interfaces, and a business exception equals a failed interface call plus a logic error.

Canteen Analogy

Service = Kitchen (always running, cooks food)

Business = You ordering Braised Pork (specific task)

Interface = The order ticket you hand over (URL + parameters)

Kitchen collapse = service failure (logs full of errors). Over-salted dish = business failure (parameter/logic issue).

Step 3: Connect Browser Requests to Server Logs

The universal chain: Page Action → Browser Capture (URL + Params) → Server Receives → Executes Business Logic → Writes Logs → Returns Result . Therefore, the troubleshooting order is always:

Click on page → Capture interface via F12.

Obtain interface URL and timestamp.

On the server, search for that interface + that time.

Examine what the logs show for that request.

Not: blindly grep error → see many errors → not know which feature they belong to → spiral into confusion.

Step 4: Complete Walkthrough — "Save Device" System Exception

Scenario: User clicks "Save Device" and gets a system exception. Two modes:

Mode 1: Real-Time Tracking (Self-Test Reproduction)

Open F12 → Network, ready to capture.

SSH to server, locate the laotang service log file (see Step 5 for finding paths).

Run real-time monitor: tail -f /data/logs/laotang/app.log. tail -f streams new log lines continuously.

Return to page, click "Save Device".

Watch terminal; logs appear instantly, e.g.:

2025-01-15 14:23:45.123 INFO [http-nio-8080-exec-1] laotang/device/save Received request, params: deviceId=123

2025-01-15 14:23:45.456 ERROR [http-nio-8080-exec-1] laotang/device/save Save failed: Database connection timeout