Kiến trúc dữ liệu cho số liệu nhật ký sự kiện?


17

Dịch vụ của tôi có số lượng lớn các sự kiện người dùng đang diễn ra và chúng tôi muốn thực hiện những việc như "sự xuất hiện của loại sự kiện T kể từ ngày D. "

Chúng tôi đang cố gắng đưa ra hai quyết định cơ bản:

  1. Lưu trữ gì? Lưu trữ mọi sự kiện so với chỉ lưu trữ tổng hợp

    • (Kiểu nhật ký sự kiện) ghi nhật ký mọi sự kiện và đếm chúng sau, vs.
    • (Kiểu chuỗi thời gian) lưu trữ một "tổng số sự kiện E cho ngày D " tổng hợp cho mỗi ngày
  2. Nơi lưu trữ dữ liệu

    • Trong cơ sở dữ liệu quan hệ (đặc biệt là MySQL)
    • Trong cơ sở dữ liệu không liên quan (NoQuery)
    • Trong tệp nhật ký phẳng (được thu thập tập trung qua mạng qua syslog-ng)

Thực hành tiêu chuẩn là gì / tôi có thể đọc thêm về việc so sánh các loại hệ thống khác nhau ở đâu?


Chi tiết bổ sung:

  • Tổng số luồng sự kiện lớn, có khả năng hàng trăm ngàn mục nhập mỗi ngày
  • Nhưng nhu cầu hiện tại của chúng tôi chỉ là đếm một số loại sự kiện trong đó
  • Chúng tôi không nhất thiết cần truy cập thời gian thực vào dữ liệu thô hoặc kết quả tổng hợp

IMHO, "ghi nhật ký tất cả các sự kiện vào tệp, thu thập dữ liệu sau đó để lọc và tổng hợp luồng" là một cách UNIX khá chuẩn, nhưng đồng bào Rails-y của tôi dường như nghĩ rằng không có gì là thật trừ khi nó có trong MySQL.


1
Bất kỳ may mắn trong dự án này?
hiwaylon

2
@hiwaylon Chúng tôi đã kết thúc bằng cách sử dụng một hệ thống kết hợp: 1) MySQL khi có thể (âm lượng thấp) (giúp tổng hợp dễ dàng sử dụng SELECT...GROUP BY, có thể dễ dàng lưu trữ kết quả của SELECTs), 2) bằng cách sử dụng Graphite để tổng hợp và hiển thị quy mô lớn đơn giản, và 3) ghi nhật ký đầy đủ các sự kiện để tham khảo và để xem chi tiết về luồng dữ liệu trong thời gian thực. Mỗi cái đã thực sự có giá trị theo những cách khác nhau.
elliot42

Nghe có vẻ là một giải pháp tuyệt vời, khá giống với những gì chúng ta đang làm.
hiwaylon

1
CẬP NHẬT hơn một năm sau đó, chúng tôi đã xây dựng một hệ thống ghi lại tất cả mọi thứ và lặp lại định kỳ trên các bản ghi đếm các thứ, và sau đó lưu trữ các số đếm đó vào cơ sở dữ liệu (có thể là một cơ sở dữ liệu theo chuỗi thời gian, nhưng MySQL đã được xử lý). Đây là một vài tuần làm việc nhưng cuối cùng lại trở thành một cách tiếp cận mạnh mẽ / nhanh chóng đáng ngạc nhiên - khi đó chỉ là mã của bạn lặp lại qua JSON đã đăng nhập, thật dễ dàng để thêm nhiều siêu dữ liệu và dễ dàng để mã của bạn có quy tắc linh hoạt cho chính xác những gì nó muốn đếm
elliot42

1
Cập nhật 2016: Kafka có thể thực hiện những việc này trong những ngày này, ít nhất là cho việc lưu trữ thô. Sau đó, bạn có thể gắn chúng vào một công việc MapReduce hoặc Spark lớn hoặc một kho lớn như Vertica, v.v. nếu bạn muốn truy vấn / tổng hợp qua chúng.
elliot42

