Ba loại cảnh báo mạnh mẽ hỗ trợ cơ sở hạ tầng sản xuất của Hugging Face

Nhóm Cơ sở hạ tầng tại Hugging Face rất vui được chia sẻ cái nhìn hậu trường về hoạt động bên trong cơ sở hạ tầng sản xuất của Hugging Face, điều mà chúng tôi vinh dự được giúp xây dựng và duy trì. Sự cống hiến của nhóm chúng tôi trong việc thiết kế và triển khai một hệ thống giám sát và cảnh báo mạnh mẽ đã đóng vai trò quan trọng trong việc đảm bảo tính ổn định và khả năng mở rộng của các nền tảng của chúng tôi. Chúng tôi liên tục được nhắc nhở về tác động mà các cảnh báo của chúng tôi có được đối với khả năng xác định và ứng phó với các sự cố tiềm ẩn trước khi chúng trở thành những sự cố lớn.

Trong bài đăng trên blog này, chúng ta sẽ đi sâu vào chi tiết của ba loại cảnh báo mạnh mẽ đóng vai trò riêng trong việc hỗ trợ cơ sở hạ tầng sản xuất của chúng ta và khám phá cách chúng đã giúp chúng ta duy trì mức hiệu suất và thời gian hoạt động cao mà cộng đồng của chúng ta tin tưởng.

Thông lượng cổng NAT cao

Thông thường, với kiến trúc điện toán đám mây, nơi dữ liệu lưu chuyển giữa mạng riêng và mạng công cộng, việc triển khai cổng NAT (Network Address Translation) là một phương pháp hay đã được chứng minh. Cổng này hoạt động như một người gác cổng chiến lược, giám sát và tạo điều kiện thuận lợi cho tất cả lưu lượng truy cập исходящий hướng tới Internet công cộng. Bằng cách tập trung lưu lượng egress, cổng NAT cung cấp một điểm thuận lợi chiến lược để có được khả năng hiển thị toàn diện. Nhóm của chúng ta có thể dễ dàng truy vấn và phân tích lưu lượng truy cập này, biến nó thành một tài sản vô giá khi giải quyết các kịch bản khác nhau liên quan đến bảo mật, tối ưu hóa chi phí hoặc các kịch bản điều tra khác.

Tối ưu hóa chi phí là một khía cạnh quan trọng của việc quản lý cơ sở hạ tầng đám mây và việc hiểu rõ động lực định giá là yếu tố then chốt. Trong các trung tâm dữ liệu, cấu trúc định giá thường phân biệt giữa lưu lượng truy cập east-west (thường là giao tiếp trong cùng một giá hoặc tòa nhà) và lưu lượng truy cập north-south (giao tiếp giữa các mạng riêng ở xa hơn hoặc internet). Bằng cách giám sát khối lượng lưu lượng mạng, Hugging Face có được những thông tin chi tiết có giá trị về các mẫu lưu lượng truy cập này. Nhận thức này cho phép chúng ta đưa ra các quyết định sáng suốt về cấu hình và kiến trúc cơ sở hạ tầng, đảm bảo chúng ta hạn chế phát sinh các chi phí không cần thiết.

Một trong những cảnh báo quan trọng của chúng ta được thiết kế để thông báo cho chúng ta khi khối lượng lưu lượng mạng của chúng ta vượt quá một ngưỡng được xác định trước. Cảnh báo này phục vụ nhiều mục đích. Thứ nhất, nó hoạt động như một hệ thống cảnh báo sớm, cảnh báo chúng ta về bất kỳ đột biến bất thường nào trong lưu lượng truy cập có thể cho thấy các sự cố tiềm ẩn hoặc hành vi không mong muốn. Thứ hai, nó nhắc nhở chúng ta thường xuyên xem xét các xu hướng lưu lượng truy cập của mình, đảm bảo chúng ta luôn cập nhật về sự phát triển và nhu cầu ngày càng tăng của cơ sở hạ tầng của mình. Cảnh báo này được đặt ở một ngưỡng tĩnh, mà chúng ta đã tinh chỉnh theo thời gian, đảm bảo nó vẫn phù hợp và hiệu quả. Khi được kích hoạt, nó thường trùng với các giai đoạn tái cấu trúc cơ sở hạ tầng của chúng ta.

