Cho dù bạn là DevOps, SRE hay chỉ là một cá nhân theo hướng dữ liệu, thì có lẽ bạn nghiện bảng điều khiển và số liệu. Chúng tôi xem xét các số liệu của mình để xem hệ thống của chúng tôi đang hoạt động như thế nào, cho dù ở cấp độ cơ sở hạ tầng, ứng dụng hay doanh nghiệp. Chúng tôi tin tưởng các số liệu của mình sẽ cho chúng tôi biết trạng thái của hệ thống và nơi hệ thống hoạt động sai. Nhưng các số liệu của chúng tôi có cho chúng tôi thấy điều gì đã thực sự xảy ra không? Bạn sẽ ngạc nhiên về mức độ thường xuyên không phải như vậy.

Trong bài đăng này, tôi sẽ xem xét toán học và cơ học đằng sau các chỉ số, một số quan niệm sai lầm phổ biến, cần có những chỉ số chính xác nào và liệu có tồn tại điều đó hay không.

Chỉ số cơ bản

Các chỉ số về cơ bản là tổng hợp các sự kiện thô. Trong quá trình tổng hợp này, các sự kiện được dịch thành các điểm dữ liệu số. Một ví dụ đơn giản là lỗi xảy ra trong hệ thống, với một số liệu đơn giản để đếm lỗi. Số liệu cũng có thể liên quan đến nhiều biến số, chẳng hạn như số lượng yêu cầu có thời gian phản hồi cao hơn 1 giây. Khi được đo theo thời gian, các điểm dữ liệu này tạo thành một chuỗi thời gian .

Số liệu có thể thuộc nhiều loại khác nhau, chẳng hạn như Bộ đếm, Đồng hồ đo và Biểu đồ. Bộ đếm được sử dụng để đếm tích lũy các sự kiện, như chúng ta đã thấy trong các ví dụ trên. Đồng hồ đo thường đại diện cho giá trị đo lường mới nhất. Và sau đó, có nhiều loại phức tạp hơn, chẳng hạn như Biểu đồ có thể lấy mẫu phân phối giá trị số liệu, bằng cách đếm các sự kiện trong “nhóm” hoặc “thùng” có thể định cấu hình. Ví dụ: bạn có thể muốn hiểu phần trăm mức sử dụng bộ nhớ được phân đoạn theo nhóm trên cụm của bạn tại các thời điểm nhất định.

Cơ chế đo lường

Trong một thế giới lý tưởng, chúng tôi sẽ nhập và lưu trữ tất cả các sự kiện thô, sau đó tính toán các số liệu về thời gian truy vấn. Điều này sẽ cho phép chúng tôi chia nhỏ các sự kiện theo bất kỳ cách nào chúng tôi cần và đặt bất kỳ câu hỏi đặc biệt nào mà chúng tôi mong muốn.

Tuy nhiên, trong thế giới thực, việc lưu giữ tất cả các sự kiện thô trong thời gian dài có thể cực kỳ tốn kém do khối lượng dữ liệu lớn. Để khắc phục điều này, các sự kiện thường được tổng hợp thành các số liệu trong quy trình thu thập, đồng thời loại bỏ các sự kiện thô hoặc chỉ giữ lại chúng trong thời gian ngắn. Đây thường là vấn đề về cấu hình đơn giản trong tác nhân thu thập số liệu của bạn.

Ngoài việc giảm chi phí, tính năng tổng hợp khi thu thập có thể cải thiện hiệu suất của phân tích thời gian thực với tốc độ truyền và nhập số liệu cao hơn ở tần suất cao hơn và bằng cách tránh tính toán và tổng hợp nặng về thời gian truy vấn.

Toán học của các số liệu một cách ngắn gọn

Quá trình cuộn lên này liên quan đến một số phép toán. Chúng tôi có thể muốn tính giá trị trung bình hoặc trung bình của thời gian phản hồi, hoặc có thể là phần trăm hoặc tổng hợp trong một khoảng thời gian. Chúng tôi cũng có thể muốn tổng hợp nhiều sự kiện thành một chỉ số tổng hợp. Ví dụ: tôi có thể muốn tính phần trăm thứ 95 (thường được gọi là P95) của tất cả các nhóm của một dịch vụ cụ thể trong cụm của tôi.

