Nhật ký là một phần quan trọng của hệ thống, cho phép bạn hiểu rằng nó hoạt động (hoặc không hoạt động) như mong đợi. Trong các điều kiện của kiến trúc microservice, làm việc với nhật ký trở thành một môn học riêng của Special Olympiad. Có rất nhiều vấn đề cần được giải quyết:
- cách viết nhật ký từ ứng dụng;
- viết nhật ký ở đâu;
- cách cung cấp nhật ký để lưu trữ và xử lý;
- cách xử lý và lưu trữ nhật ký.
Việc sử dụng các công nghệ container hóa phổ biến hiện nay sẽ tạo thêm cát trên đầu cào trong lĩnh vực tùy chọn giải quyết vấn đề.
Chỉ về điều này là bản ghi lại báo cáo của Yuri Bushmelev "Bản đồ của một kẻ cào trong lĩnh vực thu thập và giao nhật ký"
Ai quan tâm, xin vui lòng dưới con mèo.
Tên tôi là Yuri Bushmelev. Tôi làm việc cho Lazada. Hôm nay tôi sẽ nói về cách chúng tôi tạo nhật ký, cách chúng tôi thu thập chúng và những gì chúng tôi viết ở đó.
Chúng tôi đến từ đâu? Chúng ta là ai? Lazada là nhà bán lẻ trực tuyến số 1 tại sáu quốc gia ở Đông Nam Á. Tất cả các quốc gia này được phân phối giữa các trung tâm dữ liệu. Hiện có tổng cộng 4 trung tâm dữ liệu. Tại sao điều này lại quan trọng? Vì một số quyết định là do liên kết giữa các trung tâm rất yếu. Chúng tôi có một kiến trúc microservice. Tôi rất ngạc nhiên khi biết rằng chúng tôi đã có 80 dịch vụ siêu nhỏ. Khi tôi bắt đầu thực hiện nhiệm vụ với các bản ghi, chỉ có 20. Ngoài ra, có một phần lớn di sản PHP mà tôi cũng phải chung sống và chịu đựng. Tất cả điều này tạo ra cho chúng tôi tại thời điểm này hơn 6 triệu tin nhắn mỗi phút cho toàn bộ hệ thống. Hơn nữa, tôi sẽ chỉ ra cách chúng ta đang cố gắng sống chung với điều này và tại sao lại như vậy.
Bạn phải sống với 6 triệu tin nhắn này bằng cách nào đó. Chúng ta nên làm gì với chúng? Cần 6 triệu tin nhắn:
- gửi từ ứng dụng
- chấp nhận giao hàng
- cung cấp cho phân tích và lưu trữ.
- phân tích
- lưu trữ bằng cách nào đó.
Khi có ba triệu tin nhắn, tôi cũng có cái nhìn tương tự. Bởi vì chúng tôi bắt đầu với một số đồng xu. Rõ ràng là các bản ghi ứng dụng được viết ở đó. Ví dụ: không thể kết nối với cơ sở dữ liệu, có thể kết nối với cơ sở dữ liệu nhưng không thể đọc nội dung nào đó. Nhưng bên cạnh đó, mỗi vi dịch vụ của chúng tôi cũng ghi nhật ký truy cập. Mỗi yêu cầu đến vi dịch vụ đều được đưa vào nhật ký. Tại sao chúng ta lại làm việc này? Các nhà phát triển muốn có thể theo dõi. Mỗi nhật ký truy cập chứa trường theo dõi, theo đó một giao diện đặc biệt sau đó sẽ giải phóng toàn bộ chuỗi và hiển thị đẹp mắt dấu vết. Dấu vết cho thấy yêu cầu đã diễn ra như thế nào và điều này giúp các nhà phát triển của chúng tôi xử lý bất kỳ rác không xác định nào nhanh hơn.
Làm thế nào để sống với nó? Bây giờ tôi sẽ mô tả ngắn gọn lĩnh vực tùy chọn - cách giải quyết vấn đề này nói chung. Cách giải quyết vấn đề thu thập, truyền và lưu trữ nhật ký.
Cách viết từ ứng dụng? Rõ ràng là có nhiều cách khác nhau. Đặc biệt, có một phương pháp hay nhất, như các đồng chí thời trang đã nói với chúng tôi. Có hai loại trường học cũ, như ông bà đã nói. Có nhiều cách khác.
Với việc thu thập nhật ký, tình hình gần như giống nhau. Không có nhiều lựa chọn để giải quyết phần cụ thể này. Có nhiều người trong số họ, nhưng vẫn chưa có nhiều.
Nhưng với việc phân phối và phân tích tiếp theo, số lượng biến thể bắt đầu bùng nổ. Tôi sẽ không mô tả từng tùy chọn bây giờ. Tôi nghĩ rằng tất cả những người quan tâm đến chủ đề này đều biết các tùy chọn chính.
Tôi sẽ cho bạn thấy chúng tôi đã làm điều đó như thế nào tại Lazada và tất cả bắt đầu như thế nào.
Một năm trước, tôi đến Lazada và được gửi đến dự án đăng nhập. Nó là như thế này ở đó. Nhật ký từ ứng dụng được ghi vào thiết bị xuất chuẩn và thiết bị xuất chuẩn. Tất cả mọi thứ đã được thực hiện một cách thời trang. Nhưng sau đó, các nhà phát triển đã ném nó ra khỏi các luồng tiêu chuẩn, và sau đó các chuyên gia cơ sở hạ tầng sẽ tìm ra nó bằng cách nào đó. Giữa các chuyên gia cơ sở hạ tầng và nhà phát triển, cũng có những người phát hành đã nói: “uh ... tốt, chúng ta hãy bọc chúng trong một tệp có trình bao, và thế là xong.” Và vì tất cả những thứ này nằm trong một thùng chứa, nên họ gói nó ngay trong chính thùng chứa, ánh xạ thư mục bên trong và đặt nó ở đó. Tôi nghĩ chuyện gì đã xảy ra thì mọi người đã rõ.
Hãy nhìn xa hơn một chút. Làm thế nào chúng tôi cung cấp các bản ghi này. Ai đó đã chọn td-agent, thực sự thông thạo nhưng không hoàn toàn thông thạo. Tôi vẫn không hiểu mối quan hệ của hai dự án này, nhưng dường như chúng giống nhau. Và thông thạo này, được viết bằng Ruby, đọc các tệp nhật ký, phân tích chúng thành JSON bằng một số biểu thức chính quy. Sau đó, họ được gửi đến Kafka. Hơn nữa, ở Kafka, chúng tôi có 4 chủ đề riêng biệt cho mỗi API. Tại sao lại là 4? Bởi vì có trực tiếp nên có dàn dựng và bởi vì có thiết bị xuất chuẩn và thiết bị xuất chuẩn. Các nhà phát triển sản xuất chúng và nhân viên cơ sở hạ tầng phải tạo chúng trong Kafka. Hơn nữa, Kafka bị kiểm soát bởi một bộ phận khác. Do đó, cần phải tạo một vé để họ tạo 4 chủ đề ở đó cho mỗi api. Mọi người quên nó đi. Nói chung, đó là rác và chất thải.
Chúng ta đã làm gì tiếp theo với nó? Chúng tôi đã gửi nó cho kafka. Xa hơn từ Kafka, một nửa số gỗ đã bay đến Logstash. Nửa nhật ký còn lại đã được chia sẻ. Một số bay đến Graylog này, một số bay đến Graylog khác. Kết quả là, tất cả điều này đã bay vào một cụm Elaticsearch. Đó là, tất cả mớ hỗn độn này cuối cùng đã rơi vào đó. Bạn không cần phải làm điều đó!
Đây là những gì nó trông giống như khi nhìn từ trên cao. Bạn không cần phải làm điều đó! Ở đây, các khu vực có vấn đề ngay lập tức được đánh dấu bằng các con số. Thực sự có nhiều hơn trong số chúng, nhưng 6 cái thực sự có vấn đề, cần phải làm gì đó. Bây giờ tôi sẽ nói về chúng một cách riêng biệt.
Ở đây (1,2,3) chúng tôi ghi các tệp và theo đó, có ba lần cào ở đây cùng một lúc.
Đầu tiên (1) là chúng ta cần viết chúng ở đâu đó. Không phải lúc nào cũng mong muốn cung cấp cho API khả năng ghi trực tiếp vào tệp. Điều mong muốn là API được cách ly trong một vùng chứa và thậm chí tốt hơn nữa là API ở chế độ chỉ đọc. Tôi là quản trị viên hệ thống, vì vậy tôi có một cái nhìn hơi khác về những điều này.
Điểm thứ hai (2,3) là chúng tôi có rất nhiều yêu cầu đến API. API ghi rất nhiều dữ liệu vào một tệp. Các tập tin đang phát triển. Chúng ta cần xoay chúng. Bởi vì nếu không, bạn sẽ không thể lưu bất kỳ đĩa nào ở đó. Việc xoay chúng là không tốt vì chúng được chuyển hướng qua trình bao tới một thư mục. Không có cách nào chúng ta có thể xoay nó. Bạn không thể yêu cầu ứng dụng mở lại tay cầm. Bởi vì các nhà phát triển sẽ nhìn bạn như một kẻ ngốc: “Mô tả gì? Chúng tôi thường viết thư cho thiết bị xuất chuẩn. Các khung đã biến copytruncate thành logrotate, chỉ tạo một bản sao của tệp và xử lý bản gốc. Theo đó, giữa các quá trình sao chép này, dung lượng đĩa thường hết.
(4) Chúng tôi có các định dạng khác nhau trong các API khác nhau. Chúng hơi khác nhau, nhưng biểu thức chính quy phải được viết khác đi. Vì tất cả đều do Puppet quản lý nên có rất nhiều lớp có gián riêng. Thêm vào đó, td-agent hầu hết thời gian đều có thể ăn nhớ, ngu ngốc, anh ta chỉ có thể giả vờ rằng mình đang làm việc và không làm gì cả. Bề ngoài, không thể hiểu rằng anh ta không làm gì cả. Cùng lắm thì ngã, lát nữa sẽ có người đỡ. Chính xác hơn, một cảnh báo sẽ bay đến và ai đó sẽ dùng tay giơ lên.
(6) Và thứ rác rưởi và lãng phí nhất - đó là elaticsearch. Vì nó là phiên bản cũ. Bởi vì chúng tôi không có những bậc thầy tận tụy vào thời điểm đó. Chúng tôi có các bản ghi không đồng nhất có các trường có thể chồng lên nhau. Các nhật ký khác nhau của các ứng dụng khác nhau có thể được ghi với cùng tên trường, nhưng đồng thời có thể có dữ liệu khác nhau bên trong. Nghĩa là, một nhật ký đi kèm với một Số nguyên trong một trường, chẳng hạn như cấp độ. Một nhật ký khác đi kèm với một Chuỗi trong trường cấp độ. Trong trường hợp không có ánh xạ tĩnh, một điều tuyệt vời như vậy hóa ra. Nếu sau khi xoay chỉ mục, một thông báo có chuỗi xuất hiện đầu tiên trong elaticsearch, thì chúng tôi vẫn hoạt động bình thường. Và nếu tin nhắn đầu tiên đến với Số nguyên, thì tất cả các tin nhắn tiếp theo đến với Chuỗi sẽ bị loại bỏ. Vì loại trường không khớp.
Chúng tôi bắt đầu hỏi những câu hỏi này. Chúng tôi quyết định không tìm kiếm kẻ có tội.
Nhưng một cái gì đó cần phải được thực hiện! Điều hiển nhiên là chúng ta cần thiết lập các tiêu chuẩn. Chúng tôi đã có một số tiêu chuẩn. Một số chúng tôi đã mang lại một chút sau đó. May mắn thay, một định dạng nhật ký duy nhất cho tất cả các API đã được phê duyệt vào thời điểm đó. Nó được viết trực tiếp vào các tiêu chuẩn tương tác dịch vụ. Theo đó, những người muốn nhận nhật ký nên viết chúng ở định dạng này. Nếu ai đó không viết nhật ký ở định dạng này, thì chúng tôi không đảm bảo bất cứ điều gì.
Hơn nữa, tôi muốn có một tiêu chuẩn duy nhất cho các phương pháp ghi, phân phối và thu thập nhật ký. Trên thực tế, viết chúng ở đâu và gửi chúng như thế nào. Tình huống lý tưởng là khi các dự án sử dụng cùng một thư viện. Có thư viện ghi nhật ký riêng cho Go, có thư viện riêng cho PHP. Mọi người chúng ta có, mọi người nên sử dụng chúng. Hiện tại, tôi có thể nói rằng chúng tôi đang thành công 80%. Nhưng một số vẫn tiếp tục ăn xương rồng.
Và ở đó (trên trang trình bày) “SLA để phân phối nhật ký” hầu như không bắt đầu xuất hiện. Nó vẫn chưa có, nhưng chúng tôi đang làm việc với nó. Bởi vì sẽ rất thuận tiện khi cơ sở hạ tầng nói rằng nếu bạn viết ở định dạng như vậy đến một nơi như vậy và một nơi như vậy và không quá N tin nhắn mỗi giây, thì rất có thể chúng tôi sẽ gửi nó đến đó. Nó lấy đi rất nhiều đau đầu. Nếu có SLA, thì thật tuyệt!
Chúng ta đã bắt đầu giải quyết vấn đề như thế nào? Rake chính là với td-agent. Không rõ nhật ký của chúng tôi đi đâu. Họ có giao hàng không? Họ có đi không? Họ đang ở đâu? Do đó, nó đã được quyết định thay thế td-agent bằng mục đầu tiên. Các tùy chọn để thay thế nó bằng gì, tôi đã phác thảo ngắn gọn ở đây.
Lưu loát Đầu tiên, tôi tình cờ gặp anh ấy ở một công việc trước đây, và anh ấy cũng định kỳ ngã ở đó. Thứ hai, điều này giống nhau, chỉ trong hồ sơ.
filebeat. Nó tốt cho chúng ta như thế nào? Thực tế là anh ấy chơi cờ vây, và chúng tôi có chuyên môn tuyệt vời về cờ vây. Theo đó, nếu có bất cứ điều gì, bằng cách nào đó chúng ta có thể thêm nó vào chính mình. Đó là lý do tại sao chúng tôi đã không lấy nó. Vì vậy, thậm chí sẽ không có bất kỳ sự cám dỗ nào để bắt đầu viết lại nó cho chính bạn.
Giải pháp rõ ràng cho quản trị hệ thống là tất cả các loại nhật ký hệ thống với số lượng này (syslog-ng/rsyslog/nxlog).
Hoặc viết một cái gì đó của riêng bạn, nhưng chúng tôi đã loại bỏ nó, cũng như filebeat. Nếu bạn viết một cái gì đó, thì tốt hơn là viết một cái gì đó hữu ích cho doanh nghiệp. Để cung cấp nhật ký, tốt hơn là lấy thứ gì đó làm sẵn.
Do đó, sự lựa chọn thực sự dẫn đến sự lựa chọn giữa syslog-ng và rsyslog. Tôi nghiêng về rsyslog đơn giản vì chúng tôi đã có các lớp dành cho rsyslog trong Puppet và tôi không tìm thấy sự khác biệt rõ ràng giữa chúng. Nhật ký hệ thống là gì, nhật ký hệ thống là gì. Vâng, một số tài liệu tệ hơn, một số tốt hơn. Nó biết thế này, còn nó làm thế khác.
Và một chút về rsyslog. Đầu tiên, nó rất tuyệt vì nó có rất nhiều mô-đun. Nó có RainerScript mà con người có thể đọc được (ngôn ngữ cấu hình hiện đại). Một phần thưởng tuyệt vời là chúng tôi có thể mô phỏng hành vi của tác nhân td bằng các công cụ tiêu chuẩn của nó và không có gì thay đổi đối với các ứng dụng. Đó là, chúng tôi thay đổi td-agent thành rsyslog và chưa chạm vào mọi thứ khác. Và ngay lập tức chúng tôi nhận được một giao hàng làm việc. Tiếp theo, chuẩn hóa mm là điều thú vị về rsyslog. Nó cho phép bạn phân tích nhật ký, nhưng không phải với Grok và regexp. Nó tạo ra một cây cú pháp trừu tượng. Nó phân tích các bản ghi theo cách giống như cách trình biên dịch phân tích mã nguồn. Điều này cho phép bạn làm việc rất nhanh, ngốn ít CPU và nói chung, đó là một điều rất thú vị. Có một loạt các tiền thưởng khác. Tôi sẽ không tập trung vào chúng.
rsyslog có nhiều nhược điểm hơn. Chúng gần giống như tiền thưởng. Vấn đề chính là bạn cần có khả năng nấu nó và bạn cần chọn một phiên bản.
Chúng tôi quyết định rằng chúng tôi sẽ viết nhật ký trong một ổ cắm unix. Và không phải trong/dev/log, bởi vì ở đó chúng tôi có một đống nhật ký hệ thống, có nhật ký trong đường dẫn này. Vì vậy, hãy ghi vào một ổ cắm tùy chỉnh. Chúng tôi sẽ đính kèm nó vào một bộ quy tắc riêng. Chúng ta đừng can thiệp vào bất cứ điều gì. Mọi thứ sẽ minh bạch và dễ hiểu. Vì vậy, chúng tôi thực sự đã làm. Thư mục với các ổ cắm này được chuẩn hóa và chuyển tiếp tới tất cả các vùng chứa. Các thùng chứa có thể nhìn thấy ổ cắm mà họ cần, mở và ghi vào đó.
Tại sao không phải là một tập tin? Vì mọi người đã đọc , đã cố chuyển tiếp tệp tới docker và nhận thấy rằng sau khi khởi động lại rsyslog, bộ mô tả tệp thay đổi và docker mất tệp này. Anh ấy tiếp tục mở một cái gì đó khác, nhưng không phải cùng một ổ cắm nơi họ viết. Chúng tôi quyết định rằng chúng tôi sẽ bỏ qua vấn đề này, đồng thời, bỏ qua vấn đề chặn.
Rsyslog thực hiện các hành động được chỉ định trên trang trình bày và gửi nhật ký tới rơle hoặc Kafka. Kafka theo lối cũ. Rayleigh - Tôi đã thử sử dụng rsyslog thuần túy để gửi nhật ký. Không có Hàng đợi Tin nhắn, sử dụng các công cụ rsyslog tiêu chuẩn. Về cơ bản, nó hoạt động.
Nhưng có những sắc thái về cách đưa chúng vào phần này sau này (Logstash/Graylog/ES). Phần này (rsyslog-rsyslog) được sử dụng giữa các trung tâm dữ liệu. Đây là một liên kết tcp được nén, cho phép bạn tiết kiệm băng thông và theo đó, bằng cách nào đó làm tăng khả năng chúng tôi sẽ nhận được một số nhật ký từ một trung tâm dữ liệu khác khi kênh đầy. Bởi vì chúng tôi có Indonesia, nơi mọi thứ đều tồi tệ. Đó là nơi vấn đề liên tục nằm.
Chúng tôi đã nghĩ về cách chúng tôi thực sự giám sát, với xác suất nào các nhật ký mà chúng tôi đã ghi lại từ ứng dụng đạt được mục đích đó? Chúng tôi quyết định bắt đầu đo lường. Rsyslog có mô-đun thu thập số liệu thống kê riêng, có một số loại bộ đếm. Ví dụ: nó có thể hiển thị cho bạn kích thước của hàng đợi hoặc có bao nhiêu thư đến cho một hành động như vậy. Bạn đã có thể lấy một cái gì đó từ họ. Ngoài ra, nó có các bộ đếm tùy chỉnh mà bạn có thể định cấu hình và nó sẽ hiển thị cho bạn, chẳng hạn như số lượng thông báo mà một số API đã ghi lại. Tiếp theo, tôi đã viết rsyslog_exporter bằng Python và chúng tôi đã gửi tất cả cho Prometheus và vẽ sơ đồ. Chúng tôi thực sự muốn các số liệu của Graylog, nhưng cho đến nay chúng tôi vẫn chưa có thời gian để thiết lập chúng.
Vấn đề là gì? Vấn đề phát sinh với thực tế là chúng tôi đã phát hiện ra (BẤT NGỜ!) rằng các API Trực tiếp của chúng tôi viết 50 nghìn tin nhắn mỗi giây. Đây chỉ là API trực tiếp không có dàn dựng. Và Graylog chỉ hiển thị cho chúng tôi 12 nghìn tin nhắn mỗi giây. Và một câu hỏi hợp lý được đặt ra, tàn dư ở đâu? Từ đó chúng tôi kết luận rằng Graylog đơn giản là không thể đối phó. Chúng tôi đã xem xét và quả thực Graylog với Elaticsearch đã không làm chủ được quy trình này.
Tiếp theo, những khám phá khác mà chúng tôi đã thực hiện trên đường đi.
Ghi vào ổ cắm bị chặn. Chuyện đã xảy ra như thế nào? Khi tôi sử dụng rsyslog để phân phối, tại một số thời điểm, chúng tôi đã phá vỡ kênh giữa các trung tâm dữ liệu. Giao hàng tận nơi, giao hàng tận nơi. Tất cả điều này đã đến với một máy có API ghi vào ổ cắm rsyslog. Có một hàng đợi. Sau đó, hàng đợi để ghi vào ổ cắm unix đã đầy, theo mặc định là 128 gói. Và write() tiếp theo trong các khối ứng dụng. Khi chúng tôi xem xét thư viện mà chúng tôi sử dụng trong các ứng dụng Go, nó được viết ở đó rằng việc ghi vào ổ cắm xảy ra ở chế độ không chặn. Chúng tôi chắc chắn rằng không có gì bị chặn. Bởi vì chúng tôi đã đọc người đã viết về nó. Nhưng có một khoảnh khắc. Ngoài ra còn có một vòng lặp vô tận xung quanh cuộc gọi này, trong đó có một nỗ lực liên tục để đẩy một tin nhắn vào ổ cắm. Chúng tôi đã không nhận thấy anh ta. Tôi đã phải viết lại thư viện. Kể từ đó, nó đã thay đổi nhiều lần, nhưng bây giờ chúng tôi đã loại bỏ các ổ khóa trong tất cả các hệ thống con. Do đó, bạn có thể dừng rsyslog và sẽ không có gì giảm.
Cần phải theo dõi kích thước của hàng đợi, điều này giúp không giẫm lên cái cào này. Đầu tiên, chúng tôi có thể theo dõi khi chúng tôi bắt đầu mất tin nhắn. Thứ hai, chúng tôi có thể theo dõi rằng về cơ bản chúng tôi có vấn đề với việc giao hàng.
Và một khoảnh khắc khó chịu khác - khuếch đại 10 lần trong kiến trúc microservice là rất dễ dàng. Chúng tôi không có quá nhiều yêu cầu đến, nhưng do biểu đồ mà các thông báo này chạy xa hơn, do nhật ký truy cập, chúng tôi thực sự tăng tải cho nhật ký lên khoảng mười lần. Thật không may, tôi không có thời gian để tính toán các con số chính xác, nhưng microservice chính là bản chất của chúng. Điều này phải được ghi nhớ. Nó chỉ ra rằng tại thời điểm này, hệ thống con thu thập nhật ký được tải nhiều nhất trên Lazada.
Làm thế nào để giải quyết vấn đề elaticsearch? Nếu bạn cần nhanh chóng lấy nhật ký ở một nơi để không chạy trên tất cả các máy và thu thập chúng ở đó, hãy sử dụng lưu trữ tệp. Điều này được đảm bảo để làm việc. Nó được thực hiện từ bất kỳ máy chủ nào. Bạn chỉ cần dán đĩa vào đó và đặt syslog. Sau đó, bạn được đảm bảo có tất cả nhật ký ở một nơi. Sau đó, có thể từ từ định cấu hình elaticsearch, greylog hoặc thứ gì đó khác. Nhưng bạn sẽ có tất cả nhật ký và hơn nữa, bạn có thể lưu trữ chúng, miễn là có đủ mảng đĩa.
Tại thời điểm báo cáo của tôi, sơ đồ bắt đầu trông như thế này. Chúng tôi thực tế đã ngừng ghi vào tệp. Bây giờ, rất có thể, chúng tôi sẽ tắt phần còn lại. Trên các máy cục bộ chạy API, chúng tôi sẽ ngừng ghi vào tệp. Đầu tiên, có bộ lưu trữ tệp, hoạt động rất tốt. Thứ hai, các máy này liên tục hết dung lượng, bạn cần liên tục theo dõi nó.
Phần này với Logstash và Graylog, nó thực sự bay bổng. Vì vậy, bạn cần phải thoát khỏi nó. Bạn phải chọn một.
Chúng tôi quyết định bỏ Logstash và Kibana. Bởi vì chúng tôi có một bộ phận an ninh. kết nối là gì? Kết nối là Kibana không có X-Pack và không có Shield không cho phép bạn phân biệt quyền truy cập vào nhật ký. Do đó, họ đã lấy Graylog. Nó có tất cả. Tôi không thích nó, nhưng nó hoạt động. Chúng tôi đã mua phần cứng mới, cài đặt Graylog mới ở đó và chuyển tất cả nhật ký có định dạng nghiêm ngặt sang một Graylog riêng. Chúng tôi đã giải quyết vấn đề với các loại khác nhau của cùng một lĩnh vực về mặt tổ chức.
Chính xác những gì được bao gồm trong Graylog mới. Chúng tôi chỉ viết mọi thứ trong docker. Chúng tôi đã lấy một loạt máy chủ, triển khai ba phiên bản Kafka, 7 máy chủ Graylog phiên bản 2.3 (vì tôi muốn Elaticsearch phiên bản 5). Tất cả điều này đã được nâng lên trên các cuộc đột kích từ ổ cứng. Chúng tôi đã thấy tốc độ lập chỉ mục lên tới 100 nghìn tin nhắn mỗi giây. Chúng tôi đã thấy con số 140 terabyte dữ liệu mỗi tuần.
Và một lần nữa một cào! Chúng tôi có hai đợt giảm giá sắp tới. Chúng tôi đã chuyển hơn 6 triệu bài đăng. Chúng tôi Graylog không có thời gian để nhai. Bằng cách nào đó bạn phải sống sót một lần nữa.
Đây là cách chúng tôi sống sót. Đã thêm một vài máy chủ và SSD. Tại thời điểm này chúng ta sống như thế này. Bây giờ chúng tôi đã nhai 160 nghìn tin nhắn mỗi giây. Chúng tôi vẫn chưa đạt đến giới hạn, vì vậy không rõ chúng tôi có thể thực sự đạt được bao nhiêu.
Đây là những kế hoạch của chúng tôi cho tương lai. Trong số này, thực sự, điều quan trọng nhất có lẽ là tính sẵn sàng cao. Chúng tôi chưa có nó. Một số ô tô được thiết lập theo cùng một cách, nhưng cho đến nay mọi thứ đều đi qua một ô tô. Cần dành thời gian để thiết lập chuyển đổi dự phòng giữa chúng.
Thu thập số liệu từ Graylog.
Đặt giới hạn tốc độ để chúng tôi có một API điên rồ không giết băng thông của chúng tôi và mọi thứ khác.
Và cuối cùng, hãy ký một số loại SLA với các nhà phát triển để chúng tôi có thể phục vụ nhiều như vậy. Nếu bạn viết nhiều hơn, thì xin lỗi.
Và viết tài liệu.
Tóm lại, kết quả của mọi thứ mà chúng ta đã trải qua. Đầu tiên, các tiêu chuẩn. Thứ hai, syslog là chiếc bánh. Thứ ba, rsyslog hoạt động chính xác như được viết trên trang trình bày. Và chúng ta hãy đến với các câu hỏi.
câu hỏi.
câu hỏi: Tại sao họ quyết định không lấy ... (filebeat?)
câu trả lời: Cần ghi vào một tập tin. Tôi thực sự không muốn. Khi API của bạn viết hàng nghìn tin nhắn mỗi giây, ngay cả khi bạn xoay vòng mỗi giờ một lần, đây vẫn không phải là một tùy chọn. Bạn có thể ghi vào đường ống. Các nhà phát triển đã hỏi tôi: “Điều gì sẽ xảy ra nếu quá trình chúng tôi viết không thành công”? Tôi chỉ không tìm thấy những gì để trả lời họ, và nói: "Chà, được rồi, chúng ta đừng làm điều đó."
câu hỏi: Tại sao bạn không ghi nhật ký vào HDFS?
câu trả lờiA: Đây là giai đoạn tiếp theo. Chúng tôi đã nghĩ về nó ngay từ đầu, nhưng vì không có nguồn lực nào để giải quyết nó vào lúc này, nên nó nằm trong giải pháp lâu dài của chúng tôi.
câu hỏi: Một định dạng cột sẽ phù hợp hơn.
câu trả lời: Tôi hiểu. Chúng tôi "cho" bằng cả hai tay.
câu hỏi: Bạn ghi vào rsyslog. Cả TCP và UDP đều có sẵn ở đó. Nhưng nếu UDP, thì làm thế nào để bạn đảm bảo giao hàng?
câu trả lờiĐáp: Có hai điểm. Đầu tiên, tôi nói ngay với mọi người rằng chúng tôi không đảm bảo việc cung cấp nhật ký. Bởi vì khi các nhà phát triển đến và nói: “Hãy bắt đầu ghi dữ liệu tài chính vào đó và bạn sẽ đặt nó ở đâu đó cho chúng tôi trong trường hợp có điều gì đó xảy ra,” chúng tôi trả lời họ, “Tuyệt! Hãy bắt đầu chặn việc ghi vào ổ cắm và thực hiện nó trong các giao dịch để bạn được đảm bảo đặt nó vào ổ cắm cho chúng tôi và đảm bảo rằng chúng tôi đã nhận được nó từ phía bên kia. Và tại thời điểm này, mọi người ngay lập tức trở nên không cần thiết. Và nếu không, thì chúng ta có câu hỏi gì? Nếu bạn không muốn đảm bảo ghi vào ổ cắm, thì tại sao chúng tôi lại đảm bảo giao hàng? Chúng tôi đang nỗ lực hết sức. Chúng tôi thực sự cố gắng cung cấp nhiều nhất có thể và tốt nhất có thể, nhưng chúng tôi không đảm bảo 100%. Do đó, bạn không cần phải viết dữ liệu tài chính ở đó. Có cơ sở dữ liệu giao dịch cho việc này.
câu hỏi: Khi API tạo một số thông báo vào nhật ký và chuyển quyền kiểm soát sang các vi dịch vụ, bạn có gặp phải sự cố là các thông báo từ các vi dịch vụ khác nhau đến sai thứ tự không? Bởi vì điều này, sự nhầm lẫn phát sinh.
câu trả lờiA: Việc chúng đến theo một thứ tự khác là điều bình thường. Bạn phải sẵn sàng cho việc này. Bởi vì bất kỳ mạng phân phối nào cũng không đảm bảo đơn hàng cho bạn hoặc bạn cần dành các nguồn lực đặc biệt cho việc này. Nếu chúng tôi lưu trữ tệp, thì mỗi API sẽ lưu nhật ký vào tệp riêng của nó. Thay vào đó, rsyslog phân tách chúng thành các thư mục ở đó. Mỗi API có nhật ký riêng ở đó, nơi bạn có thể đến và xem, sau đó bạn có thể so sánh chúng bằng cách sử dụng dấu thời gian trong nhật ký này. Nếu họ tìm trong Graylog, thì ở đó họ sẽ được sắp xếp theo dấu thời gian. Mọi thứ sẽ ổn ở đó.
câu hỏi: Dấu thời gian có thể thay đổi theo mili giây.
câu trả lời: Dấu thời gian được tạo bởi chính API. Trên thực tế, đây là toàn bộ vấn đề. Chúng tôi có NTP. API tạo dấu thời gian đã có trong chính thông báo. Nó không được thêm vào bởi rsyslog.
câu hỏi: Tương tác giữa các trung tâm dữ liệu không thật rõ ràng. Trong khuôn khổ của trung tâm dữ liệu, rõ ràng cách các bản ghi được thu thập và xử lý. Sự tương tác giữa các trung tâm dữ liệu như thế nào? Hay mỗi trung tâm dữ liệu sống cuộc sống của riêng mình?
câu trả lời: Hầu hết. Chúng tôi có mỗi quốc gia nằm trong một trung tâm dữ liệu. Chúng tôi hiện không có trải rộng, do đó, một quốc gia được đặt trong các trung tâm dữ liệu khác nhau. Do đó, không cần phải kết hợp chúng. Bên trong mỗi trung tâm có một Log Relay. Đây là một máy chủ Rsyslog. Trong thực tế, hai máy quản lý. Chúng được thiết lập theo cùng một cách. Nhưng hiện tại, lưu lượng truy cập chỉ đi qua một trong số chúng. Cô ấy ghi lại mọi thứ tổng hợp. Nó có một hàng đợi đĩa chỉ trong trường hợp. Cô nhấn các bản ghi và gửi chúng đến trung tâm dữ liệu trung tâm (Singapore), nơi chúng đã bị đầu độc trong Graylog. Và mỗi trung tâm dữ liệu có kho lưu trữ tệp riêng. Trong trường hợp chúng tôi mất kết nối, chúng tôi có tất cả nhật ký ở đó. Họ sẽ ở lại đó. Chúng sẽ được lưu trữ ở đó.
câu hỏi: Bạn có nhận được nhật ký từ đó trong các tình huống bất thường không?
câu trả lời: Bạn có thể đến đó (đến nơi lưu trữ tệp) và xem.
câu hỏi: Làm thế nào để bạn giám sát rằng bạn không bị mất nhật ký?
câu trả lời: Chúng tôi đang thực sự mất chúng, và chúng tôi đang theo dõi nó. Giám sát bắt đầu một tháng trước. Thư viện mà API Go sử dụng có số liệu. Cô ấy có thể đếm được bao nhiêu lần cô ấy không ghi được vào ổ cắm. Hiện tại có một heuristic phức tạp. Có một bộ đệm ở đó. Nó cố gắng viết một tin nhắn từ nó đến ổ cắm. Nếu bộ đệm bị tràn, nó sẽ bắt đầu loại bỏ chúng. Và anh ấy đếm xem mình đã đánh rơi bao nhiêu cái. Nếu các quầy bắt đầu quá tải ở đó, chúng tôi sẽ biết về nó. Bây giờ chúng cũng đang đến với prometheus và bạn có thể xem các biểu đồ trong Grafana. Bạn có thể thiết lập cảnh báo. Nhưng vẫn chưa rõ gửi cho ai.
câu hỏi: Trong elaticsearch, bạn lưu trữ các bản ghi có dự phòng. Bạn có bao nhiêu bản sao?
câu trả lời: Một bản sao.
câu hỏi: Có phải nó chỉ là một dòng?
câu trả lời: Đây là bản gốc và bản sao. Dữ liệu được lưu trữ trong bản sao.
câu hỏi: Bạn đã điều chỉnh kích thước của bộ đệm rsyslog bằng cách nào đó chưa?
câu trả lời: Chúng tôi ghi các datagram vào một ổ cắm unix tùy chỉnh. Điều này ngay lập tức áp đặt giới hạn 128 kilobyte đối với chúng tôi. Chúng tôi không thể viết nhiều hơn vào nó. Chúng tôi đã viết điều này thành tiêu chuẩn. Ai muốn vào bộ lưu trữ, họ viết 128 kilobyte. Hơn nữa, các thư viện đã cắt và cắm một lá cờ rằng thông điệp đã bị cắt. Chúng tôi có một trường đặc biệt trong tiêu chuẩn của chính tin nhắn, cho biết liệu nó có bị cắt trong quá trình ghi hay không. Vì vậy, chúng tôi có cơ hội để theo dõi thời điểm này.
Câu hỏi: Bạn có viết JSON bị hỏng không?
câu trả lời: JSON bị hỏng sẽ bị loại bỏ trong quá trình chuyển tiếp vì gói quá lớn. Hoặc Graylog sẽ bị loại bỏ vì nó sẽ không thể phân tích cú pháp JSON. Nhưng có những sắc thái ở đây cần được khắc phục và chúng chủ yếu được gắn với rsyslog. Tôi đã điền vào một vài vấn đề ở đó, vấn đề này vẫn cần được giải quyết.
Câu hỏi: Tại sao lại là Kafka? Bạn đã thử RabbitMQ chưa? Graylog không cộng lại dưới tải trọng như vậy?
câu trả lời: Nó không hoạt động với Graylog. Và Graylog đang hình thành. Nó thực sự có vấn đề với anh ta. Anh ấy là một thứ. Và, trên thực tế, nó không cần thiết. Tôi muốn viết từ rsyslog trực tiếp đến elaticsearch và sau đó xem Kibana. Nhưng chúng ta cần giải quyết vấn đề với các nhân viên bảo vệ. Đây là một biến thể có thể có trong quá trình phát triển của chúng tôi khi chúng tôi loại bỏ Graylog và sử dụng Kibana. Logstash sẽ không có ý nghĩa. Bởi vì tôi có thể làm điều tương tự với rsyslog. Và nó có một mô-đun để ghi vào elaticsearch. Với Graylog, chúng tôi đang cố gắng sống bằng cách nào đó. Chúng tôi thậm chí còn tinh chỉnh nó một chút. Nhưng vẫn còn chỗ để cải thiện.
Về Kafka. Đó là cách nó đã xảy ra trong lịch sử. Khi tôi đến, nó đã ở đó rồi và nhật ký đã được ghi vào đó. Chúng tôi vừa nâng cấp cụm của mình và chuyển các bản ghi vào đó. Chúng tôi quản lý anh ấy, chúng tôi biết anh ấy cảm thấy thế nào. Đối với RabbitMQ... chúng tôi đang gặp sự cố với RabbitMQ. Và RabbitMQ đang phát triển cho chúng tôi. Chúng tôi có nó trong quá trình sản xuất và đã có vấn đề với nó. Bây giờ, trước khi bán, anh ta sẽ được shaman hóa, và anh ta sẽ bắt đầu làm việc bình thường. Nhưng trước đó, tôi chưa sẵn sàng đưa nó vào sản xuất. Còn một điểm nữa. Graylog có thể đọc phiên bản AMQP 0.9 và rsyslog có thể viết phiên bản AMQP 1.0. Và không có một giải pháp nào có thể thực hiện cả hai ở giữa. Có cái này hoặc cái kia. Vì vậy, bây giờ chỉ có Kafka. Nhưng cũng có những sắc thái. Bởi vì omkafka của phiên bản rsyslog mà chúng tôi sử dụng có thể làm mất toàn bộ bộ đệm thông báo mà nó lấy được từ rsyslog. Miễn là chúng ta đưa ra với nó.
Câu hỏi: Bạn đang sử dụng Kafka vì bạn đã có nó? Không được sử dụng cho bất kỳ mục đích nào khác?
câu trả lời: Kafka, được nhóm Khoa học dữ liệu sử dụng. Đây là một dự án hoàn toàn riêng biệt, thật không may, tôi không thể nói bất cứ điều gì. Tôi không biết. Cô được điều hành bởi nhóm Khoa học dữ liệu. Khi nhật ký bắt đầu, họ quyết định sử dụng nó để không đặt nhật ký của mình. Bây giờ chúng tôi đã cập nhật Graylog và chúng tôi đã mất khả năng tương thích vì có một phiên bản cũ của Kafka. Chúng tôi đã phải làm của riêng của chúng tôi. Đồng thời, chúng tôi đã loại bỏ bốn chủ đề này cho mỗi API. Chúng tôi tạo một đỉnh rộng cho tất cả các buổi phát trực tiếp, một đỉnh rộng rộng cho tất cả dàn dựng và chúng tôi chỉ quay mọi thứ ở đó. Graylog cào tất cả những điều này song song.
Câu hỏi: Tại sao chúng ta cần pháp sư với ổ cắm này? Bạn đã thử sử dụng trình điều khiển nhật ký nhật ký hệ thống cho vùng chứa chưa.
câu trả lời: Vào thời điểm chúng tôi đặt câu hỏi này, chúng tôi có quan hệ căng thẳng với docker. Đó là docker 1.0 hoặc 0.9. Bản thân Docker thật kỳ lạ. Thứ hai, nếu bạn cũng chuyển các bản ghi vào nó ... Tôi có một nghi ngờ chưa được xác minh rằng nó chuyển tất cả các bản ghi qua chính nó, thông qua docker daemon. Nếu chúng ta có một API phát điên, thì các API còn lại sẽ gặp phải tình trạng là chúng không thể gửi thiết bị xuất chuẩn và thiết bị xuất chuẩn. Tôi không biết chuyện này sẽ dẫn đến đâu. Tôi có một sự nghi ngờ ở mức độ cảm thấy rằng không cần thiết phải sử dụng trình điều khiển syslog docker ở nơi này. Bộ phận kiểm tra chức năng của chúng tôi có cụm Graylog riêng với nhật ký. Họ sử dụng trình điều khiển nhật ký docker và mọi thứ có vẻ ổn ở đó. Nhưng họ ngay lập tức viết GELF cho Graylog. Tại thời điểm khi chúng tôi bắt đầu tất cả những điều này, chúng tôi chỉ cần nó hoạt động. Có lẽ sau này, khi ai đó đến và nói rằng nó đã hoạt động bình thường trong một trăm năm, chúng tôi sẽ thử.
Câu hỏi: Bạn phân phối giữa các trung tâm dữ liệu bằng rsyslog. Tại sao không phải trên Kafka?
câu trả lời: Chúng tôi làm điều này, và đây là cách nó thực sự là. Vì hai lý do. Nếu kênh đã chết hoàn toàn, thì tất cả nhật ký của chúng tôi, ngay cả ở dạng nén, sẽ không vượt qua được kênh đó. Và kafka cho phép họ thua trong quá trình này. Bằng cách này, chúng tôi thoát khỏi việc dính các nhật ký này. Chúng tôi chỉ sử dụng Kafka trực tiếp trong trường hợp này. Nếu chúng tôi có một kênh tốt và muốn giải phóng kênh đó, thì chúng tôi sử dụng rsyslog của họ. Nhưng trên thực tế, bạn có thể thiết lập để nó loại bỏ những gì nó không vượt qua được. Hiện tại, chúng tôi chỉ đang sử dụng phân phối rsyslog trực tiếp ở đâu đó, ở đâu đó Kafka.
Nguồn: www.habr.com