Hội nghị HighLoad++ tiếp theo sẽ được tổ chức vào ngày 6 và 7 tháng 2020 năm XNUMX tại St. Petersburg Chi tiết và vé . HighLoad++ Moscow 2018. Hội trường “Moscow”. Ngày 9 tháng 15, 00:XNUMX. Luận văn và .
* Giám sát - trực tuyến và phân tích.
* Những hạn chế cơ bản của nền tảng ZABBIX.
* Giải pháp mở rộng quy mô lưu trữ phân tích.
* Tối ưu hóa máy chủ ZABBIX.
* Tối ưu hóa giao diện người dùng.
* Kinh nghiệm vận hành hệ thống dưới tải trên 40k NVPS.
* Kết luận ngắn gọn.
Mikhail Makurov (sau đây gọi là – MM): - Chào mọi người!
Maxim Chernetsov (sau đây gọi là – MCH): - Chào buổi chiều!
MM: – Hãy để tôi giới thiệu Maxim. Max là một kỹ sư tài năng, nhà mạng giỏi nhất mà tôi biết. Maxim tham gia vào các mạng lưới và dịch vụ, cũng như sự phát triển và vận hành của chúng.
MCH: – Và tôi muốn kể cho bạn nghe về Mikhail. Mikhail là một nhà phát triển C. Anh ấy đã viết một số giải pháp xử lý lưu lượng tải cao cho công ty chúng tôi. Chúng tôi sống và làm việc ở Urals, tại thành phố của những người đàn ông cứng rắn Chelyabinsk, trong công ty Intersvyaz. Công ty chúng tôi là nhà cung cấp dịch vụ Internet và truyền hình cáp cho một triệu người tại 16 thành phố.
MM: – Và điều đáng nói là Intersvyaz không chỉ là một nhà cung cấp mà còn là một công ty CNTT. Hầu hết các giải pháp của chúng tôi đều do bộ phận CNTT của chúng tôi thực hiện.
A: từ máy chủ xử lý lưu lượng truy cập đến trung tâm cuộc gọi và ứng dụng di động. Bộ phận CNTT hiện có khoảng 80 người với năng lực rất, rất đa dạng.
Giới thiệu về Zabbix và kiến trúc của nó
MCH: – Và bây giờ tôi sẽ cố gắng lập kỷ lục cá nhân và nói trong một phút Zabbix là gì (sau đây gọi tắt là “Zabbix”).
Zabbix tự định vị mình là một hệ thống giám sát vượt trội cấp doanh nghiệp. Nó có nhiều tính năng giúp cuộc sống dễ dàng hơn: quy tắc báo cáo nâng cao, API để tích hợp, nhóm và tự động phát hiện máy chủ và số liệu. Zabbix có cái gọi là công cụ mở rộng quy mô - proxy. Zabbix là một hệ thống nguồn mở.
Nói ngắn gọn về kiến trúc. Chúng ta có thể nói rằng nó bao gồm ba thành phần:
- Máy chủ. Viết bằng C Với việc xử lý và truyền thông tin giữa các luồng khá phức tạp. Mọi quá trình xử lý đều diễn ra trong đó: từ nhận đến lưu vào cơ sở dữ liệu.
- Tất cả dữ liệu được lưu trữ trong cơ sở dữ liệu. Zabbix hỗ trợ MySQL, PostreSQL và Oracle.
- Giao diện web được viết bằng PHP. Trên hầu hết các hệ thống, nó đi kèm với máy chủ Apache, nhưng hoạt động hiệu quả hơn khi kết hợp với nginx + php.
Hôm nay chúng tôi muốn kể một câu chuyện trong cuộc đời của công ty chúng tôi liên quan đến Zabbix...
Một câu chuyện về cuộc đời của công ty Intersvyaz. Chúng ta có gì và chúng ta cần gì?
5 hoặc 6 tháng trước. Một ngày sau giờ làm việc...
MCH: - Misha, xin chào! Tôi rất vui vì đã bắt được bạn - có một cuộc trò chuyện. Chúng tôi lại gặp vấn đề với việc giám sát. Trong một vụ tai nạn lớn, mọi thứ đều chậm và không có thông tin nào về trạng thái mạng. Thật không may, đây không phải là lần đầu tiên điều này xảy ra. Tôi cần bạn giúp. Hãy thực hiện công việc giám sát của chúng tôi trong mọi trường hợp!
MM: - Nhưng trước tiên hãy đồng bộ hóa đã. Tôi đã không nhìn vào đó trong một vài năm. Theo tôi nhớ, chúng tôi đã bỏ Nagios và chuyển sang Zabbix khoảng 8 năm trước. Và bây giờ chúng tôi dường như có 6 máy chủ mạnh mẽ và khoảng chục proxy. Tôi có nhầm lẫn gì không?
MCH: - Hầu hết. 15 máy chủ, một số trong đó là máy ảo. Điều quan trọng nhất là nó không cứu được chúng ta vào lúc chúng ta cần nó nhất. Giống như một tai nạn - máy chủ chạy chậm lại và bạn không thể nhìn thấy gì. Chúng tôi đã cố gắng tối ưu hóa cấu hình nhưng điều này không mang lại hiệu suất tăng tối ưu.
MM: - Rõ ràng. Bạn đã xem xét điều gì chưa, bạn đã tìm ra điều gì đó từ chẩn đoán chưa?
MCH: – Điều đầu tiên bạn phải giải quyết là cơ sở dữ liệu. MySQL được tải liên tục, lưu trữ các số liệu mới và khi Zabbix bắt đầu tạo ra một loạt sự kiện, cơ sở dữ liệu sẽ hoạt động quá tải trong vài giờ theo đúng nghĩa đen. Tôi đã nói với bạn về việc tối ưu hóa cấu hình, nhưng theo đúng nghĩa đen là năm nay họ đã cập nhật phần cứng: các máy chủ có hơn một trăm gigabyte bộ nhớ và mảng ổ đĩa trên RAID SSD - chẳng ích gì khi phát triển nó một cách tuyến tính về lâu dài. Chúng ta làm gì?
MM: - Rõ ràng. Nói chung, MySQL là cơ sở dữ liệu LTP. Rõ ràng, nó không còn phù hợp để lưu trữ một kho lưu trữ các số liệu có kích thước như chúng ta nữa. Hãy tìm ra nó.
MCH: - Hãy!
Tích hợp Zabbix và Clickhouse nhờ hackathon
Sau một thời gian, chúng tôi nhận được dữ liệu thú vị:
Hầu hết không gian trong cơ sở dữ liệu của chúng tôi đã bị chiếm giữ bởi kho lưu trữ số liệu và chưa đến 1% được sử dụng cho cấu hình, mẫu và cài đặt. Thời điểm đó, chúng tôi đã vận hành giải pháp Big data dựa trên Clickhouse được hơn một năm. Hướng di chuyển đã rõ ràng đối với chúng tôi. Tại Hackathon mùa xuân của chúng tôi, tôi đã viết phần tích hợp Zabbix với Clickhouse cho máy chủ và giao diện người dùng. Vào thời điểm đó, Zabbix đã hỗ trợ ElasticSearch và chúng tôi quyết định so sánh chúng.
So sánh Clickhouse và Elaticsearch
MM: – Để so sánh, chúng tôi đã tạo tải tương tự như tải mà máy chủ Zabbix cung cấp và xem xét cách hoạt động của hệ thống. Chúng tôi đã viết dữ liệu theo lô 1000 dòng bằng cách sử dụng CURL. Chúng tôi đã giả định trước rằng Clickhouse sẽ hiệu quả hơn đối với cấu hình tải mà Zabbix thực hiện. Kết quả thậm chí còn vượt quá mong đợi của chúng tôi:
Trong cùng điều kiện thử nghiệm, Clickhouse đã ghi dữ liệu nhiều hơn ba lần. Đồng thời, cả hai hệ thống đều tiêu thụ rất hiệu quả (một lượng nhỏ tài nguyên) khi đọc dữ liệu. Nhưng Elastics yêu cầu một lượng lớn bộ xử lý khi ghi:
Nhìn chung, Clickhouse vượt trội hơn đáng kể so với Elastix về mức tiêu thụ bộ xử lý và tốc độ. Đồng thời, do nén dữ liệu, Clickhouse sử dụng ổ cứng ít hơn 11 lần và thực hiện các thao tác trên đĩa ít hơn khoảng 30 lần:
MCH: – Có, công việc của Clickhouse với disk subsystem được triển khai rất hiệu quả. Bạn có thể sử dụng các ổ đĩa SATA khổng lồ cho cơ sở dữ liệu và đạt tốc độ ghi hàng trăm nghìn dòng mỗi giây. Hệ thống sẵn dùng hỗ trợ sharding, sao chép và rất dễ cấu hình. Chúng tôi rất hài lòng với việc sử dụng nó trong suốt cả năm.
Để tối ưu hóa tài nguyên, bạn có thể cài đặt Clickhouse bên cạnh cơ sở dữ liệu chính hiện có của mình và từ đó tiết kiệm rất nhiều thời gian của CPU và hoạt động của đĩa. Chúng tôi đã chuyển kho lưu trữ số liệu sang cụm Clickhouse hiện có:
Chúng tôi đã giảm bớt cơ sở dữ liệu MySQL chính đến mức có thể kết hợp nó trên một máy với máy chủ Zabbix và từ bỏ máy chủ chuyên dụng cho MySQL.
Việc bỏ phiếu hoạt động như thế nào ở Zabbix?
4 vài tháng trước đây
MM: – Chà, chúng ta có thể quên đi những vấn đề với căn cứ được không?
MCH: - Chắc chắn rồi! Một vấn đề khác chúng ta cần giải quyết là việc thu thập dữ liệu chậm. Hiện tại, tất cả 15 máy chủ proxy của chúng tôi đều bị quá tải với SNMP và quy trình thăm dò ý kiến. Và không có cách nào ngoại trừ việc cài đặt ngày càng nhiều máy chủ mới.
MM: - Tuyệt vời. Nhưng trước tiên, hãy cho chúng tôi biết hoạt động bỏ phiếu ở Zabbix như thế nào?
MCH: – Nói tóm lại, có 20 loại số liệu và hàng chục cách để có được chúng. Zabbix có thể thu thập dữ liệu ở chế độ “phản hồi yêu cầu” hoặc chờ dữ liệu mới thông qua “Giao diện Trapper”.
Điều đáng chú ý là trong Zabbix ban đầu, phương pháp này (Trapper) là nhanh nhất.
Có máy chủ proxy để phân phối tải:
Proxy có thể thực hiện các chức năng thu thập tương tự như máy chủ Zabbix, nhận nhiệm vụ từ nó và gửi các số liệu được thu thập thông qua giao diện Trapper. Đây là cách chính thức được đề xuất để phân phối tải. Proxy cũng hữu ích để giám sát cơ sở hạ tầng từ xa hoạt động thông qua NAT hoặc kênh chậm:
MM: – Mọi thứ đều rõ ràng với kiến trúc. Chúng ta cần xem xét các nguồn...
Một vài ngày sau
Câu chuyện nmap fping đã chiến thắng như thế nào
MM: “Tôi nghĩ tôi đã đào được thứ gì đó.”
MCH: - Nói cho tôi!
MM: – Tôi phát hiện ra rằng khi kiểm tra tính khả dụng, Zabbix kiểm tra tối đa 128 máy chủ cùng một lúc. Tôi đã thử tăng con số này lên 500 và loại bỏ khoảng thời gian giữa các gói trong ping (ping) của chúng - điều này đã tăng gấp đôi hiệu suất. Nhưng tôi muốn số lượng lớn hơn.
MCH: – Trong thực tế, đôi khi tôi phải kiểm tra tính khả dụng của hàng nghìn máy chủ và tôi chưa bao giờ thấy thứ gì nhanh hơn nmap cho việc này. Tôi chắc chắn đây là cách nhanh nhất. Hãy thử nó! Chúng ta cần tăng đáng kể số lượng máy chủ trên mỗi lần lặp.
MM: – Kiểm tra hơn năm trăm? 600?
MCH: - Ít nhất là vài ngàn.
MM: - ĐƯỢC RỒI. Điều quan trọng nhất tôi muốn nói là tôi thấy rằng hầu hết việc bỏ phiếu trong Zabbix đều được thực hiện đồng bộ. Chúng tôi chắc chắn cần phải thay đổi nó sang chế độ không đồng bộ. Sau đó, chúng tôi có thể tăng đáng kể số lượng chỉ số được người thăm dò thu thập, đặc biệt nếu chúng tôi tăng số lượng chỉ số trên mỗi lần lặp.
MCH: - Tuyệt vời! Và khi?
MM: – Như thường lệ, hôm qua.
MCH: – Chúng tôi so sánh cả hai phiên bản fping và nmap:
Trên một số lượng lớn máy chủ, nmap được kỳ vọng sẽ hiệu quả hơn gấp 4 lần. Vì nmap chỉ kiểm tra tính khả dụng và thời gian phản hồi nên chúng tôi đã chuyển việc tính toán tổn thất sang trình kích hoạt và giảm đáng kể khoảng thời gian kiểm tra tính khả dụng. Chúng tôi nhận thấy số lượng máy chủ tối ưu cho nmap là khoảng 120 nghìn máy chủ mỗi lần lặp. Nmap cho phép chúng tôi giảm chi phí CPU cho việc kiểm tra tính khả dụng xuống ba lần và giảm khoảng thời gian từ 10 giây xuống còn XNUMX.
Tối ưu hóa bỏ phiếu
MM: “Sau đó, chúng tôi bắt đầu thực hiện các cuộc thăm dò ý kiến. Chúng tôi chủ yếu quan tâm đến việc phát hiện và tác nhân SNMP. Ở Zabbix, việc bỏ phiếu được thực hiện đồng bộ và các biện pháp đặc biệt đã được thực hiện để tăng hiệu quả của hệ thống. Trong chế độ đồng bộ, việc không có máy chủ sẽ gây ra sự suy giảm đáng kể trong việc thăm dò ý kiến. Có cả một hệ thống trạng thái, có các quy trình đặc biệt - cái gọi là máy thăm dò không thể truy cập, chỉ hoạt động với các máy chủ không thể truy cập:
Đây là một bình luận thể hiện ma trận trạng thái, tất cả sự phức tạp của hệ thống chuyển đổi cần có để hệ thống duy trì hiệu quả. Ngoài ra, việc bỏ phiếu đồng bộ khá chậm:
Đó là lý do tại sao hàng nghìn luồng thăm dò ý kiến trên hàng chục proxy không thể thu thập đủ lượng dữ liệu cần thiết cho chúng tôi. Việc triển khai không đồng bộ không chỉ giải quyết được vấn đề về số lượng luồng mà còn đơn giản hóa đáng kể hệ thống trạng thái của các máy chủ không khả dụng, bởi vì đối với bất kỳ số nào được kiểm tra trong một lần lặp thăm dò, thời gian chờ tối đa là 1 thời gian chờ:
Ngoài ra, chúng tôi đã sửa đổi và cải thiện hệ thống bỏ phiếu cho các yêu cầu SNMP. Thực tế là hầu hết mọi người không thể đáp ứng nhiều yêu cầu SNMP cùng một lúc. Do đó, chúng tôi đã tạo chế độ kết hợp, khi việc thăm dò SNMP của cùng một máy chủ được thực hiện không đồng bộ:
Việc này được thực hiện cho toàn bộ gói máy chủ. Chế độ này cuối cùng không chậm hơn chế độ hoàn toàn không đồng bộ, vì việc thăm dò một trăm rưỡi giá trị SNMP vẫn nhanh hơn nhiều so với 1 thời gian chờ.
Các thử nghiệm của chúng tôi đã chỉ ra rằng số lượng yêu cầu tối ưu trong một lần lặp là khoảng 8 nghìn với tính năng bỏ phiếu SNMP. Tổng cộng, việc chuyển sang chế độ không đồng bộ cho phép chúng tôi tăng tốc hiệu suất bỏ phiếu lên 200 lần, vài trăm lần.
MCH: – Kết quả tối ưu hóa bỏ phiếu cho thấy rằng chúng tôi không chỉ có thể loại bỏ tất cả các proxy mà còn giảm khoảng thời gian cho nhiều lần kiểm tra và proxy sẽ không còn cần thiết như một cách để chia sẻ tải nữa.
Khoảng ba tháng trước
Thay đổi kiến trúc - tăng tải!
MM: - Max, đã đến lúc làm việc hiệu quả chưa? Tôi cần một máy chủ mạnh mẽ và một kỹ sư giỏi.
MCH: - Được rồi, hãy lên kế hoạch thôi. Đã đến lúc phải di chuyển từ điểm chết 5 nghìn số liệu mỗi giây.
Buổi sáng sau khi nâng cấp
MCH: - Misha, chúng tôi đã tự cập nhật, nhưng đến sáng thì chúng tôi đã quay lại... Đoán xem chúng tôi đã đạt được tốc độ nào?
MM: – Tối đa 20 nghìn.
MCH: - Ừ, 25! Thật không may, chúng tôi đang ở đúng nơi chúng tôi bắt đầu.
MM: - Tại sao? Bạn đã chạy bất kỳ chẩn đoán nào chưa?
MCH: - Vâng, chắc chắn rồi! Ví dụ, đây là một chiếc áo thú vị:
MM: - Cung xem nao. Tôi thấy rằng chúng tôi đã thử một số lượng lớn các chủ đề bỏ phiếu:
Nhưng đồng thời họ không thể tái chế hệ thống dù chỉ một nửa:
Và hiệu suất tổng thể khá nhỏ, khoảng 4 nghìn số liệu mỗi giây:
Có gì khác?
MCH: – Có, dấu vết của một trong những người thăm dò ý kiến:
MM: – Ở đây bạn có thể thấy rõ quá trình polling đang chờ “semaphores”. Đây là các ổ khóa:
MCH: - Không rõ.
MM: – Hãy nhìn xem, điều này tương tự như tình huống trong đó một loạt các luồng đang cố gắng làm việc với các tài nguyên mà tại một thời điểm chỉ có một luồng có thể làm việc được. Sau đó, tất cả những gì họ có thể làm là chia sẻ tài nguyên này theo thời gian:
Và tổng hiệu suất làm việc với tài nguyên như vậy bị giới hạn bởi tốc độ của một lõi:
Có hai cách để giải quyết vấn đề này.
Nâng cấp phần cứng của máy, chuyển sang các lõi nhanh hơn:
Hoặc thay đổi kiến trúc và đồng thời thay đổi tải:
MCH: – Nhân tiện, trên máy thử nghiệm, chúng tôi sẽ sử dụng ít lõi hơn so với trên máy chiến đấu, nhưng chúng có tần số trên mỗi lõi nhanh hơn 1,5 lần!
MM: - Thông thoáng? Bạn cần nhìn vào mã máy chủ.
Đường dẫn dữ liệu trong máy chủ Zabbix
MCH: – Để tìm hiểu điều đó, chúng tôi bắt đầu phân tích cách truyền dữ liệu bên trong máy chủ Zabbix:
Hình ảnh tuyệt vời phải không? Chúng ta hãy đi qua từng bước một để làm cho nó rõ ràng hơn hoặc ít hơn. Có các chủ đề và dịch vụ chịu trách nhiệm thu thập dữ liệu:
Chúng truyền các số liệu đã thu thập qua một ổ cắm tới trình quản lý Tiền xử lý, nơi chúng được lưu trong hàng đợi:
“Trình quản lý tiền xử lý” truyền dữ liệu đến các nhân viên của nó, thực hiện các hướng dẫn tiền xử lý và trả lại chúng qua cùng một ổ cắm:
Sau đó, trình quản lý tiền xử lý sẽ lưu chúng vào bộ đệm lịch sử:
Từ đó, chúng được thực hiện bởi những người đánh chìm lịch sử, những người thực hiện khá nhiều chức năng: ví dụ: tính toán trình kích hoạt, điền vào bộ nhớ đệm giá trị và quan trọng nhất là lưu số liệu vào bộ lưu trữ lịch sử. Nói chung, quá trình này phức tạp và rất khó hiểu.
MM: – Điều đầu tiên chúng tôi thấy là hầu hết các luồng đều cạnh tranh để giành lấy cái gọi là “bộ đệm cấu hình” (vùng bộ nhớ nơi lưu trữ tất cả các cấu hình máy chủ). Các chủ đề chịu trách nhiệm thu thập dữ liệu đặc biệt bị chặn rất nhiều:
...vì cấu hình không chỉ lưu trữ số liệu với các tham số của chúng mà còn lưu trữ hàng đợi từ đó người thăm dò lấy thông tin về những việc cần làm tiếp theo. Khi có nhiều người thăm dò và một người chặn cấu hình, những người khác sẽ chờ yêu cầu:
Người thăm dò ý kiến không nên xung đột
Do đó, điều đầu tiên chúng tôi làm là chia hàng đợi thành 4 phần và cho phép người bỏ phiếu chặn những hàng đợi này, những phần này cùng lúc, trong điều kiện an toàn:
Điều này loại bỏ sự cạnh tranh về bộ đệm cấu hình và tốc độ của người thăm dò tăng lên đáng kể. Nhưng sau đó chúng tôi nhận thấy thực tế là trình quản lý tiền xử lý bắt đầu tích lũy một hàng công việc:
Người quản lý tiền xử lý phải có khả năng ưu tiên
Điều này xảy ra trong những trường hợp anh ấy thiếu hiệu suất. Sau đó, tất cả những gì anh có thể làm là tích lũy các yêu cầu từ quá trình thu thập dữ liệu và thêm bộ đệm của chúng cho đến khi nó tiêu tốn hết bộ nhớ và bị hỏng:
Để giải quyết vấn đề này, chúng tôi đã thêm một ổ cắm thứ hai dành riêng cho công nhân:
Do đó, trình quản lý tiền xử lý có cơ hội ưu tiên công việc của mình và nếu bộ đệm tăng lên, nhiệm vụ là làm chậm quá trình loại bỏ, tạo cơ hội cho công nhân lấy bộ đệm này:
Sau đó, chúng tôi phát hiện ra rằng một trong những nguyên nhân dẫn đến sự chậm lại là do bản thân người lao động, vì họ đang cạnh tranh để giành lấy một nguồn lực hoàn toàn không quan trọng đối với công việc của họ. Chúng tôi đã ghi lại vấn đề này dưới dạng sửa lỗi và nó đã được giải quyết trong các phiên bản mới của Zabbix:
Chúng tôi tăng số lượng ổ cắm - chúng tôi nhận được kết quả
Hơn nữa, bản thân trình quản lý tiền xử lý đã trở thành một nút cổ chai vì nó là một luồng. Nó dựa trên tốc độ cốt lõi, cho tốc độ tối đa khoảng 70 nghìn số liệu mỗi giây:
Do đó, chúng tôi đã tạo ra bốn bộ ổ cắm, công nhân:
Và điều này cho phép chúng tôi tăng tốc độ lên khoảng 130 nghìn số liệu:
Sự tăng trưởng phi tuyến tính được giải thích là do sự cạnh tranh giành bộ nhớ đệm lịch sử đã xuất hiện. 4 nhà quản lý tiền xử lý và người ghi lịch sử đã cạnh tranh để giành được nó. Tại thời điểm này, chúng tôi đã nhận được khoảng 130 nghìn số liệu mỗi giây trên máy thử nghiệm, sử dụng khoảng 95% số liệu đó trong bộ xử lý:
Khoảng 2,5 tháng trước
Sự từ chối từ cộng đồng snmp đã tăng NVP lên gấp rưỡi
MM: – Max, tôi cần một chiếc xe thử nghiệm mới! Chúng ta không còn phù hợp với hiện tại nữa.
MCH: - Những gì bạn có bây giờ?
MM: – Hiện tại – 130 nghìn NVP và bộ xử lý sẵn sàng sử dụng.
MCH: - Ồ! Mát mẻ! Đợi đã, tôi có hai câu hỏi. Theo tính toán của tôi, nhu cầu của chúng tôi là khoảng 15-20 nghìn số liệu mỗi giây. Tại sao chúng ta cần nhiều hơn?
MM: “Tôi muốn hoàn thành công việc.” Tôi muốn xem chúng ta có thể khai thác được bao nhiêu từ hệ thống này.
MCH: - Nhưng…
MM: “Nhưng nó vô dụng cho việc kinh doanh.”
MCH: - Rõ ràng. Và câu hỏi thứ hai: liệu chúng ta có thể tự mình hỗ trợ những gì chúng ta có mà không cần sự trợ giúp của nhà phát triển không?
MM: - Tôi không nghĩ vậy. Việc thay đổi cách hoạt động của bộ đệm cấu hình là một vấn đề. Nó ảnh hưởng đến những thay đổi trong hầu hết các luồng và khá khó bảo trì. Rất có thể, sẽ rất khó để duy trì nó.
MCH: “Vậy thì chúng ta cần một số phương án thay thế.”
MM: - Có một lựa chọn như vậy. Chúng ta có thể chuyển sang lõi nhanh trong khi từ bỏ hệ thống khóa mới. Chúng tôi vẫn sẽ đạt được hiệu suất 60-80 nghìn số liệu. Đồng thời, chúng ta có thể để lại tất cả phần còn lại của mã. Clickhouse và bỏ phiếu không đồng bộ sẽ hoạt động. Và nó sẽ dễ dàng để duy trì.
MCH: - Tuyệt vời! Tôi đề nghị chúng ta dừng lại ở đây.
Sau khi tối ưu hóa phía máy chủ, cuối cùng chúng tôi cũng có thể đưa mã mới vào sản xuất. Chúng tôi đã bỏ một số thay đổi để chuyển sang sử dụng máy có lõi nhanh và giảm thiểu số lần thay đổi mã. Chúng tôi cũng đã đơn giản hóa cấu hình và loại bỏ macro trong các mục dữ liệu nếu có thể vì chúng giới thiệu tính năng khóa bổ sung.
Ví dụ: việc loại bỏ macro cộng đồng snmp, thường thấy trong tài liệu và ví dụ, trong trường hợp của chúng tôi có thể tăng tốc NVP thêm khoảng 1,5 lần.
Sau hai ngày sản xuất
Xóa cửa sổ bật lên lịch sử sự cố
MCH: – Misha, chúng tôi đã sử dụng hệ thống được hai ngày và mọi thứ đều hoạt động. Nhưng chỉ khi mọi thứ hoạt động! Chúng tôi đã lên kế hoạch làm việc với việc chuyển một phân đoạn khá lớn của mạng và chúng tôi lại tự tay kiểm tra xem điều gì đã tăng và điều gì không.
MM: - Không thể được! Chúng tôi đã kiểm tra mọi thứ 10 lần. Máy chủ xử lý ngay cả tình trạng không có mạng hoàn toàn ngay lập tức.
MCH: - Có, tôi hiểu mọi thứ: máy chủ, cơ sở dữ liệu, top, austat, nhật ký - mọi thứ đều nhanh... Nhưng chúng tôi nhìn vào giao diện web và có một bộ xử lý “trên kệ” trên máy chủ và điều này:
MM: - Rõ ràng. Hãy cùng xem web. Chúng tôi nhận thấy rằng trong tình huống có nhiều sự cố đang diễn ra, hầu hết các tiện ích trực tiếp bắt đầu hoạt động rất chậm:
Lý do cho điều này là việc tạo ra các cửa sổ bật lên về lịch sử sự cố được tạo cho từng mục trong danh sách. Do đó, chúng tôi đã từ bỏ việc tạo các cửa sổ này (đã nhận xét 5 dòng trong mã) và điều này đã giải quyết được vấn đề của chúng tôi.
Thời gian tải các tiện ích, ngay cả khi hoàn toàn không khả dụng, đã giảm từ vài phút xuống còn 10-15 giây có thể chấp nhận được đối với chúng tôi và vẫn có thể xem lịch sử bằng cách nhấp vào thời gian:
Sau giờ làm việc. 2 tháng trước
MCH: - Misha, em đi à? Chúng ta phải nói chuyện.
MM: - Tôi không có ý định đó. Lại có chuyện gì với Zabbix à?
MCH: - Không, thư giãn đi! Tôi chỉ muốn nói: mọi thứ đều ổn, cảm ơn bạn! Tôi có một cốc bia.
Zabbix hiệu quả
Zabbix là một hệ thống và chức năng khá phổ biến và phong phú. Nó có thể được sử dụng cho các cài đặt nhỏ ngay lập tức, nhưng khi nhu cầu tăng lên, nó phải được tối ưu hóa. Để lưu trữ một kho lưu trữ lớn các số liệu, hãy sử dụng bộ lưu trữ phù hợp:
- bạn có thể sử dụng các công cụ tích hợp sẵn dưới dạng tích hợp với Elasticsearch hoặc tải lịch sử lên file văn bản (có sẵn từ phiên bản 4);
- Bạn có thể tận dụng kinh nghiệm và sự tích hợp của chúng tôi với Clickhouse.
Để tăng đáng kể tốc độ thu thập số liệu, hãy thu thập chúng bằng các phương pháp không đồng bộ và truyền chúng qua giao diện trapper đến máy chủ Zabbix; hoặc bạn có thể sử dụng bản vá để làm cho trình thăm dò Zabbix không đồng bộ.
Zabbix được viết bằng C và khá hiệu quả. Việc giải quyết một số tắc nghẽn về kiến trúc cho phép bạn tăng thêm hiệu suất của nó và theo kinh nghiệm của chúng tôi, bạn có thể thu được hơn 100 nghìn số liệu trên một máy xử lý đơn.
Bản vá Zabbix tương tự
MM: – Tôi muốn thêm một vài điểm. Toàn bộ báo cáo hiện tại, tất cả các bài kiểm tra, con số đều được đưa ra cho cấu hình mà chúng tôi sử dụng. Chúng tôi hiện đang lấy khoảng 20 nghìn số liệu mỗi giây từ nó. Nếu bạn đang cố gắng hiểu liệu điều này có hiệu quả với mình hay không, bạn có thể so sánh. Những gì được thảo luận hôm nay được đăng trên GitHub dưới dạng một bản vá:
Bản vá bao gồm:
- tích hợp hoàn toàn với Clickhouse (cả máy chủ Zabbix và giao diện người dùng);
- giải quyết vấn đề với trình quản lý tiền xử lý;
- bỏ phiếu không đồng bộ.
Bản vá tương thích với tất cả phiên bản 4, bao gồm cả lts. Rất có thể, với những thay đổi tối thiểu, nó sẽ hoạt động trên phiên bản 3.4.
Cảm ơn bạn đã quan tâm của bạn.
câu hỏi
Câu hỏi của khán giả (sau đây gọi là – A): – Chào buổi chiều! Vui lòng cho tôi biết, bạn có kế hoạch tương tác chuyên sâu với nhóm Zabbix hay với họ với bạn, để đây không phải là một bản vá mà là hành vi bình thường của Zabbix?
MM: – Có, chúng tôi chắc chắn sẽ cam kết một số thay đổi. Điều gì đó sẽ xảy ra, điều gì đó sẽ vẫn còn trong bản vá.
A: - Cảm ơn bạn rất nhiều vì báo cáo xuất sắc! Xin vui lòng cho tôi biết, sau khi áp dụng bản vá, hỗ trợ từ Zabbix sẽ vẫn còn và làm cách nào để tiếp tục cập nhật lên các phiên bản cao hơn? Có thể cập nhật Zabbix sau bản vá của bạn lên 4.2, 5.0 không?
MM: – Tôi không thể nói bất cứ điều gì về hỗ trợ. Nếu tôi là người hỗ trợ kỹ thuật của Zabbix, có lẽ tôi sẽ nói không, vì đây là mã của người khác. Đối với cơ sở mã 4.2, quan điểm của chúng tôi là: “Chúng tôi sẽ di chuyển theo thời gian và chúng tôi sẽ tự cập nhật phiên bản tiếp theo”. Do đó, trong một thời gian, chúng tôi sẽ đăng bản vá cho các phiên bản cập nhật. Tôi đã nói trong báo cáo rồi: số lượng thay đổi với các phiên bản vẫn còn khá ít. Tôi nghĩ quá trình chuyển đổi từ 3.4 sang 4 mất khoảng 15 phút. Có gì đó đã thay đổi ở đó, nhưng không quan trọng lắm.
A: – Vậy bạn dự định hỗ trợ bản vá của mình và bạn có thể cài đặt nó một cách an toàn trong quá trình sản xuất cũng như nhận các bản cập nhật theo cách nào đó trong tương lai?
MM: – Chúng tôi thực sự khuyên bạn nên làm điều đó. Điều này giải quyết được rất nhiều vấn đề cho chúng tôi.
MCH: – Một lần nữa, tôi muốn thu hút sự chú ý đến thực tế là những thay đổi không liên quan đến kiến trúc và không liên quan đến việc chặn hoặc hàng đợi đều có tính mô-đun, chúng nằm trong các mô-đun riêng biệt. Ngay cả với những thay đổi nhỏ, bạn có thể duy trì chúng khá dễ dàng.
MM: – Nếu bạn quan tâm đến chi tiết, thì “Clickhouse” sử dụng cái gọi là thư viện lịch sử. Nó được cởi trói - nó là bản sao của hỗ trợ Elastics, nghĩa là nó có thể cấu hình được. Bỏ phiếu chỉ thay đổi người thăm dò. Chúng tôi tin rằng điều này sẽ có tác dụng lâu dài.
A: - Cảm ơn rất nhiều. Hãy cho tôi biết, có tài liệu nào về những thay đổi được thực hiện không?
MM: – Tài liệu là một bản vá. Rõ ràng, với sự ra đời của Clickhouse, với sự ra đời của các loại công cụ thăm dò mới, các tùy chọn cấu hình mới sẽ xuất hiện. Liên kết từ slide cuối cùng có mô tả ngắn gọn về cách sử dụng nó.
Về việc thay thế fping bằng nmap
A: – Cuối cùng bạn đã thực hiện điều này như thế nào? Bạn có thể đưa ra ví dụ cụ thể: bạn có trình duyệt và tập lệnh bên ngoài không? Điều gì dẫn đến việc kiểm tra một số lượng lớn các máy chủ một cách nhanh chóng như vậy? Làm thế nào để bạn khai thác các máy chủ này? Chúng ta có cần đưa chúng vào nmap bằng cách nào đó, lấy chúng từ đâu đó, đưa chúng vào, chạy thứ gì đó không?..
MM: - Mát mẻ. Một câu hỏi rất đúng! Vấn đề là thế này. Chúng tôi đã sửa đổi thư viện (ping ICMP, một phần của Zabbix) để kiểm tra ICMP, cho biết số lượng gói - một (1) và mã cố gắng sử dụng nmap. Tức là đây là công việc nội bộ của Zabbix, đã trở thành công việc nội bộ của pinger. Theo đó, không cần phải đồng bộ hóa hoặc sử dụng máy bẫy. Điều này được thực hiện có chủ ý để giữ nguyên hệ thống và không phải đối mặt với việc đồng bộ hóa hai hệ thống cơ sở dữ liệu: cần kiểm tra những gì, tải lên thông qua công cụ thăm dò và quá trình tải lên của chúng tôi có bị hỏng không?.. Điều này đơn giản hơn nhiều.
A: – Nó có hoạt động với proxy không?
MM: – Có, nhưng chúng tôi không kiểm tra. Mã bỏ phiếu giống nhau ở cả Zabbix và máy chủ. Nên làm việc. Hãy để tôi nhấn mạnh một lần nữa: hiệu suất của hệ thống đến mức chúng tôi không cần proxy.
MCH: – Câu trả lời đúng cho câu hỏi là: “Tại sao bạn cần proxy với hệ thống như vậy?” Chỉ vì NAT hoặc giám sát thông qua một loại kênh chậm nào đó...
A: – Và bạn sử dụng Zabbix như một kẻ gây dị ứng, nếu tôi hiểu chính xác. Hoặc đồ họa của bạn (nơi chứa lớp lưu trữ) được chuyển sang hệ thống khác, chẳng hạn như Grafana? Hay bạn không sử dụng chức năng này?
MM: – Tôi sẽ nhấn mạnh một lần nữa: chúng ta đã đạt được sự hội nhập hoàn toàn. Chúng tôi đang đưa lịch sử vào Clickhouse, nhưng đồng thời chúng tôi đã thay đổi giao diện người dùng php. Giao diện người dùng Php đi đến Clickhouse và thực hiện tất cả đồ họa từ đó. Đồng thời, thành thật mà nói, chúng tôi có bộ phận xây dựng dữ liệu trong các hệ thống hiển thị đồ họa khác từ cùng một Clickhouse, từ cùng một dữ liệu Zabbix.
MCH: – Trong “Grafan” cũng vậy.
Các quyết định được đưa ra về việc phân bổ nguồn lực như thế nào?
A: – Chia sẻ một chút về căn bếp bên trong của bạn. Làm thế nào mà quyết định được đưa ra là cần thiết phải phân bổ nguồn lực để xử lý sản phẩm một cách nghiêm túc? Nhìn chung, đây là những rủi ro nhất định. Và xin vui lòng cho tôi biết, trong bối cảnh bạn sắp hỗ trợ các phiên bản mới: quyết định này biện minh như thế nào từ quan điểm quản lý?
MM: – Rõ ràng là chúng ta đã kể không hay lắm về vở kịch lịch sử. Chúng tôi thấy mình đang ở trong một tình huống cần phải làm gì đó và về cơ bản chúng tôi đã làm việc với hai nhóm song song:
- Một là ra mắt hệ thống giám sát bằng các phương pháp mới: giám sát dưới dạng dịch vụ, một bộ giải pháp nguồn mở tiêu chuẩn mà chúng tôi kết hợp và sau đó cố gắng thay đổi quy trình kinh doanh để hoạt động với hệ thống giám sát mới.
- Đồng thời, chúng tôi có một lập trình viên nhiệt tình đang làm việc này (về bản thân anh ấy). Chuyện xảy ra là anh ấy đã thắng.
A: – Và quy mô của đội là bao nhiêu?
MCH: - Cô ấy đang ở trước mặt anh.
A: – Vậy thì, như mọi khi, bạn cần một người đam mê?
MM: – Tôi không biết đam mê là gì.
A: - Trong trường hợp này, rõ ràng là bạn. Cảm ơn bạn rất nhiều, bạn thật tuyệt vời.
MM: - Cảm ơn.
Giới thiệu về các bản vá cho Zabbix
A: – Đối với một hệ thống sử dụng proxy (ví dụ: trong một số hệ thống phân tán), liệu có thể điều chỉnh và vá lỗi, chẳng hạn như các trình thăm dò, proxy và một phần bộ tiền xử lý của chính Zabbix; và sự tương tác của chúng? Có thể tối ưu hóa sự phát triển hiện có cho một hệ thống có nhiều proxy không?
MM: – Tôi biết rằng máy chủ Zabbix được lắp ráp bằng proxy (mã được biên dịch và lấy được). Chúng tôi chưa thử nghiệm điều này trong sản xuất. Tôi không chắc về điều này nhưng tôi nghĩ trình quản lý tiền xử lý không được sử dụng trong proxy. Nhiệm vụ của proxy là lấy một bộ số liệu từ Zabbix, hợp nhất chúng (nó cũng ghi lại cấu hình, cơ sở dữ liệu cục bộ) và gửi lại cho máy chủ Zabbix. Sau đó, chính máy chủ sẽ thực hiện quá trình tiền xử lý khi nhận được nó.
Sự quan tâm đến proxy là điều dễ hiểu. Chúng tôi sẽ kiểm tra nó. Đây là một chủ đề thú vị.
A: – Ý tưởng là thế này: nếu bạn có thể vá các bộ thăm dò, bạn có thể vá chúng trên proxy và vá tương tác với máy chủ, đồng thời chỉ điều chỉnh bộ tiền xử lý cho những mục đích này trên máy chủ.
MM: – Tôi nghĩ nó còn đơn giản hơn nữa. Bạn lấy mã, áp dụng bản vá, sau đó định cấu hình mã theo cách bạn cần - thu thập máy chủ proxy (ví dụ: với ODBC) và phân phối mã đã vá trên các hệ thống. Khi cần thiết - thu thập proxy, khi cần thiết - máy chủ.
A: – Rất có thể, bạn sẽ không phải vá thêm đường truyền proxy đến máy chủ?
MCH: - Không, đó là tiêu chuẩn.
MM: – Trên thực tế, một trong những ý tưởng đó không thành công. Chúng tôi luôn duy trì sự cân bằng giữa sự bùng nổ của ý tưởng với số lượng thay đổi cũng như sự dễ dàng hỗ trợ.
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com