Hệ thống Giám sát và Cảnh báo trong Thực tế
Hệ thống giám sát giúp tăng khả năng hiển thị vào cơ sở hạ tầng và ứng dụng của bạn và xác định phạm vi hiệu suất và độ tin cậy có thể chấp nhận được. Bằng cách hiểu các thành phần cần đo lường và các chỉ số phù hợp nhất để tập trung vào cho các tình huống khác nhau, bạn có thể bắt đầu lập kế hoạch chiến lược giám sát bao gồm tất cả các phần quan trọng trong dịch vụ của bạn . Trong hướng dẫn của ta về việc thu thập các chỉ số từ cơ sở hạ tầng và ứng dụng của bạn , ta đã giới thiệu một khuôn khổ phổ biến để xác định các chỉ số giá trị cao và sau đó chia nhỏ việc triển khai thành các lớp để thảo luận về những gì cần thu thập ở các giai đoạn khác nhau.Trong hướng dẫn này, ta sẽ nói về các thành phần tạo nên một hệ thống giám sát và cách sử dụng chúng để thực hiện chiến lược giám sát của bạn. Ta sẽ bắt đầu bằng việc xem xét các trách nhiệm cơ bản của một hệ thống giám sát hiệu quả, tin cậy . Sau đó, ta sẽ trình bày cách các phần tử của hệ thống giám sát đáp ứng các yêu cầu chức năng đó. Sau đó, ta sẽ nói về cách tốt nhất để chuyển các policy giám sát của bạn thành trang tổng quan và các policy cảnh báo để cung cấp cho group của bạn thông tin họ cần mà không yêu cầu họ chú ý vào những thời điểm không chính đáng.
Đánh giá các phẩm chất quan trọng của hệ thống đo lường, giám sát và cảnh báo
Trong một trong những phần cuối cùng của phần giới thiệu về chỉ số, giám sát và cảnh báo , ta đã thảo luận về một số phẩm chất quan trọng nhất của một hệ thống giám sát hiệu quả . Vì ta sẽ xem xét các thành phần cốt lõi của các hệ thống này ngay lập tức, nên sẽ hữu ích khi xem xét các đặc điểm mà ta đã xác định là hữu ích hoặc cần thiết:
- Độc lập với Hầu hết các cơ sở hạ tầng khác : Để thu thập chính xác dữ liệu và tránh tác động tiêu cực đến hiệu suất, hầu hết các thành phần giám sát nên sử dụng tài nguyên chuyên dụng tách biệt với các ứng dụng khác.
- Đáng tin cậy và tin cậy : Vì việc giám sát được sử dụng để đánh giá sức khỏe của các hệ thống khác, điều quan trọng là phải đảm bảo bản thân hệ thống giám sát vừa chính xác vừa khả dụng.
- Chế độ xem tóm tắt và chi tiết dễ sử dụng : Dữ liệu sẽ không hữu ích nếu nó không thể hiểu được hoặc không thể thực hiện được. Cho phép người điều hành xem các dạng xem tóm tắt và sau đó khám phá thêm chi tiết trong các lĩnh vực quan trọng là vô cùng có giá trị trong quá trình điều tra.
- Chiến lược hiệu quả để duy trì dữ liệu lịch sử : Điều quan trọng là phải hiểu các mẫu điển hình là như thế nào để nhận ra các điểm bất thường. Theo thời gian dài hơn, điều này có thể yêu cầu quyền truy cập vào dữ liệu cũ hơn mà hệ thống của bạn phải có thể truy xuất và truy cập.
- Có khả năng tương quan các yếu tố từ các nguồn khác nhau : Hiển thị thông tin từ các phần khác nhau của quá trình triển khai của bạn một cách có tổ chức là điều quan trọng để xác định các mẫu và các yếu tố tương quan.
- Dễ dàng bắt đầu theo dõi các chỉ số hoặc cơ sở hạ tầng mới : Hệ thống giám sát của bạn phải phát triển khi các ứng dụng và cơ sở hạ tầng của bạn thay đổi. Phạm vi giám sát cũ hoặc không đầy đủ làm giảm sự tin tưởng vào công cụ và dữ liệu .
- Cảnh báo linh hoạt và mạnh mẽ : Chức năng cảnh báo phải có khả năng gửi thông báo theo nhiều kênh và mức độ ưu tiên tùy thuộc vào điều kiện bạn xác định.
Với những thuộc tính này, ta hãy xem những gì tạo nên một hệ thống giám sát.
Các bộ phận của hệ thống giám sát
Hệ thống giám sát bao gồm một số thành phần và giao diện khác nhau, tất cả đều hoạt động cùng nhau để thu thập, trực quan hóa và báo cáo về tình trạng triển khai của bạn. Ta sẽ đề cập đến các phần cơ bản riêng lẻ bên dưới.
Đại lý giám sát phân tán và nhà xuất dữ liệu
Mặc dù phần lớn hệ thống giám sát có thể được triển khai đến một server chuyên dụng hoặc các server , nhưng dữ liệu cần được thu thập từ nhiều nguồn khác nhau trong toàn bộ cơ sở hạ tầng của bạn. Để làm điều này, một tác nhân giám sát — một ứng dụng nhỏ được thiết kế để thu thập và chuyển tiếp dữ liệu đến một điểm cuối thu thập — được cài đặt trên từng máy riêng lẻ trong toàn mạng. Các tác nhân này thu thập số liệu thống kê và số liệu sử dụng từ server lưu trữ nơi chúng được cài đặt và gửi chúng đến phần mềm giám sát trung tâm.
Agent chạy dưới dạng daemon luôn hoạt động trên mỗi server trong toàn hệ thống. Chúng có thể bao gồm cấu hình cơ bản để xác thực một cách an toàn với điểm cuối dữ liệu từ xa, xác định tần suất dữ liệu hoặc policy lấy mẫu và đặt số nhận dạng duy nhất cho dữ liệu của server . Để giảm tác động đến các dịch vụ khác, đại lý phải sử dụng tài nguyên tối thiểu và có thể hoạt động với ít hoặc không cần quản lý. Lý tưởng nhất là việc cài đặt một tác nhân trên một nút mới và bắt đầu gửi các số liệu đến hệ thống giám sát trung tâm là điều không cần thiết.
Các tác nhân giám sát thường thu thập các số liệu chung chung, cấp server , nhưng các tác nhân để giám sát phần mềm như web server hoặc database cũng có sẵn. Tuy nhiên, đối với hầu hết các loại phần mềm chuyên dụng, dữ liệu sẽ phải được thu thập và xuất bằng cách sửa đổi bản thân phần mềm hoặc xây dựng tác nhân của bạn bằng cách tạo một dịch vụ phân tích cú pháp các điểm cuối trạng thái của phần mềm hoặc các mục log . Nhiều giải pháp giám sát phổ biến có sẵn thư viện để giúp bạn dễ dàng thêm thiết bị đo đạc tùy chỉnh vào dịch vụ của bạn . Như với phần mềm tác nhân, cần phải cẩn thận đảm bảo các giải pháp tùy chỉnh của bạn giảm thiểu dấu vết của chúng để tránh ảnh hưởng đến sức khỏe hoặc hiệu suất của các ứng dụng của bạn.
Lúc này, ta đã đưa ra một số giả định về một kiến trúc dựa trên đẩy để giám sát, nơi các tác nhân đẩy dữ liệu đến một vị trí trung tâm. Tuy nhiên, thiết kế dựa trên kéo cũng có sẵn. Trong hệ thống giám sát dựa trên kéo, các server riêng lẻ chịu trách nhiệm thu thập, tổng hợp và cung cấp các chỉ số ở một định dạng đã biết tại một điểm cuối có thể truy cập được. Server giám sát thăm dò điểm cuối số liệu trên mỗi server để thu thập dữ liệu số liệu. Phần mềm thu thập và trình bày dữ liệu thông qua điểm cuối có nhiều yêu cầu giống như một tác nhân, nhưng thường yêu cầu cấu hình ít hơn vì nó không cần biết cách truy cập vào các máy khác.
Metrics Ingress
Một trong những phần bận rộn nhất của hệ thống giám sát tại bất kỳ thời điểm nào là thành phần nhập số liệu. Vì dữ liệu liên tục được tạo ra, quy trình thu thập cần phải đủ mạnh để xử lý dung lượng hoạt động lớn và phối hợp với lớp lưu trữ để ghi lại chính xác dữ liệu đến.
Đối với các hệ thống dựa trên đẩy, điểm cuối nhập số liệu là vị trí trung tâm trên mạng nơi mỗi tác nhân giám sát hoặc bộ tổng hợp thống kê gửi dữ liệu đã thu thập của nó. Điểm cuối phải có thể xác thực và nhận dữ liệu từ một số lượng lớn các server lưu trữ đồng thời. Các điểm cuối nhập cho hệ thống chỉ số thường được cân bằng tải hoặc phân phối theo quy mô vừa đảm bảo độ tin cậy vừa để theo kịp với dung lượng lớn lưu lượng truy cập.
Đối với các hệ thống dựa trên kéo, thành phần tương ứng là cơ chế thăm dò tiếp cận và phân tích cú pháp các điểm cuối chỉ số được hiển thị trên từng server riêng lẻ. Điều này có một số yêu cầu giống nhau, nhưng một số trách nhiệm được đảo ngược. Ví dụ: nếu các server riêng lẻ triển khai xác thực, thì quy trình thu thập số liệu phải có khả năng cung cấp thông tin xác thực chính xác để đăng nhập và truy cập điểm cuối an toàn.
Lớp quản lý dữ liệu
Lớp quản lý dữ liệu chịu trách nhiệm tổ chức và ghi lại dữ liệu đến từ thành phần nhập số liệu và phản hồi các truy vấn và yêu cầu dữ liệu từ các lớp quản trị. Dữ liệu chỉ số thường được ghi lại ở định dạng được gọi là chuỗi thời gian thể hiện những thay đổi về giá trị theo thời gian. Database chuỗi thời gian — database chuyên lưu trữ và truy vấn loại dữ liệu này — thường được sử dụng trong các hệ thống giám sát.
Trách nhiệm chính của lớp quản lý dữ liệu là lưu trữ dữ liệu đến khi nó được nhận hoặc thu thập từ các server . Ở mức tối thiểu, lớp lưu trữ phải ghi lại số liệu đang được báo cáo, giá trị được quan sát, thời gian giá trị được tạo và server đã tạo ra giá trị đó.
Để tồn tại trong thời gian dài hơn, lớp lưu trữ cần cung cấp cách xuất dữ liệu khi bộ sưu tập vượt quá giới hạn local về xử lý, bộ nhớ hoặc lưu trữ. Do đó, lớp lưu trữ cũng cần có khả năng nhập dữ liệu hàng loạt để nhập lại dữ liệu lịch sử vào hệ thống khi cần thiết.
Lớp quản lý dữ liệu cũng cần cung cấp quyền truy cập có tổ chức vào thông tin được lưu trữ. Đối với hệ thống sử dụng database chuỗi thời gian, chức năng này được cung cấp bởi các ngôn ngữ hoặc API truy vấn tích hợp sẵn. Chúng được dùng để truy vấn tương tác và khám phá dữ liệu, nhưng khách hàng chính có thể sẽ là console trình bày dữ liệu và hệ thống cảnh báo.
Hình ảnh hóa và Lớp trang tổng quan
Được xây dựng trên đầu lớp quản lý dữ liệu là các giao diện mà bạn tương tác để hiểu dữ liệu đang được thu thập. Vì chỉ số là dữ liệu chuỗi thời gian nên dữ liệu được biểu thị tốt nhất dưới dạng biểu đồ theo thời gian trên trục x. Bằng cách này, bạn có thể dễ dàng hiểu các giá trị thay đổi như thế nào theo thời gian. Các chỉ số có thể được trực quan hóa qua các thang thời gian khác nhau để hiểu xu hướng trong thời gian dài cũng như những thay đổi gần đây có thể đang ảnh hưởng đến hệ thống của bạn hiện tại.
Cả hai lớp quản lý dữ liệu và trực quan đều tham gia vào việc đảm bảo dữ liệu từ các server khác nhau hoặc từ các phần khác nhau của ứng dụng của bạn có thể được phủ lên và xem một cách tổng thể. May mắn là dữ liệu chuỗi thời gian cung cấp một quy mô nhất quán giúp xác định các sự kiện hoặc thay đổi xảy ra đồng thời, ngay cả khi tác động lan rộng trên các loại cơ sở hạ tầng khác nhau. Có thể chọn dữ liệu nào để phủ một cách tương tác cho phép người vận hành xây dựng các hình ảnh trực quan hữu ích nhất cho nhiệm vụ đang thực hiện.
Các đồ thị và dữ liệu thường được sử dụng thường được sắp xếp thành các trang tổng quan đã lưu. Những điều này hữu ích trong một số ngữ cảnh, dưới dạng đại diện liên tục của các chỉ số sức khỏe hiện tại cho màn hình luôn bật hoặc là cổng tập trung để khắc phục sự cố hoặc đi sâu vào các khu vực cụ thể trong hệ thống của bạn.Ví dụ: console với bảng phân tích chi tiết về dung lượng lưu trữ vật lý trong toàn bộ đội xe có thể quan trọng khi lập kế hoạch năng lực, nhưng có thể không cần tham khảo để quản trị hàng ngày. Việc dễ dàng tạo cả trang tổng quan tổng quát và tập trung có thể giúp dữ liệu dễ truy cập và dễ hành động hơn.
Chức năng cảnh báo và ngưỡng
Mặc dù biểu đồ và trang tổng quan sẽ là những công cụ cần thiết để hiểu dữ liệu trong hệ thống của bạn, nhưng chúng chỉ hữu ích trong những bối cảnh mà người điều hành đang xem trang. Một trong những trách nhiệm quan trọng nhất của hệ thống giám sát là giảm bớt các thành viên trong group chủ động theo dõi hệ thống của bạn để họ có thể theo đuổi các hoạt động có giá trị hơn. Để làm cho điều này khả thi, hệ thống phải có khả năng yêu cầu sự chú ý của bạn khi cần thiết để bạn có thể tin tưởng rằng bạn sẽ nhận thức được những thay đổi quan trọng. Hệ thống giám sát sử dụng các ngưỡng chỉ số do user xác định và hệ thống cảnh báo để thực hiện điều này.
Mục tiêu của hệ thống cảnh báo là thông báo một cách tin cậy cho người vận hành khi dữ liệu chỉ ra một thay đổi quan trọng và để họ yên. Vì điều này yêu cầu hệ thống biết những gì bạn coi là một sự kiện quan trọng, bạn phải xác định tiêu chí cảnh báo của bạn . Định nghĩa cảnh báo bao gồm phương thức thông báo và ngưỡng chỉ số mà hệ thống liên tục đánh giá dựa trên dữ liệu đến. Ngưỡng thường xác định giá trị trung bình tối đa hoặc tối thiểu cho một chỉ số trong một khung thời gian cụ thể trong khi phương pháp thông báo mô tả cách gửi cảnh báo.
Một trong những phần khó nhất của cảnh báo là tìm ra sự cân bằng cho phép bạn phản ứng với các vấn đề trong khi không cảnh báo quá mức. Để thực hiện điều này, bạn cần hiểu các chỉ số nào là dấu hiệu tốt nhất cho các vấn đề thực tế, vấn đề nào cần được chú ý ngay lập tức và phương pháp thông báo nào phù hợp nhất cho các tình huống khác nhau. Để hỗ trợ điều này, ngôn ngữ xác định ngưỡng phải đủ mạnh để mô tả đầy đủ các tiêu chí của bạn. Tương tự, thành phần thông báo phải đưa ra các phương pháp giao tiếp phù hợp với các mức độ nghiêm trọng khác nhau.
Giám sát hộp đen và hộp trắng
Bây giờ ta đã mô tả cách các phần khác nhau của hệ thống giám sát góp phần cải thiện khả năng hiển thị trong việc triển khai của bạn, ta có thể nói về một số cách mà bạn có thể xác định ngưỡng và cảnh báo để phục vụ tốt nhất cho group của bạn . Ta sẽ bắt đầu bằng cách thảo luận về sự khác biệt giữa giám sát hộp đen và hộp trắng.
Giám sát hộp đen và hộp trắng mô tả các mô hình khác nhau để giám sát. Chúng không loại trừ lẫn nhau, vì vậy các hệ thống thường sử dụng hỗn hợp từng loại để tận dụng thế mạnh riêng của chúng.
Giám sát hộp đen mô tả định nghĩa hoặc đồ thị cảnh báo chỉ dựa trên các yếu tố có thể nhìn thấy bên ngoài. Phong cách giám sát này có quan điểm bên ngoài để duy trì sự tập trung vào hành vi công khai của ứng dụng hoặc dịch vụ của bạn. Không có kiến thức đặc biệt về tình trạng của các thành phần bên dưới, giám sát hộp đen cung cấp cho bạn dữ liệu về chức năng của hệ thống từ góc độ user . Mặc dù quan điểm này có vẻ hạn chế, nhưng thông tin này liên kết chặt chẽ với các vấn đề đang ảnh hưởng tích cực đến khách hàng, vì vậy chúng là thành phần tốt cho các trình kích hoạt cảnh báo.
Phương thức thay thế, giám sát hộp trắng , cũng vô cùng hữu ích. Giám sát hộp trắng mô tả bất kỳ giám sát nào dựa trên thông tin nội bộ, quyền về cơ sở hạ tầng của bạn. Bởi vì số lượng các quy trình nội bộ vượt quá nhiều hành vi có thể nhìn thấy bên ngoài, bạn có thể sẽ có tỷ lệ dữ liệu hộp trắng cao hơn nhiều. Và vì nó hoạt động với thông tin toàn diện hơn về hệ thống của bạn, giám sát hộp trắng có cơ hội được dự đoán. Ví dụ: bằng cách theo dõi những thay đổi trong việc sử dụng tài nguyên, nó có thể thông báo cho bạn khi bạn có thể cần mở rộng các dịch vụ nhất định để đáp ứng nhu cầu mới.
Hộp đen và hộp trắng chỉ đơn thuần là cách phân loại các loại quan điểm khác nhau vào hệ thống của bạn. Có quyền truy cập vào dữ liệu hộp trắng, nơi có thể nhìn thấy phần bên trong hệ thống của bạn, sẽ hữu ích trong việc điều tra các vấn đề, đánh giá nguyên nhân root rễ và tìm các yếu tố tương quan khi một vấn đề được biết đến hoặc cho các mục đích quản trị thông thường. Mặt khác, giám sát hộp đen giúp phát hiện các vấn đề nghiêm trọng một cách nhanh chóng bằng cách thể hiện ngay tác động của user .
Phù hợp với mức độ nghiêm trọng với loại cảnh báo
Cảnh báo và thông báo là một số phần quan trọng nhất của hệ thống giám sát của bạn. Nếu không có thông báo về những thay đổi quan trọng, group của bạn sẽ không nhận thức được các sự kiện ảnh hưởng đến hệ thống của bạn hoặc cần chủ động theo dõi trang tổng quan của bạn để luôn được cập nhật. Mặt khác, nhắn tin quá khích với tỷ lệ dương tính giả cao, các sự kiện không khẩn cấp hoặc nhắn tin không rõ ràng có thể gây hại nhiều hơn lợi.
Trong phần này, ta sẽ nói về các cấp thông báo khác nhau và cách sử dụng tốt nhất từng cấp để tối đa hóa hiệu quả của chúng. Sau đó, ta sẽ thảo luận về một số tiêu chí để chọn nội dung cảnh báo và thông báo sẽ thực hiện những gì.
Các trang
Bắt đầu với loại cảnh báo có mức độ ưu tiên cao nhất, các trang là các thông báo cố gắng khẩn cấp kêu gọi sự chú ý đến một vấn đề nghiêm trọng với hệ thống. Loại cảnh báo này nên được sử dụng cho các tình huống cần giải quyết ngay lập tức do mức độ nghiêm trọng của chúng. Hệ thống phân trang cần có một cách tin cậy và tích cực để tiếp cận những người có trách nhiệm và quyền để giải quyết vấn đề.
Các trang nên được dành riêng cho các vấn đề quan trọng với hệ thống của bạn. Do loại vấn đề mà chúng đại diện, chúng là những cảnh báo quan trọng nhất mà hệ thống của bạn gửi đi. Hệ thống phân trang tốt là tin cậy , bền bỉ và đủ mạnh để chúng không thể bị bỏ qua một cách hợp lý. Để đảm bảo phản hồi, hệ thống phân trang thường bao gồm tùy chọn thông báo cho người hoặc group thứ cấp nếu trang đầu tiên không được chấp nhận trong một khoảng thời gian nhất định.
Bởi vì về bản chất, các trang cực kỳ gây rối, chúng nên được sử dụng một cách tiết kiệm: chỉ khi rõ ràng rằng có một vấn đề không thể chấp nhận được về mặt vận hành. Thông thường, điều này nghĩa là các trang được gắn với các triệu chứng quan sát được trong hệ thống của bạn bằng kỹ thuật hộp đen. Mặc dù có thể khó xác định tác động của việc web server backend tối đa hóa kết nối, nhưng tầm quan trọng của việc domain của bạn không thể truy cập được ít mơ hồ hơn nhiều và có thể truy cập một trang .
Thông báo phụ
Giảm mức độ nghiêm trọng là các thông báo như email và vé.Những điều này được thiết kế để để lại một dấu nhắc nhở liên tục rằng các nhà khai thác nên điều tra một tình huống đang phát triển khi họ có vị trí tốt để thực hiện . Không giống như các trang, cảnh báo kiểu thông báo không nhằm cho biết cần phải có hành động ngay lập tức, do đó, chúng thường được xử lý bởi nhân viên đang làm việc thay vì cảnh báo cho nhân viên đang gọi. Nếu doanh nghiệp của bạn không có administrator làm việc mọi lúc, các thông báo phải phù hợp với các tình huống có thể đợi đến ngày làm việc tiếp theo.
Vé và email được tạo bằng cách giám sát giúp các group hiểu được công việc mà họ nên tập trung vào khi hoạt động tiếp theo. Bởi vì thông báo không nên được sử dụng cho các vấn đề quan trọng hiện đang ảnh hưởng đến production , chúng thường dựa trên các chỉ báo hộp trắng có thể dự đoán hoặc xác định các vấn đề đang phát triển cần được giải quyết sớm.
Những lần khác, cảnh báo thông báo được đặt để giám sát hành vi tương tự như cảnh báo phân trang, nhưng được đặt ở ngưỡng thấp hơn, ít quan trọng hơn. Ví dụ: bạn có thể xác định một cảnh báo thông báo khi ứng dụng của bạn có độ trễ tăng nhỏ trong một khoảng thời gian và có một trang tương ứng được gửi khi độ trễ tăng đến mức không hợp lý.
Nói chung, thông báo thích hợp nhất trong các tình huống cần phản hồi, nhưng không đe dọa ngay lập tức đến sự ổn định của hệ thống . Trong những trường hợp này, bạn muốn nâng cao nhận thức về một vấn đề để group của bạn có thể điều tra và giảm thiểu trước khi nó ảnh hưởng đến user hoặc chuyển sang một vấn đề lớn hơn.
Thông tin ghi log
Mặc dù về mặt kỹ thuật không phải là một cảnh báo, nhưng đôi khi bạn có thể cần ghi lại hành vi cụ thể được quan sát ở một nơi mà bạn có thể dễ dàng truy cập sau này mà không cần để ý đến bất kỳ ai ngay lập tức. Trong những tình huống này, việc cài đặt các ngưỡng chỉ ghi log thông tin có thể hữu ích. Chúng có thể được ghi vào một file hoặc được sử dụng để tăng bộ đếm trên console trong hệ thống giám sát của bạn. Mục đích là cung cấp thông tin được biên dịch sẵn sàng cho các mục đích điều tra để cắt giảm số lượng truy vấn mà các nhà khai thác phải xây dựng để thu thập thông tin.
Chiến lược này chỉ có ý nghĩa đối với các tình huống có mức độ ưu tiên rất thấp và không cần phản ứng riêng. Tiện ích lớn nhất của họ là so sánh các yếu tố liên quan và tóm tắt dữ liệu thời điểm có thể được tham khảo sau này như các nguồn bổ sung. Bạn có thể sẽ không có nhiều trình kích hoạt kiểu này, nhưng chúng có thể hữu ích trong trường hợp bạn thấy mình đang tìm kiếm cùng một dữ liệu mỗi khi một vấn đề xuất hiện. Các giải pháp thay thế cung cấp một số lợi ích tương tự là các truy vấn đã lưu và trang tổng quan điều tra tùy chỉnh.
Khi nào cần tránh cảnh báo
Điều quan trọng là phải rõ ràng những cảnh báo nào nên chỉ ra cho group của bạn. Mỗi cảnh báo phải biểu thị rằng một vấn đề đang xảy ra đòi hỏi hành động thủ công của con người hoặc đầu vào để đưa ra quyết định. Vì trọng tâm này, khi bạn xem xét các chỉ số cần cảnh báo, hãy lưu ý bất kỳ cơ hội nào mà phản ứng có thể được tự động hóa.
Khắc phục tự động có thể được thiết kế trong các trường hợp:
- Một chữ ký dễ nhận biết có thể xác định vấn đề một cách tin cậy
- Câu trả lời sẽ luôn giống nhau
- Phản hồi không yêu cầu bất kỳ đầu vào hoặc ra quyết định của con người
Một số câu trả lời tự động hóa đơn giản hơn những câu trả lời khác, nhưng nhìn chung, bất kỳ tình huống nào phù hợp với các tiêu chí trên đều có thể được lập kịch bản.Phản hồi vẫn có thể được gắn với ngưỡng cảnh báo, nhưng thay vì gửi tin nhắn đến một người, trình kích hoạt có thể khởi động quá trình khắc phục theo kịch bản để giải quyết vấn đề. Việc ghi log mỗi khi điều này xảy ra có thể cung cấp thông tin có giá trị về tình trạng hệ thống của bạn và hiệu quả của các ngưỡng chỉ số và các biện pháp tự động của bạn.
Điều quan trọng cần lưu ý là các quy trình tự động cũng có thể gặp sự cố. Bạn nên thêm cảnh báo bổ sung vào các phản hồi theo tập lệnh của bạn để người vận hành được thông báo khi tự động hóa không thành công. Bằng cách này, phản hồi chung tay sẽ xử lý phần lớn các trường hợp và group của bạn sẽ được thông báo về các sự cố cần can thiệp.
Thiết kế các ngưỡng và cảnh báo hiệu quả
Bây giờ ta đã đề cập đến các phương tiện cảnh báo khác nhau có sẵn và một số tình huống phù hợp cho từng phương tiện, ta có thể nói về các đặc điểm của cảnh báo tốt.
Được kích hoạt bởi Sự kiện có tác động của user thực sự
Như đã đề cập trước đây, các cảnh báo dựa trên các tình huống có tác động thực của user là tốt nhất. Điều này nghĩa là phân tích các tình huống thất bại hoặc suy giảm hiệu suất khác nhau và hiểu cách thức và thời điểm chúng có thể tạo ra các lớp mà user tương tác.
Điều này đòi hỏi bạn phải hiểu rõ về khả năng dự phòng của cơ sở hạ tầng, mối quan hệ của các thành phần khác nhau và mục tiêu của tổ chức bạn về tính khả dụng và hiệu suất. Mục đích của bạn là khám phá các chỉ số triệu chứng có thể chỉ ra một cách tin cậy các vấn đề ảnh hưởng đến user hiện tại hoặc sắp xảy ra.
Các ngưỡng có mức độ nghiêm trọng được phân loại
Sau khi bạn đã xác định các chỉ số có triệu chứng, thử thách tiếp theo là xác định các giá trị thích hợp để sử dụng làm ngưỡng. Bạn có thể phải sử dụng thử và sai để tìm ra các ngưỡng phù hợp cho một số chỉ số.
Nếu có, hãy kiểm tra các giá trị lịch sử để xác định những tình huống nào cần khắc phục trong quá khứ. Đối với mỗi chỉ số, bạn nên xác định ngưỡng "khẩn cấp" sẽ kích hoạt một trang và một hoặc một số ngưỡng "canary" được liên kết với thông báo có mức độ ưu tiên thấp hơn. Sau khi xác định các cảnh báo mới, hãy yêu cầu phản hồi về việc các ngưỡng đó có quá mạnh hoặc không đủ nhạy để bạn có thể tinh chỉnh hệ thống sao cho phù hợp nhất với mong đợi của group .
Chứa bối cảnh thích hợp
Việc giảm thiểu thời gian để người phản hồi bắt đầu điều tra vấn đề giúp bạn khôi phục sau sự cố nhanh hơn. Vì vậy, sẽ rất hữu ích khi cố gắng cung cấp ngữ cảnh trong văn bản cảnh báo để người vận hành có thể hiểu tình hình nhanh chóng và bắt đầu thực hiện các bước tiếp theo thích hợp.
Cảnh báo phải chỉ rõ các thành phần và hệ thống bị ảnh hưởng, ngưỡng chỉ số được kích hoạt và thời gian bắt đầu xảy ra sự cố. Cảnh báo cũng phải cung cấp các liên kết được dùng để lấy thêm thông tin. Đây có thể là các liên kết đến các trang tổng quan cụ thể được liên kết với số liệu được kích hoạt, các liên kết đến hệ thống bán vé của bạn nếu vé tự động được tạo hoặc các liên kết đến trang cảnh báo của hệ thống giám sát của bạn khi có ngữ cảnh chi tiết hơn.
Mục đích là cung cấp cho người vận hành đủ thông tin để hướng dẫn phản ứng ban đầu của họ và giúp họ tập trung vào sự cố đang xảy ra. Việc cung cấp mọi thông tin bạn có về sự kiện là không bắt buộc cũng như không được khuyến khích, nhưng việc cung cấp thông tin chi tiết cơ bản cùng với một số tùy chọn về nơi tiếp theo có thể rút ngắn giai đoạn khám phá ban đầu của phản hồi của bạn.
Gửi đến đúng người
Cảnh báo sẽ không hữu ích nếu chúng không thể thực hiện được. Thông thường, một cảnh báo có thể thực hiện được hay không phụ thuộc vào mức độ kiến thức, kinh nghiệm và sự cho phép mà cá nhân phản hồi có. Đối với các tổ chức có quy mô nhất định, việc quyết định người hoặc group thích hợp để nhắn tin là đơn giản trong một số trường hợp và mơ hồ đối với những người khác. Phát triển luân chuyển theo cuộc gọi cho các group khác nhau và thiết kế một kế hoạch leo thang cụ thể có thể loại bỏ một số sự mơ hồ trong các quyết định này.
Việc luân phiên theo cuộc gọi nên bao gồm đủ cá nhân có năng lực để tránh kiệt sức và mệt mỏi cảnh giác. Tốt nhất là nếu hệ thống cảnh báo của bạn bao gồm cơ chế lên lịch ca làm việc theo cuộc gọi, nhưng nếu không, bạn có thể phát triển các thủ tục để xoay vòng các số liên lạc cảnh báo theo lịch trình của bạn. Bạn có thể có nhiều cách xoay vòng khi gọi do chủ sở hữu của các bộ phận cụ thể trong hệ thống của bạn điền vào.
Kế hoạch leo thang là công cụ thứ hai đảm bảo sự cố đến đúng người. Nếu bạn có nhân viên bảo vệ hệ thống của bạn 24 giờ một ngày, tốt nhất là gửi cảnh báo được tạo ra từ hệ thống giám sát cho nhân viên trực ca thay vì luân phiên theo cuộc gọi. Sau đó, những người phản hồi có thể tự thực hiện giảm thiểu hoặc quyết định trang bị thủ công cho các nhà khai thác cuộc gọi nếu họ cần thêm trợ giúp hoặc chuyên môn. Có một kế hoạch vạch ra thời điểm và cách thức các vấn đề được leo thang có thể giảm thiểu các cảnh báo không cần thiết và duy trì cảm giác cấp bách mà các trang phải thể hiện.
Kết luận
Trong hướng dẫn này, ta đã nói về cách hoạt động của giám sát và cảnh báo trong các hệ thống thực. Ta bắt đầu bằng cách xem xét cách các bộ phận khác nhau của hệ thống giám sát hoạt động để đáp ứng nhu cầu của tổ chức về nhận thức và khả năng đáp ứng. Ta đã thảo luận về sự khác biệt giữa giám sát hộp đen và hộp trắng như một khuôn khổ để suy nghĩ về các dấu hiệu cảnh báo khác nhau. Sau đó, ta đã thảo luận về các loại cảnh báo khác nhau và cách tốt nhất để phù hợp với mức độ nghiêm trọng của sự cố với phương tiện cảnh báo thích hợp. Cuối cùng, ta đã đề cập đến các đặc điểm của quy trình cảnh báo hiệu quả để giúp bạn thiết kế một hệ thống tăng khả năng phản hồi của group bạn.
Các tin liên quan