Ví dụ: khi tích hợp các công cụ bảo mật và tự động масштабирование của bên thứ ba, chúng ta đã quan sát thấy dữ liệu đo từ xa tăng lên отток từ các nút của chúng ta, kích hoạt cảnh báo và nhắc nhở chúng ta tối ưu hóa cấu hình của mình.

Một dịp khác, việc điều chỉnh cơ sở hạ tầng của chúng ta dẫn đến việc vô tình tránh một đường dẫn riêng, chi phí thấp giữa cơ sở hạ tầng dành riêng cho sản phẩm (ví dụ: lưu lượng truy cập đến Hub từ Space để tương tác với dữ liệu kho lưu trữ). Để giải thích thêm, khối lượng công việc có tác động lớn nhất về mặt tiết kiệm chi phí mà chúng ta tìm thấy là những khối lượng công việc truy cập хранилище объектов. Việc tìm nạp các đối tượng trực tiếp có giá rẻ hơn so với việc đi qua các tài sản được lưu trữ trên CDN cho хранилище kho lưu trữ LFS của chúng ta và ngoài ra không yêu cầu các biện pháp bảo mật tương tự mà WAF của chúng ta cung cấp so với các yêu cầu công khai đến cửa trước của chúng ta. Việc tận dụng các ghi đè DNS để chuyển lưu lượng truy cập thông qua các đường dẫn mạng riêng và đường dẫn mạng công cộng đã trở thành một kỹ thuật có giá trị đối với chúng ta, được thúc đẩy bởi nhà cung cấp CDKTF AWS.

new Route53ResolverFirewallRule(
  stack,
  `dns-override-rule-${key}-${j}`,
  {
    provider: group?.provider!,
    name: `dns-override-${dnsOverride.name}-${rule[0]}`,
    action: 'BLOCK',
    blockOverrideDnsType: 'CNAME',
    blockOverrideDomain: `${rule[1]}.`,
    blockOverrideTtl: dnsOverride.ttl,
    blockResponse: 'OVERRIDE',
    firewallDomainListId: list.id,
    firewallRuleGroupId: group!.id,
    priority: 100 + j,
  },
);

Lưu ý cuối cùng, trong khi chúng ta có cấu hình dưới dạng mã đảm bảo trạng thái mong muốn luôn có hiệu lực, thì việc có thêm một lớp cảnh báo xung quanh sẽ giúp trong trường hợp có sai sót khi thể hiện trạng thái mong muốn thông qua mã.

Tỷ lệ thành công khi lưu trữ nhật ký yêu cầu của Hub

Cơ sở hạ tầng ghi nhật ký tại Hugging Face là một hệ thống tinh vi được thiết kế để thu thập, xử lý và lưu trữ một lượng lớn dữ liệu nhật ký được tạo bởi các ứng dụng và dịch vụ của chúng ta. Trọng tâm của hệ thống này là đường ống ghi nhật ký ứng dụng Hub, một giải pháp được xây dựng tốt đảm bảo dữ liệu sử dụng mô hình Hub được thu thập, làm phong phú và lưu trữ hiệu quả cho mục đích báo cáo và lưu trữ. Đường ống bắt đầu với Filebeat, một trình vận chuyển nhật ký nhẹ chạy dưới dạng демонset cùng với các pod ứng dụng của chúng ta trong mỗi cụm Kubernetes. Vai trò của Filebeat là thu thập nhật ký từ nhiều nguồn khác nhau, bao gồm cả các контейнер ứng dụng, và chuyển tiếp chúng đến giai đoạn tiếp theo của đường ống.

Sau khi nhật ký được Filebeat thu thập, chúng sẽ được gửi đến Logstash, một công cụ xử lý nhật ký mạnh mẽ. Logstash hoạt động như một con ngựa làm việc xử lý dữ liệu, áp dụng một loạt các đột biến và chuyển đổi cho các nhật ký đến. Điều này bao gồm làm phong phú nhật ký bằng dữ liệu GeoIP để có được thông tin chi tiết về vị trí địa lý, định tuyến nhật ký đến các chỉ mục Elasticsearch cụ thể dựa trên các tiêu chí được xác định trước và thao tác các trường nhật ký bằng cách thêm, xóa hoặc định dạng lại chúng để đảm bảo tính nhất quán và dễ dàng phân tích. Sau khi Logstash đã xử lý nhật ký, chúng sẽ được chuyển tiếp đến một cụm Elasticsearch.

