Tại sao tôi cần một nhà môi giới để sản xuất ngăn xếp ELK + thông số máy của tôi?

Question

Gần đây tôi đã đứng lên một hộp kiểm tra ELK ngăn xếp Ubuntu để kiểm tra chức năng và đã rất hài lòng với nó. Trường hợp sử dụng của tôi cho sản xuất sẽ liên quan đến việc nhập ít nhất 100GB nhật ký mỗi ngày. Tôi muốn có khả năng mở rộng nhất có thể, vì 100GB/ngày này có thể tăng nhanh khi chúng tôi có nhiều nguồn nhật ký hơn.

Tôi đã đọc một số bài viết về sản xuất ELK, bao gồm cả hình ảnh tưởng tượng Logz.io ELK Deployment. Trong khi tôi có ý tưởng chung về những gì tôi cần làm, tôi không chắc chắn về một số khái niệm cốt lõi, số lượng máy tôi cần cho một lượng lớn dữ liệu và liệu tôi có cần một nhà môi giới như Redis có trong kiến ​​trúc của tôi hay không.

Điểm của nhà môi giới như Redis là gì? Trong trường hợp thử nghiệm của tôi, tôi có nhiều nguồn nhật ký gửi nhật ký qua TCP, syslog và logstash forwarder tới Logstash của tôi trực tiếp trên máy chủ ELK của tôi (cũng có Elasticsearch, Nginx và Kibana được cài đặt cấu hình với SSL).

Để giữ lại một tính sẵn sàng cao, tiểu bang của cụm sản xuất nghệ thuật, những gì máy + thông số kỹ thuật tôi cần ít nhất 100GB dữ liệu mỗi ngày, có khả năng mở rộng quy mô về phía 150GB hoặc hơn trong tương lai? Tôi đang lên kế hoạch sử dụng máy chủ của riêng mình. Từ những gì tôi đã nghiên cứu, điểm khởi đầu nên thích một cái gì đó tương tự (giả sử tôi bao gồm Redis):

• 2/3 máy chủ với một trường hợp Redis + Logstash (indexer) cho mỗi máy chủ. Đối với thông số kỹ thuật, tôi đang nghĩ đến RAM 32 GB, ổ cứng I/O 500 GB, ổ cứng nhanh 500 GB, 8 lõi (i7)
• 3 máy chủ cho Elasticsearch (đây là điều tôi không chắc chắn nhất) - Tôi biết mình cần ít nhất 3 các nút chính và 2 nút dữ liệu, vì vậy 2 máy chủ sẽ có 1 dữ liệu chính/1 dữ liệu - các máy chủ này sẽ có bộ nhớ RAM 64 GB, 20TB, 8 lõi. Nút chính còn lại khác có thể nằm trên một máy spec thấp, vì nó không xử lý dữ liệu.
• 2 máy chủ cho Nginx/Kibana - những máy chủ này phải là máy spec thấp vì chúng chỉ là máy chủ web và giao diện người dùng. Cân bằng tải có cần thiết ở đây không?

EDIT: Lập kế hoạch lưu nhật ký trong 60 ngày.

Answer 1

Đối với Redis, nó hoạt động như một bộ đệm trong trường hợp logstash và/hoặc elasticsearch bị hỏng hoặc chậm. Nếu bạn đang sử dụng logstash đầy đủ hoặc logstash-forwarder như một người gửi hàng, nó sẽ phát hiện khi logstash không có sẵn và ngừng gửi các bản ghi (nhớ nơi nó đã tắt, ít nhất là trong một thời gian).

Vì vậy, trong môi trường logstash/logstash-forwarder thuần túy, tôi thấy ít lý do để sử dụng một nhà môi giới như redis.

Khi nó trở nên quan trọng là dành cho các nguồn không quan tâm đến trạng thái của logstash và không đệm bên cạnh chúng. syslog, snmptrap và những người khác thuộc danh mục này. Kể từ khi nguồn của bạn bao gồm syslog, tôi sẽ đưa lên môi giới trong thiết lập của bạn.

Redis là ứng dụng chuyên sâu RAM và số lượng bộ nhớ mà bạn có sẽ quyết định khoảng thời gian cúp logstash bạn có thể chịu được. Trên một máy chủ 32GB (được chia sẻ với logstash), bao nhiêu bộ nhớ bạn sẽ cung cấp cho redis yo? Kích thước tài liệu trung bình của bạn lớn bao nhiêu? Cần bao nhiêu tài liệu để lấp đầy bộ nhớ? Mất bao lâu để tạo ra nhiều tài liệu đó? Theo kinh nghiệm của tôi, redis thất bại khủng khiếp khi bộ nhớ đầy, nhưng đó chỉ có thể là tôi.

Logstash là quá trình sử dụng nhiều CPU vì tất cả các bộ lọc đều được thực thi.

Đối với kích thước của cụm elasticsearch, @magnus đã chỉ cho bạn một số thông tin có thể hữu ích. Bắt đầu với 64GB máy là rất tốt, và sau đó quy mô theo chiều ngang khi cần thiết.

Bạn nên có hai nút máy khách (không phải dữ liệu) được sử dụng làm điểm truy cập cho chèn (thực hiện gửi yêu cầu đến nút dữ liệu chính xác) và tìm kiếm (xử lý pha 'giảm' với dữ liệu được trả về từ dữ liệu nút). Hai trong số này trong một cấu hình chuyển đổi dự phòng sẽ là một khởi đầu tốt.

Hai máy kibana sẽ cung cấp cho bạn dự phòng. Đặt chúng trong một cấu hình chuyển đổi dự phòng cũng tốt. nginx được sử dụng nhiều hơn với kibana3, tôi tin. Tôi không biết nếu mọi người đang sử dụng nó với kibana4 hoặc đã chuyển sang 'lá chắn'.

Hy vọng điều đó sẽ hữu ích.