September 18, 2026
AI 지원 로그 분석
일반 앱은 보통 데이터가 몇 GB 정도 이에요. 로그-파일들도 몇 GB 정도 이에요. 그래서 일반 컴퓨터가 이 데이터를 쉽게 처리할 수 있어요. 유닉스의 도구와 파이프로 즉석 처리할 수 있어요. 근데 이 파이프 쓰는 게 시간이 좀 필요해요.
나는 AI를 로그-파일 보는기 판도를 바꾸는 것이예요: 제가 AI에 질문 물어보고 AI 코딩 에이전트가 유닉스 파이프와 유익스의 도고와 작은 Python 스크립트로 대답해봐요.
예는: 내가 몇일 전에 느린 응답을 조사했어요:
1. 모르는 로그-파일 형식
로그-파일 몰랐어서 그냥 물어봤어요:
결과, 요약/축약:
> What can these logs tell me. What information is in it?
# AI는 생각하고 도구 호출
# Python 스크립트 3개 사용했어요.
These are AWS Application Load Balancer (ALB) access logs for the load balancer.
They record one line per HTTP(S) request handled by the ALB.
What each entry can tell you
They include:
Timestamp in UTC
Client source IP and port
Backend target that served the request, e.g. 10.1.2.151:8090
Request method, URL/path, protocol, such as GET /healthcheck HTTP/1.1
Host header and User-Agent
ALB and backend HTTP status codes
Timing:
time spent receiving the request
backend/target processing time
time spent returning the response
Request/response byte sizes
TLS version and cipher
Target group, selected target, routing action (forward or redirect)
AWS trace ID, useful for correlating with application tracing
# 그리고 나중에
Response outcomes
ALB status Count Interpretation
----------- ------- -------------------------------------------
200 2,693 Successful
301 212 Permanent redirect, likely HTTP -> HTTPS
302 188 Temporary redirect
404 532 Resource not found
400 129 Invalid/malformed request; many rejected at the ALB
405 10 Unsupported method
401 9 Authentication required/failed
406 3 Not acceptable
460 6 Client disconnected before the target responded
# ...
Performance
For requests that reached a target:
Median backend processing time: 4 ms
95th percentile: 685 ms
99th percentile: 1.864 s
Slowest request: 24.181 s
# ....2. 문제 있는 시간을 질문
내가 언제 문제 있어는지 알고 있어서 이 시간에 뭐 있는지 물어봤어요.
결과, 요약/축약:
> Around the time Sep 11, 2026 08:20:00 UTC, what requests got answered. What was the response time, status code etc.
> Overview of a window of 10 minutes before and after the provided timestamp.
# AI는 스크립트 더 사용했어요.
# ...
Notable events
08:10:49.040 — GET /v1/some-endpoint, routed to 10.1.2.252:8090, resulted in ALB 460.
This means the client disconnected before a response was completed; consequently, no target status or target duration was recorded.
08:11:18.717 — GET /v1/some-endpoint, served by 10.1.2.151:8090:
ALB status / target status: 200 / 200
Target processing: 24.181 s
This is the clear latency outlier in the window.
08:29:36.410 — GET /v1/some-endpoint, served by 10.1.2.151:8090:
Status: 200 / 200
Target processing: 7.347 s
A second, less severe slow request.
# ...3. 다른 로그-파일 같이 분석해요.
난 지금 느린 HTTP 요청가 있는데 알아요. 나도 다른 시스템의 로그-파일 있어요. 그래서 같이 분석해요:
결과, 요약/축약:
> In the @other-system-log-2026-09-14.csv, is there any slow request that reponds to the slow times in the access logs.
Longer than 5 secons?
# AI는 생각하고 도구 호출
I matched on the endpoint and completion timestamp. The CSV message timestamp includes Z (UTC), and for the successful requests below it is within 1–8 ms of the ALB log timestamp. All are:
GET /v1/some-endpoint
Completion time (UTC) ALB target (s) App logged (s) App request ID
------------------------ --------------- --------------- ------------------------------------
2026-09-11 01:51:43.109 7.331 6.484 f19460c8-2377-43e3-95dd-1cac292f7aab
2026-09-11 07:33:18.573 23.563 23.637 adfbebe6-6641-48e9-9f70-4a93b0d135a6
2026-09-11 07:33:36.271 22.168 21.892 f391b41f-c774-4f7a-b2cf-95af7c847c77
2026-09-11 07:33:55.070 10.284 10.338 e6d8499b-acb4-473d-9a25-2db694cd1059
2026-09-11 07:50:43.006 5.391 5.377 a349c7d7-60ec-45ae-be3c-a1c5e025bf81
2026-09-11 08:11:18.717 24.181 24.209 67bd04c9-6ebc-45d3-9c8c-b173a6a0962d
2026-09-11 08:29:36.411 7.347 7.408 dbf81ef9-d6c9-40a7-b7ce-ed7b023dd0e8
2026-09-11 10:39:52.976 15.441 15.396 defaa4da-2f36-40fe-b354-3782caef6f5d
2026-09-11 11:35:42.570 5.299 5.184 53333c14-c6e5-4c1e-870b-5e733b0f03464. 타임라인
그래서 내가 느린 요청의 타임라인을 알고 싶었어요.
결과, 요약/축약:
> Create a timeline for the request f391b41f-c774-4f7a-b2cf-95af7c847c77
# AI는 생각하고 도구 호출
UTC time Elapsed Event
---------------------- ------------- ------------------------------------------------------------
07:33:14.099 +0 ms ALB created the request.
07:33:14.103 +4 ms Approximate start of ALB target processing.
07:33:14.378 +279 ms Application began handling GET /v1/some-endpoint on worker nio-8090-exec-6.
07:33:14.585 +486 ms Began fetching the requested data, data-ids etc.
07:33:15.466 +1.367 s Initial file fetch completed: 890 ms, 793 bytes. Rendering began.
07:33:15.578 +1.479 s Began fetching extra data 1.
07:33:15.965 +1.866 s extra data 2 fetched: 388 ms, 3,880 bytes.
07:33:15.980 +1.881 s Began fetching extra data 2.
07:33:16.265 +2.166 s extra data 2 fetched: 285 ms, 250 bytes.
07:33:16.274 +2.175 s Began fetching extra data 3.
07:33:16.465 +2.366 s extra 3 fetched: 191 ms, 893 bytes.
07:33:16.471 +2.372 s Began fetching extra data 4.
07:33:16.865 +2.766 s extra data 4 fetched: 394 ms, 2,775 bytes.
07:33:16.872 +2.773 s Began fetching extra data 5.
07:33:17.165 +3.066 s extra data 5 fetched: 294 ms, 279 bytes.
...
07:33:17.567-17.571 +3.47 s More stuff happened.
07:33:17.571-29.081 11.510 s gap No request-specific application log events. This is likely uninstrumented processing/rendering time.
07:33:29.081-29.087 +14.98 s Some stuff got skipped
07:33:29.087-36.086 6.999 s gap No request-specific application log events before rendering finishes.
07:33:36.086 +21.987 s Application logged "Processing complete."
07:33:36.269 +22.170 s Application completed the request: 21,891.538 ms.
07:33:36.271 +22.172 s ALB recorded 200 / 200; target processing was 22.168 s.
# AI 축약 ...5. Java Flight Recorder 데이터
혹시 JVM 문제 있어요, 예를 들어 GC 일시 정지. 그래서 Java Flight Recorder 파일도 추가했어요. 그리고 AI는 지금 Java도 써요.
결과, 요약/축약:
> There is now a @debug.jfr for the Java Flight recorder. Are there any events from when are large gaps in the logs?
# AI는 생각하고 도구 호출
JFR findings during Sep 14 slow-request windows
Log window Slow request durations JFR execution samples Some-Feature-related samples
------------------- ------------------------------ ---------------------- ------------------------
08:19:38-08:19:45 6.103 s 60 60 / 60
08:44:03-08:44:43 7.097-33.556 s 160 156 / 160
09:00:51-09:01:09 5.211 s and 17.797 s 6 6 / 6
The sampled stacks are dominated by Some-Feature rendering and PNG generation, including:
net.a.library.*
net.a.library.png.SomeOperation.*
net.a.library.png.Png.write
com.sun.imageio.plugins.png.PNGImageWriter.encodePass
java.awt.image.BufferedImage.*
References to other code
For example, in the 08:19 slow request window, the JFR repeatedly sampled:
BufferedImage.getRGB
SomeOperation.packMeIfPossible
Png.write
GraphicStuff.writeToStream
ImageBuilder.writeImageInternal
# ...
GC activity during the 08:44 slow-request burst
There was also substantial G1 old-generation GC activity while four requests took 7–34 seconds:
Start time (UTC) GC event Wall-clock duration Longest stop-the-world pause
----------------- ------------------------------------------ -------------------- -----------------------------
08:44:12.901 G1 Old, triggered by humongous allocation 3.104 s 491 ms
08:44:19.384 G1 Old 2.816 s 293 ms
08:44:26.290 G1 Old 3.498 s 535 ms
09:00:51.875 G1 Old, triggered by humongous allocation 2.210 s 464 ms6. 더 분석했는데, 이제 당신 충분히 알아요.
제가 더 분석했어요. 예는 상위 10개 느린 요청 찾고 느린 요청의 유사한 작업 찾았어요.
AI 때문에 유닉스의 파이프를 생각하지 말고 질문을 생각할 수 있어요.
로그-파일을 분석하면 AI로 해보세요!