Elasticsearch, một công cụ tìm kiếm và phân tích phân tán, tạo thành cốt lõi của nền tảng lưu trữ và phân tích nhật ký của chúng ta. Nó nhận nhật ký từ Logstash và áp dụng bộ quy tắc xử lý riêng thông qua các đường ống Elasticsearch. Các đường ống này thực hiện các tác vụ xử lý tối thiểu, chẳng hạn như thêm các trường dấu thời gian để cho biết thời gian xử lý, điều này rất quan trọng cho việc phân tích và tương quan nhật ký. Elasticsearch cung cấp một giải pháp lưu trữ linh hoạt và có khả năng mở rộng, cho phép chúng ta đệm nhật ký để sử dụng vận hành và phân tích theo thời gian thực.

Để quản lý vòng đời của nhật ký trong Elasticsearch, chúng ta sử dụng một chiến lược quản lý vòng đời và lưu trữ mạnh mẽ. Điều này đảm bảo rằng nhật ký được giữ lại trong Elasticsearch trong một khoảng thời gian xác định, cung cấp khả năng truy cập nhanh chóng cho mục đích vận hành và khắc phục sự cố. Sau khoảng thời gian lưu giữ này, nhật ký sẽ được chuyển sang хранилище lưu trữ dài hạn. Quá trình lưu trữ liên quan đến một công cụ tự động đọc nhật ký từ các chỉ mục Elasticsearch, định dạng chúng dưới dạng các tệp Parquet — một định dạng lưu trữ theo cột hiệu quả — và ghi chúng vào hệ thống хранилище объектов của chúng ta.

Giai đoạn cuối cùng của đường ống ghi nhật ký của chúng ta tận dụng các dịch vụ kho dữ liệu AWS. Ở đây, trình thu thập thông tin AWS Glue được sử dụng để khám phá và phân loại dữ liệu trong хранилище объектов của chúng ta, tự động tạo một Glue Data Catalog, cung cấp một kho siêu dữ liệu hợp nhất. Lược đồ bảng Glue được làm mới định kỳ để đảm bảo nó luôn cập nhật với cấu trúc đang phát triển của dữ liệu nhật ký của chúng ta. Sự tích hợp này với AWS Glue cho phép chúng ta truy vấn nhật ký được lưu trữ bằng Amazon Athena, một dịch vụ truy vấn tương tác không máy chủ. Athena cho phép chúng ta chạy các truy vấn SQL trực tiếp trên dữ liệu trong хранилище объектов, cung cấp một giải pháp có chi phí hiệu quả và có khả năng mở rộng để phân tích nhật ký và khám phá dữ liệu lịch sử.

Đường ống ghi nhật ký, mặc dù được thiết kế tỉ mỉ, nhưng không tránh khỏi những thách thức và các điểm hỏng hóc tiềm ẩn. Một trong những уязвимостей quan trọng nhất nằm ở tính đàn hồi của hệ thống, đặc biệt là trong cụm Elasticsearch. Elasticsearch, là một hệ thống phân tán, có thể gặp phải áp suất ngược в различных сценариях, chẳng hạn như lưu lượng ingress cao, truy vấn chuyên sâu hoặc các hoạt động nội bộ như chuyển vị trí shard. Khi áp suất ngược xảy ra, nó có thể dẫn đến một loạt các vấn đề trong toàn bộ đường ống. Ví dụ: nếu cụm Elasticsearch trở nên quá tải, nó có thể bắt đầu từ chối hoặc trì hoãn việc nhập nhật ký, gây ra sự tồn đọng trong Logstash hoặc thậm chí Filebeat, có thể dẫn đến mất nhật ký hoặc xử lý bị trì hoãn.

