Có phải ghi các tệp nhật ký máy chủ vào cơ sở dữ liệu hay không?

Question

Sau khi đọc an article about the subject from O'Reilly, tôi muốn hỏi Stack Overflow cho những suy nghĩ của họ về vấn đề này.

Answer 1

Viết cục bộ vào đĩa, sau đó chèn hàng loạt vào cơ sở dữ liệu theo định kỳ (ví dụ: tại thời gian rollover nhật ký). Làm điều đó trong một quá trình ưu tiên thấp riêng biệt. hiệu quả hơn và mạnh mẽ hơn ...

(Đảm bảo rằng bảng cơ sở dữ liệu đăng nhập của bạn chứa một cột cho "mà máy sự kiện log đến từ" by the way - rất tiện dụng)

Answer 2

Tôi muốn nói không, với một tỷ lệ phần trăm khá lớn các lỗi máy chủ liên quan đến các vấn đề giao tiếp với cơ sở dữ liệu. Nếu cơ sở dữ liệu nằm trên một máy khác, kết nối mạng sẽ là một nguồn lỗi khác không thể ghi lại được.

Nếu tôi đăng nhập lỗi máy chủ vào cơ sở dữ liệu, sẽ rất quan trọng để có một trình ghi nhật ký được ghi cục bộ (vào nhật ký sự kiện hoặc tệp hoặc nội dung nào đó) trong trường hợp cơ sở dữ liệu không thể truy cập được.

Answer 3

Nó có lẽ không phải là một ý tưởng tồi nếu bạn muốn các bản ghi trong cơ sở dữ liệu nhưng tôi sẽ nói không làm theo lời khuyên của bài viết nếu bạn có nhiều mục nhập tệp nhật ký. Vấn đề chính là tôi đã nhìn thấy các hệ thống tập tin có vấn đề theo kịp với các bản ghi đến từ một trang web bận rộn cho phép một mình một cơ sở dữ liệu. Nếu bạn thực sự muốn làm điều này, tôi sẽ xem xét tải các tệp nhật ký vào cơ sở dữ liệu sau khi chúng được ghi vào đĩa đầu tiên.

Answer 4

Hãy suy nghĩ về cơ sở dữ liệu thiết lập đúng cách sử dụng RAM để đọc và ghi? Điều này nhanh hơn rất nhiều so với ghi vào đĩa và sẽ không hiện ra nút nghẽn đĩa IO mà bạn thấy khi phục vụ số lượng lớn khách hàng xảy ra khi các chủ đề bắt đầu khóa xuống do hệ điều hành yêu cầu họ đợi các chủ đề hiện đang sử dụng tất cả IO tay cầm.

Tôi không có bất kỳ điểm chuẩn nào để chứng minh dữ liệu này, mặc dù ứng dụng mới nhất của tôi đang được ghi nhật ký cơ sở dữ liệu. Điều này sẽ có một failsafe như đã đề cập trong một trong những phản ứng này. Nếu không thể tạo kết nối cơ sở dữ liệu, hãy tạo cơ sở dữ liệu cục bộ (h2 có thể?) Và ghi vào đó. Sau đó chúng ta có thể kiểm tra kết nối cơ sở dữ liệu định kỳ để thiết lập lại kết nối, đổ cơ sở dữ liệu cục bộ và đẩy nó vào cơ sở dữ liệu từ xa.

Điều này có thể được thực hiện trong giờ làm việc nếu bạn không có trang web H-A.

Đôi khi trong tương lai, tôi hy vọng phát triển điểm chuẩn để chứng minh quan điểm của mình.

Chúc may mắn!

Answer 5

Đăng nhập vào DB nếu bạn có thể và nó không làm chậm DB của bạn :)

Đó là cách cách nhanh hơn để tìm bất cứ điều gì trong DB sau đó trong tệp nhật ký. Đặc biệt là nếu bạn nghĩ trước những gì bạn sẽ cần. Đăng nhập bạn bảng đăng nhập truy vấn db let của như thế này:

select * from logs 
where log_name = 'wcf' and log_level = 'error' 

sau đó sau khi bạn tìm thấy lỗi, bạn có thể nhìn thấy toàn bộ con đường dẫn đến lỗi này

select * from logs 
where contextId = 'what you get from previous select' order by timestamp 

Làm thế nào bạn sẽ nhận được thông tin này nếu bạn đăng nhập nó trong các tập tin văn bản?

Chỉnh sửa: Vì JonSkeet đề xuất câu trả lời này sẽ tốt hơn nếu tôi tuyên bố rằng nên xem xét việc ghi nhật ký vào db không đồng bộ. Vì vậy, tôi nhà nước nó :) Tôi chỉ không cần nó.Ví dụ như làm thế nào để làm điều đó bạn có thể kiểm tra "Ultra Fast ASP.NET" của Richard Kiessig.

Answer 6

Nếu cơ sở dữ liệu là cơ sở dữ liệu sản xuất, đây là một ý tưởng khủng khiếp. Bạn sẽ có vấn đề với sao lưu, nhân rộng, khôi phục. Giống như lưu trữ nhiều hơn cho bản thân DB, bản sao, nếu có và sao lưu. Thêm thời gian để thiết lập và khôi phục bản sao, nhiều thời gian hơn để xác minh bản sao lưu, nhiều thời gian hơn để phục hồi DB từ bản sao lưu.