Câu trả lời:


4

Nó luôn luôn phụ thuộc, tôi sẽ cho bạn lời khuyên của tôi để cung cấp cho bạn một quan điểm mới

Lưu trữ gì? Lưu trữ mọi sự kiện so với chỉ lưu trữ tổng hợp

(Kiểu nhật ký sự kiện) ghi nhật ký mọi sự kiện và đếm chúng sau, vs.

Nếu bạn dự định không bỏ lỡ bất kỳ chi tiết nào, mặc dù bây giờ chúng không liên quan, trong mắt tôi đó là cách tiếp cận tốt nhất, bởi vì đôi khi, khi kết quả đến, thì bạn sẽ tìm thấy một số sự kiện khác mà X hoặc Y không liên quan hoặc họ không mang thêm bất kỳ thông tin nào, nhưng sau khi phân tích, nó chỉ đơn giản là như vậy, và bạn cũng cần theo dõi thông tin đó, sau đó vì nó được ghi nhưng không được tính toán nên bạn sẽ mất một thời gian trước khi bạn có thể thêm nó vào ảnh .

(Kiểu chuỗi thời gian) lưu trữ một "tổng số sự kiện E cho ngày D" tổng hợp cho mỗi ngày

Nếu bạn muốn triển khai và sử dụng nó vào ngày mai, nó có thể hoạt động, nhưng sau đó nếu bạn có một yêu cầu mới hoặc bạn tìm thấy mối tương quan với một sự kiện khác mà bạn đã bỏ qua vì bất kỳ lý do gì, thì bạn cần thêm sự kiện mới này và sau đó chờ một số thời gian dài để có mức độ tổng hợp tốt đẹp

Nơi lưu trữ dữ liệu

Trong cơ sở dữ liệu quan hệ (đặc biệt là MySQL)

Tùy chọn đầu tiên có thể nặng đối với DB nếu bạn đi ghi lại tất cả các sự kiện, vì vậy MySQL tôi sợ có thể trở nên quá nhỏ và nếu bạn muốn tìm giải pháp RDBMS, bạn có thể nghĩ lớn hơn, như PostgreQuery hoặc độc quyền như Oracle hoặc DB2 .

Nhưng đối với tập hợp sẽ là một lựa chọn tốt, tùy thuộc vào tải được tạo, bạn có thể tổng hợp theo mã và chèn các tập hợp đó vào DB.

Trong cơ sở dữ liệu không liên quan (NoQuery)

Nếu bạn tìm giải pháp này, bạn cần xem cách tiếp cận nào bạn muốn theo dõi tốt trên wikipedia có thể giúp bạn, tôi không thể giúp bạn nhiều về chủ đề đó vì đơn giản là tôi không có đủ kinh nghiệm, tôi chủ yếu sử dụng rdbms.

Trong tệp nhật ký phẳng (được thu thập tập trung qua mạng qua syslog-ng)

Cá nhân tôi sẽ không khuyến khích bạn chọn tùy chọn đó, nếu tệp phát triển quá nhiều, sẽ khó phân tích hơn, nhưng tôi vẫn không biết mục đích chính là theo dõi hệ thống hoặc đơn giản là kiểm tra nhật ký tập tin ...

Hy vọng nó giúp!


1
Các tệp nhật ký nên được xoay theo kích thước hoặc chiều dài. Tôi không nghĩ rằng mối quan tâm cuối cùng sẽ là một vấn đề sau đó.
hiwaylon

1

Tôi nghĩ rằng ý tưởng của bạn để phân tích các bản ghi, đếm và lưu trữ kết quả trong một DB là hợp lệ. Không chắc chắn bạn muốn tất cả các bản ghi thô trong DB nào (tôi nghĩ đó là những gì bạn nói đồng bào của bạn đang đề xuất). Bạn đã có nhật ký trong tập tin, đúng không? Bạn chỉ có thể lưu trữ những cái đó. Tôi cho rằng bit đó thực sự phụ thuộc vào (các) trường hợp sử dụng của bạn.

