Tôi chưa bao giờ viết chương trình sử dụng đăng nhập đáng kể. Việc tôi đã làm nhiều nhất là ghi lại dấu vết ngăn xếp khi có ngoại lệ xảy ra.
Tôi đã tự hỏi, những người khác đăng nhập bao nhiêu? Có phụ thuộc vào loại ứng dụng bạn đang viết? Bạn có thấy các bản ghi thực sự hữu ích?
Câu trả lời:
Đối với công việc tôi đã thực hiện phần lớn các ứng dụng nhúng, đăng nhập vào một công cụ vô giá. Ở mức tối thiểu các lỗi cần phải được ghi lại với đủ thông tin để trỏ đến dòng mã. Tiếp theo, sẽ là các điểm chức năng chính trên ứng dụng. Những thứ như quản trị viên truy cập vào máy. Chúng tôi sử dụng một hệ thống cho phép chúng tôi kích hoạt ghi nhật ký dài hơn. Đây thường là nhà phát triển cụ thể. Nó có thể được sử dụng để hỗ trợ nhà phát triển trong quá trình thử nghiệm tính năng hoặc có thể hỗ trợ chẩn đoán sự cố của khách hàng.
Cá nhân tôi đã sử dụng đăng nhập trong tất cả các ứng dụng tôi đã phát triển. Nó luôn luôn dẫn đến một sự hiểu biết tốt hơn về dòng chảy của một ứng dụng. Đặc biệt là khi có trong tay một khách hàng. Họ không bao giờ (hiếm khi) giới hạn các trường hợp sử dụng của họ cho những người bạn kiểm tra.
Tôi không nghĩ nó phụ thuộc vào loại ứng dụng: ghi nhật ký là hữu ích trong tất cả các ứng dụng (không tầm thường). Chắc chắn, tôi đoán, nó có thể hữu ích hơn trong một số ứng dụng so với các ứng dụng khác, nhưng tôi không nghĩ nó vô dụng .
Đặc biệt, trong trường hợp có lỗi, theo dõi ngăn xếp sẽ cho bạn biết trạng thái của chương trình tại điểm chính xác của sự cố, nhưng bạn đã có rất ít manh mối về trạng thái ngay trước lỗi. Thông tin đó có thể rất hữu ích trong việc theo dõi vấn đề và đăng nhập có thể cung cấp một cái nhìn sâu sắc hữu ích về vấn đề đó. Tôi nghĩ đó là thứ mà tất cả những chương trình tầm thường nhất có thể được hưởng lợi.
Một cách sử dụng khác của ghi nhật ký, có thể không hữu ích cho tất cả các chương trình, là trong phân tích thống kê. Ví dụ: máy chủ web của bạn thường ghi nhật ký mọi yêu cầu xuất hiện, và sau đó có nhiều công cụ có thể phân tích các nhật ký đó và tạo ra các biểu đồ về thời điểm bận rộn nhất của bạn, các trang phổ biến nhất, v.v. Bạn có thể sử dụng dữ liệu đó để lập kế hoạch dung lượng ("tôi có cần máy chủ lớn hơn không?"), V.v.
Có hai lý do đăng nhập được thực hiện:
Ghi nhật ký chẩn đoán đã được thảo luận bởi những người khác và tôi sẽ không tin vào quan điểm nhiều hơn nữa. Tôi sẽ chỉ nói rằng bạn nên suy nghĩ mạnh mẽ về những gì sẽ xảy ra nếu có lỗi đăng nhập? Bạn có đủ quan tâm để đưa ra một ngoại lệ thông qua ứng dụng hoặc quản lý nó theo cách khác không? Đây là một "nó phụ thuộc" nhưng có thể bỏ qua các thông báo mức thông tin.
Kiểm toán đăng nhập là một yêu cầu kinh doanh. Ghi nhật ký kiểm toán ghi lại các sự kiện quan trọng trong hệ thống và là điều mà quản lý và đại bàng pháp lý quan tâm. Đây là những việc như ai đã ký vào một cái gì đó, ai đã chỉnh sửa, v.v. Là một sysadmin hoặc nhà phát triển khắc phục sự cố hệ thống, có lẽ bạn chỉ quan tâm nhẹ đến những điều này. Tuy nhiên, trong nhiều trường hợp, loại đăng nhập này hoàn toàn là một phần của giao dịch và sẽ thất bại toàn bộ giao dịch nếu không thể hoàn thành.
Suy nghĩ về hai cái riêng biệt có ích cho tôi không chỉ bởi vì một cái là "tùy chọn" và cái bắt buộc khác, mà bởi vì tùy thuộc vào yêu cầu, tôi thực sự có thể cần phải thực hiện chúng một cách riêng biệt. Có thể là một trường hợp (đôi khi) cả hai đều là trái cây, nhưng một là táo và các cam khác. Thông thường, một khung đăng nhập duy nhất có thể xử lý cả hai mặc dù.
Trong hầu hết các tác vụ máy chủ, việc ghi nhật ký là rất quan trọng, vì quản trị viên thường không có mặt khi có sự cố xảy ra, do đó anh ta phải kiểm tra thực tế.
Nhưng, một anh chàng ở Google đã nói với tôi rằng máy chủ của họ không đăng nhập; thay vào đó, chúng là 'công cụ'; điều đó có nghĩa là mọi quy trình đều có móc hoặc cổng (anh ta không chỉ định cơ học) trong đó các quy trình khác có thể chốt để yêu cầu tham số và thống kê. Đó là những quy trình giám sát lưu trữ nhiều thứ vào nhật ký, lợi thế là thông tin họ nhận được không phải là "mở tệp", "viết cái này", "lấy nó"; họ nhận được những thứ như "45,453 tệp đang mở", "653 khách hàng của dịch vụ X", "phản hồi trung bình 344ms cho truy vấn Y"
Chắc chắn là một cách tiếp cận khác, và một cách mà tôi có xu hướng ghi nhớ khi tôi trông trẻ các hệ thống của mình, ngay cả khi chúng có một số đơn đặt hàng nhỏ hơn.
Tôi đến từ một ứng dụng winforms N-Tiered ghi lại mọi thứ.
Nó không hữu ích lắm.
Chắc chắn, ngoại lệ đăng nhập là tuyệt vời; nhưng tại sao lại đăng nhập chúng vào máy của khách hàng khi bạn chỉ có thể gửi email ngoại lệ cho nhóm nhà phát triển?
Ghi nhật ký thông tin dễ dàng biến thành nghiện mà giá trị của nó hiếm khi được chứng minh. Đối với mọi tình huống mà bạn có thể đăng nhập một cách miễn phí, tốt hơn là thu thập thông tin được nhắm mục tiêu và gửi nó đến nơi bạn cần đến.
Nắm bắt thông tin ngoại lệ là phải bởi vì nó có thể rất hữu ích ở một mức độ nào đó. Nhưng đôi khi thông tin ngoại lệ là không đủ, đặc biệt nếu người dùng / khách hàng ứng dụng không thể báo cáo lỗi với thông tin phù hợp.
Là đăng nhập chỉ giới hạn để nắm bắt thông tin lỗi?
Trong trường hợp của tôi (ứng dụng web), tôi luôn ghi nhật ký trang nào được truy cập, khi nào, nhấp vào trang nào, ip & trình duyệt, v.v. Tôi thậm chí còn ghi tổng thời gian tải cho mỗi lần truy cập trang để tôi có thể biết trang nào chậm và cần tối ưu hóa. vì vậy tôi có thể nói rằng tôi đăng nhập càng nhiều càng tốt.
Lúc đầu, tôi không biết nó sẽ quan trọng như thế nào. nhưng rõ ràng nó rất hữu ích trong nhiều thứ (ngoài việc gỡ lỗi):
Tôi nghĩ rằng, đăng nhập có thể trở nên quan trọng hơn nếu chúng ta thích khai thác thông tin thống kê trong đó.
Tôi là một nhà phát triển trong một công ty có sản phẩm được triển khai ở nước ngoài. Khi một nhóm hỗ trợ đến hỏi về định nghĩa vấn đề, công cụ chẩn đoán duy nhất của tôi là tệp nhật ký của tôi và bản sao cơ sở dữ liệu của khách hàng. Sử dụng cơ sở dữ liệu và môi trường phát triển của tôi, tôi có cơ hội tái tạo trường hợp sai sót, bởi vì tôi đăng nhập dữ liệu đến mô-đun của mình và các hành động liên quan. Nếu tôi có thể tái tạo lỗi với sự trợ giúp của dữ liệu tôi thu thập, thì tôi có thể sửa lỗi bằng cách gỡ lỗi. Nếu tôi không có tệp nhật ký, thì tôi sẽ phải phụ thuộc vào mô tả của khách hàng hoặc nhóm hỗ trợ về những gì xảy ra trong trường hợp nào (có khả năng gây hiểu nhầm lớn).
Thứ hai, việc ghi nhật ký cho tôi cơ hội phát hiện các nút thắt của mô-đun của tôi tại trang web được triển khai, vì tôi ghi nhật ký ngày & giờ của một số hành động nhất định và sau đó tôi có thể xem hành động nào tiêu tốn bao nhiêu thời gian.
Ngoài ra, giả sử giải pháp của chúng tôi bao gồm 6 mô-đun và tôi đang thấy các bản ghi lỗi trong các tệp nhật ký của mình về thời gian chờ cơ sở dữ liệu. Nếu các lỗi này cũng được ghi vào 5 trong số các mô-đun khác, thì xác suất đây là sự cố liên quan đến máy chủ SQL sẽ lớn hơn. Nếu điều này chỉ được ghi lại trong mô-đun của tôi, thì xác suất các truy vấn của tôi bị lỗi sẽ lớn hơn. Tôi nghĩ rằng những loại điều này là chỉ số hữu ích.
Về loại dữ liệu tôi thấy trong các tệp nhật ký của mình phụ thuộc vào cấu hình của cấp độ nhật ký. Nếu đây là sản phẩm mới, chúng tôi sẽ đặt mức nhật ký thành "Tất cả" để thu thập càng nhiều dữ liệu càng tốt. Nhưng khi chúng tôi cải thiện sản phẩm, chúng tôi có thể muốn giữ mức nhật ký ở mức "Lỗi" để chỉ ghi nhật ký lỗi chứ không phải nhật ký cấp thông tin, v.v ...
Ghi nhật ký rất hữu ích cho các thông tin mà bạn không thể có được bằng các chương trình khác:
Lưu ý: Bạn muốn ít nhất HAI tệp nhật ký.
Một INFO luôn luôn bật. Một DEBUG là khi cần thiết.
Viết mã đăng nhập dự đoán rằng một ngày nào đó bạn có thể phải gỡ lỗi một tình huống trong đó TẤT CẢ bạn có là tệp nhật ký và thực hiện đúng có thể là sự khác biệt giữa việc bị sa thải và được thăng chức.
Đối với dặm bổ sung, có tất cả các lệnh gọi hàm thêm tham số của chúng vào bất kỳ dấu vết ngăn xếp nào, trong Java với
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
Cách tiếp cận này về cơ bản nâng cao ngăn xếp cuộc gọi của bạn với các giá trị tham số và có thể cho phép bạn phân tích tình huống chỉ với theo dõi ngăn xếp và không phải xem các tệp nhật ký.
Tôi cũng sẽ đề nghị rằng tất cả các ứng dụng không tầm thường sử dụng ghi nhật ký đa cấp.
Vì những lý do khác mà người khác đã nêu, đây là một công cụ vô giá để giải quyết các vấn đề với ứng dụng.
Trong một số trường hợp, ghi nhật ký là điều cần thiết, ví dụ trong các ứng dụng tài chính và các lĩnh vực khác yêu cầu nhật ký hoạt động, để bảo mật, số liệu sử dụng và kiểm toán.
Nó chắc chắn phụ thuộc vào loại hệ thống bạn đang xây dựng.
Nếu bạn đang viết một ứng dụng máy tính để bàn độc lập, chẳng hạn như trình xử lý văn bản, thì có lẽ bạn không cần đăng nhập.
Nếu bạn đang viết một hệ thống nhúng, thì bạn không thể sống mà không đăng nhập. Mặt khác, khi thiết bị nhúng của bạn đóng băng, bạn không biết tại sao. Bạn cũng cần đăng nhập bất cứ khi nào hệ thống của bạn liên quan đến nhiều quy trình hoặc nhiều máy vật lý giao tiếp với nhau. Một lần nữa, khi hệ thống bị treo, bạn cần biết phần nào của nó chết khi nào và tại sao. Bạn cần có khả năng so sánh các bản ghi để xác định liệu dữ liệu được tạo từ dữ liệu này sang quy trình khác hay không. Với cùng một mã thông báo, bạn cần đăng nhập bất cứ khi nào hệ thống của bạn có nghĩa là chạy trong thời gian dài mà không có nhiều tương tác trực tiếp với người dùng.
Ghi nhật ký luôn hữu ích. Nhưng khi thực hiện hãy lưu ý rằng không nhất thiết là bạn, người sẽ đọc nhật ký. Có lẽ đó là một loại quản trị viên, người dùng cuối, khách hàng, nhóm hỗ trợ, ...
Vì vậy, không chỉ đăng nhập stacktraces, mà còn một số thông tin bổ sung có thể được giải thích bởi những người không phải là nhà phát triển. Khi ứng dụng của bạn được duy trì bởi một số nhóm khác, việc viết một số mã lỗi duy nhất vào nhật ký của bạn cũng rất hữu ích. Điều này có thể dễ dàng hỗ trợ, tự động hóa, ...
Một điểm khác từ góc độ quản trị viên: Hãy suy nghĩ về luân chuyển nhật ký.