Tại sao phải bố trí lực lượng phân tán
Sau khi tốt nghiệp đại học, tôi đã làm việc ở Amazon. Một trong những bài tập nhập môn đầu tiên của tôi là thiết lập máy chủ web amazon.com và chạy trên máy tính để bàn dành cho nhà phát triển của tôi. Lần đầu tiên tôi thử làm đã thất bại nhưng tôi không chắc mình làm sai ở khâu nào. Một đồng nghiệp tốt bụng đã khuyên rằng tôi nên xem nhật ký để biết được lỗi nằm ở đâu. Anh ấy bảo để làm như vậy, tôi nên dùng lệnh “cat” (mèo). Tôi đã nghĩ là họ đang nói đùa về con mèo hoặc xỏ xiên tôi mà tôi không hiểu. Hồi học đại học, tôi chỉ dùng Linux để biên soạn, sử dụng kiểm soát nguồn và dùng trình soạn thảo văn bản. Vì thế, tôi không biết lệnh “cat” (mèo) thực sự là một lệnh để in một tệp ra định dạng mà tôi có thể cấp dữ liệu vào một chương trình khác nhằm tìm kiếm các mẫu. Các đồng nghiệp đã chỉ cho tôi những công cụ như cat, grep, sed và awk. Khi được trang bị bộ công cụ mới này, tôi đã nghiền ngẫm nhật ký máy chủ web amazon.com trên máy tính để bàn dành cho nhà phát triển của mình. Ứng dụng máy chủ web đã được đo lường để xuất mọi loại thông tin hữu ích sang nhật ký. Điều này giúp tôi biết mình còn thiếu cấu hình nào khiến máy chủ web không thể khởi động, thiếu cấu hình nào cho biết vị trí có thể gặp lỗi hoặc thiếu cấu hình nào cho biết vị trí không kết nối được với một dịch vụ xuôi tuyến. Trang web này hình thành từ rất nhiều thành phần di động và đó thực sự là một điều bí ẩn đối với tôi khi mới vào nghề. Tuy nhiên, sau khi nghiền ngẫm hệ thống trước tiên, tôi đã biết cách xác định máy chủ hoạt động ra sao và cách tương tác với các thành phần phụ thuộc trong máy chủ mà chỉ cần nhìn vào kết quả của công cụ đo lường.
Khi luân chuyển công việc giữa các nhóm trong những năm làm việc ở Amazon, tôi thấy rằng công cụ đo lường là một thấu kính vô giá mà tôi và mọi người ở Amazon có thể nhìn vào để hiểu một hệ thống hoạt động ra sao. Tuy nhiên, công cụ đo lường không chỉ giúp bạn tìm hiểu về hệ thống thôi đâu. Đó còn là thành phần cốt lõi trong văn hóa vận hành ở Amazon. Công cụ đo lường tuyệt vời giúp chúng tôi biết được trải nghiệm mà mình đang tạo ra cho khách hàng. Công ty chúng tôi rất chú trọng đến vấn đề hiệu suất vận hành. Trong các dịch vụ liên quan đến amazon.com, thời gian trễ càng dài thì trải nghiệm mua sắm càng tệ, khiến tỷ lệ chuyển đổi sụt giảm. Với những khách hàng sử dụng AWS, họ dựa vào độ sẵn sàng cao và độ trễ thấp của các dịch vụ AWS. Ở Amazon, chúng tôi không chỉ cân nhắc độ trễ trung bình. Chúng tôi còn tập trung hơn nữa đến khoảng lệch độ trễ, như phân vị phần trăm thứ 99,9 và 99,99. Đó là bởi vì nếu một yêu cầu trong tổng số 1.000 hay 10.000 yêu cầu bị chậm, thì trải nghiệm đó vẫn bị coi là tồi tệ. Chúng tôi thấy rằng khi giảm độ trễ theo phân vị phần trăm cao trong hệ thống, thì cũng tạo ra một hiệu ứng phụ là giảm độ trễ trung bình. Ngược lại, chúng tôi thấy rằng khi giảm độ trễ trung bình, thì ít khi giảm được độ trễ theo phân vị phần trăm cao. Một lý do khác khiến chúng tôi tập trung vào độ trễ theo phân vị phần trăm cao đó là độ trễ cao trong một dịch vụ có thể tạo ra hiệu ứng ở cấp số nhân trên các dịch vụ khác. Amazon được xây dựng trên một kiến trúc hướng dịch vụ. Nhiều dịch vụ cộng tác với nhau để thực hiện công việc nào đó, chẳng hạn như kết xuất một trang web trên amazon.com. Kết quả là, độ trễ gia tăng của một dịch vụ nằm sâu trong chuỗi lệnh gọi—ngay cả khi mức tăng nằm ở ngưỡng phân vị phần trăm cao—có hiệu ứng lan tỏa lớn đến độ trễ ở phía người dùng cuối. Các hệ thống lớn ở Amazon hình thành từ nhiều dịch vụ cộng tác với nhau. Mỗi dịch vụ do một nhóm phát triển và vận hành (“dịch vụ” lớn bao gồm nhiều dịch vụ hoặc thành phần không hiển thị). Nhóm sở hữu một dịch vụ được gọi là chủ sở hữu dịch vụ. Mỗi thành viên trong nhóm đó sẽ suy nghĩ như chủ sở hữu và người vận hành dịch vụ, cho dù thành viên đó là nhà phát triển phần mềm, kỹ sư mạng, người quản lý hay giữ bất kỳ vai trò nào khác. Là chủ sở hữu, các nhóm sẽ đặt mục tiêu cho hiệu suất vận hành của toàn bộ dịch vụ liên quan. Chúng tôi cũng đảm bảo mình hiểu rõ cách vận hành dịch vụ để đảm bảo đáp ứng các mục tiêu đó, khắc phục mọi sự cố phát sinh và cam kết đặt mục tiêu cao hơn cho năm sau. Để đặt mục tiêu và hiểu được cách dịch vụ vận hành, các nhóm phải sử dụng hệ thống đo lường. Công cụ đo lường cũng giúp chúng tôi phát hiện và phản hồi khéo léo với các sự cố vận hành. Công cụ đo lường cấp dữ liệu vào bảng thông tin vận hành sao cho người vận hành có thể xem các chỉ số trong thời gian thực. Công cụ đo lường cũng cấp dữ liệu tới các báo động sẽ kích hoạt và thông báo cho người vận hành khi hệ thống hoạt động không đúng cách. Người vận hành dùng kết quả chi tiết mà công cụ đo lường phân tích để chẩn đoán nhanh lý do gặp sự cố. Từ đó, chúng tôi có thể khắc phục vấn đề và quay lại sau để ngăn không cho vấn đề tái diễn. Khi không có công cụ đo lường hiệu quả trong mã, chúng tôi sẽ tốn rất nhiều thời gian quý báu để chẩn đoán vấn đề.
Để vận hành dịch vụ theo tiêu chuẩn cao về độ sẵn sàng và độ trễ, chúng tôi, với tư cách là chủ sở hữu dịch vụ, cần đo lường xem hệ thống hoạt động ra sao. Để đo từ xa khi cần thiết, chủ sở hữu dịch vụ sẽ đo hiệu suất vận hành từ nhiều vị trí để nắm được nhiều phương diện về cách mọi thứ đang vận hành từ đầu đến cuối. Việc này rất phức tạp, ngay cả trong một kiến trúc đơn giản. Đơn cử là một dịch vụ mà khách hàng gọi thông qua cân bằng tải: dịch vụ này sẽ giao tiếp với một bộ nhớ đệm từ xa và cơ sở dữ liệu từ xa. Chúng tôi muốn mỗi thành phần sẽ cho các chỉ số về hành vi của thành phần đó. Chúng tôi cũng muốn có các chỉ số về cách mỗi thành phần nhận biết hành vi của các thành phần khác. Khi chỉ số từ tất cả các phương diện này được tập hợp lại với nhau, chủ sở hữu dịch vụ có thể nhanh chóng truy nguyên nguồn gốc vấn đề và nghiên cứu để tìm nguyên nhân. Nhiều dịch vụ AWS tự động cung cấp thông tin vận hành chi tiết về tài nguyên của bạn. Ví dụ: Amazon DynamoDB cung cấp cho Amazon CloudWatch các chỉ số về tỷ lệ thành công và tỷ lệ lỗi cũng như độ trễ mà dịch vụ này đo được. Tuy nhiên, khi xây dựng hệ thống sử dụng các dịch vụ này, chúng tôi cần rất nhiều thông tin chi tiết hơn về cách các hệ thống đang hoạt động. Công cụ đo lường cần có mã rõ ràng sẽ ghi lại thời lượng của nhiệm vụ, tần suất thực hiện đường dẫn mã nhất định, siêu dữ liệu về nhiệm vụ đã phân tích và phần nhiệm vụ nào thành công hay thất bại. Nếu một nhóm không bổ sung công cụ đo lường rõ ràng, thì nhóm đó sẽ buộc phải vận hành dịch vụ của mình dưới dạng một hộp đen. Ví dụ: nếu chúng tôi triển khai một hoạt động API dịch vụ sẽ truy xuất thông tin sản phẩm theo ID sản phẩm, thì mã có thể trông giống như ví dụ sau đây. Mã này sẽ tra cứu thông tin sản phẩm trong một bộ nhớ đệm cục bộ, sau đó là bộ nhớ đệm từ xa rồi đến cơ sở dữ liệu: public GetProductInfoResponse getProductInfo(GetProductInfoRequest request) { // check our local cache ProductInfo info = localCache.get(request.getProductId()); // check the remote cache if we didn't find it in the local cache if (info == null) { info = remoteCache.get(request.getProductId()); localCache.put(info); } // finally check the database if we didn't have it in either cache if (info == null) { info = db.query(request.getProductId()); localCache.put(info); remoteCache.put(info); } return info; }
Nếu vận hành dịch vụ này, thì tôi sẽ cần rất nhiều công cụ đo lường trong mã này để có thể hiểu hành vi của dịch vụ trong môi trường sản xuất. Tôi sẽ cần khả năng khắc phục những yêu cầu bị chậm hoặc lỗi và theo dõi xu hướng cũng như dấu hiệu mà các thành phần phụ thuộc khác nhau có quy mô thấp hơn hoặc có hành vi ngoài dự kiến. Đây là mã đó, kèm theo ghi chú một số câu hỏi mà tôi cần giải đáp được về hệ thống sản xuất nói chung hoặc cho một yêu cầu cụ thể: public GetProductInfoResponse getProductInfo(GetProductInfoRequest request) { // Which product are we looking up? // Who called the API? What product category is this in? // Did we find the item in the local cache? ProductInfo info = localCache.get(request.getProductId()); if (info == null) { // Was the item in the remote cache? // How long did it take to read from the remote cache? // How long did it take to deserialize the object from the cache? info = remoteCache.get(request.getProductId()); // How full is the local cache? localCache.put(info); } // finally check the database if we didn't have it in either cache if (info == null) { // How long did the database query take? // Did the query succeed? // If it failed, is it because it timed out? Or was it an invalid query? Did we lose our database connection? // If it timed out, was our connection pool full? Did we fail to connect to the database? Or was it just slow to respond? info = db.query(request.getProductId()); // How long did populating the caches take? // Were they full and did they evict other items? localCache.put(info); remoteCache.put(info); } // How big was this product info object? return info; }
Mã để trả lời toàn bộ các câu hỏi đó (và nhiều hơn thế) dài hơn lô-gic công việc thực tế một chút. Một số thư viện có thể giúp giảm số lượng mã công cụ đo lường, tuy nhiên, nhà phát triển vẫn phải đặt các câu hỏi về thông tin chi tiết mà các thư viện này sẽ cần rồi tập trung vào việc kết nối công cụ đo lường. Khi khắc phục một yêu cầu di chuyển qua hệ thống phân tán, có lẽ bạn khó có thể hiểu được điều gì xảy ra nếu chỉ nhìn vào yêu cầu đó dựa trên một tương tác. Để xâu chuỗi các sự kiện, chúng tôi thấy việc tập hợp mọi phép đo về tất cả các hệ thống này về cùng một nơi là cách làm khá hữu ích. Trước khi chúng tôi có thể làm điều đó, mỗi dịch vụ phải được đo lường để ghi lại ID theo dõi cho mỗi nhiệm vụ và để cung cấp ID theo dõi đó cho mỗi dịch vụ khác cũng cộng tác trên nhiệm vụ đó. Chúng tôi có thể thu thập công cụ đo lường trên các hệ thống cho một ID theo dõi cụ thể sau một dữ kiện theo yêu cầu hoặc trong thời gian gần thực bằng một dịch vụ như AWS X-Ray.
Công cụ đo lường cho phép khắc phục sự cố ở nhiều cấp độ, từ cái nhìn sơ lược về các chỉ số để xem có vấn đề bất thường nào quá khó phát hiện để kích hoạt báo động hay không, để tiến hành điều tra nhằm tìm hiểu nguyên nhân của những vấn đề bất thường đó. Ở cấp độ cao nhất, công cụ đo lường được tích hợp vào các chỉ số có thể kích hoạt báo động và hiển thị trên bảng thông tin. Những chỉ số tích hợp này cho phép người vận hành theo dõi tốc độ yêu cầu tổng thể, độ trễ của các lệnh gọi dịch vụ và tỷ lệ lỗi. Những báo động và chỉ số này giúp chúng tôi nhận biết vấn đề bất thường hay các thay đổi cần điều tra. Sau khi phát hiện một vấn đề bất thường, chúng tôi cần tìm hiểu vì sao vấn đề đó lại xảy ra. Để trả lời câu hỏi đó, chúng tôi còn có thể dựa vào các chỉ số mà công cụ đo lường khác cung cấp. Khi đo lường thời gian cần để thực hiện các phần khác nhau trong khi phân phối một yêu cầu, chúng tôi có thể biết phần nào trong quy trình đang chậm hơn bình thường hoặc thường xuyên kích hoạt lỗi hơn. Mặc dù các bộ hẹn giờ và chỉ số tích hợp có thể giúp chúng tôi tìm ra nguyên nhân hoặc đánh dấu một khu vực cần điều tra, nhưng không phải lúc nào chúng cũng cung cấp một giải thích đầy đủ. Ví dụ: khi nhìn vào các chỉ số, chúng tôi có thể thấy rằng lỗi đến từ một hoạt động của API cụ thể nhưng các chỉ số không thể cung cấp thông tin ở mức cụ thể về lý do hoạt động đó gặp lỗi. Lúc này, chúng tôi sẽ nhìn vào dữ liệu nhật ký chi tiết, chưa xử lý theo dịch vụ trong khoảng thời gian đó. Sau đó, nhật ký chưa xử lý sẽ cho biết nguồn gốc vấn đề, lỗi cụ thể đã xảy ra hay khía cạnh cụ thể của yêu cầu đã kích hoạt một số trường hợp khó và bất khả thi.
Công cụ đo lường yêu cầu phải viết mã. Điều đó có nghĩa là khi triển khai chức năng mới, chúng tôi cần dành thời gian để bổ sung mã phụ nhằm cho biết điều gì đã xảy ra, thành công hay lỗi và thời lượng xảy ra. Vì công cụ đo lường chỉ là một nhiệm vụ viết mã thông thường, nên dần dần, Amazon đã hình thành những phương pháp xử lý các mẫu thường gặp: chuẩn hóa cho thư viện công cụ đo lường phổ biến và chuẩn hóa cho báo cáo chỉ số dựa trên nhật ký có cấu trúc. Chuẩn hóa thư viện công cụ đo lường chỉ số giúp chủ thư viện cung cấp cho người dùng thư viện thông tin chi tiết về cách thư viện vận hành. Ví dụ: các máy khách HTTP thường dùng sẽ tích hợp với các thư viện phổ biến này để nếu một nhóm dịch vụ triển khai lệnh gọi từ xa tới một dịch vụ khác, thì các máy khách sẽ tự động nhận được công cụ đo lường về những lệnh gọi đó. Khi một ứng dụng có công cụ đo lường chạy và thực hiện công việc, dữ liệu đo lường từ xa được ghi vào một tệp nhật ký có cấu trúc. Nói chung, dữ liệu được cung cấp dưới dạng một mục nhật ký trên mỗi “đơn vị công việc”, cho dù đó là yêu cầu tới dịch vụ HTTP hay thông báo được lấy từ hàng đợi. Ở Amazon, các phép đo trong ứng dụng không được tích hợp và đôi khi bị đẩy vào một hệ thống tích hợp chỉ số. Tất cả các bộ hẹn giờ và bộ đếm cho mọi phần công việc đều được ghi vào tệp nhật ký. Từ đó, các nhật ký được xử lý và số liệu tích hợp được tính toán sau một dữ kiện của một số hệ thống khác. Bằng cách này, chúng tôi có được mọi thông tin từ chỉ số vận hành tích hợp cấp cao cho đến dữ liệu khắc phục sự cố chi tiết ở cấp độ yêu cầu, tất cả chỉ nhờ vào phương pháp viết mã đo lường. Ở Amazon, chúng tôi ghi nhật ký trước rồi mới tạo chỉ số tích hợp.
Chúng tôi thường đo lường các dịch vụ của mình để tạo hai loại dữ liệu nhật ký: dữ liệu yêu cầu và dữ liệu gỡ lỗi. Dữ liệu nhật ký yêu cầu thường được trình bày dưới dạng mục nhật ký có cấu trúc cho mỗi đơn vị công việc. Dữ liệu này chứa các thuộc tính về yêu cầu và người yêu cầu, nội dung yêu cầu, bộ đếm tần suất yêu cầu và bộ hẹn giờ thời lượng diễn ra. Nhật ký yêu cầu phân phối dưới dạng một nhật ký kiểm tra và một nguồn theo dõi cho mọi hoạt động xảy ra trong dịch vụ. Dữ liệu gỡ lỗi bao gồm dữ liệu có cấu trúc rời rạc hoặc phi cấu trúc về những dòng gỡ lỗi mà ứng dụng cung cấp. Thông thường, đó là các mục nhật ký phi cấu trúc như lỗi Log4j hoặc dòng nhật ký cảnh báo. Ở Amazon, hai loại dữ liệu này thường được ghi vào các tệp nhật ký riêng, một phần vì những lý do trước đây, nhưng cũng bởi nó có thể giúp việc phân tích nhật ký trở nên tiện lợi hơn trên một định dạng mục nhật ký đồng nhất. Các tác nhân như CloudWatch Logs Agent xử lý cả hai loại dữ liệu nhật ký trong thời gian thực và gửi nhật ký vào CloudWatch Logs. Đổi lại, CloudWatch Logs tạo ra chỉ số tích hợp về dịch vụ trong thời gian gần thực. Amazon CloudWatch Alarms sẽ đọc các chỉ số tích hợp và kích hoạt báo động. Mặc dù việc ghi nhật ký quá chi tiết về từng yêu cầu có thể gây tốn kém, nhưng ở Amazon, chúng tôi thấy việc này cực kỳ quan trọng. Sau cùng, chúng tôi cần điều tra về sự cố tạm thời với độ sẵn sàng, độ trễ tăng vọt và vấn đề mà khách hàng báo cáo. Nếu không có nhật ký chi tiết, chúng tôi không thể trả lời khách hàng và cải thiện dịch vụ của họ.
Chủ đề về hoạt động giám sát và báo động rất rộng. Trong bài viết này, chúng tôi không đề cập đến các chủ đề như thiết lập và tinh chỉnh ngưỡng báo động, sắp xếp các bảng thông tin vận hành, đo lường hiệu suất từ cả phía máy chủ lẫn máy khách, liên tục chạy các ứng dụng “canary” và chọn hệ thống phù hợp dùng để tích hợp các chỉ số và phân tích nhật ký. Bài viết này tập trung vào nhu cầu đo lường các ứng dụng của chúng tôi để tạo ra dữ liệu đo lường chưa xử lý phù hợp. Chúng tôi sẽ mô tả những điều mà các nhóm ở Amazon nỗ lực đưa vào (hoặc tránh) khi đo lường các ứng dụng của họ.
Trong phần này, tôi sẽ mô tả những thói quen tốt mà chúng tôi đã lĩnh hội được về việc ghi nhật ký dữ liệu “theo đơn vị công việc” có cấu trúc khi làm việc ở Amazon. Một nhật ký đáp ứng những tiêu chí này sẽ chứa các bộ đếm cho biết tần suất các hoạt động diễn ra, bộ hẹn giờ chứa thời lượng hoạt động diễn ra và các thuộc tính bao gồm siêu dữ liệu về từng đơn vị công việc. Cách chúng tôi ghi nhật ký
• Phát hành một mục nhật ký yêu cầu cho mỗi đơn vị công việc. Một đơn vị công việc thường là một yêu cầu mà dịch vụ của chúng tôi nhận được hoặc là một thông báo lấy từ một hàng đợi. Chúng tôi ghi một mục nhật ký dịch vụ cho mỗi yêu cầu mà dịch vụ của mình nhận được. Chúng tôi không kết hợp nhiều đơn vị công việc cùng nhau. Bằng cách này, khi khắc phục một yêu cầu bị lỗi, chúng tôi chỉ cần nhìn vào một mục nhật ký. Mục nhật ký này chứa các tham số đầu vào liên quan về yêu cầu để xem mục đích của yêu cầu này, thông tin về người gọi và toàn bộ thông tin hẹn giờ cũng như bộ đếm ở cùng một nơi. Nội dung chúng tôi ghi nhật ký
• Ghi nhật ký độ sẵn sàng và độ trễ của toàn bộ các thành phần phụ thuộc. Chúng tôi thấy điều này đặc biệt hữu ích khi trả lời câu hỏi “vì sao yêu cầu bị chậm?” hay “vì sao yêu cầu không thành công?” Khi không có nhật ký này, chúng tôi chỉ có thể so sánh các biểu đồ của thành phần phụ thuộc với các biểu đồ của một dịch vụ, và đoán xem liệu một sự tăng vọt trong độ trễ của một dịch vụ phụ thuộc có khiến yêu cầu mà chúng tôi đang điều tra gặp lỗi hay không. Nhiều framework dịch vụ và máy khách tự động khám phá các chỉ số nhưng các framework khác (như SDK AWS chẳng hạn) lại yêu cầu đo lường thủ công.
Phần này mô tả thói quen tốt mà chúng tôi đã lĩnh hội được ở Amazon khi ghi dữ liệu nhật ký gỡ lỗi phi cấu trúc. • Loại bỏ spam khỏi nhật ký ứng dụng. Mặc dù chúng tôi có thể có các tuyên bố nhật ký cấp độ THÔNG TIN và GỠ LỖI trên đường dẫn yêu cầu để hỗ trợ hoạt động phát triển và gỡ lỗi trong môi trường kiểm thử, nhưng chúng tôi cân nhắc việc tắt những cấp độ nhật ký này trong môi trường sản xuất. Thay vì dựa vào nhật ký ứng dụng để biết thông tin theo dõi yêu cầu, chúng tôi coi nhật ký dịch vụ là một ví trí lưu trữ thông tin theo dõi có thể dễ dàng tạo ra các chỉ số và xem xu hướng tích hợp theo thời gian. Tuy nhiên, không có quy tắc đúng - sai nào ở đây cả. Phương pháp của chúng tôi là liên tục xem xét nhật ký để xem chúng có quá nhiễu không (hay chưa đủ nhiễu) và điều chỉnh cấp độ nhật ký theo thời gian. Ví dụ: khi nghiên cứu nhật ký, chúng tôi thường thấy các tuyên bố nhật ký quá nhiễu hay các chỉ số chúng tôi mong muốn có được quá nhiễu. Thật may là những cải tiến này thường dễ dàng tiến hành nên chúng tôi đã tạo thói quen lập hồ sơ theo dõi nhanh các mục tồn đọng để nhật ký luôn rõ ràng.
Đối với hầu hết các dịch vụ chính ở Amazon, việc ghi mọi yêu cầu không tạo ra chi phí quản lý bất hợp lý. Dịch vụ có thông lượng cao hơn sẽ đi vào vùng xám hơn nhưng chúng tôi thường vẫn ghi nhật ký trên mọi yêu cầu. Ví dụ: chúng tôi có thể giả định rằng DynamoDB phân phối ở mức tối đa 20 triệu yêu cầu mỗi giây chỉ với lưu lượng trong Amazon sẽ không ghi quá nhiều nhật ký. Nhưng thực tế là nó ghi lại mọi yêu cầu để khắc phục sự cố và vì lý do kiểm tra cũng như tuân thủ. Sau đây là một số mẹo ở cấp cao chúng tôi áp dụng ở Amazon để giúp ghi nhật ký hiệu quả hơn ở thông lượng mỗi máy chủ cao hơn: • Lấy mẫu nhật ký. Thay vì ghi mọi mục, hãy cân nhắc việc ghi mỗi N mục. Mỗi mục cũng bao gồm số lượng mục bị bỏ qua để hệ thống tổng hợp chỉ số có thể ước tính lượng nhật ký thực sự trong chỉ số mà nó tính toán. Các thuật toán lấy mẫu khác như lấy mẫu dự trữ cung cấp nhiều mẫu đại diện hơn. Các thuật toán khác ưu tiên ghi nhật ký các lỗi hoặc yêu cầu chậm so với yêu cầu nhanh, thành công. Tuy nhiên, khi lấy mẫu, thì khả năng giúp khách hàng và khắc phục những lỗi cụ thể có thể giảm đi. Một số yêu cầu tuân thủ không cho phép làm như vậy.
Ở Amazon, chúng tôi vận hành các dịch vụ mà chúng tôi ghi nên tất cả chúng tôi đều phải trở thành chuyên gia khắc phục các dịch vụ đó. Điều này bao gồm việc có thể dễ dàng phân tích nhật ký. Chúng tôi có rất nhiều công cụ mà bạn có thể sử dụng, từ phân tích nhật ký cục bộ để xem xét số lượng nhật ký tương đối nhỏ cho đến phân tích nhật ký phân tán để chọn lọc và tổng hợp kết quả từ một lượng nhật ký khổng lồ. Chúng tôi thấy bạn cần đầu tư vào công cụ và tài liệu vận hành để nhóm phân tích nhật ký. Nếu nhật ký hiện còn nhỏ, nhưng dịch vụ sẽ phát triển theo thời gian, chúng tôi sẽ quan tâm đến thời điểm công cụ hiện tại dừng mở rộng quy mô để có thể đầu tư vào việc áp dụng giải pháp phân tích nhật ký phân tán. Phân tích nhật ký cục bộ
Quy trình phân tích nhật ký có thể yêu cầu kinh nghiệm sử dụng nhiều tiện ích dòng lệnh Linux. Ví dụ: dòng lệnh “tìm địa chỉ IP tạo ra lưu lượng nặng nhất trong nhật ký” khá đơn giản: cat log | grep -P "^RemoteIp=" | cut -d= -f2 | sort | uniq -c | sort -nr | head -n20 Phân tích nhật ký phân tán
Là chủ sở hữu dịch vụ và nhà phát triển phần mềm, tôi đành lượng lớn thời gian xem xét kết quả của công cụ đo lường: biểu đồ trên bảng thông tin, từng tệp nhật ký, đồng thời sử dụng các công cụ phân tích nhật ký phân tán như CloudWatch Logs Insights. Đó là một số công việc yêu thích của tôi. Khi cần nghỉ ngơi sau khi hoàn thành một số nhiệm vụ thách thức, tôi sẽ thư giãn và thưởng cho mình bằng cách khám phá một số nhật ký. Tôi bắt đầu bằng các câu hỏi như “vì sao chỉ số này lại tăng vọt ở đây?” hay “độ trễ của hoạt động này có thể thấp hơn không?” Khi câu hỏi của tôi đi vào bế tắc, tôi thường tìm một số phép đo sẽ hữu ích trong mã nên tôi thêm công cụ đo lường, phép kiểm thử và gửi đánh giá mã cho thành viên nhóm. Mặc dù nhiều chỉ số đi kèm với dịch vụ được quản lý mà chúng tôi sử dụng, nhưng chúng tôi cần dành rất nhiều tâm huyết cho việc đo lường dịch vụ của chính mình để hiểu rõ mình cần gì để vận hành chúng hiệu quả. Trong các sự kiện vận hành, chúng tôi cần xác định nhanh vì sao chúng tôi gặp vấn đề và chúng tôi có thể làm gì để khắc phục vấn đề đó. Việc có chỉ số phù hợp trên bảng thông tin đóng vai trò sống còn, giúp chúng tôi có thể chẩn đoán nhanh chóng. Ngoài ra, vì chúng tôi luôn thay đổi dịch vụ, bổ sung tính năng mới và thay đổi cách tương tác với thành phần phụ thuộc, nên việc cập nhật và thêm công cụ đo lường phù hợp sẽ diễn ra liên tục.
David Yanacek là Kỹ sư chính cấp cao làm việc với AWS Lambda. David là nhà phát triển phần mềm tại Amazon từ năm 2006, trước đây đã làm việc với Amazon DynamoDB và AWS IoT, cũng như các khung dịch vụ web nội bộ và các hệ thống tự động hóa nghiệp vụ nhóm. Một trong những hoạt động yêu thích của David tại nơi làm việc là thực hiện phân tích nhật ký và sàng lọc các số liệu hoạt động để tìm cách làm cho hệ thống vận hành ngày càng trơn tru hơn. |