GHI LOG LÀ GÌ

Photo by Arian Darvishi on UnsplashLog là gì?

Log hiểu 1 cách đơn giản là mọi thứ dùng để lưu vết những thông tin được thông báo trong quá trình buổi giao lưu của một ứng dụng.

Bạn đang xem: Ghi log là gì

Log là một phần rất cần thiết trong vượt trình phát triển 1 ứng dụng. Mặc dù nhiên, ko phải tất cả lập trình viên đều tráng lệ về vấn đề này còn chỉ những chúng ta phải tốn mặt hàng giờ đồng hồ đeo tay để debug thì mới thật sự ngấm thía với lời nói này.

Tại sao phải viết Log?

Mình cho chúng ta 1 vài trường hợp thực tiễn mà mình đã có lần gặp:

Câu chuyện 1: Vào 1 ngày giông bão, bản thân bị báo lỗi là ứng dụng kiểm tra in check out sản phẩm thường giỏi bị crash. Thời gian này, QA đã nhảy vào test với không hề ít trường vừa lòng online và cả offline dẫu vậy vẫn không làm sao crash app được. Tiếp theo, gửi tiếp cho Dev code phần này và Dev đã lao vào Debug để mong tìm được vấn đề nhưng mà vẫn không kiếm ra vấn đề. Thời gian này, áp lực của team ngày càng tăng vì con số báo lỗi crash app cũng tăng theo nhưng sự việc thì vẫn không tìm kiếm ra.

Tiếp theo, tôi đã mở log vận dụng lên xem cùng ôi chẳng có tin tức gì Y_Y. Rồi mình đã phải yêu thương cầu bổ sung cập nhật log vào toàn bộ ứng dụng, thông tin lỗi ngay nhanh chóng lên Slack và đấy là lúc bản thân phát chỉ ra vấn đề.

Do ứng dụng cung cấp làm việc offline nên những lúc có mạng lại sẽ đẩy dữ liệu đến Server mà lại vô tình tất cả dữ liệu kiểm tra in đã up load rồi đề xuất Server trả về lỗi 400. Tuy nhiên, ứng dụng check in kiểm tra out lại không xử lí riêng đến trường thích hợp này yêu cầu thành ra áp dụng cứ gọi đến Server tiếp tục rồi thành vòng lặp mãi mãi và còn tăng theo con số đơn hàng.

Qua mẩu truyện này các bạn có thể thấy rằng bao gồm log tệp tin đã là 1 trong những chuyện nhưng mà mình log chiếc gì là 1 chuyện khác nếu như khách hàng log không có tâm thì bạn chính là người đề xuất chịu khổ trong tương lai và trả toàn hoàn toàn có thể rơi vào trường thích hợp trên: QA, Dev code phần này, Debug cùng tốn rất nhiều thời gian nhưng trọn vẹn không tìm kiếm được vấn đề.


*

Câu chuyện 2: Trong thời gian QA đang kiểm tra 1 task lớn tương quan nhiều service và tất cả multi-tenant thì phát hiện lỗi với báo mang lại Dev A. Dev A chú ý báo lỗi “Wrong Tenant. Please tương tác to Administrator.” xong thì kiểm tra thông tin tenant vẫn truyền đúng chưa và nói về Dev B liên quan tới làm phần tenant. Dev B nhìn xem thì nói truyền không đúng tenant phải báo lỗi vậy đúng rồi. Thay là hành trình tranh cãi và minh chứng truyền đúng dữ liệu của Dev A. Sau 1 hồi cự cãi thì Dev B đã kiểm soát bằng vấn đề debug thì phát hiển thị rằng config Database bị không nên password đề nghị không liên kết được.

Đọc tới đây mình suy nghĩ nhiều bạn sẽ phải bất ngờ giống bản thân sao lỗi Database mà lại đi báo “Wrong Tenant”. Đây chính là vấn đề.

Xem thêm: Cách Chơi Diana - Bảng Ngọc Diana Mùa 12 Và Cách Lên Đồ Mạnh Nhất

Bạn hoàn toàn có thể trả lỗi phổ biến về mang đến User “Wrong Tenant. Please tương tác to Administrator.” mà lại trong log các bạn phải giữ lại dấu dấu để biết vấn đề lỗi thật sự.

Chứ như trường hòa hợp này toàn bộ trường phù hợp lỗi rất nhiều cùng 1 câu với khi có lỗi xẩy ra chính các bạn Dev B cũng không khẳng định được lỗi chính xác trong log và phải debug vừa gây tốn thời gian cho Dev B lẫn Dev A.


*

Câu chuyện từ hào ^_^: Chuyện xảy ra vào 1 ngày đẹp trời cùng mình đã nhận được 1 yêu ước production support là data gửi tới Server sai như quý khách mong đợi. Như một thói quen việc trước tiên mình có tác dụng là soát sổ Log.

Đầu tiên là API Log và mình thấy request/response mọi đúng nhưng vị sao data lưu trên hệ thống lại rất khác trong API log. Tiếp theo, tôi đã vào coi system log với đây tôi đã phát hiển thị vấn đề. Tức thì tại thời điểm quý khách thực hiện 1 yêu cầu update data thì có 1 Schedule chạy ngầm đã vô tình khiến lỗi update cùng data với khách hàng đó.

Và các bạn biết bản thân tốn bao lâu để xác minh lỗi này không?

Chỉ là 30 phút, và trong ngữ cảnh mình không còn biết có schedule chạy ngầm này vì dự án lớn và có khá nhiều người tham gia. 1 Điểm đặc biệt quan trọng nhất giúp mình có thể phát chỉ ra lỗi này trong thời gian ngắn vậy là người các bạn vô tình tạo thành lỗi này đã làm tốt nhất 1 việc là ghi log lại từng bước một của schedule chạy ngầm này nhờ vào những mẫu log đó mình đã xác định được tại sao lỗi.

Do đó, khi vận dụng có đông đảo dòng log giỏi sẽ là 1 trong sự cung cấp lớn cho tất cả những người chịu trách nhiệm gia hạn ứng dụng có thể hiểu và nắm bắt được ứng dụng tương tự như code hoạt động như cố gắng nào (Đặc biệt là trong số trường hợp nhiều luồng như trên)


*

Lời kết:

Đối với bản thân log là 1 tài năng rất đặc biệt đối với lập trình viên. Đặc biệt là sinh hoạt Senior Level. Khi bạn ở Senior cấp độ thì không chỉ là code nhằm chạy thôi mà chúng ta còn đề xuất nghĩ cho tới trước, trong cùng sau quá trình phát triển.

Log xuất sắc thể hiện nay được năng lực nhìn xa trông rộng của người tiêu dùng biết bỏ thời gian ra viết log nhằm tiết kiệm thời gian debug sau này. Bên cạnh ra, log tốt còn làm người chịu trách nhiệm duy trì đọc gọi code và phát hiện phần đa lỗi chỉ xảy ra khi chạy trên môi trường thiên nhiên thực tế.

Nếu bạn đã lưu ý đến log thì không thể làm lơ các chia sẻ về “Phân loại log và những vấn đề cần biết”. Đón xem nội dung bài viết tiếp theo của chính bản thân mình nhé!