Trong môi trường của các kỹ sư SRE/DevOps, sẽ không có gì ngạc nhiên khi một ngày nào đó khách hàng (hoặc hệ thống giám sát) xuất hiện và báo cáo rằng “mọi thứ đã mất”: trang web không hoạt động, thanh toán không được thực hiện, cuộc sống đang suy tàn ... Cho dù bạn có muốn giúp đỡ trong tình huống như vậy đến mức nào đi chăng nữa thì cũng có thể rất khó thực hiện được điều này nếu không có một công cụ đơn giản và dễ hiểu. Thông thường vấn đề ẩn trong chính mã ứng dụng; bạn chỉ cần bản địa hóa nó.
Và trong nỗi buồn và trong niềm vui…
Điều đó đã xảy ra đến nỗi chúng tôi đã yêu New Relic từ lâu và sâu sắc. Nó đã và vẫn là một công cụ tuyệt vời để theo dõi hiệu suất ứng dụng, đồng thời cho phép bạn trang bị kiến trúc vi dịch vụ (sử dụng tác nhân của nó) và hơn thế nữa. Và mọi thứ có thể đã tuyệt vời nếu không có những thay đổi trong chính sách giá của dịch vụ: nó chi phí tăng gấp 3 lần. Ngoài ra, kể từ năm ngoái, việc có được tài khoản dùng thử đòi hỏi phải liên lạc với người quản lý cá nhân, điều này gây khó khăn cho việc giới thiệu sản phẩm cho khách hàng tiềm năng.
Tình huống thông thường: Di tích mới không cần thiết một cách “vĩnh viễn”; họ chỉ nhớ nó vào thời điểm khi vấn đề bắt đầu. Tuy nhiên, bạn vẫn cần phải trả tiền thường xuyên (140 USD cho mỗi máy chủ mỗi tháng) và trong cơ sở hạ tầng đám mây tự động mở rộng, tổng số tiền sẽ khá lớn. Mặc dù có tùy chọn Trả tiền khi bạn di chuyển, việc bật Di tích mới sẽ yêu cầu bạn khởi động lại ứng dụng, điều này có thể dẫn đến việc loại bỏ tình huống có vấn đề mà tất cả đã bắt đầu. Cách đây không lâu, New Relic đã giới thiệu gói cước mới - , - thoạt nhìn có vẻ như là một sự thay thế hợp lý cho Chuyên nghiệp... nhưng khi xem xét kỹ hơn, hóa ra thiếu một số chức năng quan trọng (đặc biệt là nó không có Giao dịch chính, Theo dõi ứng dụng chéo, Truy tìm phân tán).
Do đó, chúng tôi bắt đầu nghĩ đến việc tìm kiếm một giải pháp thay thế rẻ hơn và lựa chọn của chúng tôi thuộc về hai dịch vụ: Datadog và Atatus. Tại sao lại thuộc về họ?
Về đối thủ cạnh tranh
Hãy để tôi nói ngay rằng có những giải pháp khác trên thị trường. Chúng tôi thậm chí còn xem xét các tùy chọn Nguồn mở, nhưng không phải mọi khách hàng đều có khả năng lưu trữ miễn phí các giải pháp tự lưu trữ... - ngoài ra, chúng sẽ yêu cầu bảo trì bổ sung. Cặp đôi chúng tôi chọn hóa ra lại là người thân nhất Những nhu cầu cua chúng ta:
- hỗ trợ tích hợp và phát triển cho các ứng dụng PHP (ngăn xếp của khách hàng của chúng tôi rất đa dạng, nhưng đây rõ ràng là công ty dẫn đầu trong bối cảnh tìm kiếm giải pháp thay thế cho New Relic);
- chi phí phải chăng (dưới 100 USD mỗi tháng cho mỗi máy chủ);
- thiết bị đo tự động;
- tích hợp với Kubernetes;
- Sự giống nhau với giao diện New Relic là một điểm cộng đáng chú ý (vì các kỹ sư của chúng tôi đã quen với nó).
Do đó, ở giai đoạn lựa chọn ban đầu, chúng tôi đã loại bỏ một số giải pháp phổ biến khác, cụ thể:
- Tideways, AppDynamics và Dynatrace - tính theo chi phí;
- Stackify bị chặn ở Liên bang Nga và hiển thị quá ít dữ liệu.
Phần còn lại của bài viết được cấu trúc theo cách mà các giải pháp được đề cập trước tiên sẽ được trình bày ngắn gọn, sau đó tôi sẽ nói về sự tương tác điển hình của chúng tôi với New Relic và trải nghiệm/ấn tượng khi thực hiện các hoạt động tương tự trong các dịch vụ khác.
Trình bày các đối thủ cạnh tranh được lựa chọn
trên , chắc mọi người đã nghe rồi nhỉ? Dịch vụ này bắt đầu phát triển cách đây hơn 10 năm, vào năm 2008. Chúng tôi đã tích cực sử dụng nó từ năm 2012 và không gặp vấn đề gì khi tích hợp một số lượng lớn ứng dụng trong PHP, Ruby và Python, đồng thời chúng tôi cũng đã có kinh nghiệm tích hợp với C# và Go. Các tác giả của dịch vụ có các giải pháp giám sát ứng dụng, cơ sở hạ tầng, truy tìm cơ sở hạ tầng dịch vụ vi mô, tạo ra các ứng dụng tiện lợi cho thiết bị người dùng, v.v.
Tuy nhiên, tác nhân Relic mới chạy trên các giao thức độc quyền và không hỗ trợ OpenTracing. Công cụ đo lường nâng cao yêu cầu chỉnh sửa cụ thể cho Di tích mới. Cuối cùng, hỗ trợ Kubernetes vẫn đang thử nghiệm.
Bắt đầu phát triển vào năm 2010 trông thú vị hơn đáng kể so với New Relic về mặt sử dụng trong môi trường Kubernetes. Đặc biệt, nó hỗ trợ tích hợp với các giao thức NGINX Ingress, thu thập nhật ký, statsd và OpenTracing, cho phép bạn theo dõi yêu cầu của người dùng từ thời điểm kết nối đến khi hoàn thành, cũng như tìm nhật ký cho yêu cầu này (cả ở phía máy chủ web). và của người tiêu dùng).
Khi sử dụng Datadog, chúng tôi gặp phải hiện tượng đôi khi nó xây dựng bản đồ microservice không chính xác và một số thiếu sót về mặt kỹ thuật. Ví dụ: nó xác định sai loại dịch vụ (nhầm Django với dịch vụ bộ nhớ đệm) và gây ra 500 lỗi trong ứng dụng PHP sử dụng thư viện Predis phổ biến.
- nhạc cụ trẻ nhất; dịch vụ này đã được ra mắt vào năm 2014. Ngân sách tiếp thị của nó rõ ràng là kém hơn so với các đối thủ được liệt kê, việc đề cập ít phổ biến hơn nhiều. Tuy nhiên, bản thân công cụ này rất giống với New Relic, không chỉ về khả năng (APM, giám sát trình duyệt, v.v.) mà còn về hình thức.
Một nhược điểm đáng kể là nó chỉ hỗ trợ Node.js và PHP. Mặt khác, nó được triển khai tốt hơn đáng kể so với Datadog. Không giống như sau, Atatus không yêu cầu ứng dụng thực hiện sửa đổi hoặc thêm nhãn bổ sung vào mã.
Cách chúng tôi làm việc với New Relic
Bây giờ hãy tìm hiểu cách chúng ta thường sử dụng Di tích mới. Giả sử chúng ta có một vấn đề cần giải pháp:
Thật dễ dàng nhận thấy trên biểu đồ tăng đột biến - hãy phân tích nó. Trong New Relic, các giao dịch web được chọn ngay lập tức cho một ứng dụng web, tất cả các thành phần được biểu thị trong biểu đồ hiệu suất, có bảng tỷ lệ lỗi, tỷ lệ yêu cầu... Điều quan trọng nhất là trực tiếp từ các bảng này, bạn có thể di chuyển giữa các bảng khác nhau. các phần của ứng dụng (ví dụ: nhấp vào MySQL sẽ dẫn đến phần cơ sở dữ liệu).
Vì trong ví dụ đang xem xét, chúng ta thấy sự gia tăng hoạt động PHP, nhấp vào biểu đồ này và tự động đi đến Giao dịch:
Danh sách các giao dịch, về cơ bản là các bộ điều khiển từ mô hình MVC, đã được sắp xếp theo thứ tự Tốn nhiều thời gian nhất, rất tiện lợi: chúng ta sẽ thấy ngay ứng dụng đó làm gì. Dưới đây là ví dụ về các truy vấn dài được New Relic tự động thu thập. Bằng cách chuyển đổi sắp xếp, có thể dễ dàng tìm thấy:
- bộ điều khiển ứng dụng được tải nhiều nhất;
- bộ điều khiển được yêu cầu thường xuyên nhất;
- bộ điều khiển chậm nhất.
Ngoài ra, bạn có thể mở rộng từng giao dịch và xem ứng dụng đang làm gì tại thời điểm mã được thực thi:
Cuối cùng, ứng dụng lưu trữ các ví dụ về dấu vết của các yêu cầu dài (những yêu cầu mất hơn 2 giây). Đây là bảng điều khiển cho một giao dịch dài:
Có thể thấy 2 phương thức tiêu tốn rất nhiều thời gian, đồng thời khi request được thực thi thì URI và domain của nó cũng được hiển thị. Điều này rất thường xuyên giúp tìm thấy yêu cầu trong nhật ký. Sẽ Chi tiết dấu vết, bạn có thể thấy các phương thức này được gọi từ đâu:
Và trong Truy vấn cơ sở dữ liệu — đánh giá các truy vấn tới cơ sở dữ liệu đã được thực thi trong khi ứng dụng đang chạy:
Được trang bị kiến thức này, chúng tôi có thể đánh giá lý do tại sao ứng dụng chậm lại và làm việc với nhà phát triển để đưa ra chiến lược giải quyết vấn đề. Trên thực tế, New Relic không phải lúc nào cũng đưa ra một bức tranh rõ ràng nhưng nó giúp chọn vectơ điều tra:
- dài
PDO::Constructdẫn chúng tôi đến chức năng kỳ lạ của pgpoll; - sự bất ổn theo thời gian
Memcache::Getcho rằng máy ảo được cấu hình không chính xác; - thời gian xử lý mẫu tăng lên một cách đáng ngờ đã dẫn đến một vòng lặp lồng nhau kiểm tra sự hiện diện của 500 hình đại diện trong bộ lưu trữ đối tượng;
- Vân vân…
Điều cũng xảy ra là thay vì thực thi mã, một thứ gì đó liên quan đến lưu trữ dữ liệu ngoài sẽ xuất hiện trên màn hình chính - và không quan trọng nó sẽ là gì: Redis hay PostgreSQL - tất cả chúng đều bị ẩn trong tab Cơ sở dữ liệu.
Bạn có thể chọn một cơ sở cụ thể để nghiên cứu và sắp xếp các truy vấn - tương tự như cách thực hiện trong Giao dịch. Và bằng cách đi tới tab yêu cầu, bạn có thể xem yêu cầu này xảy ra bao nhiêu lần trong mỗi bộ điều khiển ứng dụng, đồng thời ước tính tần suất yêu cầu đó được gọi. Nó rất thoải mái:
Tab chứa dữ liệu tương tự Dịch vụ bên ngoài, ẩn các yêu cầu tới các dịch vụ HTTP bên ngoài, chẳng hạn như truy cập vào bộ lưu trữ đối tượng, gửi sự kiện đến lính canh hoặc tương tự. Nội dung của tab hoàn toàn giống với Database:
Đối thủ: cơ hội và ấn tượng
Bây giờ điều thú vị nhất là so sánh khả năng của New Relic với những gì đối thủ cạnh tranh cung cấp. Rất tiếc, chúng tôi không thể thử nghiệm cả ba công cụ trên một phiên bản của một ứng dụng đang chạy trong phiên bản chính thức. Tuy nhiên, chúng tôi đã cố gắng so sánh các tình huống/cấu hình giống nhau nhất có thể.
1. Dữ liệu
Datadog chào đón chúng tôi bằng một bảng điều khiển với một bức tường dịch vụ:
Nó cố gắng chia các ứng dụng thành các thành phần/microservices, vì vậy trong ví dụ về ứng dụng Django chúng ta sẽ thấy 2 kết nối tới PostgreSQL (defaultdb и postgres), cũng như Celery, Redis. Làm việc với Datadog yêu cầu bạn phải có kiến thức tối thiểu về các nguyên tắc MVC: bạn cần hiểu yêu cầu của người dùng thường đến từ đâu. Điều này thường giúp bản đồ dịch vụ:
Nhân tiện, có một cái gì đó tương tự trong New Relic:
... và bản đồ của họ, theo ý kiến của tôi, được làm đơn giản và rõ ràng hơn: nó không hiển thị các thành phần của một ứng dụng (điều này sẽ khiến nó quá chi tiết, như trong trường hợp của Datadog), mà chỉ hiển thị các dịch vụ hoặc dịch vụ vi mô cụ thể.
Hãy quay lại Datadog: từ bản đồ dịch vụ, chúng ta có thể thấy các yêu cầu của người dùng đến Django. Hãy đến với dịch vụ Django và cuối cùng xem những gì chúng tôi mong đợi:
Thật không may, không có biểu đồ ở đây theo mặc định Thời gian giao dịch trên web, tương tự như những gì chúng ta thấy trên bảng Di tích mới chính. Tuy nhiên, nó có thể được cấu hình thay cho lịch trình % thời gian sử dụng. Chỉ cần chuyển nó sang là đủ Thời gian trung bình cho mỗi yêu cầu theo Loại... và bây giờ biểu đồ quen thuộc đang nhìn chúng ta!
Tại sao Datadog chọn một biểu đồ khác là một điều bí ẩn đối với chúng tôi. Một điều khó chịu nữa là hệ thống không ghi nhớ lựa chọn của người dùng (không giống cả hai đối thủ), và do đó giải pháp duy nhất là tạo bảng tùy chỉnh.
Nhưng tôi hài lòng với khả năng trong Datadog chuyển từ các biểu đồ này sang số liệu của các máy chủ liên quan, đọc nhật ký và đánh giá tải trên trình xử lý máy chủ web (Gunicorn). Mọi thứ gần giống như trong New Relic... và thậm chí nhiều hơn một chút (nhật ký)!
Bên dưới biểu đồ là các giao dịch hoàn toàn giống với New Relic:
Trong Datadog, các giao dịch được gọi tài nguyên. Bạn có thể sắp xếp bộ điều khiển theo số lượng yêu cầu, theo thời gian phản hồi trung bình và theo thời gian tối đa dành cho một khoảng thời gian đã chọn.
Bạn có thể mở rộng tài nguyên và xem mọi thứ chúng tôi đã quan sát được trong Di tích mới:
Có số liệu thống kê về tài nguyên, danh sách tổng quát các cuộc gọi nội bộ và ví dụ về các yêu cầu có thể được sắp xếp theo mã phản hồi... Nhân tiện, các kỹ sư của chúng tôi thực sự thích cách sắp xếp này.
Bất kỳ tài nguyên ví dụ nào trong Datadog đều có thể được mở và nghiên cứu:
Các tham số yêu cầu, biểu đồ tóm tắt về thời gian dành cho từng thành phần và biểu đồ thác nước hiển thị chuỗi các cuộc gọi được trình bày. Bạn cũng có thể chuyển sang chế độ xem dạng cây của biểu đồ thác nước:
Và điều thú vị nhất là xem tải của máy chủ nơi yêu cầu được thực hiện và xem nhật ký yêu cầu.
Sự tích hợp tuyệt vời!
Bạn có thể thắc mắc các tab ở đâu Cơ sở dữ liệu и Dịch vụ bên ngoài, như trong Di tích mới. Không có gì ở đây: vì Datadog phân tách ứng dụng thành các thành phần nên PostgreSQL sẽ được xem xét một dịch vụ riêng biệtvà thay vì Dịch vụ bên ngoài, nó đáng để tìm kiếm aws.storage (nó sẽ tương tự đối với mọi dịch vụ bên ngoài khác mà ứng dụng có thể truy cập).
Đây là một ví dụ với postgres:
Về cơ bản có mọi thứ chúng tôi muốn:
Bạn có thể xem yêu cầu đến từ “dịch vụ” nào.
Sẽ không sai khi nhắc bạn rằng Datadog tích hợp hoàn hảo với NGINX Ingress và cho phép bạn thực hiện theo dõi từ đầu đến cuối kể từ thời điểm có yêu cầu đến cụm, đồng thời cho phép bạn nhận số liệu thống kê, thu thập nhật ký và số liệu máy chủ .
Một điểm cộng rất lớn của Datadog là giá của nó Gấp lại từ giám sát cơ sở hạ tầng, APM, kiểm tra Quản lý nhật ký và Tổng hợp, tức là. Bạn có thể chọn kế hoạch của mình một cách linh hoạt.
2. Trạng thái
Nhóm Atatus tuyên bố rằng dịch vụ của họ “giống như New Relic, nhưng tốt hơn”. Hãy xem liệu điều này có thực sự như vậy không.
Bảng điều khiển chính trông tương tự nhưng không thể xác định Redis và memcached được sử dụng trong ứng dụng.
APM chọn tất cả các giao dịch theo mặc định, mặc dù thông thường chỉ cần các giao dịch trên Web. Giống như Datadog, không có cách nào để điều hướng đến dịch vụ mong muốn từ bảng điều khiển chính. Hơn nữa, các giao dịch được liệt kê sau các lỗi, điều này có vẻ không hợp lý lắm đối với APM.
Trong các giao dịch Atatus, mọi thứ đều giống với Di tích mới nhất có thể. Nhược điểm là động lực của từng bộ điều khiển không thể nhìn thấy ngay lập tức. Bạn phải tìm nó trong bảng điều khiển, sắp xếp theo Tiêu tốn nhiều thời gian nhất:
Danh sách bộ điều khiển thông thường có sẵn trong tab Khám phá:
Ở một khía cạnh nào đó, bảng này gợi nhớ đến Datadog và tôi thích nó hơn bảng tương tự trong New Relic.
Bạn có thể mở rộng từng giao dịch và xem ứng dụng đang làm gì:
Bảng điều khiển cũng gợi nhớ đến Datadog nhiều hơn: có một số yêu cầu, một bức tranh chung về các cuộc gọi. Bảng trên cùng cung cấp một tab lỗi Lỗi HTTP và ví dụ về truy vấn chậm Dấu vết phiên:
Nếu bạn tham gia một giao dịch, bạn có thể xem ví dụ về dấu vết, bạn có thể lấy danh sách các yêu cầu tới cơ sở dữ liệu và xem tiêu đề yêu cầu. Mọi thứ đều tương tự như New Relic:
Nhìn chung, Atatus hài lòng với các dấu vết chi tiết - không có việc dán các lệnh gọi Di tích Mới điển hình vào khối nhắc nhở:
Tuy nhiên, nó thiếu bộ lọc (như New Relic) sẽ cắt các yêu cầu cực nhanh (<5ms). Mặt khác, tôi thích hiển thị phản hồi giao dịch cuối cùng (thành công hoặc lỗi).
Bảng điều khiển Cơ sở dữ liệu sẽ giúp bạn nghiên cứu các yêu cầu tới cơ sở dữ liệu bên ngoài mà ứng dụng đưa ra. Hãy để tôi nhắc bạn rằng Atatus chỉ tìm thấy PostgreSQL và MySQL, mặc dù Redis và memcached cũng tham gia vào dự án.
Các yêu cầu được sắp xếp theo tiêu chí thông thường: tần suất phản hồi, thời gian phản hồi trung bình, v.v. Tôi cũng muốn đề cập đến tab có truy vấn chậm nhất - nó rất tiện lợi. Hơn nữa, dữ liệu trong tab này của PostgreSQL trùng khớp với dữ liệu từ tiện ích mở rộng - kết quả tuyệt vời!
Chuyển hướng Yêu cầu bên ngoài hoàn toàn giống với Cơ sở dữ liệu.
Những phát hiện
Cả hai công cụ được trình bày đều hoạt động tốt trong vai trò của APM. Bất kỳ ai trong số họ có thể cung cấp mức tối thiểu cần thiết. Ấn tượng của chúng tôi có thể được tóm tắt ngắn gọn như sau:
Bảng dữ liệu
Ưu điểm:
- biểu giá thuận tiện (APM có giá 31 USD mỗi máy chủ);
- hoạt động tốt với Python;
- Khả năng tích hợp với OpenTracing
- tích hợp với Kubernetes;
- tích hợp với NGINX Ingress.
Nhược điểm:
- APM duy nhất khiến ứng dụng không khả dụng do lỗi mô-đun (predis);
- thiết bị tự động PHP yếu;
- định nghĩa có phần lạ lùng về dịch vụ và mục đích của chúng.
Atatus
Ưu điểm:
- công cụ PHP sâu;
- giao diện người dùng tương tự như New Relic.
Nhược điểm:
- không hoạt động trên các hệ điều hành cũ hơn (Ubuntu 12.05, CentOS 5);
- thiết bị đo tự động yếu;
- chỉ hỗ trợ hai ngôn ngữ (Node.js và PHP);
- Giao diện chậm.
Xem xét mức giá 69 USD mỗi tháng cho mỗi máy chủ của Atatus, chúng tôi muốn sử dụng Datadog hơn, nó tích hợp tốt với nhu cầu của chúng tôi (ứng dụng web trong K8) và có nhiều tính năng hữu ích.
PS
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «'.
Nguồn: www.habr.com