Ngay cả khi bạn không thích toán học, bạn cũng không thể tránh nó với số liệu. Bạn cần hiểu các chức năng tổng hợp khác nhau và mối quan hệ giữa câu hỏi bạn muốn hỏi với số liệu và tổng hợp bạn cần để trả lời câu hỏi đó. Hãy xem hàm Trung bình làm ví dụ, vì nhiều người có xu hướng bắt đầu từ đó. Theo định nghĩa, giá trị trung bình sẽ làm trơn tru mọi thứ và sẽ ít phù hợp hơn để loại bỏ các hành vi bất thường và các điểm khác biệt. Ví dụ: khi điều tra các vấn đề về độ trễ, sẽ khá vô ích khi xem xét các giá trị số liệu trung bình và tốt hơn hết là bạn nên xem xét các phần trăm.

Xác định câu hỏi của bạn, thiết kế số liệu của bạn cho phù hợp

Theo một cách nào đó, bạn có thể nghĩ về các số liệu này dưới dạng nén mất dữ liệu, trong đó chúng tôi mất dữ liệu và bối cảnh từ các sự kiện thô. Nếu chúng tôi không giữ các sự kiện thô, thì chúng tôi cần xác định trước điều gì quan trọng đối với chúng tôi. Ví dụ: nếu tôi chỉ tính giá trị trung bình trên dữ liệu, thì sau này tôi sẽ không thể hỏi về P95 (phân vị thứ 95) trên dữ liệu tổng hợp trước.

Bạn cần xác định câu hỏi nào bạn muốn trả lời, điều gì quan trọng đối với bạn và thiết kế số liệu cũng như tổng hợp của bạn cho phù hợp. Một sai lầm phổ biến là mọi người tránh giai đoạn thiết kế này và chỉ sử dụng các chỉ số đặt trước và giá trị mặc định được cung cấp sẵn với trình thu thập chỉ số mà họ lựa chọn. Mặc dù bạn có thể nghĩ rằng các giá trị mặc định này đại diện cho một số tiêu chuẩn ngành, nhưng chúng thường khá cũ và trong hầu hết các trường hợp sẽ không phù hợp với nhu cầu cụ thể của bạn.

Vấn đề đo lường

Giống như trong vật lý, vấn đề về phép đo xảy ra khi chúng ta đo một đặc tính (dường như) liên tục ở các khoảng rời rạc, thường được gọi là khoảng lấy mẫu , xác định tốc độ lấy mẫu. Điều này tạo ra một biểu diễn méo mó, trong đó số liệu có thể không thực sự phản ánh thuộc tính được đo ban đầu. Ví dụ: nếu chúng tôi đo mức sử dụng CPU cứ sau 60 giây, thì bất kỳ điểm ngoại lệ nào của CPU xảy ra giữa các điểm lấy mẫu này sẽ không hiển thị với chúng tôi.

Ngoài ra, để vẽ một đường liên tiếp, các công cụ trực quan thường tính trung bình trên các điểm dữ liệu liên tiếp, điều này làm cho đường thẳng bị sai lệch. Trong một số trường hợp, điều ngược lại có thể xảy ra, khi bạn có thể nhận được các thành phần giả trong các chỉ số không có thật, chẳng hạn như các đỉnh trong các chỉ số không thực sự tồn tại. Điều này có thể xảy ra khi chạy tập hợp trong phụ trợ lưu trữ, do tính toán đang được thực hiện.

Thời gian trung bình để phát hiện

Khoảng thời gian lấy mẫu cũng ảnh hưởng đến tốc độ hiển thị của sự thay đổi trong hệ thống trong các số liệu. Hầu hết các thuật toán yêu cầu năm điểm dữ liệu để phát hiện xu hướng. Nếu khoảng thời gian lấy mẫu là 60 giây, thì phép toán đơn giản xác định rằng sẽ mất năm phút (tức là 60 giây X 5 điểm dữ liệu) trước khi chúng tôi thấy có điều gì đó không ổn. Bạn có thể đợi 5 phút để biết rằng hệ thống của bạn bị lỗi không? Sử dụng khoảng thời gian lấy mẫu ngắn hơn (tức là tốc độ lấy mẫu cao hơn) sẽ rút ngắn thời gian này và cho phép chúng tôi phát hiện và phản ứng nhanh hơn. Tất nhiên, tốc độ lấy mẫu cao hơn sẽ phát sinh chi phí chung cho CPU và bộ nhớ, vì vậy chúng tôi cần tìm cấu hình đạt được sự cân bằng phù hợp với nhu cầu của mình.