Đồng ý với @ Thorbjørn Ravn Andersen về việc chuyển "câu trả lời bình luận" của bạn cho câu hỏi.


1

Phụ thuộc vào mục đích sử dụng của bạn. Nếu bạn có một biểu đồ hoặc báo cáo tiêu chuẩn hiển thị các giá trị tổng hợp, thì bạn sẽ chỉ muốn lọc các sự kiện khi chúng đến và tổng hợp chúng vào nhóm thích hợp. Nếu bạn cần đi sâu vào các sự kiện cụ thể hoặc nếu bạn nghĩ rằng bạn có thể muốn quay lại và phân tích lại / phân loại lại các sự kiện sau đó, thì bạn nên lưu trữ các sự kiện riêng lẻ.

Nếu bạn có thời gian và không gian, điều tôi thường muốn làm là tổng hợp dữ liệu, nhưng lưu trữ các chi tiết trong tệp (đã nén). Các chi tiết không cần phải dễ dàng truy cập, vì tôi gần như không bao giờ cần đến chúng, nhưng chúng có sẵn để xử lý lại hàng loạt nếu tiêu chí phân loại thay đổi.


"Tổng hợp dữ liệu, nhưng lưu trữ các chi tiết trong một tệp (đã nén)". Suy nghĩ tuyệt vời nói riêng, cảm ơn!
elliot42

Có mối quan tâm nào với khối lượng đăng nhập OP được đề cập và thực hiện lọc + tổng hợp khi chúng vào không? Có vẻ như nó có thể là một nút cổ chai nguy hiểm nếu khối lượng nhật ký cao và / hoặc tổng hợp là không tầm thường.
hiwaylon

OP đã đề cập đến khối lượng "hàng trăm ngàn sự kiện mỗi ngày". Một triệu sự kiện mỗi ngày ít hơn bảy trăm một phút, hoặc khoảng mười một giây. Trừ khi đầu vào là một số XML dài, máy chủ trung bình của bạn sẽ có thể xử lý việc đó mà không bị đổ mồ hôi. Tuy nhiên, đây chắc chắn là điều cần được xem xét khi thiết kế (và triển khai) giải pháp.
TMN

1

Bất kỳ kiến ​​trúc decisión nên được thúc đẩy bởi nhu cầu kinh doanh. Trong trường hợp của bạn, bạn nên có ý tưởng rõ ràng hơn về thông tin nào bạn muốn nhận được từ hệ thống nhật ký của mình và để quyết định cách lưu trữ, tần suất bạn sẽ yêu cầu thông tin này và thời gian bạn có thể chờ để nhận kết quả . Đây là những gì thúc đẩy thiết kế của người thu thập nhật ký, bộ tương quan sự kiện và các ứng dụng tương tự.

Thay vì đưa ra ý kiến ​​của tôi, tôi khuyên bạn nên xem xét một số ứng dụng tương tự như những gì bạn cố gắng phát triển. Một số trong số chúng có thể mạnh hơn những gì bạn giả vờ phát triển nhưng sẽ không đau nếu bạn nhìn vào các chính sách kiến ​​trúc và lưu trữ theo sau. Về mặt chuyên môn, bạn có các ứng dụng SIEM như RSA và Arcsight và ở phía Nguồn mở, bạn có các sáng kiến ​​như Kiwi hoặc OSSIM (cũng có phiên bản dựa trên thiết bị chuyên nghiệp).

Một điều khác cần xem xét là khi bạn bắt đầu sử dụng các kết quả mà công cụ thu được, bạn sẽ bắt đầu nhận được rất nhiều yêu cầu từ quản lý của bạn để biết thêm thông tin và chi tiết hơn. Vì vậy, ... sử dụng nó một cách cẩn thận và lập kế hoạch với tầm nhìn của bạn ở đường chân trời. Nó có thể cung cấp cho bạn nhiều công việc hơn, nhưng chắc chắn bạn có thể nhận được rất nhiều hỗ trợ và khả năng hiển thị (áp lực đi kèm trong gói) ....

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.