Chúng tôi đã bắt đầu sử dụng nền tảng của bên thứ ba (GigaSpaces) giúp chúng tôi với tính toán phân tán. Một trong những vấn đề chính mà chúng tôi đang cố gắng giải quyết hiện nay là cách quản lý các tệp nhật ký của chúng tôi trong môi trường phân tán này. Hiện tại chúng tôi có thiết lập sau.Quản lý một số lượng lớn tệp nhật ký được phân phối trên nhiều máy
Nền tảng của chúng tôi được phân phối trên 8 máy. Trên mỗi máy chúng ta có 12-15 quy trình đăng nhập để tách các tệp nhật ký bằng cách sử dụng java.util.logging. Trên nền tảng này, chúng tôi có các ứng dụng riêng của chúng tôi sử dụng log4j và đăng nhập vào các tệp riêng biệt. Chúng tôi cũng chuyển hướng stdout sang một tệp riêng biệt để nắm bắt các chuỗi chủ đề và tương tự.
Điều này dẫn đến khoảng 200 tệp nhật ký khác nhau.
Hiện tại, chúng tôi không có công cụ hỗ trợ trong việc quản lý các tệp này. Trong những trường hợp sau, điều này khiến chúng ta đau đầu nghiêm trọng.
Khắc phục sự cố khi chúng tôi không biết trước về quá trình xảy ra sự cố. Trong trường hợp này, chúng tôi hiện đang đăng nhập vào mỗi máy bằng ssh và bắt đầu sử dụng
grep.Cố gắng chủ động bằng cách thường xuyên kiểm tra nhật ký để tìm bất kỳ thứ gì không bình thường. Trong trường hợp này, chúng tôi cũng hiện đang đăng nhập vào tất cả các máy và xem các nhật ký khác nhau bằng cách sử dụng
lessvàtail.Thiết lập cảnh báo. Chúng tôi đang tìm cách thiết lập cảnh báo về các sự kiện trên ngưỡng. Đây là một nỗi đau với 200 tệp nhật ký để kiểm tra.
Hôm nay chúng tôi chỉ có khoảng 5 sự kiện nhật ký mỗi giây, nhưng điều đó sẽ tăng lên khi chúng tôi di chuyển ngày càng nhiều mã sang nền tảng mới.
Tôi muốn hỏi cộng đồng các câu hỏi sau đây.
- Bạn xử lý các trường hợp tương tự như thế nào với nhiều tệp nhật ký được phân phối trên một số máy được đăng nhập qua các khung công tác khác nhau?
- Tại sao bạn chọn giải pháp cụ thể đó?
- Giải pháp của bạn hoạt động như thế nào? Bạn đã tìm thấy điều gì tốt và bạn thấy điều gì xấu?
Rất cám ơn.
Cập nhật
Chúng tôi đã kết thúc đánh giá một phiên bản dùng thử của Splunk. Chúng tôi rất hài lòng với cách thức hoạt động và đã quyết định mua nó. Dễ dàng thiết lập, tìm kiếm nhanh và nhiều tính năng cho kỹ thuật nghiêng. Tôi có thể đề nghị bất cứ ai trong tình huống tương tự để kiểm tra xem nó ra.
Điều đáng nói là chuyển hướng mọi thứ tới Scribe về cơ bản sẽ tạo ra điểm duy nhất của sự thất bại trong hệ thống, ví dụ khi daemon Scribe bị hỏng. –
Vâng, khía cạnh chịu lỗi của giải pháp cuối cùng thường rất triển khai cụ thể và như vậy, còn lại như một bài tập cho kiến trúc sư chịu trách nhiệm về giải pháp cuối cùng. Tuy nhiên, đó là điều cần lưu ý. –
Tôi muốn nói thêm rằng nó không phải là "điểm thất bại" thực theo nghĩa là nếu nút trung tâm Scribe bị hỏng, toàn bộ giải pháp không bị ảnh hưởng - các nút Scribe riêng lẻ chỉ xếp hàng bản ghi nhật ký cục bộ cho đến khi nút trung tâm trở lại lên một lần nữa. Thời gian ngừng hoạt động của người ghi chép chỉ ảnh hưởng đến tính khả dụng của hệ thống con đăng nhập. –