SRE (Site Reliability Engineering) là một cách tiếp cận để làm cho các dự án web có thể truy cập được. Nó được coi là một khuôn khổ cho DevOps và cho biết cách thành công trong việc áp dụng các phương pháp DevOps. Bài viết này dịch sách từ Google. Tôi đã tự chuẩn bị bản dịch này và dựa trên kinh nghiệm của bản thân trong việc tìm hiểu các quy trình giám sát. Trong kênh điện tín и Tôi cũng đã đăng một liên kết đến bản dịch Chương 4 của cùng một cuốn sách về Mục tiêu cấp độ dịch vụ.
Bản dịch của mèo. Thích đọc sách!
Nhóm Google SRE có các nguyên tắc cơ bản và phương pháp hay nhất để xây dựng hệ thống giám sát và thông báo thành công. Chương này cung cấp các đề xuất về những vấn đề mà người truy cập trang web có thể gặp phải và cách giải quyết các vấn đề gây khó khăn cho việc hiển thị các trang web.
Định nghĩa
Không có từ vựng duy nhất được sử dụng để thảo luận về các chủ đề liên quan đến giám sát. Ngay cả trên Google, các thuật ngữ dưới đây không được sử dụng phổ biến nhưng chúng tôi sẽ liệt kê những cách hiểu phổ biến nhất.
Giám sát
Thu thập, xử lý, tổng hợp và hiển thị dữ liệu định lượng theo thời gian thực về hệ thống: số lượng yêu cầu và loại yêu cầu, số lỗi và loại lỗi, thời gian xử lý yêu cầu và thời gian hoạt động của máy chủ.
Giám sát hộp trắng
Giám sát dựa trên số liệu được hiển thị bởi nội bộ hệ thống, bao gồm nhật ký, số liệu hồ sơ trình xử lý JVM hoặc HTTP tạo số liệu thống kê nội bộ.
giám sát hộp đen
Kiểm tra hành vi của ứng dụng từ quan điểm của người dùng.
Bảng điều khiển (dashboard)
Một giao diện (thường là giao diện web) cung cấp tổng quan về các chỉ báo tình trạng chính của dịch vụ. Trang tổng quan có thể có các bộ lọc, khả năng chọn số liệu sẽ hiển thị, v.v... Giao diện được thiết kế để xác định các số liệu quan trọng nhất cho người dùng. Bảng điều khiển cũng có thể hiển thị thông tin cho nhân viên hỗ trợ kỹ thuật: hàng đợi yêu cầu, danh sách các lỗi có mức độ ưu tiên cao, kỹ sư được chỉ định cho một khu vực trách nhiệm nhất định.
Cảnh báo (thông báo)
Thông báo dự định được nhận bởi một người qua e-mail hoặc cách khác, có thể được kích hoạt do lỗi hoặc sự gia tăng trong hàng đợi yêu cầu. Thông báo được phân loại thành: vé, thông báo qua email và tin nhắn nhắn tin.
Nguyên nhân gốc rễ (nguyên nhân gốc rễ)
Một lỗi phần mềm hoặc lỗi của con người, khi được sửa chữa, sẽ không xảy ra nữa. Vấn đề có thể có một số lý do chính: không đủ tự động hóa quy trình, lỗi phần mềm, nghiên cứu logic ứng dụng không đầy đủ. Mỗi yếu tố trong số này có thể là nguyên nhân gốc rễ và mỗi yếu tố trong số chúng phải được loại bỏ.
Nút và máy (node and machine)
Các thuật ngữ có thể hoán đổi cho nhau để chỉ một phiên bản duy nhất của ứng dụng đang chạy trên máy chủ vật lý, máy ảo hoặc bộ chứa. Có thể có một số dịch vụ trên một máy. Dịch vụ có thể là:
- liên quan đến nhau: ví dụ: máy chủ bộ đệm và máy chủ web;
- các dịch vụ không liên quan trên cùng một phần cứng: ví dụ: kho lưu trữ mã và trình hướng dẫn cho hệ thống cấu hình, chẳng hạn như hoặc .
Đẩy
Bất kỳ thay đổi nào đối với cấu hình phần mềm.
Tại sao cần giám sát
Có một số lý do tại sao các ứng dụng nên được giám sát:
Phân tích các xu hướng dài hạn
Cơ sở dữ liệu lớn như thế nào và nó phát triển nhanh như thế nào? Số lượng người dùng hàng ngày thay đổi như thế nào?
So sánh hiệu suất
Các truy vấn trên Acme Bucket of Bytes 2.72 có nhanh hơn Ajax DB 3.14 không? Các yêu cầu được lưu trong bộ nhớ cache tốt hơn bao nhiêu sau khi xuất hiện một nút bổ sung? Trang web có trở nên chậm hơn so với tuần trước không?
Cảnh báo (thông báo)
Một cái gì đó bị hỏng và ai đó phải sửa chữa nó. Hoặc một cái gì đó sẽ sớm bị hỏng và ai đó phải kiểm tra nó sớm.
Tạo trang tổng quan
Trang tổng quan nên trả lời các câu hỏi cơ bản và bao gồm nội dung nào đó từ - độ trễ (latency), lưu lượng (traffic), lỗi (errors) và giá trị tải (saturation).
Tiến hành phân tích hồi cứu (gỡ lỗi)
Độ trễ xử lý yêu cầu tăng lên, điều gì khác đã xảy ra cùng lúc?
Các hệ thống giám sát rất hữu ích như một nguồn dữ liệu cho các hệ thống kinh doanh thông minh và để tạo thuận lợi cho việc phân tích các sự cố bảo mật. Vì cuốn sách này tập trung vào các lĩnh vực kỹ thuật mà các SRE có chuyên môn nên chúng tôi sẽ không thảo luận về các kỹ thuật giám sát ở đây.
Giám sát và cảnh báo cho phép hệ thống biết khi nào nó bị hỏng hoặc sắp bị hỏng. Khi một hệ thống không thể tự động sửa chữa, chúng tôi muốn con người phân tích cảnh báo, xác định xem sự cố có còn tồn tại hay không, khắc phục sự cố và xác định nguyên nhân gốc rễ của sự cố. Nếu bạn không kiểm tra các thành phần hệ thống, bạn sẽ không bao giờ nhận được cảnh báo chỉ vì "có gì đó hơi kỳ lạ".
Tải cảnh báo của con người là cách sử dụng thời gian của nhân viên khá tốn kém. Nếu nhân viên đang làm việc, cảnh báo sẽ làm gián đoạn quy trình làm việc. Nếu nhân viên đang ở nhà, cảnh báo sẽ làm gián đoạn thời gian cá nhân và có thể là giấc ngủ. Khi cảnh báo xảy ra quá thường xuyên, nhân viên sẽ lướt qua, trì hoãn hoặc bỏ qua các cảnh báo đến. Đôi khi, họ bỏ qua cảnh báo thực sự, được che đậy bởi các sự kiện tiếng ồn. Sự gián đoạn dịch vụ có thể kéo dài trong một thời gian dài do các sự kiện tiếng ồn ngăn cản việc chẩn đoán và giải quyết vấn đề nhanh chóng. Các hệ thống địa chỉ công cộng hiệu quả có tỷ lệ tín hiệu trên tạp âm tốt.
Xác định kỳ vọng hợp lý từ hệ thống giám sát
Bản thân việc thiết lập giám sát cho một ứng dụng phức tạp là một nhiệm vụ kỹ thuật phức tạp. Ngay cả khi có cơ sở hạ tầng quan trọng gồm các công cụ thu thập, hiển thị và cảnh báo, nhóm Google SRE gồm 10-12 thành viên thường bao gồm một hoặc hai người có mục đích chính là xây dựng và duy trì hệ thống giám sát. Con số này đã giảm theo thời gian khi chúng tôi khái quát hóa và tập trung hóa cơ sở hạ tầng giám sát, nhưng mỗi nhóm SRE thường có ít nhất một nhân viên chỉ giám sát. Phải nói rằng mặc dù khá thú vị khi xem các bảng điều khiển của hệ thống giám sát, các nhóm SRE vẫn cẩn thận tránh các tình huống yêu cầu ai đó nhìn vào màn hình để giám sát các vấn đề.
Nói chung, Google đã chuyển sang các hệ thống giám sát đơn giản và nhanh chóng với các công cụ phân tích sau thực tế tối ưu. Chúng tôi tránh các hệ thống "ma thuật" cố gắng dự đoán ngưỡng hoặc tự động khám phá nguyên nhân gốc rễ. Các cảm biến phát hiện nội dung không mong muốn trong yêu cầu của người dùng cuối là ví dụ duy nhất; miễn là các cảm biến này vẫn đơn giản, chúng có thể nhanh chóng phát hiện ra nguyên nhân của những bất thường nghiêm trọng. Các định dạng khác để sử dụng dữ liệu giám sát, chẳng hạn như lập kế hoạch năng lực hoặc dự báo lưu lượng, khó khăn hơn. Một quan sát trong thời gian rất dài (tháng hoặc năm) với tốc độ lấy mẫu thấp (giờ hoặc ngày) sẽ cho thấy xu hướng dài hạn.
Nhóm Google SRE đã làm việc với các mức độ thành công khác nhau với các hệ thống phân cấp phụ thuộc phức tạp. Chúng tôi hiếm khi sử dụng các quy tắc như "nếu tôi phát hiện ra rằng cơ sở dữ liệu trở nên chậm chạp, tôi sẽ nhận được cảnh báo làm chậm cơ sở dữ liệu, nếu không, tôi sẽ nhận được cảnh báo trang web chậm." Các quy tắc dựa trên sự phụ thuộc thường đề cập đến các phần không thay đổi trong hệ thống của chúng tôi, chẳng hạn như hệ thống lọc lưu lượng người dùng đến trung tâm dữ liệu. Ví dụ: "nếu tính năng lọc lưu lượng truy cập trung tâm dữ liệu được định cấu hình, thì không thông báo cho tôi về sự chậm trễ trong việc xử lý yêu cầu của người dùng" là một quy tắc chung cho các cảnh báo của trung tâm dữ liệu. Rất ít nhóm tại Google hỗ trợ hệ thống phân cấp phụ thuộc phức tạp vì cơ sở hạ tầng của chúng tôi có tốc độ tái cấu trúc liên tục không đổi.
Một số ý tưởng được nêu trong chương này vẫn đúng: luôn có cách để chuyển nhanh hơn từ triệu chứng sang nguyên nhân gốc rễ, đặc biệt là trong các hệ thống luôn thay đổi. Do đó, trong khi chương này vạch ra một số mục tiêu cho hệ thống giám sát và cách đạt được những mục tiêu đó, điều quan trọng là hệ thống giám sát phải đơn giản và dễ hiểu đối với mọi người trong nhóm.
Tương tự như vậy, để giữ mức nhiễu thấp và mức tín hiệu cao, các phương pháp giám sát các đối tượng đang được cảnh báo phải rất đơn giản và đáng tin cậy. Các quy tắc tạo cảnh báo cho con người phải dễ hiểu và trình bày vấn đề rõ ràng.
Triệu chứng so với nguyên nhân
Hệ thống giám sát của bạn phải trả lời hai câu hỏi: “cái gì bị hỏng” và “tại sao nó bị hỏng”.
“Cái gì đã hỏng” đề cập đến triệu chứng và “tại sao lại hỏng” đề cập đến nguyên nhân. Bảng dưới đây cho thấy các ví dụ về các liên kết như vậy.
Triệu chứng
Nguyên nhân
Nhận lỗi HTTP 500 hoặc 404
Máy chủ cơ sở dữ liệu đang từ chối kết nối
Máy chủ phản hồi chậm
Sử dụng CPU cao hoặc cáp Ethernet bị hỏng
Người dùng ở Nam Cực không nhận được ảnh GIF về mèo
CDN của bạn ghét các nhà khoa học và mèo, vì vậy một số IP bị đưa vào danh sách đen
Nội dung riêng tư có sẵn ở mọi nơi
Tung ra bản phát hành phần mềm mới khiến tường lửa quên tất cả ACL và cho phép mọi người vào
"Cái gì" và "tại sao" là một trong những khối xây dựng quan trọng nhất để tạo ra một hệ thống giám sát tốt với tín hiệu tối đa và tiếng ồn tối thiểu.
Hộp đen so với Hộp trắng
Chúng tôi kết hợp giám sát hộp trắng mở rộng với giám sát hộp đen khiêm tốn cho các chỉ số quan trọng. Cách dễ nhất để so sánh Hộp đen với Hộp trắng là Hộp đen tập trung vào triệu chứng và mang tính phản ứng hơn là theo dõi chủ động: “hiện tại hệ thống không hoạt động bình thường”. Hộp trắng phụ thuộc vào khả năng kiểm tra nội bộ của hệ thống: nhật ký sự kiện hoặc máy chủ web. Do đó, Hộp trắng cho phép bạn phát hiện các sự cố sắp xảy ra, các sự cố trông giống như truyền lại yêu cầu, v.v.
Lưu ý rằng trong một hệ thống nhiều lớp, một triệu chứng trong khu vực trách nhiệm của một kỹ sư là một triệu chứng trong khu vực trách nhiệm của một kỹ sư khác. Ví dụ, hiệu suất cơ sở dữ liệu đã giảm. Cơ sở dữ liệu đọc chậm là một triệu chứng của cơ sở dữ liệu SRE phát hiện ra chúng. Tuy nhiên, đối với một SRE giao diện người dùng xem một trang web chậm, lý do cho cùng một cơ sở dữ liệu chậm được đọc là do cơ sở dữ liệu chậm. Do đó, giám sát hộp trắng đôi khi tập trung vào các triệu chứng và đôi khi tập trung vào nguyên nhân, tùy thuộc vào mức độ lan rộng của nó.
Khi thu thập phép đo từ xa để gỡ lỗi, cần phải giám sát hộp trắng. Nếu máy chủ web phản hồi chậm các truy vấn cơ sở dữ liệu, bạn cần biết máy chủ web đang giao tiếp với cơ sở dữ liệu nhanh như thế nào và tốc độ phản hồi của nó. Nếu không, bạn sẽ không thể phân biệt được sự khác biệt giữa máy chủ cơ sở dữ liệu chậm và sự cố mạng giữa máy chủ web và cơ sở dữ liệu.
Giám sát hộp đen có một lợi thế chính khi gửi cảnh báo: bạn kích hoạt thông báo cho người nhận khi sự cố đã gây ra các triệu chứng thực tế. Mặt khác, đối với sự cố Hộp đen chưa phát sinh nhưng sắp xảy ra thì việc giám sát là vô ích.
Bốn tín hiệu vàng
Bốn tín hiệu giám sát vàng là độ trễ, lưu lượng truy cập, lỗi và độ bão hòa. Nếu bạn chỉ có thể đo bốn chỉ số hệ thống người dùng, hãy tập trung vào bốn chỉ số đó.
Trì hoãn
Thời gian cần thiết để xử lý yêu cầu. Điều quan trọng là phải phân biệt giữa độ trễ của các yêu cầu thành công và không thành công. Ví dụ: lỗi HTTP 500 do mất kết nối với cơ sở dữ liệu hoặc chương trình phụ trợ khác có thể được chẩn đoán rất nhanh, tuy nhiên, lỗi HTTP 500 có thể cho biết yêu cầu không thành công. Việc tìm ra tác động của lỗi 500 đối với độ trễ tổng thể có thể dẫn đến kết luận sai lầm. Mặt khác, một lỗi chậm thậm chí là một lỗi nhanh! Do đó, điều quan trọng là phải theo dõi độ trễ của lỗi thay vì chỉ lọc ra các lỗi.
giao thông
Số lượng yêu cầu đối với hệ thống của bạn, được đo bằng chỉ số hệ thống cấp cao. Đối với dịch vụ web, phép đo này thường biểu thị số lượng yêu cầu HTTP mỗi giây chia cho bản chất của yêu cầu (ví dụ: nội dung tĩnh hoặc động). Đối với hệ thống phát trực tuyến âm thanh, phép đo này có thể tập trung vào tốc độ I/O của mạng hoặc số lượng phiên đồng thời. Đối với hệ thống lưu trữ khóa-giá trị, phép đo này có thể là giao dịch hoặc tra cứu mỗi giây.
Sai lầm
Đây là tỷ lệ yêu cầu không thành công, rõ ràng (ví dụ: HTTP 500), ngầm (ví dụ: HTTP 200 nhưng được kết hợp với nội dung xấu) hoặc theo chính sách (ví dụ: "Nếu bạn nhận được phản hồi trong một giây, bất kỳ một giây là lỗi"). Nếu không có đủ mã phản hồi HTTP để thể hiện tất cả các điều kiện lỗi, các giao thức phụ (nội bộ) có thể được yêu cầu để phát hiện lỗi một phần. Theo dõi tất cả các yêu cầu sai như vậy có thể không mang lại thông tin, trong khi kiểm tra hệ thống từ đầu đến cuối có thể giúp bạn phát hiện ra rằng bạn đang xử lý nội dung sai.
bão hòa
Số liệu cho biết mức độ sử dụng dịch vụ của bạn. Đây là biện pháp giám sát hệ thống nhằm xác định các tài nguyên bị hạn chế nhất (ví dụ: trong hệ thống có bộ nhớ hạn chế, hiển thị bộ nhớ, trong hệ thống có I/O hạn chế, hiển thị số lượng I/O). Lưu ý rằng nhiều hệ thống xuống cấp trước khi đạt mức sử dụng 100%, do đó, việc có mục tiêu sử dụng là điều cần thiết.
Trong các hệ thống phức tạp, độ bão hòa có thể được bổ sung bằng phép đo tải ở cấp độ cao hơn: dịch vụ của bạn có thể xử lý đúng lưu lượng truy cập gấp đôi, chỉ xử lý lưu lượng truy cập nhiều hơn 10% hoặc thậm chí xử lý ít lưu lượng truy cập hơn hiện tại không? Đối với các dịch vụ đơn giản không có tham số làm thay đổi độ phức tạp của yêu cầu (ví dụ: "Không cho tôi gì cả" hoặc "Tôi muốn một số nguyên đơn điệu duy nhất") mà hiếm khi thay đổi cấu hình, giá trị kiểm tra tải tĩnh có thể là đủ. Tuy nhiên, như đã thảo luận trong đoạn trước, hầu hết các dịch vụ nên sử dụng các tín hiệu gián tiếp như mức sử dụng CPU hoặc băng thông mạng có giới hạn trên đã biết. Độ trễ tăng thường là chỉ báo chính về độ bão hòa. Đo thời gian phản hồi phân vị thứ 99 trong một cửa sổ nhỏ (ví dụ: một phút) có thể đưa ra tín hiệu bão hòa rất sớm.
Cuối cùng, độ bão hòa cũng liên quan đến các dự đoán về độ bão hòa sắp xảy ra, chẳng hạn như: "Có vẻ như cơ sở dữ liệu của bạn sẽ lấp đầy ổ cứng của bạn sau 4 giờ nữa".
Nếu bạn đo lường cả bốn tín hiệu vàng và khi có vấn đề với một trong các chỉ số (hoặc, trong trường hợp bão hòa, gần như có vấn đề), bạn thông báo cho người đó, dịch vụ của bạn ít nhiều sẽ bị giám sát.
Lo lắng về phần đuôi (hoặc thiết bị đo đạc và hiệu suất)
Khi xây dựng một hệ thống giám sát từ đầu, bạn nên phát triển một hệ thống dựa trên các mức trung bình: độ trễ trung bình, mức sử dụng CPU trung bình của nút hoặc mức chiếm dụng cơ sở dữ liệu trung bình. Sự nguy hiểm của hai ví dụ cuối cùng là rõ ràng: bộ xử lý và cơ sở dữ liệu được xử lý theo một cách rất khó đoán. Điều tương tự áp dụng cho sự chậm trễ. Nếu bạn đang chạy một dịch vụ web có độ trễ trung bình là 100 mili giây với 1000 yêu cầu mỗi giây, thì 1% yêu cầu có thể mất 5 giây. Nếu người dùng phụ thuộc vào nhiều dịch vụ web như vậy, phân vị thứ 99 của một chương trình phụ trợ có thể dễ dàng trở thành thời gian phản hồi trung bình của giao diện.
Cách đơn giản nhất để phân biệt giữa yêu cầu trung bình chậm và yêu cầu rất chậm là thu thập phép đo các yêu cầu được thể hiện trong số liệu thống kê (biểu đồ là công cụ phù hợp để hiển thị), thay vì độ trễ thực tế: có bao nhiêu yêu cầu được phục vụ bởi dịch vụ đã thực hiện từ 0 mili giây đến 10 mili giây, từ 10 mili giây đến 30 mili giây, từ 30 mili giây đến 100 mili giây, từ 100 mili giây đến 300 mili giây, v.v. Mở rộng giới hạn biểu đồ xấp xỉ theo cấp số nhân (theo hệ số khoảng 3) thường là một cách dễ dàng để trực quan hóa phân phối truy vấn.
Chọn độ chi tiết phù hợp cho các phép đo
Các yếu tố khác nhau của hệ thống nên được đo lường với các mức độ chi tiết khác nhau. Ví dụ:
- Việc theo dõi mức sử dụng sử dụng CPU trong một khoảng thời gian sẽ không hiển thị các đợt tăng đột biến kéo dài dẫn đến độ trễ cao.
- Mặt khác, đối với dịch vụ web nhắm mục tiêu không quá 9 giờ ngừng hoạt động mỗi năm (99,9% thời gian hoạt động hàng năm), việc kiểm tra phản hồi HTTP 200 nhiều hơn một hoặc hai lần mỗi phút có thể là thường xuyên không cần thiết.
- Tương tự, việc kiểm tra dung lượng trống trên ổ cứng để biết độ khả dụng 99,9% nhiều hơn 1-2 phút một lần có lẽ là không cần thiết.
Hãy quan tâm đến cách bạn cấu trúc mức độ chi tiết của kích thước. Tốc độ sử dụng CPU là 1 mỗi giây có thể cung cấp dữ liệu thú vị, nhưng các phép đo thường xuyên như vậy có thể rất tốn kém để thu thập, lưu trữ và phân tích. Nếu mục tiêu giám sát của bạn yêu cầu mức độ chi tiết cao và không yêu cầu khả năng phản hồi cao, bạn có thể giảm các chi phí này bằng cách thiết lập bộ sưu tập số liệu trên máy chủ, sau đó định cấu hình hệ thống bên ngoài để thu thập và tổng hợp các số liệu đó. Bạn có thể:
- Đo mức sử dụng CPU mỗi giây.
- Giảm chi tiết xuống 5%.
- Tổng hợp số liệu mỗi phút.
Chiến lược này sẽ cho phép bạn thu thập dữ liệu chi tiết cao mà không gặp phải chi phí phân tích và lưu trữ cao.
Đơn giản nhất có thể, nhưng không dễ dàng hơn
Xếp chồng các yêu cầu khác nhau lên nhau có thể dẫn đến một hệ thống giám sát rất phức tạp. Ví dụ: hệ thống của bạn có thể có các yếu tố phức tạp sau:
- Cảnh báo theo các ngưỡng khác nhau đối với độ trễ của yêu cầu, theo các phần trăm khác nhau, trên tất cả các loại số liệu khác nhau.
- Viết mã bổ sung để phát hiện và xác định các nguyên nhân có thể xảy ra.
- Tạo các bảng thông tin liên quan cho từng nguyên nhân có thể gây ra sự cố.
Các nguồn phức tạp tiềm năng không bao giờ kết thúc. Giống như tất cả các hệ thống phần mềm, việc giám sát có thể trở nên phức tạp đến mức trở nên mong manh, khó thay đổi và bảo trì.
Do đó, hãy thiết kế hệ thống giám sát của bạn để đơn giản hóa nó càng nhiều càng tốt. Khi chọn những gì để theo dõi, hãy ghi nhớ những điều sau:
- Các quy tắc thường nắm bắt các sự cố thực tế nhất phải đơn giản, có thể dự đoán và đáng tin cậy nhất có thể.
- Cấu hình để thu thập, tổng hợp và cảnh báo dữ liệu được thực hiện không thường xuyên (ví dụ: ít hơn hàng quý đối với một số nhóm SRE) nên bị xóa.
- Các chỉ số được thu thập nhưng không hiển thị trong bất kỳ bảng xem trước nào hoặc được sử dụng bởi bất kỳ cảnh báo nào đều có thể bị xóa.
Tại Google, việc thu thập và tổng hợp các số liệu cơ bản, kết hợp với cảnh báo và trang tổng quan, hoạt động tốt như một hệ thống tương đối khép kín (hệ thống giám sát của Google thực sự được chia thành nhiều hệ thống con, nhưng mọi người thường biết về tất cả các khía cạnh của các hệ thống con này). Việc kết hợp giám sát với các phương pháp kiểm tra hệ thống phức tạp khác có thể rất hấp dẫn: lập hồ sơ hệ thống chi tiết, gỡ lỗi quy trình, theo dõi chi tiết ngoại lệ hoặc lỗi, kiểm tra tải, thu thập và phân tích nhật ký hoặc kiểm tra lưu lượng. Mặc dù hầu hết những điều này đều có điểm chung với giám sát cơ bản, nhưng việc trộn lẫn chúng sẽ dẫn đến quá nhiều kết quả và tạo ra một hệ thống phức tạp và dễ vỡ. Cũng như nhiều khía cạnh khác của phát triển phần mềm, hỗ trợ các hệ thống khác nhau với các điểm tích hợp rõ ràng, đơn giản, liên kết lỏng lẻo là chiến lược tốt nhất (ví dụ: sử dụng API web để truy xuất dữ liệu tóm tắt ở định dạng có thể không đổi trong một khoảng thời gian dài ).
Liên kết các nguyên tắc với nhau
Các nguyên tắc được thảo luận trong chương này có thể được kết hợp thành một triết lý giám sát và cảnh báo được các nhóm Google SRE xác nhận và tuân theo. Tuân thủ triết lý giám sát này là điều nên làm, đây là điểm khởi đầu tốt để tạo hoặc sửa đổi phương pháp cảnh báo và có thể giúp bạn đặt câu hỏi phù hợp cho các hoạt động bất kể quy mô tổ chức của bạn hay mức độ phức tạp của dịch vụ hoặc hệ thống.
Khi tạo các quy tắc giám sát và cảnh báo, việc đặt các câu hỏi sau đây có thể giúp bạn tránh các thông báo sai và cảnh báo không cần thiết:
- Quy tắc này có phát hiện trạng thái hệ thống khẩn cấp, kêu gọi hành động và chắc chắn ảnh hưởng đến người dùng không?
- Tôi có thể bỏ qua cảnh báo này khi biết nó lành tính không? Khi nào và tại sao tôi có thể bỏ qua cảnh báo này và làm cách nào để tránh tình huống này?
- Cảnh báo này có nghĩa là người dùng đang bị ảnh hưởng bất lợi không? Có tình huống nào mà người dùng không bị ảnh hưởng tiêu cực, chẳng hạn như do lọc lưu lượng truy cập hoặc khi sử dụng hệ thống kiểm tra, các cảnh báo sẽ được lọc không?
- Tôi có thể thực hiện hành động để đáp lại cảnh báo này không? Những biện pháp này có khẩn cấp hay họ có thể đợi đến sáng? Có an toàn để tự động hóa hành động? Hành động này sẽ là một giải pháp lâu dài hay một cách giải quyết ngắn hạn?
- Một số người nhận được nhiều cảnh báo về vấn đề này, vậy có thể giảm số lượng không?
Những câu hỏi này phản ánh triết lý cơ bản về cảnh báo và hệ thống cảnh báo:
- Mỗi khi có cảnh báo, tôi phải phản ứng khẩn cấp. Tôi có thể vội vã nhiều lần trong ngày trước khi tôi mệt mỏi.
- Mỗi cảnh báo phải được cập nhật.
- Mỗi phản hồi cho một cảnh báo phải yêu cầu sự can thiệp của con người. Nếu thông báo có thể được xử lý tự động, thì nó sẽ không đến.
- Cảnh báo phải là về một vấn đề mới hoặc một sự kiện chưa từng xảy ra trước đó.
Cách tiếp cận này làm mờ đi những khác biệt nhất định: nếu một cảnh báo thỏa mãn bốn điều kiện trước đó, thì việc cảnh báo được gửi từ hệ thống giám sát Hộp trắng hay Hộp đen không thành vấn đề. Cách tiếp cận này cũng củng cố những khác biệt nhất định: tốt hơn là dành nhiều nỗ lực hơn cho việc xác định các triệu chứng hơn là nguyên nhân; khi nói đến nguyên nhân, bạn chỉ cần lo lắng về những nguyên nhân không thể tránh khỏi.
Giám sát dài hạn
Trong môi trường sản xuất ngày nay, hệ thống giám sát giám sát hệ thống sản xuất không ngừng phát triển với kiến trúc phần mềm, đặc tính tải và mục tiêu hiệu suất luôn thay đổi. Các cảnh báo hiện khó tự động hóa có thể trở nên phổ biến, thậm chí có thể đáng được giải quyết. Tại thời điểm này, ai đó phải tìm và khắc phục nguyên nhân gốc rễ của vấn đề; nếu không thể giải quyết như vậy, phản ứng với cảnh báo yêu cầu tự động hóa hoàn toàn.
Điều quan trọng là các quyết định giám sát được đưa ra có tính đến các mục tiêu dài hạn. Mọi cảnh báo chạy hôm nay sẽ khiến một người không thể cải thiện hệ thống vào ngày mai, do đó, thường có sự sụt giảm về tính khả dụng hoặc hiệu suất của một hệ thống hiệu quả trong thời gian cần thiết để cải thiện hệ thống giám sát về lâu dài. Hãy xem hai ví dụ minh họa cho hiện tượng này.
Bigtable SRE: Câu chuyện về cảnh báo quá mức
Cơ sở hạ tầng nội bộ của Google thường được cung cấp và đo lường theo Cấp độ dịch vụ (SLO). Nhiều năm trước, SLO của dịch vụ Bigtable dựa trên hiệu suất trung bình của một giao dịch tổng hợp mô phỏng một ứng dụng khách đang chạy. Do các sự cố trong Bigtable và các mức thấp hơn của ngăn xếp lưu trữ, hiệu suất trung bình bị chi phối bởi một cái đuôi "lớn": 5% truy vấn tệ nhất thường chậm hơn đáng kể so với phần còn lại.
Thông báo qua email đã được gửi khi đạt đến ngưỡng SLO và thông báo nhắn tin được gửi khi vượt quá SLO. Cả hai loại cảnh báo đều được gửi khá thường xuyên, tiêu tốn lượng thời gian kỹ thuật không thể chấp nhận được: nhóm đã dành một lượng thời gian đáng kể để phân tích cú pháp các cảnh báo để tìm ra một số cảnh báo thực sự có liên quan. Chúng tôi thường bỏ sót một sự cố thực sự ảnh hưởng đến người dùng vì chỉ có một số cảnh báo dành cho sự cố cụ thể đó. Nhiều cảnh báo không khẩn cấp do các vấn đề về cơ sở hạ tầng dễ hiểu và được xử lý theo cách tiêu chuẩn hoặc hoàn toàn không được xử lý.
Để khắc phục tình trạng này, nhóm đã sử dụng phương pháp ba hướng: trong khi nỗ lực cải thiện hiệu suất của Bigtable, chúng tôi tạm thời đặt phân vị thứ 75 cho độ trễ phản hồi truy vấn làm mục tiêu SLO của mình. Chúng tôi cũng đã tắt thông báo qua email vì có quá nhiều thông báo trong số đó nên không thể lãng phí thời gian để chẩn đoán chúng.
Chiến lược này cho phép chúng tôi dễ thở hơn để bắt đầu khắc phục các sự cố dài hạn trong Bigtable và các lớp thấp hơn của kho lưu trữ, thay vì liên tục khắc phục các sự cố chiến thuật. Các kỹ sư thực sự có thể hoàn thành công việc khi họ không phải lúc nào cũng bị tấn công bởi các cảnh báo. Cuối cùng, sự chậm trễ tạm thời trong việc xử lý cảnh báo cho phép chúng tôi cải thiện chất lượng dịch vụ.
Gmail: Phản hồi của con người theo thuật toán, có thể đoán trước
Ngay từ đầu, Gmail đã được xây dựng trên hệ thống kiểm soát quy trình Workqueue đã sửa đổi, hệ thống này được tạo để xử lý hàng loạt khối chỉ mục tìm kiếm. Workqueue đã được điều chỉnh cho phù hợp với các quy trình tồn tại lâu dài và sau đó được áp dụng cho Gmail, nhưng một số lỗi trong mã bộ lập lịch không rõ ràng tỏ ra rất khó sửa.
Vào thời điểm đó, tính năng giám sát của Gmail được cấu trúc sao cho các cảnh báo sẽ kích hoạt khi các tác vụ riêng lẻ bị hủy bằng Workqueue. Cách tiếp cận này không phải là lý tưởng, bởi vì ngay cả vào thời điểm đó, Gmail đã thực hiện hàng nghìn tác vụ, mỗi tác vụ được giao cho một phần nhỏ của phần trăm người dùng của chúng tôi. Chúng tôi đã hết sức cẩn trọng để đảm bảo rằng người dùng Gmail có trải nghiệm người dùng tốt, nhưng việc xử lý nhiều cảnh báo như vậy là điều không thể.
Để giải quyết vấn đề này, Gmail SRE đã tạo ra một công cụ giúp gỡ lỗi bộ lập lịch một cách tốt nhất có thể để giảm thiểu ảnh hưởng đến người dùng. Nhóm đã có một số cuộc thảo luận về việc liệu có nên tự động hóa toàn bộ chu trình từ tìm ra vấn đề đến khắc phục sự cố cho đến khi tìm ra giải pháp lâu dài hay không, nhưng một số người lo ngại rằng giải pháp như vậy sẽ làm chậm quá trình khắc phục sự cố thực sự.
Sự căng thẳng như vậy là phổ biến trong nhóm và thường phản ánh sự không tin tưởng vào kỷ luật tự giác: trong khi một số thành viên trong nhóm muốn dành thời gian để khắc phục sự cố, thì những người khác lại lo lắng rằng cách khắc phục cuối cùng sẽ bị lãng quên và cách khắc phục tạm thời sẽ kéo dài mãi mãi. Vấn đề này đáng được chú ý vì quá dễ dàng để khắc phục sự cố tạm thời thay vì thực hiện sửa chữa vĩnh viễn. Các nhà quản lý và nhân viên kỹ thuật đóng vai trò quan trọng trong việc triển khai các bản sửa lỗi dài hạn bằng cách hỗ trợ và ưu tiên các bản sửa lỗi dài hạn có khả năng xảy ra ngay cả khi vấn đề ban đầu giảm bớt.
Cảnh báo định kỳ thường xuyên và phản ứng theo thuật toán phải là dấu hiệu cảnh báo. Việc nhóm của bạn miễn cưỡng tự động hóa các cảnh báo này có nghĩa là nhóm thiếu tự tin rằng họ có thể tin tưởng vào các thuật toán. Đây là một vấn đề nghiêm trọng cần được giải quyết.
Dài hạn
Một chủ đề phổ biến liên kết các ví dụ về Bigtable và Gmail: sự cạnh tranh giữa tính khả dụng ngắn hạn và dài hạn. Thông thường, một nỗ lực mạnh mẽ có thể giúp một hệ thống mong manh đạt được tính sẵn sàng cao, nhưng con đường này thường tồn tại trong thời gian ngắn, dẫn đến tình trạng kiệt sức của nhóm và sự phụ thuộc vào một số ít thành viên của cùng một đội anh hùng này.
Sự suy giảm khả dụng trong thời gian ngắn, có kiểm soát thường gây đau đớn, nhưng quan trọng về mặt chiến lược đối với sự ổn định lâu dài của hệ thống. Điều quan trọng là không xem xét riêng lẻ từng cảnh báo mà phải xem xét liệu tỷ lệ cảnh báo tổng thể có dẫn đến một hệ thống lành mạnh, có thể truy cập phù hợp với một nhóm khả thi và tiên lượng thuận lợi hay không. Chúng tôi phân tích số liệu thống kê về tỷ lệ cảnh báo (thường được biểu thị dưới dạng sự cố mỗi ca, trong đó một sự cố có thể bao gồm nhiều sự cố liên quan) trong các báo cáo hàng quý với ban quản lý, cho phép những người ra quyết định liên tục trình bày tải hệ thống cảnh báo và tình trạng tổng thể của nhóm.
Kết luận
Đường dẫn đến theo dõi và cảnh báo lành mạnh rất đơn giản và dễ hiểu. Nó tập trung vào các triệu chứng của sự cố mà các cảnh báo được tạo ra và việc theo dõi nguyên nhân đóng vai trò hỗ trợ gỡ lỗi sự cố. Giám sát triệu chứng dễ dàng hơn khi bạn ở cấp cao hơn trong ngăn xếp mà bạn kiểm soát, mặc dù việc giám sát hiệu suất và tải cơ sở dữ liệu nên được thực hiện trực tiếp trên chính cơ sở dữ liệu. Thông báo qua email được sử dụng rất hạn chế và có xu hướng dễ dàng trở thành tiếng ồn; thay vào đó, bạn nên sử dụng bảng điều khiển theo dõi tất cả các sự cố hiện tại được cảnh báo qua email. Bảng điều khiển cũng có thể được ghép nối với nhật ký sự kiện để phân tích các mối tương quan lịch sử.
Về lâu dài, cần đạt được sự xen kẽ thành công giữa các cảnh báo triệu chứng và các vấn đề thực sự sắp xảy ra, đồng thời điều chỉnh các mục tiêu để đảm bảo rằng việc theo dõi hỗ trợ chẩn đoán nhanh chóng.
Cảm ơn bạn đã đọc bản dịch đến cuối. Đăng ký kênh telegram của tôi về giám sát и .
Nguồn: www.habr.com