Một điểm dễ vỡ khác là cơ chế phát hiện sơ đồ tự động trong Elasticsearch. Mặc dù nó được thiết kế để thích ứng với các cấu trúc nhật ký đang thay đổi, nhưng nó có thể không thành công khi nhật ký ứng dụng trải qua những thay đổi lớn về loại trường. Nếu quá trình phát hiện sơ đồ không nhận ra các loại trường mới, nó có thể dẫn đến việc ghi không thành công từ Logstash sang Elasticsearch, gây ra tắc nghẽn trong quá trình xử lý nhật ký và những điểm không nhất quán tiềm ẩn về dữ liệu. Vấn đề này nhấn mạnh tầm quan trọng của việc quản lý sơ đồ nhật ký chủ động và sự cần thiết phải giám sát mạnh mẽ để phát hiện và giải quyết các vấn đề đó một cách kịp thời.

Quản lý bộ nhớ cũng là một khía cạnh quan trọng của sự ổn định của đường ống. Tầng xử lý nhật ký, bao gồm Logstash và Filebeat, hoạt động với các tài nguyên bộ nhớ hạn chế để kiểm soát chi phí. Khi áp suất ngược xảy ra, các thành phần này có thể gặp phải các vấn đề Out-of-Memory (OOM), đặc biệt là trong quá trình hệ thống chậm lại. Khi nhật ký tích lũy và áp suất ngược tăng lên, dấu chân bộ nhớ của các quá trình này tăng lên, đẩy chúng đến gần giới hạn của chúng hơn. Nếu không được giải quyết kịp thời, điều này có thể dẫn đến sự cố quy trình hoặc làm trầm trọng thêm vấn đề áp suất ngược.

Các công việc lưu trữ, chịu trách nhiệm chuyển nhật ký từ Elasticsearch sang хранилище объектов, cũng gặp phải những thách thức. Đôi khi, các công việc này có thể sử dụng nhiều tài nguyên, với hiệu suất của chúng trở nên nhạy cảm với kích thước nút và khả năng sử dụng bộ nhớ. Trong những trường hợp dữ liệu rác hoặc các mục nhập nhật ký lớn bất thường đi qua đường ống, chúng có thể gây căng thẳng cho quá trình lưu trữ, dẫn đến lỗi do cạn kiệt bộ nhớ hoặc giới hạn dung lượng nút. Điều này nhấn mạnh tầm quan trọng của việc xác thực và lọc dữ liệu sớm hơn trong đường ống để ngăn các vấn đề như vậy đến giai đoạn lưu trữ.

Để giảm thiểu những lỗi tiềm ẩn này, chúng ta đã triển khai một hệ thống cảnh báo mạnh mẽ с уникальной мотивацией: xác thực luồng nhật ký từ đầu đến cuối. Cảnh báo được thiết kế để so sánh số lượng yêu cầu mà Bộ cân bằng tải ứng dụng (ALB) của chúng ta nhận được với số lượng nhật ký được lưu trữ thành công, cung cấp một cái nhìn toàn diện về luồng dữ liệu nhật ký trong toàn bộ đường ống. Cách tiếp cận này cho phép chúng ta nhanh chóng xác định bất kỳ sự khác biệt nào có thể cho thấy mất nhật ký tiềm ẩn hoặc các vấn đề xử lý.

Cơ chế cảnh báo dựa trên một so sánh đơn giản nhưng hiệu quả: số lượng yêu cầu truy cập ALB của chúng ta, đại diện cho tổng khối lượng nhật ký đi vào hệ thống, so với số lượng nhật ký được lưu trữ thành công trong хранилище dài hạn của chúng ta. Bằng cách giám sát tỷ lệ này, chúng ta có thể đảm bảo rằng những gì đi vào phải đi ra, cung cấp một xác thực mạnh mẽ về tình trạng cơ sở hạ tầng ghi nhật ký của chúng ta. Khi cảnh báo được kích hoạt, nó sẽ cho biết sự không khớp tiềm ẩn, thúc đẩy điều tra và khắc phục ngay lập tức.

