Hãy xem xét khái niệm giám sát Kubernetes, làm quen với công cụ Prometheus và nói về cảnh báo.
Chủ đề giám sát rất nhiều, không thể gói gọn trong một bài viết. Mục đích của văn bản này là cung cấp một cái nhìn tổng quan về các công cụ, khái niệm và phương pháp tiếp cận.
Nội dung của bài viết được lấy từ . Nếu bạn muốn tham gia một khóa học đầy đủ - hãy đăng ký một khóa học trên .
Những gì được giám sát trong cụm Kubernetes
máy chủ vật lý. Nếu cụm Kubernetes được triển khai trên các máy chủ của nó, bạn cần theo dõi tình trạng của chúng. Zabbix xử lý nhiệm vụ này; nếu làm việc với anh ấy thì bạn không cần phải từ chối, sẽ không có mâu thuẫn. Zabbix là người theo dõi trạng thái máy chủ của chúng tôi.
Hãy chuyển sang giám sát ở cấp độ cụm.
Các thành phần của mặt phẳng điều khiển: API, Trình lập lịch biểu và các thứ khác. Ở mức tối thiểu, bạn cần đảm bảo rằng API của máy chủ hoặc etcd lớn hơn 0. Etcd có thể trả về rất nhiều số liệu: theo số đĩa mà nó đang quay, theo tình trạng của cụm etcd của nó và các số liệu khác.
phu bến tàu đã xuất hiện từ lâu và mọi người đều nhận thức rõ vấn đề của nó: rất nhiều container gây ra hiện tượng đóng băng và các vấn đề khác. Do đó, bản thân Docker, với tư cách là một hệ thống, cũng cần được kiểm soát, ít nhất là về tính khả dụng.
DNS Nếu DNS bị rớt trong cluster thì toàn bộ dịch vụ Discovery cũng sẽ bị rớt sau đó, các cuộc gọi từ pod này sang pod khác sẽ ngừng hoạt động. Trong thực tế của tôi, không có vấn đề nào như vậy, nhưng điều này không có nghĩa là không cần theo dõi trạng thái của DNS. Độ trễ yêu cầu và một số số liệu khác có thể được theo dõi trên CoreDNS.
Xâm nhập. Cần phải kiểm soát tính khả dụng của các mục nhập (bao gồm cả Bộ điều khiển mục nhập) làm điểm vào dự án.
Các thành phần chính của cụm đã được tháo dỡ - bây giờ chúng ta hãy chuyển sang mức độ trừu tượng hóa.
Có vẻ như các ứng dụng chạy theo nhóm, có nghĩa là chúng cần được kiểm soát, nhưng thực tế thì không như vậy. Các nhóm là phù du: hôm nay chúng chạy trên một máy chủ, ngày mai trên máy chủ khác; hôm nay có 10 quả, ngày mai có 2. Vì vậy, không có ai giám sát quả. Trong kiến trúc microservice, điều quan trọng hơn là kiểm soát tính khả dụng của toàn bộ ứng dụng. Đặc biệt, hãy kiểm tra tính khả dụng của các điểm cuối dịch vụ: có gì hoạt động không? Nếu ứng dụng có sẵn, thì điều gì xảy ra đằng sau nó, hiện tại có bao nhiêu bản sao - đây là những câu hỏi thuộc loại thứ hai. Không cần phải giám sát các trường hợp riêng lẻ.
Ở cấp độ cuối cùng, bạn cần kiểm soát hoạt động của chính ứng dụng, lấy các số liệu kinh doanh: số lượng đơn đặt hàng, hành vi của người dùng, v.v.
Prometheus
Hệ thống tốt nhất để giám sát một cụm là . Tôi không biết có công cụ nào có thể sánh ngang với Prometheus về chất lượng và tính dễ sử dụng. Điều này rất tốt cho cơ sở hạ tầng linh hoạt, vì vậy khi nói “giám sát Kubernetes”, họ thường ám chỉ Prometheus.
Có một số tùy chọn để bắt đầu với Prometheus: sử dụng Helm, bạn có thể cài đặt Prometheus hoặc Prometheus Operator thông thường.
- Prometheus thường xuyên. Mọi thứ đều ổn với anh ấy, nhưng bạn cần định cấu hình ConfigMap - trên thực tế, viết các tệp cấu hình dựa trên văn bản, như chúng tôi đã làm trước đây, trước kiến trúc microservice.
- Toán tử Prometheus trải rộng hơn một chút, phức tạp hơn một chút về mặt logic bên trong, nhưng làm việc với nó dễ dàng hơn: có các đối tượng riêng biệt, các phần trừu tượng được thêm vào cụm, do đó chúng thuận tiện hơn nhiều trong việc điều khiển và định cấu hình.
Để hiểu sản phẩm, trước tiên tôi khuyên bạn nên cài đặt Prometheus thông thường. Bạn sẽ phải định cấu hình mọi thứ thông qua cấu hình, nhưng điều này sẽ có lợi: bạn sẽ tìm ra cái gì thuộc về cái gì và nó được cấu hình như thế nào. Trong Prometheus Operator, bạn ngay lập tức nâng lên mức độ trừu tượng cao hơn, mặc dù bạn cũng có thể đi sâu vào chiều sâu nếu muốn.
Prometheus được tích hợp tốt với Kubernetes: nó có thể truy cập và tương tác với API Server.
Prometheus rất phổ biến, đó là lý do tại sao một số lượng lớn ứng dụng và ngôn ngữ lập trình hỗ trợ nó. Cần có sự hỗ trợ vì Prometheus có định dạng số liệu riêng và để chuyển nó, bạn cần có thư viện bên trong ứng dụng hoặc trình xuất có sẵn. Và có khá nhiều nhà xuất khẩu như vậy. Ví dụ: có PostgreSQL Exporter: nó lấy dữ liệu từ PostgreSQL và chuyển đổi sang định dạng Prometheus để Prometheus có thể làm việc với nó.
Kiến trúc Prometheus
Máy chủ Prometheus là phần sau, bộ não của Prometheus. Số liệu được lưu trữ và xử lý ở đây.
Các số liệu được lưu trữ trong cơ sở dữ liệu chuỗi thời gian (TSDB). TSDB không phải là một cơ sở dữ liệu riêng biệt mà là một gói bằng ngôn ngữ Go được nhúng trong Prometheus. Nói một cách đại khái, mọi thứ đều ở dạng nhị phân.
Không lưu trữ dữ liệu trong TSDB lâu
Cơ sở hạ tầng Prometheus không phù hợp để lưu trữ số liệu lâu dài. Thời gian lưu giữ mặc định là 15 ngày. Bạn có thể vượt quá giới hạn này, nhưng hãy nhớ: bạn càng lưu trữ nhiều dữ liệu trong TSDB và lưu trữ càng lâu thì dữ liệu đó sẽ càng tiêu tốn nhiều tài nguyên hơn. Lưu trữ dữ liệu lịch sử trong Prometheus được coi là hành vi xấu.
Nếu bạn có lưu lượng truy cập lớn, số lượng chỉ số lên tới hàng trăm nghìn mỗi giây, thì tốt hơn hết bạn nên giới hạn dung lượng lưu trữ của chúng theo dung lượng ổ đĩa hoặc theo khoảng thời gian. Thông thường, “dữ liệu nóng” được lưu trữ trong TSDB, số liệu chỉ trong vài giờ. Để lưu trữ lâu hơn, bộ nhớ ngoài được sử dụng trong những cơ sở dữ liệu thực sự phù hợp cho việc này, chẳng hạn như InfluxDB, ClickHouse, v.v. Tôi thấy nhiều đánh giá tốt hơn về ClickHouse.
Prometheus Server hoạt động theo mô hình kéo: anh ấy tìm kiếm các số liệu cho các điểm cuối mà chúng tôi đã cung cấp cho anh ấy. Họ nói: “hãy truy cập Máy chủ API” và anh ấy sẽ đến đó sau mỗi số giây thứ n và lấy số liệu.
Đối với các đối tượng có thời gian tồn tại ngắn (công việc hoặc công việc định kỳ) có thể xuất hiện giữa các giai đoạn thu thập dữ liệu, có thành phần Pushgateway. Các số liệu từ các đối tượng ngắn hạn được đẩy vào đó: công việc đã tăng lên, thực hiện một hành động, gửi số liệu đến Pushgateway và hoàn thành. Sau một thời gian, Prometheus sẽ đi xuống theo tốc độ riêng của mình và lấy các số liệu này từ Pushgateway.
Để định cấu hình thông báo trong Prometheus, có một thành phần riêng - Trình quản lý cảnh báo. Và các quy tắc cảnh báo. Ví dụ: bạn cần tạo cảnh báo nếu API máy chủ bằng 0. Khi sự kiện xảy ra, cảnh báo sẽ được chuyển đến người quản lý cảnh báo để gửi tiếp. Trình quản lý cảnh báo có cài đặt định tuyến khá linh hoạt: một nhóm cảnh báo có thể được gửi đến cuộc trò chuyện qua điện tín của quản trị viên, một nhóm cảnh báo khác đến cuộc trò chuyện của nhà phát triển và nhóm thứ ba đến cuộc trò chuyện của nhân viên cơ sở hạ tầng. Thông báo có thể được gửi tới Slack, Telegram, email và các kênh khác.
Và cuối cùng, tôi sẽ kể cho bạn nghe về tính năng sát thủ Prometheus - Khám phá. Khi làm việc với Prometheus, bạn không cần chỉ định địa chỉ cụ thể của các đối tượng để theo dõi, chỉ cần đặt loại của chúng là đủ. Nghĩa là, bạn không cần phải viết “đây là địa chỉ IP, đây là cổng - màn hình”, thay vào đó, bạn cần xác định theo nguyên tắc nào để tìm các đối tượng này (mục tiêu - bàn thắng). Bản thân Prometheus, tùy thuộc vào đối tượng nào hiện đang hoạt động, sẽ lấy ra những đối tượng cần thiết và thêm chúng vào giám sát.
Cách tiếp cận này rất phù hợp với cấu trúc Kubernetes, nơi mọi thứ cũng trôi nổi: hôm nay có 10 máy chủ, ngày mai là 3. Để không chỉ định địa chỉ IP của máy chủ mỗi lần, họ đã viết một lần cách tìm nó - và Discovering sẽ làm điều đó .
Ngôn ngữ Prometheus được gọi là PromQL. Sử dụng ngôn ngữ này, bạn có thể lấy giá trị của các số liệu cụ thể, sau đó chuyển đổi chúng, xây dựng các phép tính phân tích dựa trên chúng.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Giao diện web Prometheus
Prometheus có giao diện web khá tối giản của riêng mình. Chỉ thích hợp để gỡ lỗi hoặc trình diễn.
Trong dòng Biểu thức, bạn có thể viết truy vấn bằng ngôn ngữ PromQL.
Tab Cảnh báo chứa các quy tắc cảnh báo và chúng có ba trạng thái:
- không hoạt động - nếu cảnh báo không hoạt động vào lúc này, nghĩa là mọi thứ đều ổn với nó và nó không hoạt động;
- đang chờ xử lý - đây là trường hợp cảnh báo đã hoạt động nhưng quá trình gửi vẫn chưa được thực hiện. Độ trễ được đặt để bù cho hiện tượng nhấp nháy mạng: nếu dịch vụ được chỉ định tăng lên trong vòng một phút thì cảnh báo sẽ chưa vang lên;
- kích hoạt là trạng thái thứ ba khi cảnh báo sáng lên và gửi tin nhắn.
Trong menu Trạng thái, bạn sẽ tìm thấy quyền truy cập vào thông tin về Prometheus là gì. Ngoài ra còn có sự chuyển đổi sang các mục tiêu (mục tiêu) mà chúng ta đã nói ở trên.
Để biết tổng quan chi tiết hơn về giao diện Prometheus, hãy xem .
Tích hợp với Grafana
Trong giao diện web Prometheus, bạn sẽ không tìm thấy những biểu đồ đẹp và dễ hiểu để từ đó bạn có thể đưa ra kết luận về trạng thái của cụm. Để xây dựng chúng, Prometheus được tích hợp với Grafana. Chúng tôi nhận được bảng điều khiển như vậy.
Thiết lập tích hợp Prometheus và Grafana không khó chút nào, bạn có thể tìm thấy hướng dẫn trong tài liệu: Vâng, tôi sẽ kết thúc với điều này.
Trong các bài viết tiếp theo, chúng tôi sẽ tiếp tục chủ đề giám sát: chúng tôi sẽ nói về việc thu thập và phân tích nhật ký bằng Grafana Loki và các công cụ thay thế.
Tác giả: Marcel Ibraev, quản trị viên Kubernetes được chứng nhận, kỹ sư thực hành trong công ty , diễn giả và nhà phát triển khóa học Slurm.
Nguồn: www.habr.com