Thu thập số liệu từ cơ sở hạ tầng và ứng dụng của bạn
Giới thiệu
Hiểu trạng thái hệ thống của bạn là điều cần thiết đảm bảo độ tin cậy và ổn định của các ứng dụng và dịch vụ của bạn. Thông tin về tình trạng và hiệu suất của việc triển khai của bạn không chỉ giúp group của bạn phản ứng với các vấn đề mà còn cung cấp cho họ sự an toàn để tự tin áp dụng các thay đổi . Một trong những cách tốt nhất để đạt được thông tin chi tiết này là sử dụng một hệ thống giám sát mạnh mẽ thu thập các chỉ số, trực quan hóa dữ liệu và cảnh báo cho người vận hành khi mọi thứ dường như bị hỏng.
Trong phần giới thiệu về số liệu, hướng dẫn giám sát và cảnh báo , ta đã thảo luận một số khái niệm cốt lõi liên quan đến phần mềm và cơ sở hạ tầng giám sát. Chỉ số là tài liệu chính được xử lý bởi hệ thống giám sát để xây dựng một cái nhìn thống nhất về hệ thống đang được theo dõi. Biết thành phần nào đáng theo dõi và những đặc điểm cụ thể nào bạn nên xem xét là bước đầu tiên trong việc thiết kế một hệ thống có thể cung cấp thông tin chi tiết tin cậy , có thể hành động về trạng thái phần mềm và phần cứng của bạn.
Trong hướng dẫn này, ta sẽ bắt đầu bằng cách thảo luận về một khuôn khổ phổ biến được sử dụng để xác định các chỉ số quan trọng nhất cần theo dõi. Sau đó, ta sẽ hướng dẫn cách áp dụng các chỉ số đó cho các thành phần trong suốt quá trình triển khai của bạn. Quá trình này sẽ tập trung vào các tài nguyên cơ bản của các server riêng lẻ lúc đầu và sau đó điều chỉnh phạm vi để bao gồm các khu vực ngày càng lớn hơn cần quan tâm.
Các tín hiệu vàng về giám sát
Trong Sách Google SRE (kỹ thuật độ tin cậy của trang web) có ảnh hưởng lớn, chương về giám sát các hệ thống phân tán giới thiệu một khuôn khổ hữu ích được gọi là bốn tín hiệu vàng về giám sát đại diện cho các yếu tố quan trọng nhất để đo lường trong một hệ thống hướng đến user . Ta sẽ thảo luận về từng đặc điểm trong số bốn đặc điểm dưới đây.
Độ trễ
Độ trễ là thước đo thời gian cần thiết để hoàn thành một hành động. Các chi tiết cụ thể về cách đo lường điều này phụ thuộc vào thành phần, nhưng một số điểm tương tự phổ biến là thời gian xử lý, thời gian phản hồi hoặc thời gian di chuyển.
Việc đo độ trễ cung cấp cho bạn thước đo cụ thể về thời gian hoàn thành một nhiệm vụ hoặc hành động cụ thể. Việc nắm bắt độ trễ của các thành phần khác nhau cho phép bạn xây dựng một mô hình tổng thể về các đặc tính hiệu suất khác nhau của hệ thống . Điều này có thể giúp bạn tìm ra điểm nghẽn, hiểu tài nguyên nào cần nhiều thời gian nhất để truy cập và thông báo khi các hành động đột ngột kéo dài hơn dự kiến. Các tác giả của cuốn sách SRE nhấn mạnh tầm quan trọng của việc phân biệt giữa các yêu cầu thành công và không thành công khi tính toán độ trễ, vì chúng có thể có các cấu hình rất khác nhau có thể làm sai lệch mức trung bình của một dịch vụ.
Giao thông
Lưu lượng đo lường "mức độ bận rộn" của các thành phần và hệ thống của bạn. Điều này nắm bắt lượng tải hoặc nhu cầu đối với các dịch vụ của bạn để bạn có thể hiểu hệ thống của bạn hiện đang thực hiện bao nhiêu công việc.
Số lượng lưu lượng truy cập cao hoặc thấp duy trì có thể cho biết dịch vụ có thể cần nhiều tài nguyên hơn hoặc sự cố đang ngăn lưu lượng truy cập được định tuyến chính xác. Tuy nhiên, trong phần lớn các trường hợp, tỷ lệ lưu lượng sẽ hữu ích nhất trong việc giúp hiểu các vấn đề xuất hiện thông qua các tín hiệu khác. Ví dụ: nếu độ trễ tăng vượt quá mức có thể chấp nhận được, thì việc có thể tương quan khung thời gian đó với lưu lượng truy cập tăng đột biến sẽ rất hữu ích.Lưu lượng truy cập được dùng để hiểu lưu lượng truy cập tối đa có thể được xử lý và cách dịch vụ xuống cấp hoặc thất bại ở các giai đoạn tải khác nhau.
Lỗi
Điều quan trọng là theo dõi các lỗi để hiểu tình trạng của các thành phần của bạn và tần suất chúng không đáp ứng các yêu cầu một cách thích hợp. Một số ứng dụng hoặc dịch vụ để lộ lỗi trong các giao diện được tạo sẵn, sạch sẽ nhưng có thể phải thực hiện thêm công việc để thu thập dữ liệu từ các chương trình khác.
Việc phân biệt giữa các loại lỗi khác nhau có thể giúp bạn dễ dàng xác định bản chất chính xác của các vấn đề đang ảnh hưởng đến ứng dụng của bạn. Điều này cũng giúp bạn linh hoạt trong việc cảnh báo. Bạn có thể cần được cảnh báo ngay lập tức nếu một loại lỗi xuất hiện, nhưng đối với một loại lỗi khác, bạn có thể không lo ngại miễn là tỷ lệ dưới ngưỡng chấp nhận được.
Bão hòa
Độ bão hòa đo lường lượng tài nguyên nhất định đang được sử dụng. Tỷ lệ phần trăm hoặc phân số thường được sử dụng với các tài nguyên có tổng dung lượng rõ ràng, nhưng có thể cần nhiều phép đo sáng tạo hơn đối với các tài nguyên có mức tối đa ít được xác định rõ hơn.
Dữ liệu bão hòa cung cấp thông tin về các tài nguyên mà một dịch vụ hoặc ứng dụng phụ thuộc vào để hoạt động hiệu quả. Vì một dịch vụ được cung cấp bởi một thành phần có thể bị tiêu thụ bởi một thành phần khác, nên độ bão hòa là một trong những thước đo keo xác định các vấn đề về dung lượng của các hệ thống cơ bản. Do đó, các vấn đề về độ bão hòa và độ trễ trong một lớp có thể tương ứng với sự gia tăng rõ rệt về lưu lượng hoặc các phép đo lỗi trong lớp bên dưới.
Đo lường dữ liệu quan trọng trong suốt môi trường của bạn
Sử dụng bốn tín hiệu vàng làm kim chỉ nam, bạn có thể bắt đầu xem xét các chỉ số đó sẽ được thể hiện như thế nào trong toàn bộ hệ thống phân cấp của bạn. Vì các dịch vụ thường được xây dựng bằng cách thêm các lớp trừu tượng lên trên các thành phần cơ bản hơn, các chỉ số phải được thiết kế để thêm thông tin chi tiết ở mỗi cấp độ triển khai.
Ta sẽ xem xét các mức độ phức tạp khác nhau hiện diện trong các môi trường ứng dụng phân tán phổ biến:
- Các thành phần server riêng lẻ
- Ứng dụng và dịch vụ
- Tập hợp các server
- Phụ thuộc môi trường
- Trải nghiệm từ đầu đến cuối
Thứ tự trên mở rộng phạm vi và mức độ trừu tượng với mỗi lớp tiếp theo.
Các chỉ số cần thu thập cho các thành phần server riêng lẻ
Các chỉ số cấp cơ sở quan trọng cần thu thập là những chỉ số có liên quan đến các máy tính cơ bản mà hệ thống của bạn dựa vào. Mặc dù nỗ lực đáng kể trong việc phát triển phần mềm hiện đại nhằm vào việc trừu tượng hóa các thành phần vật lý và chi tiết hệ điều hành cấp thấp, nhưng mọi dịch vụ đều dựa vào phần cứng và hệ điều hành cơ bản để thực hiện công việc của bạn . Do đó, theo dõi các tài nguyên nền tảng của máy là bước đầu tiên để xây dựng sự hiểu biết về tình trạng của hệ thống .
Khi xem xét chỉ số nào cần thu thập ở cấp máy, hãy nghĩ đến các tài nguyên riêng lẻ có sẵn. Chúng sẽ bao gồm các bản trình bày về phần cứng server của bạn cũng như các thông tin tóm tắt cốt lõi được cung cấp bởi Hệ điều hành, như các quy trình và bộ mô tả file . Nhìn vào từng thành phần theo bốn tín hiệu vàng, một số tín hiệu nhất định có thể rõ ràng trong khi những tín hiệu khác có thể khó suy luận hơn.
Brendan Gregg , một kỹ sư hiệu suất có ảnh hưởng, đã vạch ra nhiều cách để lấy các chỉ số cốt lõi từ hệ thống Linux nhằm đáp ứng nhu cầu của một khuôn khổ mà ông gọi là phương pháp SỬ DỤNG để phân tích hiệu suất ( u tization, s aturation và e rrors). Vì có sự trùng lặp đáng kể giữa phương pháp USE và bốn tín hiệu vàng, ta có thể sử dụng một số khuyến nghị của anh ấy như một điểm khởi đầu để tìm ra dữ liệu cần thu thập từ các thành phần server .
Để đo CPU , các phép đo sau có thể phù hợp:
- Độ trễ : Độ trễ trung bình hoặc tối đa trong bộ lập lịch CPU
- Lưu lượng : sử dụng CPU
- Lỗi : Các sự kiện lỗi cụ thể của bộ xử lý, CPU bị lỗi
- Độ bão hòa : Độ dài hàng đợi chạy
Đối với bộ nhớ , các tín hiệu có thể trông như thế này:
- Độ trễ : (không có - khó tìm một phương pháp đo lường tốt và không thể thực hiện được)
- Lưu lượng : Dung lượng bộ nhớ đang được sử dụng
- Lỗi : Lỗi hết bộ nhớ
- Độ bão hòa : Sự kiện sát thủ OOM, sử dụng swap
Đối với thiết bị lưu trữ :
- Độ trễ : thời gian chờ trung bình (
await) để đọc và ghi - Lưu lượng : đọc và ghi các mức I / O
- Lỗi : lỗi hệ thống file , lỗi đĩa trong
/sys/devices - Độ bão hòa : Độ sâu hàng đợi I / O
Các tín hiệu mạng có thể giống như sau:
- Độ trễ : Hàng đợi trình điều khiển mạng
- Lưu lượng : byte hoặc gói tin đến và đi / giây
- Lỗi : Lỗi thiết bị mạng, gói bị rớt
- Độ bão hòa : vượt quá, gói bị giảm, phân đoạn được truyền lại
Cùng với việc trình bày các tài nguyên vật lý, bạn cũng nên thu thập các số liệu liên quan đến các phần tóm tắt của hệ điều hành có giới hạn được thực thi. Một số ví dụ thuộc loại này là xử lý file và số stream . Đây không phải là tài nguyên vật lý, mà thay vào đó là cấu trúc với mức trần do hệ điều hành đặt ra để ngăn các quá trình tự mở rộng quá mức. Hầu hết có thể được điều chỉnh và cấu hình bằng các lệnh như ulimit , nhưng việc theo dõi các thay đổi trong việc sử dụng các tài nguyên này có thể giúp bạn phát hiện những thay đổi có thể gây hại trong việc sử dụng phần mềm của bạn .
Các chỉ số cần thu thập cho Ứng dụng và Dịch vụ
Di chuyển lên một lớp, ta bắt đầu xử lý các ứng dụng và dịch vụ chạy trên server . Các chương trình này sử dụng các thành phần server riêng lẻ mà ta đã xử lý trước đó làm tài nguyên để thực hiện công việc. Các chỉ số ở cấp độ này giúp ta hiểu tình trạng của các ứng dụng và dịch vụ trên một server duy nhất của ta . Ta đã tách các dịch vụ đa server lưu trữ phân tán thành một phần riêng biệt để làm rõ các yếu tố quan trọng nhất trong các cấu hình đó.
Trong khi các số liệu trong phần cuối nêu chi tiết về khả năng và hiệu suất của các thành phần riêng lẻ và hệ điều hành, các số liệu ở đây sẽ cho ta biết các ứng dụng có thể thực hiện công việc ta yêu cầu tốt như thế nào. Ta cũng muốn biết ứng dụng của ta phụ thuộc vào tài nguyên nào và chúng quản lý những ràng buộc đó tốt như thế nào.
Điều quan trọng cần lưu ý là các chỉ số trong phần này thể hiện sự khác biệt so với phương pháp tiếp cận tổng quát mà ta đã có thể sử dụng lần trước. Các số liệu quan trọng nhất từ thời điểm này trở đi sẽ phụ thuộc rất nhiều vào đặc tính của ứng dụng, cấu hình của bạn và dung lượng công việc bạn đang chạy trên máy của bạn . Ta có thể thảo luận về các cách xác định các chỉ số quan trọng nhất của bạn, nhưng kết quả của bạn sẽ phụ thuộc vào những gì server được yêu cầu cụ thể.
Đối với các ứng dụng phục vụ khách hàng, bốn tín hiệu vàng thường khá đơn giản để chọn ra:
- Độ trễ : Thời gian hoàn thành yêu cầu
- Lưu lượng truy cập : Số lượng yêu cầu mỗi giây được phân phát
- Lỗi : Lỗi ứng dụng xảy ra khi xử lý yêu cầu của khách hàng hoặc truy cập tài nguyên
- Độ bão hòa : Phần trăm hoặc số lượng tài nguyên hiện đang được sử dụng
Một số chỉ số quan trọng hơn bạn cần theo dõi là những chỉ số liên quan đến dependencies .Những điều này thường sẽ được thể hiện tốt nhất bằng các chỉ số độ bão hòa liên quan đến các thành phần riêng lẻ. Ví dụ: việc sử dụng bộ nhớ ứng dụng, các kết nối khả dụng, số lượng xử lý file được mở hoặc số lượng công nhân đang hoạt động có thể giúp bạn hiểu tác dụng của cấu hình được áp dụng trong ngữ cảnh của server vật lý.
Bốn tín hiệu vàng được thiết kế chủ yếu cho các dịch vụ vi mô phân tán, vì vậy chúng giả định một kiến trúc client - server . Đối với các ứng dụng không sử dụng kiến trúc client - server , các tín hiệu tương tự vẫn rất quan trọng, nhưng tín hiệu "lưu lượng" có thể cần được xem xét lại một chút. Về cơ bản, đây là một phép đo mức độ bận rộn, vì vậy việc tìm kiếm một số liệu đại diện đầy đủ cho ứng dụng của bạn sẽ phục vụ cùng một mục đích. Các chi tiết cụ thể sẽ phụ thuộc vào những gì chương trình của bạn đang làm, nhưng một số thay thế chung có thể là số lượng hoạt động hoặc dữ liệu được xử lý mỗi giây.
Các chỉ số đo lường Tập hợp Server và Giao tiếp của họ
Hầu hết các dịch vụ, đặc biệt là khi hoạt động trong môi trường production , sẽ trải dài nhiều version server để tăng hiệu suất và tính khả dụng. Mức độ phức tạp tăng lên này làm tăng thêm diện tích bề mặt cần theo dõi. Tính toán phân tán và các hệ thống dự phòng có thể làm cho hệ thống của bạn linh hoạt hơn, nhưng sự phối hợp dựa trên mạng thì mong manh hơn giao tiếp trong một server duy nhất. Việc giám sát chặt chẽ có thể giúp giảm bớt một số khó khăn khi đối phó với một kênh liên lạc kém tin cậy hơn.
Ngoài bản thân mạng, đối với các dịch vụ phân tán, tình trạng và hiệu suất của group server quan trọng hơn các biện pháp tương tự được áp dụng cho bất kỳ server riêng lẻ nào. Mặc dù các dịch vụ được liên kết mật thiết với máy tính mà chúng chạy khi bị giới hạn trong một server duy nhất, các dịch vụ đa server dự phòng dựa vào tài nguyên của nhiều server trong khi vẫn tách biệt khỏi dependencies trực tiếp vào bất kỳ máy tính nào.
Các tín hiệu vàng ở cấp độ này trông rất giống với các tín hiệu đo lường tình trạng dịch vụ trong phần trước. Tuy nhiên, họ sẽ tính đến sự phối hợp bổ sung cần thiết giữa các thành viên group :
- Độ trễ : Thời gian để group phản hồi yêu cầu, thời gian để phối hợp hoặc đồng bộ hóa với các đồng nghiệp
- Lưu lượng truy cập : Số lượng yêu cầu được xử lý bởi group mỗi giây
- Lỗi : Lỗi ứng dụng xảy ra khi xử lý yêu cầu của khách hàng, truy cập tài nguyên hoặc tiếp cận đồng nghiệp
- Độ bão hòa : Lượng tài nguyên hiện đang được sử dụng, số lượng server hiện đang hoạt động hết công suất, số lượng server còn trống.
Mặc dù những tín hiệu này có sự tương đồng nhất định với các chỉ số quan trọng cho các dịch vụ lưu trữ đơn lẻ, nhưng mỗi tín hiệu sẽ tăng độ phức tạp khi được phân phối. Độ trễ trở thành một vấn đề phức tạp hơn vì quá trình xử lý có thể yêu cầu giao tiếp giữa nhiều server . Lưu lượng truy cập không còn là một chức năng của khả năng của một server duy nhất, mà thay vào đó là bản tóm tắt các khả năng của group và hiệu quả của thuật toán định tuyến được sử dụng để phân phối công việc. Các chế độ lỗi bổ sung được đưa ra liên quan đến kết nối mạng hoặc lỗi server . Cuối cùng, sự bão hòa mở rộng để bao gồm các tài nguyên kết hợp có sẵn cho các server , liên kết mạng kết nối mỗi server và khả năng điều phối quyền truy cập đúng vào các phụ thuộc mà mỗi máy tính cần.
Các chỉ số liên quan đến dependencies bên ngoài và môi trường triển khai
Một số chỉ số có giá trị nhất cần thu thập tồn tại ở ranh giới ứng dụng hoặc dịch vụ của bạn, nằm ngoài tầm kiểm soát trực tiếp của bạn.Các phần phụ thuộc bên ngoài bao gồm những phần liên quan đến nhà cung cấp dịch vụ lưu trữ của bạn và bất kỳ dịch vụ nào mà ứng dụng của bạn được xây dựng để dựa vào. Những tài nguyên này đại diện cho các tài nguyên mà bạn không thể quản lý trực tiếp, nhưng có thể ảnh hưởng đến khả năng đảm bảo dịch vụ của chính bạn.
Bởi vì các yếu tố phụ thuộc bên ngoài đại diện cho các nguồn lực quan trọng, một trong những chiến lược giảm thiểu duy nhất có sẵn trong trường hợp hết điện là chuyển hoạt động sang một nhà cung cấp khác. Đây chỉ là một chiến lược khả thi cho các dịch vụ hàng hóa, và thậm chí sau đó chỉ khi lập kế hoạch trước và kết hợp chặt chẽ với nhà cung cấp. Ngay cả khi việc giảm thiểu khó khăn, kiến thức về các sự kiện bên ngoài ảnh hưởng đến ứng dụng của bạn vẫn vô cùng quý giá.
Các tín hiệu vàng được áp dụng cho các phụ thuộc bên ngoài có thể trông giống như sau:
- Độ trễ : Thời gian cần thiết để nhận được phản hồi từ dịch vụ hoặc cung cấp tài nguyên mới từ nhà cung cấp
- Lưu lượng truy cập : Số lượng công việc được đẩy sang một dịch vụ bên ngoài, số lượng yêu cầu được thực hiện tới một API bên ngoài
- Lỗi : Tỷ lệ lỗi cho các yêu cầu dịch vụ
- Độ bão hòa : Số lượng tài nguyên bị giới hạn account được sử dụng (phiên bản, yêu cầu API, chi phí chấp nhận được, v.v.)
Những chỉ số này có thể giúp bạn xác định các vấn đề với những người phụ thuộc của bạn , cảnh báo bạn về sự cạn kiệt tài nguyên sắp xảy ra và giúp kiểm soát chi phí. Nếu dịch vụ có các lựa chọn thay thế thả xuống, dữ liệu này được dùng để quyết định có chuyển công việc sang một nhà cung cấp khác hay không khi các chỉ số cho thấy sự cố đang xảy ra. Đối với các tình huống kém linh hoạt hơn, các chỉ số ít nhất được dùng để cảnh báo người vận hành ứng phó với tình huống và thực hiện bất kỳ tùy chọn giảm thiểu thủ công nào có sẵn.
Các chỉ số theo dõi chức năng tổng thể và trải nghiệm terminal
Các chỉ số cấp cao nhất theo dõi các yêu cầu thông qua hệ thống trong ngữ cảnh của thành phần ngoài cùng mà user tương tác. Đây có thể là bộ cân bằng tải hoặc cơ chế định tuyến khác chịu trách nhiệm nhận và điều phối các yêu cầu đến dịch vụ của bạn. Vì điều này đại diện cho điểm tiếp xúc đầu tiên với hệ thống của bạn, việc thu thập các chỉ số ở cấp độ này sẽ cung cấp một con số gần đúng về trải nghiệm user tổng thể.
Mặc dù các chỉ số được mô tả trước đây cực kỳ hữu ích, nhưng các chỉ số trong phần này thường là quan trọng nhất để cài đặt cảnh báo. Để tránh phản ứng mệt mỏi, các cảnh báo — đặc biệt là các trang — nên được dành riêng cho các trường hợp có tác động tiêu cực có thể nhận ra đối với trải nghiệm user . Các vấn đề nảy sinh với các chỉ số này có thể được điều tra bằng cách đi sâu vào sử dụng các chỉ số được thu thập ở các cấp độ khác.
Các tín hiệu mà ta tìm kiếm ở đây tương tự như các tín hiệu của các dịch vụ riêng lẻ mà ta đã mô tả trước đó. Sự khác biệt chính là phạm vi và tầm quan trọng của dữ liệu ta thu thập ở đây:
- Độ trễ : Thời gian hoàn thành yêu cầu của user
- Lưu lượng truy cập : Số lượng yêu cầu của user mỗi giây
- Lỗi : Lỗi xảy ra khi xử lý yêu cầu của khách hàng hoặc truy cập tài nguyên
- Độ bão hòa : Phần trăm hoặc số lượng tài nguyên hiện đang được sử dụng
Khi các chỉ số này yêu cầu user song song, các giá trị nằm ngoài phạm vi có thể chấp nhận cho các chỉ số này có thể cho thấy tác động trực tiếp của user . Độ trễ không tuân theo SLA đối mặt với khách hàng hoặc nội bộ (thỏa thuận mức dịch vụ), lưu lượng truy cập cho thấy mức tăng đột biến nghiêm trọng, tỷ lệ lỗi tăng và không có khả năng phục vụ yêu cầu do hạn chế về tài nguyên đều khá dễ hiểu về lý do Ở mức này.Giả sử rằng các chỉ số là chính xác, các giá trị ở đây có thể được ánh xạ trực tiếp với các mục tiêu về tính khả dụng, hiệu suất và độ tin cậy của bạn.
Kết luận
Trong hướng dẫn này, ta đã bắt đầu thảo luận về bốn tín hiệu vàng có xu hướng hữu ích nhất để khám phá và hiểu những thay đổi có tác động trong hệ thống của bạn. Sau đó, ta sử dụng các tín hiệu như một thấu kính để đánh giá các yếu tố quan trọng nhất để theo dõi ở các lớp khác nhau của quá trình triển khai.
Đánh giá hệ thống của bạn từ trên xuống dưới có thể giúp xác định các thành phần quan trọng và các tương tác cần thiết để chạy các dịch vụ tin cậy và hiệu quả. Bốn tín hiệu vàng có thể là điểm khởi đầu tuyệt vời để cấu trúc các chỉ số nhằm chỉ ra tốt nhất tình trạng hệ thống của bạn. Tuy nhiên, hãy nhớ rằng trong khi các tín hiệu vàng là một khuôn khổ tốt, bạn sẽ phải nhận thức được các số liệu khác cụ thể cho tình huống của bạn . Thu thập bất kỳ dữ liệu nào bạn cho là có nhiều khả năng để cảnh báo sự cố hoặc giúp bạn khắc phục sự cố khi có sự cố.
Các tin liên quan