Trong thực tế, cảnh báo này đã được chứng minh là một công cụ có giá trị, đặc biệt là trong các giai đoạn tái cấu trúc cơ sở hạ tầng. Ví dụ: khi chúng ta di chuyển ALB của mình sang nguồn gốc VPC, cảnh báo này đã đóng vai trò quan trọng trong việc xác định và giải quyết các khác biệt về luồng nhật ký. Tuy nhiên, nó cũng đã cứu chúng ta trong những kịch bản ít rõ ràng hơn. Ví dụ: khi các công việc lưu trữ không chạy do các vấn đề không lường trước được, cảnh báo đã gắn cờ các nhật ký được lưu trữ bị thiếu, cho phép chúng ta nhanh chóng điều tra và giải quyết vấn đề trước khi nó ảnh hưởng đến các quy trình lưu giữ và phân tích nhật ký của chúng ta.

Mặc dù cảnh báo này là một công cụ mạnh mẽ, nhưng nó chỉ là một phần trong chiến lược giám sát toàn diện của chúng ta. Chúng ta liên tục tinh chỉnh và điều chỉnh cơ sở hạ tầng ghi nhật ký của mình để xử lý khối lượng và độ phức tạp ngày càng tăng của dữ liệu nhật ký. Bằng cách kết hợp giám sát chủ động, quản lý tài nguyên hiệu quả và hiểu biết sâu sắc về hành vi của hệ thống, Hugging Face đảm bảo rằng đường ống ghi nhật ký của chúng ta vẫn kiên cường, đáng tin cậy và có khả năng hỗ trợ sự phát triển và nhu cầu ngày càng tăng của nền tảng của chúng ta. Cảnh báo này là một minh chứng cho cam kết của chúng ta trong việc duy trì một hệ thống ghi nhật ký mạnh mẽ và minh bạch, cung cấp cho các nhóm của chúng ta những thông tin chi tiết mà họ cần để giữ cho Hugging Face hoạt động trơn tru.

Lỗi yêu cầu API Kubernetes và giới hạn tốc độ

Khi vận hành các ứng dụng gốc đám mây và cơ sở hạ tầng dựa trên Kubernetes, ngay cả những vấn đề dường như nhỏ cũng có thể leo thang thành thời gian ngừng hoạt động đáng kể nếu không được kiểm tra. Điều này đặc biệt đúng đối với API Kubernetes, đóng vai trò là hệ thần kinh trung ương của một cụm Kubernetes, điều phối việc tạo, quản lý và kết nối các контейнер. Tại Hugging Face, chúng ta đã học được thông qua kinh nghiệm rằng việc giám sát tỷ lệ lỗi API Kubernetes và các số liệu giới hạn tốc độ là một практика quan trọng, có thể ngăn chặn những thảm họa tiềm ẩn.

Cơ sở hạ tầng của Hugging Face được tích hợp sâu với Kubernetes và thư viện kube-rs đã đóng vai trò quan trọng trong việc xây dựng và quản lý hệ sinh thái này một cách hiệu quả. kube-rs cung cấp một cách tiếp cận tập trung vào Rust để phát triển ứng dụng Kubernetes, cung cấp cho các nhà phát triển một bộ công cụ quen thuộc và mạnh mẽ. Trọng tâm của nó, kube-rs giới thiệu ba khái niệm chính: bộ phản xạ, bộ điều khiển và giao diện tài nguyên tùy chỉnh. Bộ phản xạ đảm bảo đồng bộ hóa thời gian thực của các tài nguyên Kubernetes, cho phép các ứng dụng phản ứng nhanh chóng với những thay đổi. Bộ điều khiển, những người ra quyết định, liên tục đối chiếu trạng thái mong muốn và trạng thái thực tế của các tài nguyên, giúp Kubernetes tự phục hồi. Giao diện tài nguyên tùy chỉnh mở rộng Kubernetes, cho phép các nhà phát triển xác định các tài nguyên dành riêng cho ứng dụng để có được sự trừu tượng tốt hơn.

Ngoài ra, kube-rs giới thiệu các trình theo dõi và trình hoàn thiện. Trình theo dõi giám sát các tài nguyên cụ thể để tìm các thay đổi, kích hoạt các hành động để đáp ứng các sự kiện. Mặt khác, trình hoàn thiện, đảm bảo dọn dẹp và chấm dứt tài nguyên thích hợp bằng cách xác định logic tùy chỉnh. Bằng cách cung cấp các trừu tượng dựa trên Rust cho các khái niệm Kubernetes này, kube-rs cho phép các nhà phát triển xây dựng các ứng dụng mạnh mẽ, hiệu quả, tận dụng sức mạnh và tính linh hoạt của nền tảng Kubernetes trong khi vẫn duy trì một cách tiếp cận phát triển tập trung vào Rust. Sự tích hợp này hợp lý hóa quá trình xây dựng và quản lý các ứng dụng Kubernetes phức tạp, biến nó thành một công cụ có giá trị trong cơ sở hạ tầng của Hugging Face.

