Logstash mở rộng (với redis / elaticsearch)

Trong một cụm gồm hơn 12 centos 5,8 máy chủ, tôi đã triển khai logstash bằng cách sử dụng trình gửi logstash gốc, gửi /var/log/*/*.loglại cho một máy chủ logstash trung tâm.

Chúng tôi đã thử sử dụng rsyslogd với tư cách là người giao hàng, nhưng do lỗi trong mô-đun ImFile của rsyslogd, nếu đầu từ xa không trả lời, nhật ký sẽ chồng chất trong bộ nhớ.

Chúng tôi hiện đang sử dụng Redis làm cơ chế vận chuyển, vì vậy logstash01 đã chạy lại cục bộ, ràng buộc với IP cho Vlan cho các nhật ký này.

Vì vậy, logstash-shipper gửi tới redis trên logstash01. logstash01 gửi đến Elaticsearch đang chạy trong một quy trình riêng.

Đây là những gì chúng ta đang thấy. Elaticsearch có 141 chủ đề bị chặn. Stracing cha mẹ elaticsearch cho thấy:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Đây là jstack từ elaticsearch

Đây là jstack từ logstash

Vì vậy, đêm qua, một số máy chủ web (có nhật ký được xử lý bằng logstash) đã hoạt động, với tải trung bình trên 500.

Trên logstash01, có cái này

Dec 19 00:44:45 logstash01 kernel: [736965.925863] Killed process 23429 (redis-server) total-vm:5493112kB, anon-rss:4248840kB, file-rss:108kB

Vì vậy, kẻ giết người OOM đã giết chết máy chủ redis, điều đó có nghĩa là các bản ghi được chất đống trong bộ nhớ trên các máy chủ đang vận chuyển .. Điều đó có nghĩa là apache bị mắc kẹt trong vòng xoắn. (Thành thật mà nói, tôi không chắc bằng cách nào, tôi chỉ cho rằng nó đang theo dõi nhật ký) ..

Đây là lý thuyết của tôi về cách các sự kiện diễn ra:

1. Chúng tôi đã có một lưu lượng truy cập tăng đột biến.
2. Một lượng lớn các bản ghi đã được tạo ra.
3. Những thứ này chất đống trong Redis, vì logstash / elSTERearch dường như chỉ có thể xử lý 300-400 sự kiện mới / giây.
4. Redis đã lấp đầy hoàn toàn đến mức giết chết OOM một cách vô nghĩa.
5. Redis ngừng chấp nhận các mặt hàng mới.
6. Các mục bây giờ bắt đầu chồng chất lên phía máy chủ từ xa.
7. Tất cả mọi thứ đi hạt . Apache ngừng chấp nhận yêu cầu. (Tại sao?).

Câu hỏi là:

8. Tại sao apache trở nên tồi tệ nếu chỉ có một cái gì đó theo đuôi nhật ký của nó. Có phải đó là điều mà nó ngăn chặn apache viết?

9. Có cách nào lành mạnh để làm cho elaticsearch nhanh hơn / tốt hơn / kiên cường hơn không?

10. Có cách nào lành mạnh để làm cho redis trở nên kiên cường và không chết vì bị OOM'd

11. Có một lỗ hổng cơ bản trong cách tôi thiết lập tất cả, hoặc mọi người có vấn đề này không?

-- BIÊN TẬP --

Một số thông số kỹ thuật cho @lusis.

admin@log01:/etc/init$ free -m
             total       used       free     shared    buffers     cached
Mem:          7986       6041       1944          0        743       1157
-/+ buffers/cache:       4140       3845
Swap:         3813       3628        185

Filesystem             Size  Used Avail Use% Mounted on
/dev/sda2               19G  5.3G   13G  31% /
udev                   3.9G  4.0K  3.9G   1% /dev
tmpfs                  1.6G  240K  1.6G   1% /run
none                   5.0M     0  5.0M   0% /run/lock
none                   3.9G     0  3.9G   0% /run/shm
/dev/sda1               90M   72M   14M  85% /boot
/dev/mapper/data-disk  471G  1.2G  469G   1% /data

/dev/sda2 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
/dev/mapper/data-disk on /data type ext3 (rw)
/data/elasticsearch on /var/lib/elasticsearch type none (rw,bind)

log01:/etc/init$ top 
top - 14:12:20 up 18 days, 21:59,  2 users,  load average: 0.20, 0.35, 0.40
Tasks: 103 total,   1 running, 102 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.0%us,  1.0%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu1  : 12.0%us,  1.0%sy,  0.0%ni, 86.6%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu2  :  4.7%us,  0.3%sy,  0.0%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  5.6%us,  1.3%sy,  0.0%ni, 93.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  5.3%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  6.4%us,  1.0%sy,  0.0%ni, 92.3%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   8178120k total,  6159036k used,  2019084k free,   761780k buffers

Bài đăng của bạn không mô tả nhiều về cách thông số kỹ thuật (bộ nhớ trên bộ chỉ mục LS, khối lượng nhật ký hoặc nhiều thứ khác) nhưng tôi sẽ thử và trả lời câu hỏi của bạn tốt nhất trước tiên tôi có thể. Tuyên bố miễn trừ trách nhiệm: Tôi là một trong những nhà phát triển logstash -

1. Các hạt dẻ của Apache có khả năng là tác dụng phụ của quá trình logstash. Bây giờ tôi sẽ gạt chuyện đó sang một bên.

2. Cách lành mạnh để tạo ES f / b / s là thêm nhiều nút ES. Thật là dễ dàng. Họ thậm chí tự động phát hiện lẫn nhau tùy thuộc vào cấu trúc liên kết mạng. Sau 17 năm trong ngành này, tôi chưa bao giờ thấy bất cứ thứ gì có quy mô theo chiều ngang dễ dàng như ElasticSearch.

3. Để f / b / s Redis, không sử dụng bất kỳ cụm redis nào. Các phiên bản mới hơn của Logstash có thể thực hiện Redis cân bằng nội bộ. Đầu ra Redis hỗ trợ danh sách các máy chủ Redis trong cấu hình plugin và hỗ trợ sắp được thêm vào phía đầu vào để phù hợp với điều đó. Tạm thời, bạn có thể sử dụng nhiều định nghĩa đầu vào Redis ở phía người lập chỉ mục / người tiêu dùng.

4. Tôi không thể trả lời điều này ngoài việc nói rằng có vẻ như bạn đang cố gắng làm nhiều việc với một máy chủ duy nhất (có thể bị thiếu năng lực).

Bất kỳ quy trình nhân rộng tốt đều bắt đầu bằng việc phá vỡ các thành phần được sắp xếp thành các hệ thống riêng biệt. Tôi không thấy cấu hình của bạn ở bất cứ đâu ngoài những nơi mà logstash 'nút cổ chai' nằm trong các bộ lọc. Tùy thuộc vào số lượng biến đổi bạn đang thực hiện, nó có thể có tác động đến việc sử dụng bộ nhớ của các quy trình Logstash.

Logstash hoạt động rất nhiều như legos. Bạn có thể sử dụng gạch 2x4 hoặc bạn có thể sử dụng hai gạch 2x2 để hoàn thành cùng một nhiệm vụ. Ngoại trừ trong trường hợp logstash, thực sự chắc chắn hơn khi sử dụng các viên gạch nhỏ hơn một viên gạch lớn.

Một số lời khuyên chung mà chúng tôi thường đưa ra là:

• vận chuyển nhật ký càng nhanh càng tốt từ cạnh Nếu bạn có thể sử dụng truyền tải mạng thuần túy thay vì ghi vào đĩa, điều đó thật tuyệt nhưng không bắt buộc. Logstash dựa trên JVM và có ý nghĩa tốt và xấu. Sử dụng một người giao hàng thay thế. Tôi đã viết một con trăn dựa trên ( https://github.com/lusis/logstash-shipper ) nhưng tôi sẽ đề nghị mọi người sử dụng Beaver thay thế ( https://github.com/josegonzalez/beaver ).

• tạo nhật ký của bạn ở định dạng yêu cầu lọc càng ít càng tốt (định dạng json hoặc tối ưu json-event) Điều này không phải lúc nào cũng có thể. Tôi đã viết một app4 log4j để làm điều này ( https://github.com/lusis/zmq-appender ) và cuối cùng đã phá vỡ bố cục mẫu vào repo của riêng nó ( https://github.com/lusis/log4j-jsonevent-layout ). Điều này có nghĩa là tôi không phải thực hiện bất kỳ bộ lọc nào trong logstash cho các nhật ký đó. Tôi chỉ đặt loại trên đầu vào thành 'json-event'

Đối với apache, bạn có thể thử phương pháp này: http://cookbook.logstash.net/recipes/apache-json-logs/

• chia mọi thứ thành nhiều thành phần Trong mỗi cuộc nói chuyện tôi đã thực hiện về logstash, tôi mô tả nó như một ống unix trên steroid. Bạn có thể làm cho đường ống dài hoặc ngắn như bạn muốn. Bạn mở rộng quy mô logstash bằng cách thay đổi các trách nhiệm theo chiều ngang. Điều này có thể có nghĩa là làm cho đường ống dài hơn nhưng chúng ta không nói về bất cứ điều gì có liên quan về mặt thống kê về mặt chi phí trễ. Nếu bạn có quyền kiểm soát lớn hơn đối với mạng của mình (tức là KHÔNG trên EC2), bạn có thể thực hiện một số điều tuyệt vời với cách ly lưu lượng tiêu chuẩn.

Cũng lưu ý rằng danh sách gửi thư đăng nhập là RẤT hoạt động vì vậy bạn nên luôn luôn bắt đầu ở đó. Vệ sinh và kiểm tra cấu hình của bạn vì đó là nơi tốt nhất để bắt đầu.

Có những công ty (như Sonian) chia tỷ lệ đàn hồi Tìm kiếm theo cấp độ petabyte và các công ty (như Mailchimp và Dreamhost) mở rộng Logstash thành mức độ điên rồ. Nó có thể được thực hiện.