Đếm mức log trong file log: cách công cụ phân loại và cách đọc kết quả cho đúng
Công cụ đếm nhanh số dòng thuộc bốn nhóm error, warning, info và debug trong một đoạn log dán vào hoặc một file log tải lên. Kết quả hiển thị số dòng từng nhóm kèm tỷ lệ trên tổng số dòng, giúp bạn ước lượng tình trạng của một khoảng log trước khi mở công cụ phân tích nặng hơn.
Tính năng nổi bật
- Dán thẳng đoạn log vào ô nhập hoặc tải lên file đuôi log và txt
- Đếm số dòng thuộc bốn nhóm error, warning, info và debug
- Hiển thị tổng số dòng có nội dung, bỏ qua dòng trống
- Tính tỷ lệ phần trăm từng nhóm trên tổng số dòng, làm tròn một chữ số thập phân
- Thanh tỷ lệ trực quan cho từng nhóm để so nhanh bằng mắt
- Gộp cả dòng chứa từ fatal vào nhóm lỗi và dòng chứa từ trace vào nhóm debug
- Cảnh báo khi tỷ lệ cảnh báo vượt 10 phần trăm tổng số dòng
- Đọc file bằng trình duyệt, nội dung log không được tải lên máy chủ nào
Khi nào một phép đếm thô lại hữu ích hơn hệ thống phân tích đầy đủ
Không phải lúc nào bạn cũng có sẵn hệ thống thu thập log tập trung, và ngay cả khi có thì việc đưa một file log lẻ vào đó cũng mất công. Rất nhiều tình huống thực tế chỉ cần một câu trả lời thô: khách hàng gửi qua một file log vài nghìn dòng, đồng nghiệp dán một đoạn log trong nhóm chat, hoặc bạn vừa kéo về một đoạn log từ máy chủ và muốn biết có nên đào sâu hay không. Lúc đó điều cần biết chỉ là mật độ lỗi trong đoạn đó cao hay thấp, có tỷ lệ cảnh báo bất thường hay không. Đây chính là việc công cụ này làm trong vài giây, ngay trên trình duyệt, không phải cấu hình gì. Điều cần nhớ là nó đếm theo từ khóa xuất hiện trong dòng chứ không hiểu cấu trúc log, nên hãy coi con số nhận được là ước lượng để định hướng, không phải số liệu để đưa vào báo cáo vận hành.
Lợi ích khi sử dụng
- Biết ngay mật độ lỗi của một đoạn log mà không cần dựng công cụ nào
- Đọc được file log gửi qua từ khách hàng hoặc từ máy chủ không có quyền truy cập trực tiếp
- Dùng được trên máy không cài công cụ dòng lệnh, chỉ cần trình duyệt
- Có con số tỷ lệ để so hai đoạn log trước và sau khi triển khai một thay đổi
- Nội dung log không rời khỏi máy nên dùng được với log chứa dữ liệu nội bộ
Cách phân tích một đoạn log
- 1Dán đoạn log vào ô nhập, hoặc bấm chọn file để tải lên file đuôi log hay txt từ máy.
- 2Cắt bớt phần không liên quan nếu file quá lớn, ví dụ chỉ giữ khoảng thời gian đang cần điều tra.
- 3Bấm nút Phân Tích, công cụ tách theo từng dòng và bỏ qua các dòng trống.
- 4Đọc bốn ô kết quả: số dòng và tỷ lệ của nhóm lỗi, cảnh báo, thông tin và gỡ lỗi.
- 5Đối chiếu con số với hiểu biết về định dạng log của bạn trước khi kết luận, đặc biệt khi tổng bốn nhóm không bằng tổng số dòng.
Công cụ phân loại một dòng log theo quy tắc nào
Đoạn văn bản được cắt theo ký tự xuống dòng, các dòng chỉ chứa khoảng trắng bị loại bỏ, phần còn lại là tổng số dòng. Mỗi dòng được hạ về chữ thường rồi đối chiếu lần lượt với bốn nhóm từ khóa theo đúng thứ tự ưu tiên. Trước hết, dòng chứa error, err hoặc fatal vào nhóm lỗi. Nếu không khớp, dòng chứa warn hoặc warning vào nhóm cảnh báo. Tiếp theo, dòng chứa debug hoặc trace vào nhóm gỡ lỗi. Cuối cùng, dòng chứa info hoặc log vào nhóm thông tin. Thứ tự này quan trọng vì mỗi dòng chỉ được tính đúng một lần: một dòng vừa có chữ debug vừa có chữ error sẽ được tính là lỗi chứ không phải gỡ lỗi. Tỷ lệ phần trăm hiển thị bên dưới mỗi thanh lấy số dòng của nhóm chia cho tổng số dòng, nên nếu file có nhiều dòng không chứa từ khóa nào thì tổng bốn tỷ lệ sẽ nhỏ hơn 100.
Ba kiểu đếm sai thường gặp và cách nhận ra
Vì công cụ khớp chuỗi con chứ không đọc trường mức log, có ba tình huống cho ra con số lệch mà bạn cần biết. Thứ nhất, chuỗi err nằm bên trong nhiều từ khác, điển hình là referrer trong log truy cập của máy chủ web; một file log dạng combined của Nginx hay Apache có thể bị đếm gần như toàn bộ vào nhóm lỗi chỉ vì mỗi dòng đều có trường referrer. Thứ hai, chuỗi log nằm trong login, logout và logger, nên những dòng ghi nhận đăng nhập thành công sẽ rơi vào nhóm thông tin dù bản thân dòng đó không mang mức info. Thứ ba, vết ngăn xếp lỗi trong Java hay Python trải ra hàng chục dòng, trong đó chỉ dòng đầu chứa từ khóa lỗi còn các dòng bắt đầu bằng at hoặc File không khớp nhóm nào; kết quả là một lỗi duy nhất làm phồng tổng số dòng và kéo tỷ lệ lỗi xuống thấp giả tạo. Dấu hiệu nhận biết là tổng bốn nhóm chênh nhiều so với tổng số dòng.
Thang mức log theo các chuẩn phổ biến
Biết thang mức của hệ thống mình đang đọc giúp bạn hiểu đúng con số. Chuẩn syslog theo RFC 5424 chia tám mức từ 0 đến 7: emergency, alert, critical, error, warning, notice, informational, debug. Thư viện logging của Python đánh số theo bậc mười: DEBUG là 10, INFO là 20, WARNING là 30, ERROR là 40, CRITICAL là 50, và bộ lọc hoạt động theo nguyên tắc mức cài đặt bao nhiêu thì mọi thứ từ mức đó trở lên được ghi. Hệ Log4j và Logback trong thế giới Java dùng thang TRACE, DEBUG, INFO, WARN, ERROR, FATAL. Trình chạy Node.js với thư viện pino đánh số ngược lại theo chiều tăng dần độ nghiêm trọng, còn winston theo thang npm với error ở mức 0. Điểm chung là ba nhóm giữa gần như giống nhau ở mọi hệ, nên phép đếm bốn nhóm ở đây áp dụng được rộng; khác biệt nằm ở mức thấp nhất và mức nghiêm trọng nhất, và đó là lý do công cụ gộp fatal vào nhóm lỗi cùng trace vào nhóm gỡ lỗi.
Chuẩn bị đoạn log trước khi đo để con số có ý nghĩa
Con số chỉ nói lên điều gì đó khi đoạn log được cắt có chủ đích. Hãy giới hạn theo một khoảng thời gian rõ ràng, ví dụ mười lăm phút quanh thời điểm sự cố, thay vì dán cả file của một ngày. Loại bỏ trước những dòng nhiễu cố định như kiểm tra sức khỏe dịch vụ, thăm dò của bộ cân bằng tải hay yêu cầu tới tệp tĩnh, vì chúng chiếm phần lớn số dòng và làm loãng mọi tỷ lệ. Nếu hệ thống của bạn ghi log dạng JSON theo dòng thì việc đếm ở đây khá chính xác vì mỗi bản ghi đúng một dòng và trường mức log nằm rõ ràng. Với log nhiều dòng, cân nhắc gộp vết ngăn xếp lại thành một dòng trước khi dán. Cuối cùng, nếu định so sánh trước và sau một lần triển khai, hãy lấy hai đoạn cùng độ dài thời gian và cùng mức lưu lượng, vì tỷ lệ lỗi chỉ so được khi mẫu số tương đương.
Khi nào phải chuyển sang công cụ chuyên dụng
Công cụ này chạy trong trình duyệt và giữ toàn bộ nội dung trong bộ nhớ của tab, nên với file vài chục megabyte trở lên trang sẽ chậm hẳn hoặc treo. Nó cũng không đọc mốc thời gian, không vẽ được diễn biến theo giờ, không gom các dòng lỗi giống nhau lại để đếm theo loại, và không nối được log của nhiều dịch vụ theo một mã truy vết chung. Khi bạn cần những thứ đó thì đã đến lúc dùng hệ thu thập log: bộ ba Elasticsearch, Logstash và Kibana là lựa chọn mã nguồn mở lâu đời; Grafana Loki nhẹ hơn và hợp nếu đã dùng Grafana cho giám sát; các nền tảng dịch vụ như Datadog hay CloudWatch Logs của AWS đỡ công vận hành nhưng tính tiền theo dung lượng nhập. Song song đó, hãy cấu hình xoay vòng file log để đĩa không đầy, đặt thời hạn lưu trữ theo từng tầng nóng và lạnh, và gắn mã truy vết vào mọi bản ghi ngay từ cổng vào.
Câu hỏi thường gặp (FAQ)
Vì sao tổng bốn nhóm không bằng tổng số dòng?
Vì một dòng chỉ được tính khi nó chứa ít nhất một trong các từ khóa của bốn nhóm. Những dòng không chứa từ khóa nào, ví dụ các dòng vết ngăn xếp bắt đầu bằng at, dòng in dữ liệu JSON xuống dòng hay dòng phân cách, vẫn được tính vào tổng nhưng không rơi vào nhóm nào. Chênh lệch càng lớn thì kết quả càng nên đọc dè dặt.
Log truy cập của Nginx bị đếm gần hết vào nhóm lỗi là sao?
Nguyên nhân gần như chắc chắn là trường referrer trong định dạng log combined, vì chuỗi err nằm ngay trong từ đó và công cụ khớp chuỗi con. Với log truy cập máy chủ web, bạn nên lọc theo mã trạng thái bằng công cụ dòng lệnh trước, hoặc phân tích riêng file error log thay vì file access log.
Công cụ có phân biệt được FATAL với ERROR không?
Không, dòng chứa fatal được gộp chung vào nhóm lỗi. Cách chia này hợp lý cho mục tiêu ước lượng nhanh, vì cả hai đều là việc phải xử lý. Nếu bạn cần tách riêng số dòng fatal, hãy dùng lệnh đếm theo mẫu trên máy, ví dụ lọc dòng chứa fatal rồi đếm số dòng kết quả.
File log lớn cỡ nào thì công cụ còn xử lý được?
Toàn bộ nội dung được giữ trong bộ nhớ của tab và hiển thị trong một ô nhập, nên file vài megabyte vẫn mượt, còn từ vài chục megabyte trở lên trang sẽ giật hoặc treo tùy máy. Với file lớn, hãy cắt lấy khoảng thời gian cần thiết trước, ví dụ bằng lệnh lọc theo dấu thời gian, rồi mới dán phần đó vào.
Nội dung log tôi tải lên có bị gửi đi đâu không?
Không. File được đọc bằng bộ đọc file của trình duyệt ngay trên máy bạn, phần đếm cũng chạy bằng JavaScript trong tab, không có bước tải lên máy chủ. Dù vậy, log thường chứa địa chỉ IP, mã phiên hoặc dữ liệu người dùng, nên vẫn nên che những phần nhạy cảm trước khi chia sẻ kết quả cho người khác.
Tỷ lệ lỗi bao nhiêu thì đáng lo?
Không có ngưỡng chung cho mọi hệ thống vì nó phụ thuộc vào việc bạn ghi log dày hay thưa. Điều đáng tin hơn con số tuyệt đối là xu hướng: so cùng một khoảng thời gian giữa hôm nay và hôm qua, hoặc giữa trước và sau khi triển khai. Một mức nhảy đột ngột luôn đáng điều tra kể cả khi tỷ lệ tuyệt đối vẫn nhỏ.
Ở môi trường thật nên bật mức log nào?
Thông lệ là bật từ mức info trở lên cho môi trường thật và mở tới debug cho môi trường phát triển. Bật debug ở môi trường thật vừa làm phồng dung lượng vừa dễ ghi ra dữ liệu nhạy cảm. Nếu cần gỡ lỗi trên môi trường thật, hãy dùng cơ chế hạ mức log tạm thời cho riêng một thành phần thay vì bật cho toàn hệ thống.
Ghi log dạng JSON có lợi gì so với ghi log dạng chữ?
Log dạng JSON mỗi bản ghi một dòng với các trường tách bạch giúp máy đọc được ngay, lọc theo mức log hay theo mã truy vết chỉ là một truy vấn thay vì phải viết biểu thức chính quy. Với công cụ đếm này, log JSON cũng cho kết quả chuẩn hơn vì mỗi bản ghi đúng một dòng và trường mức log nằm rõ ràng.
Vết ngăn xếp trải nhiều dòng làm sai kết quả, xử lý thế nào?
Cách gọn nhất là cấu hình thư viện ghi log gộp vết ngăn xếp vào một trường của bản ghi thay vì in ra nhiều dòng, điều này khả thi khi ghi log dạng JSON. Nếu chỉ có file sẵn, bạn có thể lọc bỏ những dòng bắt đầu bằng khoảng trắng rồi at hoặc bằng từ Caused trước khi dán vào để tổng số dòng phản ánh đúng số sự kiện.
Nên giữ log trong bao lâu?
Thực tế phổ biến là chia tầng: giữ log truy vấn nhanh trong khoảng vài tuần, chuyển sang lưu trữ rẻ hơn cho vài tháng tiếp theo, rồi nén và cất kho cho phần cũ hơn. Yếu tố quyết định là nhu cầu điều tra sự cố và các ràng buộc phải tuân thủ trong ngành của bạn, vì có lĩnh vực yêu cầu giữ chứng cứ nhiều năm.
Có nên ghi mọi yêu cầu vào log không?
Với hệ thống lưu lượng lớn thì không, vì chi phí lưu trữ và nhiễu đều tăng nhanh. Thông lệ là ghi đầy đủ cho lỗi và cho các yêu cầu chậm vượt ngưỡng, còn phần yêu cầu bình thường thì lấy mẫu một tỷ lệ nhỏ. Khi cần theo dấu chi tiết một luồng xử lý, dùng cơ chế truy vết phân tán sẽ hiệu quả hơn là ghi log dày đặc.
Có xuất được kết quả phân tích ra file không?
Phiên bản hiện tại chỉ hiển thị kết quả trên màn hình, chưa có nút tải về hay xuất báo cáo. Bạn có thể chụp lại màn hình hoặc ghi tay bốn con số. Nếu cần theo dõi định kỳ và lưu lịch sử, nên viết một đoạn lệnh đếm chạy trên máy chủ hoặc đưa log vào hệ thống thu thập tập trung.
Từ khóa liên quan
- phân tích log online
- log level analyzer
- đếm số dòng lỗi trong file log
- thống kê error warn info debug
- log level là gì
- mức log error warn info debug
- đọc file log ứng dụng
- phân tích error log
- syslog severity level
- python logging level
- log4j log level
- structured logging json
- công cụ đọc file log miễn phí
- tỷ lệ lỗi ứng dụng
- giám sát lỗi ứng dụng
- elk stack phân tích log
- grafana loki log
- log rotation là gì
- correlation id trong log
- kiểm tra log máy chủ