Sự tích hợp của Hugging Face với Kubernetes là một nền tảng của cơ sở hạ tầng của chúng ta và thư viện kube-rs đóng một vai trò quan trọng trong việc quản lý hệ sinh thái này. Mô-đun kube::api:: là công cụ giúp tự động hóa các tác vụ khác nhau, chẳng hạn như quản lý chứng chỉ HTTPS cho các tên miền tùy chỉnh hỗ trợ sản phẩm Spaces của chúng ta. Bằng cách xử lý theo chương trình vòng đời chứng chỉ, chúng ta đảm bảo tính bảo mật và khả năng truy cập của các dịch vụ của mình, cung cấp cho người dùng trải nghiệm liền mạch. Ngoài ra, chúng ta đã sử dụng mô-đun này bên ngoài các tính năng hướng đến người dùng trong quá trình bảo trì định kỳ để tạo điều kiện thuận lợi cho việc rút và chấm dứt nút, cung cấp sự ổn định của cụm trong quá trình cập nhật cơ sở hạ tầng.

Mô-đun kube::runtime:: cũng rất quan trọng đối với chúng ta, cho phép phát triển và triển khai các bộ điều khiển tùy chỉnh giúp tăng cường khả năng tự động hóa và khả năng phục hồi của cơ sở hạ tầng của chúng ta. Ví dụ: chúng ta đã triển khai các bộ điều khiển để quản lý thanh toán trong các dịch vụ được quản lý của chúng ta, trong đó trình theo dõi và trình hoàn thiện trên các pod của khách hàng đảm bảo theo dõi tài nguyên và thanh toán chính xác. Mức độ tùy chỉnh này cho phép chúng ta điều chỉnh Kubernetes theo nhu cầu cụ thể của chúng ta.

Thông qua kube-rs, Hugging Face đã đạt được mức độ hiệu quả, độ tin cậy và khả năng kiểm soát cao đối với các ứng dụng gốc đám mây của chúng ta. Thiết kế tập trung vào Rust của thư viện phù hợp với triết lý kỹ thuật của chúng ta, cho phép chúng ta tận dụng các điểm mạnh của Rust trong việc quản lý các tài nguyên Kubernetes. Bằng cách tự động hóa các tác vụ quan trọng và xây dựng các bộ điều khiển tùy chỉnh, chúng ta đã tạo ra một cơ sở hạ tầng có khả năng mở rộng, tự phục hồi đáp ứng các nhu cầu đa dạng và ngày càng phát triển của người dùng và khách hàng doanh nghiệp của chúng ta. Sự tích hợp này chứng minh cam kết của chúng ta trong việc khai thác toàn bộ tiềm năng của Kubernetes trong khi vẫn duy trì một cách tiếp cận phát triển phù hợp với các yêu cầu riêng của chúng ta.

Mặc dù cơ sở hạ tầng của chúng ta hiếm khi gặp phải các sự cố liên quan đến API Kubernetes, nhưng chúng ta vẫn luôn cảnh giác, đặc biệt là trong và sau khi triển khai. API Kubernetes là một thành phần quan trọng trong việc chúng ta sử dụng kube::runtime:: để quản lý các pod của khách hàng và các tài nguyên mạng đám mây. Bất kỳ sự gián đoạn hoặc không hiệu quả nào trong giao tiếp API đều có thể có tác động tầng lên các dịch vụ của chúng ta, có khả năng dẫn đến thời gian ngừng hoạt động hoặc hiệu suất bị suy giảm.

