Laravel Nightwatch: APM nội bộ thực sự hiểu framework của bạn

Bạn đã chạy ba công cụ, mỗi cái chỉ làm nửa việc. Pulse cho bạn một bảng điều khiển trực tiếp trên route nội bộ. Datadog tính phí theo host và khối lượng sử dụng, hóa đơn tăng theo hạ tầng. Sentry bắt exception sau khi chúng đã gây hại cho ai đó. Không cái nào cho bạn biết điều duy nhất bạn thực sự hỏi: request thanh toán mất 900ms lúc 14:03 đã dispatch một job, job đó chạy một truy vấn, và chính truy vấn đó đã timeout.

Laravel Nightwatch đạt GA vào năm 2025 với tư cách là APM của chính framework, nhắm thẳng vào khoảng trống đó. Bạn cần biết chính xác nó thu thập gì, tính phí thế nào, và ranh giới giữa kiến thức của nó về ứng dụng của bạn và kiến thức của bạn bắt đầu từ đâu.

Nightwatch thực sự là gì

Hai thành phần chuyển động: một gói Composer bên trong ứng dụng của bạn, và một tiến trình agent riêng biệt gửi dữ liệu đi. Gói này ghi sự kiện vào một socket cục bộ. Agent lắng nghe trên 127.0.0.1:2407, gom batch những gì nhận được, và gửi lên cloud của Nightwatch. Vì agent chạy bên ngoài vòng đời request, luồng request không bị chặn chờ gọi mạng tới backend telemetry. Laravel ước tính chi phí thêm dưới 3ms mỗi request; hãy coi đó là con số khởi đầu và tự đo lường trước khi tin tưởng.

Một chi tiết hay gây khó khăn: agent phải chạy thì mọi thứ mới đến được. Trong môi trường dev cục bộ, bạn tự khởi động nó. Trong production, nó thuộc về supervisor, Forge daemon, hoặc Vapor, giống như cách bạn đã chạy Horizon.

Những gì nó thu thập mà không cần bạn viết một dòng code

Nightwatch hook vào event dispatcher của Laravel, vì vậy nó thấy các khái niệm framework bằng tên thay vì các lời gọi hệ thống vô danh. Ngay khi cài đặt, nó ghi lại:

Request đến, kèm route, trạng thái và thời gian
Gọi HTTP đi
Truy vấn cơ sở dữ liệu
Job và batch trong hàng đợi
Mail và thông báo
Đọc và ghi cache
Lệnh Artisan
Tác vụ đã lên lịch
Exception và log
Người dùng đã xác thực trên request

Giá trị không nằm ở danh sách. Nó nằm ở sự kết nối. Nightwatch gắn một request với các truy vấn nó chạy, job nó xếp hàng, và mail job đó sau đó gửi, thành một trace duy nhất. Việc tự tay kết nối sự tương quan đó là phần lớn công việc trong một APM chung chung. Ở đây, nó là mặc định.

Nightwatch so với Pulse

Pulse và Nightwatch đều đến từ đội ngũ Laravel, và chúng trả lời các câu hỏi khác nhau. Pulse là một dashboard tổng hợp sống trong ứng dụng của bạn, được hỗ trợ bởi cơ sở dữ liệu hoặc Redis. Nó hiển thị truy vấn chậm, route bận nhất, và exception hàng đầu dưới dạng số đếm cuộn. Nó miễn phí, tự lưu trữ, và cho bạn cái nhìn "ứng dụng có khỏe không ngay lúc này". Điều nó không cho bạn là dòng thời gian của một request đơn lẻ hoặc lịch sử ngoài cửa sổ lưu giữ. Bạn không thể mở request lúc 14:03 và xem xét nó.

Nightwatch là theo từng sự kiện và được lưu trữ, được xây dựng cho câu hỏi hồi cứu: tại sao request đó lại chậm. Hãy giữ cả hai. Pulse vẫn là bảng điều khiển trực tiếp miễn phí trên route nội bộ; Nightwatch là nơi bạn đến khi ai đó báo cáo một thanh toán chậm hôm qua và bạn cần trace.

Nightwatch so với Datadog và các APM chung chung khác

Datadog, New Relic, và OpenTelemetry thô được thiết kế không phụ thuộc ngôn ngữ. Chúng thấy worker PHP-FPM, span HTTP, và câu lệnh SQL. Điều chúng không thấy là Laravel. Một job xếp hàng chỉ là một tiến trình CLI chạy lâu. Một supervisor Horizon là một hộp đen. Một N+1 Eloquent là ba mươi câu lệnh SELECT vô danh không có gợi ý chúng đến từ một vòng lặp. Bạn mua lại bối cảnh đó thông qua custom instrumentation và tinh chỉnh dd-trace, và bạn duy trì nó mãi mãi.

