Mọi người đều thích cảnh báo.
Tất nhiên, sẽ tốt hơn nhiều nếu được thông báo khi có điều gì đó xảy ra (hoặc đã được khắc phục) hơn là ngồi nhìn vào biểu đồ và tìm kiếm những điều bất thường.
Và nhiều công cụ đã được tạo ra cho việc này. Alertmanager từ hệ sinh thái Prometheus và vmalert từ nhóm sản phẩm VictoriaMetrics. Thông báo và cảnh báo Zabbix trong Grafana. Các tập lệnh tự viết trong bot bash và Telegram định kỳ lấy một số URL và cho bạn biết nếu có điều gì sai. Rất nhiều thứ.
Trong công ty của mình, chúng tôi cũng đã sử dụng các giải pháp khác nhau cho đến khi gặp phải sự phức tạp, hay nói đúng hơn là không thể tạo các cảnh báo tổng hợp, phức tạp. Những gì chúng tôi muốn và những gì chúng tôi đã làm đều nằm dưới mức cắt giảm. TLDR: Đây là cách dự án nguồn mở xuất hiện
Trong một thời gian khá dài, chúng tôi đã sống tốt với các cảnh báo được định cấu hình trong Grafana. Vâng, đây không phải là cách tốt nhất. Chúng tôi luôn khuyến nghị sử dụng một số giải pháp chuyên dụng, chẳng hạn như Alertmanager. Và chúng tôi cũng đã nhiều lần hướng tới việc di chuyển. Và rồi dần dần, chúng tôi muốn nhiều hơn nữa.
Giả sử khi một biểu đồ nhất định giảm/tăng XX% và ở đó được N phút so với khoảng thời gian M giờ trước đó? Có vẻ như bạn có thể thử triển khai điều này bằng Grafana hoặc Alertmanager, nhưng việc này không hoàn toàn dễ dàng. (Hoặc có thể là không thể, bây giờ tôi sẽ không nói)
Mọi chuyện càng trở nên phức tạp hơn khi quyết định cảnh báo phải được đưa ra dựa trên dữ liệu từ nhiều nguồn khác nhau. Ví dụ trực tiếp:
Chúng tôi kiểm tra dữ liệu từ hai cơ sở dữ liệu Clickhouse, sau đó so sánh dữ liệu đó với một số dữ liệu từ Postgres và quyết định cảnh báo. Tín hiệu hoặc hủy bỏ
Chúng tôi đã tích lũy khá nhiều mong muốn giống nhau để chúng tôi suy nghĩ về quyết định của mình. Và sau đó chúng tôi đã cố gắng biên soạn danh sách các yêu cầu/khả năng đầu tiên của dịch vụ này, danh sách này vẫn chưa được tạo.
-
truy cập các nguồn dữ liệu khác nhau. Ví dụ: Prometheus, Clickhouse, Postgres
-
gửi thông báo đến nhiều kênh khác nhau - telegram, Slack, v.v.
-
Trong quá trình suy nghĩ, rõ ràng là tôi không muốn một mô tả mang tính khai báo mà là khả năng viết kịch bản
-
chạy tập lệnh theo lịch trình
-
dễ dàng cập nhật các tập lệnh mà không cần khởi động lại dịch vụ
-
khả năng bằng cách nào đó mở rộng chức năng mà không cần xây dựng lại dịch vụ từ mã nguồn
Danh sách này là gần đúng và rất có thể không chính xác lắm. Một số điểm thay đổi, một số đã chết. Mọi thứ vẫn như thường lệ.
Trên thực tế, đây là cách lịch sử của Balerter bắt đầu.
Tôi sẽ cố gắng mô tả ngắn gọn điều gì đã xảy ra và cách thức hoạt động của nó. (Vâng, tất nhiên, đây chưa phải là kết thúc. Còn rất nhiều kế hoạch phát triển sản phẩm. Tôi sẽ chỉ dừng lại ở hôm nay)
Nó hoạt động như thế nào?
Bạn viết một tập lệnh bằng Lua nơi bạn gửi yêu cầu một cách rõ ràng (tới Prometheus, Clickhouse, v.v.). Bạn nhận được câu trả lời và bằng cách nào đó xử lý và so sánh chúng. Sau đó bật/tắt một số loại cảnh báo. Bản thân Balerter sẽ gửi thông báo đến các kênh mà bạn đã định cấu hình (Email, telegram, Slack, v.v.). Tập lệnh được thực thi theo các khoảng thời gian được chỉ định. Và... nói chung là vậy thôi)
Tốt nhất là hiển thị bằng một ví dụ:
-- @interval 10s
-- @name script1
local minRequestsRPS = 100
local log = require("log")
local ch1 = require("datasource.clickhouse.ch1")
local res, err = ch1.query("SELECT sum(requests) AS rps FROM some_table WHERE date = now()")
if err ~= nil then
log.error("clickhouse 'ch1' query error: " .. err)
return
end
local resultRPS = res[1].rps
if resultRPS < minResultRPS then
alert.error("rps-min-limit", "Requests RPS are very small: " .. tostring(resultRPS))
else
alert.success("rps-min-limit", "Requests RPS ok")
end Những gì đang xảy ra ở đây:
-
chúng tôi chỉ ra rằng tập lệnh này sẽ được thực thi cứ sau 10 giây
-
cho biết tên của tập lệnh (đối với API, để hiển thị trong nhật ký, để sử dụng trong các thử nghiệm)
-
kết nối mô-đun để xuất nhật ký
-
kết nối một mô-đun để truy cập clickhouse với tên
ch1(bản thân kết nối được cấu hình trong cấu hình) -
gửi yêu cầu tới clickhouse
-
trong trường hợp có lỗi, chúng tôi hiển thị thông báo trong nhật ký và thoát
-
so sánh kết quả truy vấn với một hằng số (trong ví dụ trực tiếp, chúng ta có thể lấy giá trị này, ví dụ: từ cơ sở dữ liệu Postgres)
-
bật hoặc tắt cảnh báo bằng ID
rps-min-limit -
bạn sẽ nhận được thông báo nếu trạng thái cảnh báo đã thay đổi
Ví dụ khá đơn giản và dễ hiểu. Tuy nhiên, tất nhiên, trong đời thực, kịch bản có thể khá dài và phức tạp. Rất dễ bị nhầm lẫn và mắc sai lầm.
Vì vậy, mong muốn hợp lý đã trưởng thành - có thể viết bài kiểm tra cho tập lệnh của bạn. Và trong phiên bản v0.4.0 điều này đã xuất hiện.
Kịch bản thử nghiệm
Kiểm tra ví dụ cho tập lệnh của chúng tôi từ ví dụ trên:
-- @test script1
-- @name script1-test
test = require('test')
local resp = {
{
rps = 10
}
}
test.datasource('clickhouse.ch1').on('query', 'SELECT sum(requests) AS rps FROM some_table WHERE date = now()').response(resp)
test.alert().assertCalled('error', 'rps-min-limit', 'Requests RPS are very small: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Requests RPS ok')Từng bước một:
-
cho biết tên của tập lệnh mà bài kiểm tra được viết
-
tên kiểm tra (đối với nhật ký)
-
kết nối mô-đun thử nghiệm
-
chúng tôi cho biết kết quả nào sẽ được trả lại cho một yêu cầu cụ thể tới clickhouse
ch1 -
chúng tôi kiểm tra xem cảnh báo (lỗi) rps-min-limit với thông báo được chỉ định đã được gọi chưa
-
kiểm tra xem cảnh báo giới hạn rps-min không bị tắt (thành công)
Balerter có thể làm gì khác?
Theo tôi, tôi sẽ cố gắng đề cập đến điều quan trọng nhất là kỹ năng của Balerter. Bạn có thể xem mọi thứ chi tiết trên trang web chính thức
-
nhận dữ liệu từ
-
nhà nhấp chuột
-
bưu điện
-
mysql
-
Prometheus
-
Loki
-
-
gửi thông báo tới các kênh
-
lún xuống
-
điện tín
-
syslog
-
thông báo (thông báo UI trên máy tính của bạn)
-
e-mail
-
bất hòa
-
-
xây dựng biểu đồ dựa trên dữ liệu của bạn, tải hình ảnh lên bộ lưu trữ tương thích S3 và đính kèm nó vào thông báo ()
-
cho phép bạn trao đổi dữ liệu giữa các tập lệnh - lưu trữ Khóa/Giá trị chung
-
viết thư viện của riêng bạn bằng Lua và sử dụng chúng trong tập lệnh (theo mặc định, thư viện lua được cung cấp để làm việc với json, csv)
-
gửi yêu cầu HTTP từ tập lệnh của bạn (và tất nhiên là nhận được phản hồi)
-
cung cấp API (chưa có chức năng như chúng tôi mong muốn)
-
xuất số liệu ở định dạng Prometheus
Bạn còn muốn có thể làm gì nữa?
Rõ ràng là người dùng và chúng tôi muốn có khả năng kiểm soát việc khởi chạy tập lệnh bằng cú pháp cron. Việc này sẽ được thực hiện trước phiên bản v1.0.0
Tôi muốn hỗ trợ nhiều nguồn dữ liệu và kênh gửi thông báo hơn. Ví dụ, ai đó chắc chắn sẽ nhớ MongoDB. Tìm kiếm đàn hồi cho một số. Gửi SMS và/hoặc thực hiện cuộc gọi đến điện thoại di động của bạn. Chúng tôi muốn có thể nhận các tập lệnh không chỉ từ các tệp mà còn từ cơ sở dữ liệu chẳng hạn. Cuối cùng, chúng tôi muốn có một trang web thân thiện hơn với người dùng và tài liệu tốt hơn cho dự án.
Ai đó luôn thiếu thứ gì đó) Ở đây chúng tôi dựa vào yêu cầu của cộng đồng để đặt mức độ ưu tiên một cách chính xác. Và với sự giúp đỡ của cộng đồng để nhận ra mọi thứ
Kết luận
Chúng tôi sử dụng Tôi đã có nó được một thời gian rồi. Hàng tá kịch bản bảo vệ sự an tâm của chúng ta. Tôi hy vọng công việc này sẽ hữu ích cho người khác.
Và chào mừng với vấn đề và PR của bạn.
Nguồn: www.habr.com