About this skill

Problem

When debugging application incidents, engineers often face logs scattered across files: plain-text access logs, JSON lines, stack traces, rotated archives, and cross-service request traces. Manual search is slow and can miss the root cause.

Workflow

shengtest provides a practical path for log analysis: narrow the search first with grep, awk, or jq, then parse structured logs, extract stack traces, aggregate error frequency, and correlate events across services by time or request ID. It also covers day-to-day dev workflows such as tail -f monitoring, grep --line-buffered pipeline filtering, and extracting fields from Nginx/Apache or custom delimited logs. If a team has not structured logging yet, the docs point to Node.js pino, Python structlog, and Go zerolog as setup options.

Caveats

It is closer to a log-debugging methodology and command examples than a full monitoring platform. The guidance stresses finding a request ID or correlation ID first, then filtering by a time window; for large files, prefer awk for counting and aggregation, and handle rotated/compressed files and sampling. If logs lack stable IDs, cross-service correlation becomes much weaker.

Screenshots

Use Cases

Filter production logs by correlation ID and time window to isolate failing requests.
Monitor development logs in real time while observing new errors and key events.
Extract fields from access or JSON logs, count error frequency, and generate reports.
Merge and sort logs from multiple services to reconstruct the request path.

Best For

Backend engineers who need to pinpoint failing requests from production application logs.
Ops engineers who monitor live logs, aggregate error rates, and inspect rotated log files.
Full-stack developers who want structured logging for easier filtering and grouping.
SREs who trace requests across services and produce reviewable error summaries.