Nightwatch biết job, batch, thông báo, và lệnh đã lên lịch là gì, bởi vì nó là framework tự theo dõi chính nó. Đó là sự đánh đổi bạn đang thực hiện. Nightwatch chỉ dành cho Laravel và được quản lý hoàn toàn, với dữ liệu cư trú tại Mỹ, EU, hoặc Úc và không có tùy chọn tự lưu trữ. Nếu bạn chạy hạ tầng đa ngôn ngữ và cần một bảng điều khiển duy nhất cho dịch vụ Go, ứng dụng Laravel, và worker Node, Datadog vẫn thắng về bề rộng. Nếu Laravel là toàn bộ ứng dụng, Nightwatch cho bạn nhiều tín hiệu hơn với ít cấu hình hơn nhiều.

Chi phí và cái bẫy trong định giá

Nightwatch tính phí theo sự kiện, không theo host. Các gói công bố, tính đến giữa năm 2026: Miễn phí: $0, 300k sự kiện, xem lại 14 ngày; Pro: $20/tháng, 7.5m sự kiện, xem lại 30 ngày; Team: $60/tháng, 30m sự kiện, xem lại 60 ngày; Business: $300/tháng, 180m sự kiện, xem lại 90 ngày. Vượt mức tính $0.35 mỗi 100k ở các gói thấp hơn, giảm xuống $0.20 ở gói Business.

Bây giờ hãy đọc "sự kiện" một cách cẩn thận. Một request là một sự kiện. Mỗi truy vấn nó chạy, mỗi job nó dispatch, mỗi lần cache hit, mỗi cuộc gọi đi cũng vậy. Một request thông thường có thể phát ra hàng chục sự kiện. Làm phép tính: 300k sự kiện với mười sự kiện mỗi request là 30k request, một ứng dụng production khiêm tốn có thể đốt hết trong một ngày. Gói miễn phí hào phóng cho một dự án phụ và mỏng cho bất cứ thứ gì có lưu lượng thực sự.

Đòn bẩy là sampling, và Nightwatch cung cấp cho bạn một giới hạn chi tiêu sẽ ngừng thu thập khi bạn chạm tới. Bạn thất bại đóng vào việc thiếu dữ liệu, không phải mở vào một hóa đơn bất ngờ. Đó là một chế độ thất bại khác với định giá theo host, và thân thiện hơn.

Instrumentation bạn vẫn phải tự làm

Zero-config mang lại cho bạn góc nhìn của framework. Nó không bao giờ mang lại góc nhìn của ứng dụng bạn. Ba điều Nightwatch không thể suy luận, và cách bạn cung cấp chúng.

1. Nightwatch ghi lại gì về người dùng. Nightwatch tự động đọc người dùng đã xác thực, nhưng bạn quyết định trường nào xác định họ. Đăng ký một resolver một lần trong AppServiceProvider. Đây là nơi bạn ánh xạ một tài khoản thành tên có thể đọc được, hoặc thêm tiền tố ID với tenant để hai khách hàng có id là 5 không xung đột trong trace của bạn.

2. Một request có ý nghĩa gì với doanh nghiệp. Nightwatch thấy rằng POST /checkout mất 900ms. Nó không biết rằng 900ms đã vi phạm SLA thanh toán của bạn, hoặc đường dẫn này là đường kiếm tiền. Sampling là nơi bạn mã hóa mức độ ưu tiên đó, bởi vì các điểm vào (request, lệnh, tác vụ đã lên lịch) là những gì bạn sample.

3. Các thao tác nghiệp vụ không ánh xạ tới nguyên thủy framework. "Dự trữ hàng tồn kho" có thể là ba dịch vụ, hai truy vấn, và một sự kiện được dispatch. Với Nightwatch, nó là một đống truy vấn rải rác dưới một request, không có tên kết nối chúng. Framework có thể thu thập một truy vấn; nó không thể biết các lời gọi nghiệp vụ của bạn sắp xếp một dự trữ. Nếu bạn muốn khái niệm đó xuất hiện, bạn thể hiện nó thông qua các tín hiệu Nightwatch thu thập, log có cấu trúc và sự kiện, để trace mang một từ mà nhóm của bạn nhận ra.

Điểm cuối cùng là điểm cần suy ngẫm. APM nội bộ xóa bỏ công việc kết nối hạ tầng. Nó không xóa bỏ công việc đặt tên cho những gì phần mềm của bạn làm. Việc đặt tên đó luôn là của bạn.

Nightwatch là một lựa chọn mặc định tốt vì nó sống ở ranh giới framework và không yêu cầu gì từ code nghiệp vụ của bạn. Đó chính xác là lý do tại sao nghiệp vụ vẫn cần từ vựng riêng của nó: các khái niệm quan trọng với doanh nghiệp của bạn không phải là sự kiện framework, và không có công cụ zero-config nào sẽ đặt tên cho một trường hợp sử dụng "dự trữ hàng tồn kho" cho bạn. Giữ observability của framework ở rìa, trong khi các thao tác nghiệp vụ của bạn vẫn rõ ràng và độc lập với nó, là sự tách biệt quan trọng.