Thay đổi độ phân giải và thu nhỏ

Một phương pháp phổ biến là lưu các chỉ số ở các độ phân giải khác nhau theo cách tiếp cận theo tầng để giảm chi phí. Ví dụ: bạn có thể muốn lưu số liệu 10 giây một lần trong ngày đầu tiên, nhưng sau đó là 5 phút một lần trong tuần tiếp theo và có thể là 1 giờ một lần trong tháng hoặc hơn thế nữa. Phương pháp này giả định rằng chúng tôi cần độ chi tiết tốt nhất trong khoảng thời gian gần như thời gian thực, mà chúng tôi có thể cần nếu có sự cố trong hệ thống, trong khi các cuộc điều tra trong thời gian dài hơn yêu cầu các xu hướng quy mô lớn hơn.

Có thể đạt được các mức độ chi tiết khác nhau bằng cách thu nhỏ các chỉ số, cụ thể là tính toán chỉ số ít chi tiết hơn so với chỉ số có mức độ chi tiết cao hơn. Mặc dù điều này nghe có vẻ hoàn toàn hợp lý, nhưng toán học có thể gây trở ngại ở đây, vì một số hàm tổng hợp không tương thích với một số phép tính nhất định và do đó không thể tổng hợp sau này. Ví dụ, phần trăm không phải là cộng và không thể được tổng hợp. Vì vậy, theo ví dụ trên, nếu bạn lấy mẫu phần trăm P99 với độ phân giải 10 giây, thì bạn không thể chuyển chúng lên độ phân giải 5 phút. Điều quan trọng là phải nhận thức được tính tương thích của các hàm tổng hợp và khi sử dụng các hàm không tương thích như phần trăm, để đưa ra quyết định thiết kế về độ phân giải mà chúng tôi yêu cầu và tính toán trước các chuỗi thời gian này.

Độ phân giải khác nhau không chỉ giới hạn ở yếu tố thời gian. Một ví dụ khác là lưu dữ liệu trên mỗi nhóm, sau đó muốn “nhóm theo” các nút hoặc cụm. Ràng buộc tương tự cũng áp dụng ở đây, nghĩa là nếu chúng ta muốn quan tâm đến việc cắt và chia số liệu dựa trên phần trăm trên mỗi nút, mỗi vùng, mỗi không gian tên hoặc trên toàn bộ cụm, thì chúng ta cần tổng hợp trước cho phù hợp.

Một cách tiếp cận khác là từ bỏ độ chính xác của phép đo để đạt được tính tương thích trong tính toán, bằng cách sử dụng biểu đồ. Bạn có thể lấy biểu đồ của một vài máy chủ và tổng hợp chúng hoặc biểu đồ của một số cửa sổ thời gian và tổng hợp chúng, sau đó giảm tỷ lệ xuống. Vấn đề là trong trường hợp này, phần trăm sẽ là ước tính hơn là chính xác. Cũng cần lưu ý rằng các biểu đồ tốn nhiều thời gian hơn trong việc lưu trữ và thông lượng, vì mỗi mẫu không chỉ là một số mà là một vài mẫu (mỗi mẫu một nhóm).

Bản tóm tắt

Số liệu là một cách mạnh mẽ để giám sát các ứng dụng của chúng tôi. Nhưng chúng không nhất thiết phải đại diện cho trạng thái của hệ thống thực tế. Nó đòi hỏi sự hiểu biết về toán học và bản chất của các chỉ số, cũng như thiết kế cẩn thận, để đảm bảo các chỉ số của chúng tôi thực sự hữu ích để trả lời các câu hỏi mà chúng tôi cần. Có quyền truy cập vào dữ liệu thô bên cạnh các số liệu luôn là điều tốt vì đây cuối cùng là nguồn gốc của sự thật.

Muốn tìm hiểu thêm? Hãy xem tập Thảo luận về khả năng quan sát mở: Tất cả các chỉ số đều sai, một số hữu ích trên Spotify , Podcast của Apple hoặc các ứng dụng podcast khác .

Bài viết này ban đầu ở đây .