16 modem, 4 nhà khai thác mạng di động = Tốc độ gửi đi 933.45 Mbit/s
Giới thiệu
Xin chào! Bài viết này nói về cách chúng tôi viết một hệ thống giám sát mới cho chính mình. Nó khác với những cái hiện có ở khả năng thu được các số liệu đồng bộ tần số cao và mức tiêu thụ tài nguyên rất thấp. Tốc độ bỏ phiếu có thể đạt 0.1 mili giây với độ chính xác đồng bộ hóa giữa các số liệu là 10 nano giây. Tất cả các tệp nhị phân chiếm 6 megabyte.
Về dự án
Chúng tôi có một sản phẩm khá cụ thể. Chúng tôi tạo ra một giải pháp toàn diện để tóm tắt thông lượng và khả năng chịu lỗi của các kênh truyền dữ liệu. Đây là khi có một số kênh, giả sử Toán tử1 (40Mbit/s) + Toán tử2 (30Mbit/s)+ Cái gì khác (5 Mbit/s), kết quả là một kênh ổn định và nhanh, tốc độ của kênh này sẽ giống như cái này: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Những giải pháp như vậy đang có nhu cầu khi dung lượng của bất kỳ kênh nào không đủ. Ví dụ: giao thông, hệ thống giám sát video và truyền phát video thời gian thực, phát sóng truyền hình và đài phát thanh trực tiếp, bất kỳ cơ sở ngoại ô nào mà trong số các nhà khai thác viễn thông chỉ có đại diện của Big Four và tốc độ trên một modem/kênh là không đủ .
Đối với mỗi lĩnh vực này, chúng tôi sản xuất một dòng thiết bị riêng biệt, nhưng phần phần mềm của chúng gần như giống nhau và hệ thống giám sát chất lượng cao là một trong những mô-đun chính của nó, nếu không triển khai chính xác thì sản phẩm sẽ không thể thực hiện được.
Trong vài năm, chúng tôi đã cố gắng tạo ra một hệ thống giám sát đa cấp, nhanh, đa nền tảng và nhẹ. Đây là những gì chúng tôi muốn chia sẻ với cộng đồng đáng kính của chúng tôi.
Báo cáo sự cố
Hệ thống giám sát cung cấp số liệu của hai loại cơ bản khác nhau: số liệu thời gian thực và tất cả các loại khác. Hệ thống giám sát chỉ có các yêu cầu sau:
- Thu thập đồng bộ tần số cao các số liệu thời gian thực và chuyển chúng sang hệ thống quản lý truyền thông mà không bị chậm trễ.
Tần số cao và sự đồng bộ hóa của các số liệu khác nhau không chỉ quan trọng mà còn quan trọng trong việc phân tích entropy của các kênh truyền dữ liệu. Nếu trong một kênh truyền dữ liệu có độ trễ trung bình là 30 mili giây thì lỗi đồng bộ hóa giữa các số liệu còn lại chỉ một mili giây sẽ dẫn đến giảm tốc độ của kênh kết quả khoảng 5%. Nếu chúng ta tính sai thời gian 1 mili giây trên 4 kênh, tốc độ suy giảm có thể dễ dàng giảm xuống 30%. Ngoài ra, entropy trong các kênh thay đổi rất nhanh, vì vậy nếu chúng ta đo nó ít hơn 0.5 mili giây một lần, trên các kênh nhanh có độ trễ nhỏ, chúng ta sẽ bị suy giảm tốc độ cao. Tất nhiên, độ chính xác như vậy không cần thiết cho tất cả các số liệu và không phải trong mọi điều kiện. Khi độ trễ trong kênh là 500 mili giây và chúng tôi làm việc với điều đó, thì sai số 1 mili giây sẽ gần như không đáng chú ý. Ngoài ra, đối với các chỉ số của hệ thống hỗ trợ sự sống, chúng tôi có đủ tốc độ thăm dò và đồng bộ hóa là 2 giây, nhưng bản thân hệ thống giám sát phải có khả năng hoạt động với tốc độ thăm dò cực cao và đồng bộ hóa các chỉ số cực kỳ chính xác. - Tiêu thụ tài nguyên tối thiểu và một ngăn xếp duy nhất.
Thiết bị cuối có thể là một tổ hợp mạnh mẽ trên xe có thể phân tích tình hình trên đường hoặc tiến hành ghi lại sinh trắc học của con người hoặc một máy tính bảng đơn cỡ lòng bàn tay mà một người lính lực lượng đặc biệt mặc dưới áo giáp để truyền video vào. thời gian thực trong điều kiện truyền thông kém. Mặc dù có nhiều kiến trúc và sức mạnh tính toán như vậy nhưng chúng tôi vẫn muốn có cùng một bộ phần mềm. - Kiến trúc ô dù
Các số liệu phải được thu thập và tổng hợp trên thiết bị cuối, được lưu trữ cục bộ và được hiển thị theo thời gian thực và hồi cứu. Nếu có kết nối, truyền dữ liệu về hệ thống giám sát trung tâm. Khi không có kết nối, hàng đợi gửi sẽ tích lũy và không tiêu tốn RAM. - API để tích hợp vào hệ thống giám sát của khách hàng, vì không ai cần nhiều hệ thống giám sát. Khách hàng phải thu thập dữ liệu từ mọi thiết bị và mạng vào một giám sát duy nhất.
Chuyện gì đã xảy ra thế
Để không tạo gánh nặng cho bài đọc dài vốn đã rất ấn tượng, tôi sẽ không đưa ra ví dụ và số đo của tất cả các hệ thống giám sát. Điều này sẽ dẫn đến một bài viết khác. Tôi chỉ nói rằng chúng tôi không thể tìm thấy hệ thống giám sát có khả năng thực hiện đồng thời hai số liệu với sai số dưới 1 mili giây và hoạt động hiệu quả như nhau trên cả kiến trúc ARM với 64 MB RAM và trên kiến trúc x86_64 với 32 GB RAM. Vì vậy, chúng tôi quyết định tự viết, thứ có thể làm được tất cả những điều này. Đây là những gì chúng tôi có:
Tóm tắt thông lượng của ba kênh cho các cấu trúc liên kết mạng khác nhau
Trực quan hóa một số số liệu chính
kiến trúc
Chúng tôi sử dụng Golang làm ngôn ngữ lập trình chính, cả trên thiết bị và trung tâm dữ liệu. Nó đơn giản hóa đáng kể cuộc sống nhờ khả năng triển khai đa nhiệm và khả năng lấy một tệp nhị phân thực thi được liên kết tĩnh cho mỗi dịch vụ. Do đó, chúng tôi tiết kiệm đáng kể tài nguyên, phương pháp và lưu lượng để triển khai dịch vụ đến thiết bị cuối, thời gian phát triển và gỡ lỗi mã.
Hệ thống này được triển khai theo nguyên tắc mô-đun cổ điển và bao gồm một số hệ thống con:
- Đăng ký số liệu.
Mỗi số liệu được phân phát theo luồng riêng và được đồng bộ hóa trên các kênh. Chúng tôi có thể đạt được độ chính xác đồng bộ hóa lên tới 10 nano giây. - Lưu trữ số liệu
Chúng tôi đang lựa chọn giữa việc ghi bộ nhớ của riêng mình cho chuỗi thời gian hoặc sử dụng thứ gì đó đã có sẵn. Cơ sở dữ liệu cần thiết cho dữ liệu hồi cứu có thể hiển thị tiếp theo. Nghĩa là, nó không chứa dữ liệu về độ trễ trong kênh cứ sau 0.5 mili giây hoặc đọc lỗi trong mạng truyền tải, nhưng có tốc độ trên mỗi giao diện cứ sau 500 mili giây. Ngoài các yêu cầu cao về đa nền tảng và mức tiêu thụ tài nguyên thấp, điều cực kỳ quan trọng đối với chúng tôi là khả năng xử lý. dữ liệu là nơi nó được lưu trữ. Điều này tiết kiệm tài nguyên máy tính khổng lồ. Chúng tôi đã sử dụng Tarantool DBMS trong dự án này từ năm 2016 và cho đến nay chúng tôi chưa thấy có giải pháp thay thế nó. Linh hoạt, tiêu thụ tài nguyên tối ưu, hỗ trợ kỹ thuật đầy đủ. Tarantool cũng triển khai một mô-đun GIS. Tất nhiên, nó không mạnh bằng PostGIS, nhưng nó đủ cho nhiệm vụ của chúng tôi là lưu trữ một số số liệu liên quan đến vị trí (có liên quan đến vận chuyển). - Trực quan hóa các số liệu
Mọi thứ ở đây tương đối đơn giản. Chúng tôi lấy dữ liệu từ kho và hiển thị dữ liệu theo thời gian thực hoặc hồi cứu. - Đồng bộ dữ liệu với hệ thống giám sát trung tâm.
Hệ thống giám sát trung tâm nhận dữ liệu từ tất cả các thiết bị, lưu trữ dữ liệu với lịch sử cụ thể và gửi đến hệ thống giám sát của Khách hàng thông qua API. Không giống như các hệ thống giám sát cổ điển, trong đó “người đứng đầu” đi xung quanh và thu thập dữ liệu, chúng tôi có sơ đồ ngược lại. Các thiết bị tự gửi dữ liệu khi có kết nối. Đây là một điểm rất quan trọng vì nó cho phép bạn nhận dữ liệu từ thiết bị trong những khoảng thời gian không có sẵn và không tải các kênh cũng như tài nguyên khi thiết bị không khả dụng. Chúng tôi sử dụng máy chủ giám sát Influx làm hệ thống giám sát trung tâm. Không giống như các tính năng tương tự, nó có thể nhập dữ liệu hồi cứu (nghĩa là có dấu thời gian khác với thời điểm nhận được số liệu). Các số liệu đã thu thập được Grafana trực quan hóa, được sửa đổi bằng một tệp. Ngăn xếp tiêu chuẩn này cũng được chọn vì nó có tích hợp API sẵn có với hầu hết mọi hệ thống giám sát khách hàng. - Đồng bộ hóa dữ liệu với hệ thống quản lý thiết bị trung tâm.
Hệ thống quản lý thiết bị triển khai Cung cấp cảm ứng không (cập nhật chương trình cơ sở, cấu hình, v.v.) và không giống như hệ thống giám sát, chỉ nhận được sự cố trên mỗi thiết bị. Đây là những yếu tố kích hoạt hoạt động của các dịch vụ giám sát phần cứng trên bo mạch và tất cả các số liệu của hệ thống hỗ trợ sự sống: nhiệt độ CPU và SSD, tải CPU, dung lượng trống và tình trạng SMART trên đĩa. Bộ lưu trữ hệ thống con cũng được xây dựng trên Tarantool. Điều này mang lại cho chúng tôi tốc độ đáng kể trong việc tổng hợp chuỗi thời gian trên hàng nghìn thiết bị và cũng giải quyết hoàn toàn vấn đề đồng bộ hóa dữ liệu với các thiết bị này. Tarantool có hệ thống phân phối đảm bảo và xếp hàng tuyệt vời. Chúng tôi đã có tính năng quan trọng này ngay lập tức, thật tuyệt!
Hệ thống quản lý mạng
những gì tiếp theo
Cho đến nay, mắt xích yếu nhất của chúng ta là hệ thống giám sát trung tâm. Nó được triển khai 99.9% trên ngăn xếp tiêu chuẩn và có một số nhược điểm:
- InfluxDB mất dữ liệu khi mất điện. Theo quy định, Khách hàng sẽ nhanh chóng thu thập mọi thứ đến từ thiết bị và bản thân cơ sở dữ liệu không chứa dữ liệu cũ hơn 5 phút, nhưng trong tương lai, điều này có thể trở thành một vấn đề khó khăn.
- Grafana gặp một số vấn đề với việc tổng hợp dữ liệu và đồng bộ hóa màn hình của nó. Vấn đề phổ biến nhất là khi cơ sở dữ liệu chứa chuỗi thời gian có khoảng thời gian là 2 giây bắt đầu từ 00:00:00 và Grafana bắt đầu hiển thị dữ liệu tổng hợp từ +1 giây. Kết quả là người dùng nhìn thấy một biểu đồ nhảy múa.
- Quá nhiều mã để tích hợp API với hệ thống giám sát của bên thứ ba. Nó có thể được làm nhỏ gọn hơn nhiều và tất nhiên được viết lại bằng Go)
Tôi nghĩ tất cả các bạn đều đã thấy Grafana trông như thế nào và biết vấn đề của nó mà không cần có tôi, vì vậy tôi sẽ không đăng quá nhiều hình ảnh trong bài đăng.
Kết luận
Tôi cố tình không mô tả chi tiết kỹ thuật mà chỉ mô tả thiết kế cơ bản của hệ thống này. Đầu tiên, để mô tả đầy đủ về mặt kỹ thuật hệ thống, sẽ cần phải có một bài viết khác. Thứ hai, không phải ai cũng quan tâm đến điều này. Viết trong phần bình luận những chi tiết kỹ thuật mà bạn muốn biết.
Nếu ai có câu hỏi ngoài phạm vi của bài viết này, bạn có thể viết thư cho tôi theo địa chỉ [email protected]
Nguồn: www.habr.com