Tầm quan trọng của việc giám sát các số liệu API này được nhấn mạnh bởi kinh nghiệm của những người dùng Kubernetes khác. Ví dụ: OpenAI đã chia sẻ một cập nhật trạng thái chi tiết cách các vấn đề về tính khả dụng của DNS dẫn đến thời gian ngừng hoạt động đáng kể. Mặc dù không liên quan trực tiếp đến API Kubernetes, nhưng kinh nghiệm của họ nhấn mạnh sự kết nối lẫn nhau của các thành phần cơ sở hạ tầng khác nhau và khả năng xảy ra các lỗi xếp tầng. Giống như tính khả dụng của DNS rất quan trọng đối với khả năng truy cập ứng dụng, một API Kubernetes khỏe mạnh và phản hồi nhanh là điều cần thiết để quản lý và điều phối khối lượng công việc được container hóa của chúng ta.

Như một thực hành tốt nhất, chúng ta đã tích hợp các số liệu API này vào các hệ thống giám sát và cảnh báo của mình, đảm bảo rằng bất kỳ sự bất thường hoặc xu hướng nào cũng được chúng ta chú ý kịp thời. Điều này cho phép chúng ta thực hiện một cách tiếp cận chủ động, điều tra và giải quyết các vấn đề trước khi chúng ảnh hưởng đến khách hàng của chúng ta. Ví dụ: vào một dịp, một cụm duy nhất bắt đầu giới hạn tốc độ các yêu cầu đến API Kubernetes. Chúng ta đã có thể lần theo dấu vết này trở lại một trong những công cụ của bên thứ ba của chúng ta gặp phải một lỗi và liên tục yêu cầu một nút được rút ngay cả khi nó đã thực hiện xong. Để đáp lại, chúng ta đã có thể xóa công việc bị trục trặc khỏi hệ thống trước khi bất kỳ sự suy giảm đáng chú ý nào ảnh hưởng đến người dùng của chúng ta. Đây là một ví dụ điển hình cho thấy các kịch bản cảnh báo không chỉ xảy ra ngay sau khi triển khai các phiên bản mới của bộ điều khiển tùy chỉnh của chúng ta — các lỗi có thể mất thời gian để biểu hiện thành các vấn đề sản xuất.

Tóm lại, mặc dù cơ sở hạ tầng của chúng ta mạnh mẽ và được xây dựng tốt, nhưng chúng ta nhận ra rằng sự cảnh giác và giám sát chủ động là điều cần thiết để duy trì sức khỏe và sự ổn định của nó. Bằng cách theo dõi chặt chẽ tỷ lệ lỗi API Kubernetes và các số liệu giới hạn tốc độ, chúng ta bảo vệ các dịch vụ được quản lý của mình, đảm bảo trải nghiệm khách hàng mượt mà và duy trì cam kết của chúng ta về độ tin cậy và hiệu suất. Đây là một minh chứng cho niềm tin của chúng ta rằng trong thế giới công nghệ gốc đám mây, mọi thành phần, dù nhỏ đến đâu, đều đóng một vai trò quan trọng trong khả năng phục hồi và thành công chung của nền tảng của chúng ta.

Cảnh báo bổ sung: Cụm mới gửi không số liệu

Và một cảnh báo bổ sung cuối cùng cho việc đọc bài đăng này đến tận đây!

Tại Hugging Face, các thử nghiệm của chúng ta liên tục thay đổi, thường xuyên có các cụm phù hợp với mục đích được khởi động và tắt khi chúng ta lặp lại các tính năng và sản phẩm. Để tăng thêm entropy, sự phát triển của chúng ta cũng là một yếu tố quan trọng, với các cụm mở rộng đến giới hạn của chúng và kích hoạt các phân chia giống như giảm phân để duy trì sự cân bằng. Để điều hướng môi trường năng động này mà không cần dùng đến mã hóa cứng hoặc giới thiệu thêm một lớp khám phá cụm, chúng ta đã nghĩ ra một cảnh báo thông minh thích ứng với những thay đổi này.

(
  (sum by (cluster) (rate(container_network_transmit_packets_total{pod="prometheus"}[1h] ) ) > 0)
or
  (-1 * (sum by (cluster) (rate(container_network_transmit_packets_total{pod="prometheus"}[1h] offset 48h) ) > 0))
) < 0

