Ngày nay, ngoài mã nguyên khối, dự án của chúng tôi còn có hàng tá dịch vụ vi mô. Mỗi người trong số họ yêu cầu phải được theo dõi. Thực hiện việc này ở quy mô như vậy bằng cách sử dụng các kỹ sư DevOps là một vấn đề. Chúng tôi đã phát triển một hệ thống giám sát hoạt động như một dịch vụ dành cho các nhà phát triển. Họ có thể ghi các số liệu vào hệ thống giám sát một cách độc lập, sử dụng chúng, xây dựng trang tổng quan dựa trên chúng và đính kèm các cảnh báo sẽ được kích hoạt khi đạt đến các giá trị ngưỡng. Đối với kỹ sư DevOps, chỉ có cơ sở hạ tầng và tài liệu.
Bài đăng này là bản ghi lại bài phát biểu của tôi với tại RIT++. Nhiều người đã yêu cầu chúng tôi tạo phiên bản văn bản của các báo cáo từ đó. Nếu bạn đang tham dự hội nghị hoặc xem video, bạn sẽ không tìm thấy điều gì mới. Và những người khác - chào mừng bạn đến với con mèo. Tôi sẽ cho bạn biết làm thế nào chúng tôi có được một hệ thống như vậy, nó hoạt động như thế nào và chúng tôi dự định cập nhật nó như thế nào.
Quá khứ: kế hoạch và kế hoạch
Làm thế nào chúng ta có được hệ thống giám sát hiện tại? Để trả lời câu hỏi này, bạn cần phải quay lại năm 2015. Lúc đó nó trông như thế này:
Chúng tôi có khoảng 24 nút chịu trách nhiệm giám sát. Có rất nhiều vương miện, tập lệnh, daemon khác nhau bằng cách nào đó giám sát thứ gì đó, gửi tin nhắn và thực hiện các chức năng. Chúng tôi nghĩ rằng càng đi xa thì hệ thống như vậy càng kém khả thi. Không có ích gì khi phát triển nó: nó quá cồng kềnh.
Chúng tôi quyết định chọn những yếu tố giám sát mà chúng tôi sẽ giữ và phát triển cũng như những yếu tố mà chúng tôi sẽ từ bỏ. Có 19 chiếc, chỉ còn lại than chì, bộ tổng hợp và Grafana làm bảng điều khiển. Nhưng hệ thống mới sẽ trông như thế nào? Như thế này:
Chúng tôi có một bộ lưu trữ số liệu: đây là các than chì, sẽ dựa trên ổ SSD nhanh, đây là những bộ tổng hợp nhất định cho các số liệu. Tiếp theo - Grafana để hiển thị trang tổng quan và Moira để cảnh báo. Chúng tôi cũng muốn phát triển một hệ thống tìm kiếm những điều bất thường.
Tiêu chuẩn: Giám sát 2.0
Đây là kế hoạch của năm 2015. Nhưng chúng tôi không chỉ phải chuẩn bị cơ sở hạ tầng và dịch vụ mà còn cả tài liệu cho nó. Chúng tôi đã phát triển một tiêu chuẩn doanh nghiệp cho chính mình mà chúng tôi gọi là giám sát 2.0. Các yêu cầu cho hệ thống là gì?
- sẵn có liên tục;
- khoảng thời gian lưu trữ số liệu = 10 giây;
- lưu trữ có cấu trúc các số liệu và bảng điều khiển;
- SLA > 99,99%
- tập hợp các số liệu sự kiện thông qua UDP (!).
Chúng tôi cần UDP vì chúng tôi có lưu lượng truy cập và sự kiện lớn tạo ra số liệu. Nếu bạn viết tất cả chúng vào than chì cùng một lúc, kho lưu trữ sẽ sụp đổ. Chúng tôi cũng đã chọn tiền tố cấp một cho tất cả số liệu.
Mỗi tiền tố có một số thuộc tính. Có các số liệu về máy chủ, mạng, vùng chứa, tài nguyên, ứng dụng, v.v. Tính năng lọc rõ ràng, nghiêm ngặt, được đánh máy đã được triển khai, trong đó chúng tôi chấp nhận các số liệu cấp đầu tiên và chỉ cần loại bỏ phần còn lại. Đây là cách chúng tôi lên kế hoạch cho hệ thống này vào năm 2015. Hiện tại có gì?
Hiện tại: sơ đồ tương tác của các thành phần quan trắc
Trước hết, chúng tôi giám sát các ứng dụng: mã PHP, ứng dụng và vi dịch vụ - nói tóm lại là mọi thứ mà nhà phát triển của chúng tôi viết. Tất cả các ứng dụng đều gửi số liệu qua UDP tới bộ tổng hợp Brubeck (statsd, viết lại bằng C). Nó hóa ra là nhanh nhất trong các thử nghiệm tổng hợp. Và nó sẽ gửi các số liệu đã được tổng hợp tới Graphite thông qua TCP.
Nó có một loại số liệu được gọi là bộ tính giờ. Đây là một điều rất thuận tiện. Ví dụ: đối với mỗi người dùng kết nối với dịch vụ, bạn gửi số liệu kèm theo thời gian phản hồi tới Brubeck. Một triệu phản hồi được gửi đến nhưng công cụ tổng hợp chỉ trả về 10 số liệu. Bạn có số lượng người đã đến, thời gian phản hồi tối đa, tối thiểu và trung bình, giá trị trung bình và 4 phần trăm. Sau đó, dữ liệu được chuyển sang Graphite và chúng tôi thấy tất cả đều trực tiếp.
Chúng tôi cũng có sự tổng hợp các số liệu về phần cứng, phần mềm, số liệu hệ thống và hệ thống giám sát Munin cũ của chúng tôi (nó hoạt động với chúng tôi cho đến năm 2015). Chúng tôi thu thập tất cả những điều này thông qua C daemon CollectD (nó có rất nhiều plugin khác nhau được tích hợp trong đó, nó có thể thăm dò tất cả các tài nguyên của hệ thống máy chủ mà nó được cài đặt, chỉ cần chỉ định trong cấu hình nơi ghi dữ liệu) và ghi dữ liệu vào Graphite thông qua nó. Nó cũng hỗ trợ các plugin python và tập lệnh shell, vì vậy bạn có thể viết các giải pháp tùy chỉnh của riêng mình: CollectD sẽ thu thập dữ liệu này từ máy chủ cục bộ hoặc từ xa (giả sử Curl) và gửi nó đến Graphite.
Sau đó, chúng tôi gửi tất cả số liệu mà chúng tôi đã thu thập tới Carbon-c-relay. Đây là giải pháp Carbon Relay từ Graphite, được sửa đổi trong C. Đây là bộ định tuyến thu thập tất cả số liệu mà chúng tôi gửi từ bộ tổng hợp của mình và định tuyến chúng đến các nút. Cũng ở giai đoạn định tuyến, nó sẽ kiểm tra tính hợp lệ của các số liệu. Thứ nhất, chúng phải tương ứng với sơ đồ tiền tố mà tôi đã trình bày trước đó và thứ hai, chúng hợp lệ đối với than chì. Nếu không họ sẽ thả.
Sau đó, carbon-c-relay sẽ gửi số liệu đến cụm Graphite. Chúng tôi sử dụng bộ đệm Carbon, được viết lại trong Go, làm nơi lưu trữ số liệu chính. Go-carbon, nhờ tính năng đa luồng, vượt trội hơn nhiều so với bộ nhớ đệm Carbon. Nó nhận dữ liệu và ghi vào đĩa bằng gói thì thầm (tiêu chuẩn, viết bằng python). Để đọc dữ liệu từ kho lưu trữ của chúng tôi, chúng tôi sử dụng API Graphite. Nó nhanh hơn nhiều so với WEB Graphite tiêu chuẩn. Điều gì xảy ra với dữ liệu tiếp theo?
Họ đến Grafana. Chúng tôi sử dụng các cụm than chì làm nguồn dữ liệu chính, ngoài ra chúng tôi còn có Grafana làm giao diện web để hiển thị số liệu và xây dựng trang tổng quan. Đối với mỗi dịch vụ của họ, nhà phát triển tạo trang tổng quan của riêng họ. Sau đó, họ xây dựng các biểu đồ dựa trên chúng để hiển thị các số liệu họ viết từ ứng dụng của mình. Ngoài Grafana, chúng tôi còn có SLAM. Đây là con quỷ trăn tính toán SLA dựa trên dữ liệu từ than chì. Như tôi đã nói, chúng tôi có hàng chục microservice, mỗi microservice đều có những yêu cầu riêng. Bằng cách sử dụng SLAM, chúng tôi truy cập tài liệu và so sánh nó với những gì có trong Graphite và so sánh mức độ phù hợp của các yêu cầu với tính khả dụng của dịch vụ của chúng tôi.
Hãy đi xa hơn: cảnh báo. Nó được tổ chức bằng một hệ thống mạnh mẽ - Moira. Nó độc lập vì nó có than chì riêng bên dưới. Được phát triển bởi những người đến từ SKB "Kontur", được viết bằng python và Go, hoàn toàn là mã nguồn mở. Moira nhận được dòng chảy tương tự đi vào than chì. Nếu vì lý do nào đó bộ nhớ của bạn hết, cảnh báo của bạn sẽ vẫn hoạt động.
Chúng tôi đã triển khai Moira trong Kubernetes; nó sử dụng một cụm máy chủ Redis làm cơ sở dữ liệu chính. Kết quả là một hệ thống có khả năng chịu lỗi. Nó so sánh luồng số liệu với danh sách trình kích hoạt: nếu không có đề cập nào trong đó thì nó sẽ loại bỏ số liệu. Vì vậy, nó có thể xử lý hàng gigabyte số liệu mỗi phút.
Chúng tôi cũng đính kèm LDAP công ty vào đó, với sự trợ giúp của nó, mỗi người dùng hệ thống công ty có thể tự tạo thông báo dựa trên các trình kích hoạt hiện có (hoặc mới được tạo). Vì Moira có chứa Graphite nên nó hỗ trợ tất cả các tính năng của nó. Vì vậy, trước tiên bạn hãy lấy dòng đó và sao chép nó vào Grafana. Xem cách dữ liệu được hiển thị trên biểu đồ. Và sau đó bạn lấy dòng tương tự và sao chép nó vào Moira. Bạn treo nó với giới hạn và nhận được cảnh báo ở đầu ra. Để làm tất cả điều này, bạn không cần bất kỳ kiến thức cụ thể nào. Moira có thể cảnh báo qua SMS, email, Jira, Slack... Nó cũng hỗ trợ thực thi các tập lệnh tùy chỉnh. Khi một kích hoạt xảy ra với cô ấy và cô ấy đăng ký một tập lệnh hoặc tệp nhị phân tùy chỉnh, cô ấy sẽ chạy nó và gửi JSON tới stdin cho tệp nhị phân này. Theo đó, chương trình của bạn phải phân tích nó. Bạn sẽ làm gì với JSON này là tùy thuộc vào bạn. Nếu muốn thì gửi lên Telegram, nếu muốn thì mở task trong Jira, làm gì cũng được.
Chúng tôi cũng sử dụng sự phát triển của riêng mình để cảnh báo - Imagotag. Chúng tôi đã điều chỉnh bảng điều khiển thường được sử dụng cho thẻ giá điện tử trong cửa hàng để phù hợp với nhu cầu của mình. Chúng tôi đã mang yếu tố kích hoạt từ Moira đến với nó. Nó cho biết chúng đang ở trạng thái nào và khi nào chúng xảy ra. Một số người phát triển đã bỏ thông báo trong Slack và gửi email để chuyển sang bảng điều khiển này.
Chà, vì chúng tôi là một công ty tiến bộ nên chúng tôi cũng giám sát Kubernetes trong hệ thống này. Chúng tôi đã đưa nó vào hệ thống bằng Heapster mà chúng tôi đã cài đặt trong cụm, nó thu thập dữ liệu và gửi đến Graphite. Kết quả là sơ đồ trông như thế này:
Thành phần giám sát
Đây là danh sách các liên kết đến các thành phần chúng tôi đã sử dụng cho nhiệm vụ này. Tất cả đều là nguồn mở.
Than chì:
- go-carbon:
- thì thầm:
- than chì-api:
Rơle carbon-c:
Brubeck:
Đã sưu tầm:
Mora:
Grafana:
Heapster:
thống kê
Và đây là một số con số về cách hệ thống hoạt động đối với chúng tôi.
Bộ tổng hợp (brubeck)
Số lượng số liệu: ~300/giây
Khoảng thời gian gửi số liệu tới Graphite: 30 giây
Mức sử dụng tài nguyên máy chủ: ~ 6% CPU (chúng ta đang nói về các máy chủ chính thức); ~ RAM 1Gb; ~3 Mb/giây mạng LAN
Than chì (go-cacbon)
Số lượng chỉ số: ~ 1/phút
Khoảng thời gian cập nhật số liệu: 30 giây
Sơ đồ lưu trữ số liệu: 30 giây 35d, 5 phút 90d, 10 phút 365d (cung cấp cho bạn hiểu biết về những gì xảy ra với dịch vụ trong một khoảng thời gian dài)
Mức sử dụng tài nguyên máy chủ: ~10% CPU; ~ RAM 20Gb; ~30 Mb/giây LAN
Tính linh hoạt
Tại Avito, chúng tôi thực sự coi trọng tính linh hoạt trong dịch vụ giám sát của mình. Tại sao anh ấy lại thành ra thế này? Thứ nhất, các thành phần của nó có thể hoán đổi cho nhau: cả bản thân các thành phần và phiên bản của chúng. Thứ hai, khả năng hỗ trợ. Vì toàn bộ dự án là nguồn mở nên bạn có thể tự chỉnh sửa mã, thực hiện các thay đổi và triển khai các chức năng không có sẵn. Các ngăn xếp khá phổ biến được sử dụng, chủ yếu là Go và Python nên việc này được thực hiện khá đơn giản.
Đây là một ví dụ về một vấn đề thực sự. Số liệu trong Graphite là một tệp. Nó có một cái tên. Tên tệp = tên số liệu. Và có một cách để đạt được điều đó. Tên tệp trong Linux được giới hạn ở 255 ký tự. Và chúng tôi có những người (với tư cách là “khách hàng nội bộ”) từ bộ phận cơ sở dữ liệu. Họ nói với chúng tôi: “Chúng tôi muốn theo dõi các truy vấn SQL của mình. Và chúng không phải là 255 ký tự mà là 8 MB mỗi ký tự. Chúng tôi muốn hiển thị chúng trong Grafana, xem các thông số cho yêu cầu này và thậm chí tốt hơn, chúng tôi muốn xem phần đầu của các yêu cầu đó. Sẽ thật tuyệt nếu nó được hiển thị theo thời gian thực. Sẽ thật tuyệt nếu đưa chúng vào tình trạng báo động.”
Truy vấn SQL mẫu được lấy làm ví dụ từ
Chúng tôi thiết lập máy chủ Redis và sử dụng plugin Đã sưu tập của mình, đi đến Postgres và lấy tất cả dữ liệu từ đó, gửi số liệu đến Graphite. Nhưng chúng tôi thay thế tên số liệu bằng giá trị băm. Chúng tôi đồng thời gửi cùng một hàm băm tới Redis dưới dạng khóa và toàn bộ truy vấn SQL dưới dạng giá trị. Tất cả những gì chúng ta phải làm là đảm bảo rằng Grafana có thể đến Redis và lấy thông tin này. Chúng tôi đang mở API Graphite vì... đây là giao diện chính để tương tác giữa tất cả các thành phần giám sát với than chì và chúng tôi nhập một chức năng mới có tên là aliasByHash() - từ Grafana, chúng tôi lấy tên của số liệu và sử dụng nó trong yêu cầu tới Redis làm khóa, trong phản hồi, chúng tôi nhận được giá trị của khóa, đó là “truy vấn SQL” của chúng tôi " Do đó, chúng tôi đã hiển thị trong Grafana một màn hình hiển thị truy vấn SQL, về mặt lý thuyết là không thể hiển thị ở đó, cùng với số liệu thống kê về nó (cuộc gọi, hàng, Total_time, ...).
Kết quả
Tính khả dụng. Dịch vụ giám sát của chúng tôi hoạt động 24/7 từ bất kỳ ứng dụng và mã nào. Nếu bạn có quyền truy cập vào các phương tiện lưu trữ, bạn có thể ghi dữ liệu vào dịch vụ. Ngôn ngữ không quan trọng, quyết định không quan trọng. Bạn chỉ cần biết cách mở ổ cắm, đặt thước đo vào đó và đóng ổ cắm lại.
Độ tin cậy. Tất cả các thành phần đều có khả năng chịu lỗi và xử lý tốt tải của chúng tôi.
Ngưỡng đầu vào thấp. Để sử dụng hệ thống này, bạn không cần phải học ngôn ngữ lập trình và truy vấn trong Grafana. Chỉ cần mở ứng dụng của bạn, nhập một ổ cắm vào đó sẽ gửi số liệu đến Graphite, đóng ứng dụng, mở Grafana, tạo trang tổng quan ở đó và xem hoạt động của số liệu của bạn, nhận thông báo qua Moira.
Sự độc lập. Bạn có thể tự mình làm tất cả những việc này mà không cần sự trợ giúp của các kỹ sư DevOps. Và đây là một lợi thế, vì bạn có thể giám sát dự án của mình ngay bây giờ, bạn không cần phải nhờ bất kỳ ai - bắt đầu công việc hoặc thực hiện thay đổi.
Chúng ta đang phấn đấu vì điều gì?
Mọi thứ được liệt kê dưới đây không chỉ là những suy nghĩ trừu tượng mà còn là thứ mà ít nhất những bước đầu tiên đã được thực hiện.
- Máy dò bất thường. Chúng tôi muốn tạo một dịch vụ sẽ đi tới kho lưu trữ Graphite của chúng tôi và kiểm tra từng số liệu bằng nhiều thuật toán khác nhau. Đã có những thuật toán mà chúng tôi muốn xem, có dữ liệu, chúng tôi biết cách làm việc với nó.
- Metadata. Chúng tôi có nhiều dịch vụ, chúng thay đổi theo thời gian, giống như những người làm việc với chúng. Liên tục duy trì tài liệu theo cách thủ công không phải là một lựa chọn. Đó là lý do tại sao chúng tôi hiện đang nhúng siêu dữ liệu vào các vi dịch vụ của mình. Nó cho biết ai đã phát triển nó, các ngôn ngữ mà nó tương tác, các yêu cầu SLA, thông báo sẽ được gửi ở đâu và cho ai. Khi triển khai một dịch vụ, tất cả dữ liệu thực thể được tạo độc lập. Kết quả là bạn nhận được hai liên kết - một liên kết đến trình kích hoạt, liên kết còn lại đến trang tổng quan trong Grafana.
- Giám sát tại mọi nhà. Chúng tôi tin rằng tất cả các nhà phát triển nên sử dụng một hệ thống như vậy. Trong trường hợp này, bạn luôn hiểu lưu lượng truy cập của mình ở đâu, điều gì xảy ra với nó, nó rơi vào đâu, điểm yếu của nó là ở đâu. Ví dụ: nếu có điều gì đó xảy ra và làm hỏng dịch vụ của bạn, thì bạn sẽ tìm hiểu về nó không phải trong cuộc gọi từ người quản lý mà từ một cảnh báo và bạn có thể mở ngay nhật ký mới nhất và xem điều gì đã xảy ra ở đó.
- Hiệu suất cao. Dự án của chúng tôi không ngừng phát triển và ngày nay nó xử lý khoảng 2 giá trị số liệu mỗi phút. Một năm trước, con số này là 000. Và con số này vẫn tiếp tục tăng, điều này có nghĩa là sau một thời gian, Graphite (thì thầm) sẽ bắt đầu tải nặng hệ thống con đĩa. Như tôi đã nói, hệ thống giám sát này khá phổ biến do khả năng thay thế lẫn nhau của các thành phần. Có người duy trì và liên tục mở rộng cơ sở hạ tầng dành riêng cho Graphite, nhưng chúng tôi quyết định đi một con đường khác: sử dụng như một kho lưu trữ các số liệu của chúng tôi. Quá trình chuyển đổi này gần như đã hoàn tất và tôi sẽ sớm cho bạn biết chi tiết hơn về cách thực hiện quá trình này: những khó khăn đã có và cách khắc phục chúng, quá trình di chuyển diễn ra như thế nào, tôi sẽ mô tả các thành phần được chọn làm ràng buộc và cấu hình của chúng.
Cám ơn vì sự quan tâm của bạn! Hãy đặt câu hỏi của bạn về chủ đề này, tôi sẽ cố gắng trả lời ở đây hoặc trong các bài viết sau. Có lẽ ai đó đã có kinh nghiệm xây dựng một hệ thống giám sát tương tự hoặc chuyển sang Clickhouse trong tình huống tương tự - hãy chia sẻ trong phần bình luận.
Nguồn: www.habr.com