Số liệu được sử dụng trong truy vấn này là container_network_transmit_packets_total, đại diện cho tổng số gói được truyền bởi một контейнер. Truy vấn đang lọc các số liệu từ phiên bản Prometheus cục bộ của một cụm, có nhiệm vụ thu thập số liệu cũng như ghi từ xa vào хранилище số liệu trung tâm của chúng ta — Grafana Mimir. Việc truyền các gói gần đúng với ghi từ xa khỏe mạnh, đó là những gì chúng ta muốn đảm bảo trên tất cả các cụm đang hoạt động.

Phần đầu tiên của truy vấn thực hiện kiểm tra tỷ lệ hiện tại. Phần thứ hai của truy vấn thực hiện kiểm tra tỷ lệ lịch sử bằng cách sử dụng cùng một phép tính như kiểm tra tỷ lệ hiện tại cộng với một mệnh đề offset 48h. Phép nhân -1 * được sử dụng để đảo ngược kết quả, sao cho nếu tỷ lệ lịch sử lớn hơn 0, kết quả sẽ nhỏ hơn 0.

Toán tử or kết hợp hai phần của truy vấn. Truy vấn sẽ trả về true nếu một trong các điều kiện sau được đáp ứng:

• Tỷ lệ truyền gói hiện tại cho một cụm lớn hơn 0.
• Tỷ lệ truyền gói lịch sử cho một cụm (cách đây 48 giờ) lớn hơn 0, nhưng tỷ lệ hiện tại thì không.

Điều kiện < 0 bên ngoài kiểm tra xem kết quả của hoạt động or có nhỏ hơn 0 hay không. Điều này có nghĩa là truy vấn sẽ chỉ kích hoạt nếu không có điều kiện nào được đáp ứng, tức là nếu một cụm chưa bao giờ gửi bất kỳ số liệu nào (cả tỷ lệ hiện tại và lịch sử đều là 0).

Có hai trường hợp truy vấn sẽ kích hoạt:

1. Cụm mới không có số liệu: Một cụm mới được thêm vào, nhưng nó chưa gửi bất kỳ số liệu nào. Trong trường hợp này, cả tỷ lệ hiện tại và lịch sử đều sẽ là 0 và truy vấn sẽ kích hoạt.
2. Cụm chưa bao giờ gửi số liệu: Một cụm đã có mặt trong hơn 48 giờ, nhưng nó chưa bao giờ gửi bất kỳ số liệu nào. Trong trường hợp này, tỷ lệ lịch sử sẽ là 0 và tỷ lệ hiện tại cũng sẽ là 0, kích hoạt truy vấn.

Trong cả hai trường hợp, truy vấn sẽ phát hiện ra rằng cụm không gửi bất kỳ số liệu nào và kích hoạt cảnh báo.

Giải pháp đơn giản nhưng hiệu quả này được kích hoạt trong các kịch bản mà cơ sở hạ tầng số liệu của chúng ta gặp sự cố, trong quá trình thiết lập cụm và khi chúng bị phá hủy, cung cấp cho chúng ta những thông tin chi tiết kịp thời về tình trạng cơ sở hạ tầng của chúng ta. Mặc dù nó có thể không phải là cảnh báo quan trọng nhất trong kho vũ khí của chúng ta, nhưng nó giữ một vị trí đặc biệt vì nó được sinh ra từ sự hợp tác. Nó là một minh chứng cho sức mạnh của làm việc nhóm thông qua xem xét mã nghiêm ngặt, được thực hiện nhờ chuyên môn và sự sẵn sàng giúp đỡ của các đồng nghiệp trong nhóm cơ sở hạ tầng Hugging Face 🤗

Kết luận

Trong bài đăng này, chúng ta đã chia sẻ một số cảnh báo yêu thích của mình hỗ trợ cơ sở hạ tầng tại Hugging Face. Chúng ta cũng rất muốn nghe những cảnh báo yêu thích của nhóm bạn!

Bạn đang giám sát cơ sở hạ tầng ML của mình như thế nào? Những cảnh báo nào khiến nhóm của bạn quay lại để sửa chữa? Điều gì thường xuyên bị hỏng trong cơ sở hạ tầng của bạn hoặc ngược lại, bạn chưa bao giờ giám sát điều gì và nó chỉ hoạt động?

Hãy chia sẻ với chúng tôi trong các bình luận bên dưới!

Link bài viết gốc

• Tags:
• Ai
• July 8, 2025
• Huggingface.co