Đọc phản hồi
Đọc mọi phản hồi theo thứ tự sau:- Đọc trạng thái HTTP.
- Kiểm tra body có đúng cấu trúc mà route quy định.
- Kiểm tra mỗi
project_idnằm trong phạm vi dự án đã yêu cầu. - Giữ nguyên các giá trị enum chuẩn và các định danh.
- Chỉ làm theo
next_actionkhi client hỗ trợcodevàtargetcủa nó. - Coi
null, trường bị lược bỏ và danh sách trống là ba trạng thái khác nhau.
200 OK có thể chứa danh sách trống. Danh sách log trống nghĩa là
không có log nào khớp với yêu cầu. Điều đó không có nghĩa là vấn đề, trace hay
hành động cũng trống. Không ghép các tín hiệu chỉ vì dấu thời gian của chúng
gần nhau. Chỉ chuyển sang một trace khi phản hồi chứa đúng trace_id của trace
đó.
404 và danh sách trống là hai kết quả khác nhau. Route danh sách trả về []
khi không có bản ghi nào khớp. Route chi tiết trả về 404 với code: not_found
khi không tìm thấy bản ghi nào đọc được. Cả hai kết quả đều không chứng minh
rằng việc gửi dữ liệu đã thất bại.
Cần gửi gì
Phản hồi chỉ hữu ích khi telemetry bạn gửi đủ tốt. Gửi các giá trị sau trong mọi envelope hoặc khi thiết lập SDK:releasevàenvironment.- Tên ổn định cho dịch vụ, hành động và chỉ số.
- Ngữ cảnh trace khi log, span, hành động và vấn đề thuộc cùng một yêu cầu.
- Các giá trị mức độ nghiêm trọng chuẩn:
info,warning,errorvàcritical. - Các thuộc tính giúp gỡ lỗi, không chứa thông tin bí mật hay dữ liệu cá nhân không cần thiết.
Phản hồi khi gửi dữ liệu
Các SDK công khai tự đọc phản hồi củaPOST /v1/events. Mã ứng dụng không cần
xử lý phản hồi này.
Phản hồi batch của SDK
Một batch SDK thành công trả về200 OK cùng số lượng được chấp nhận cho từng
luồng:
Các số lượng chỉ tính cho batch này. Khi gửi lại một batch mà LogBrew đã chấp
nhận, phản hồi trả về
0 cho từng luồng và số sự kiện trong
already_accepted. Giữ nguyên ID sự kiện gốc khi thử lại.
Phản hồi envelope gốc
POST /api/telemetry/ingest trả về 200 OK cùng số mục được chấp nhận cho
từng luồng:
metrics hay context_updated. Không tự thêm
các trường này. already_accepted đếm các mục có id mà LogBrew đã chấp nhận
trước đó cho dự án. Xem Gửi trực tiếp envelope gốc.
Lỗi khi gửi dữ liệu
401 với code: ingest_key_invalid nghĩa là bearer token gửi dữ liệu đã bị
thu hồi, đã hết hạn hoặc không hợp lệ cho dự án. Với POST /v1/events, yêu cầu
thiếu bearer token hoặc dùng bearer token không phải khóa gửi dữ liệu sẽ nhận
401 với code: unauthorized. Dùng bearer token gửi dữ liệu hiện tại thuộc
phạm vi dự án. Không thử lại bằng bearer token của tài khoản.
Một batch SDK bị từ chối trả về 422 với code: validation_failed:
error khác gồm SDK event batch requires at least one event và
SDK event type is not supported by this ingest route. Kiểm tra phiên bản SDK
và cấu hình truyền tải. Không gửi batch trống. Không đổi loại sự kiện hay ID
chỉ để batch vượt qua bước kiểm tra hợp lệ.
Yêu cầu dùng phương thức khác POST trả về 405 với
code: method_not_allowed. Body JSON không đọc được trả về code: invalid_json.
Định dạng phản hồi danh sách telemetry
Theo mặc định, route danh sách trả về một mảng JSON trần. Danh sách trống thành công là[].
Với pagination=cursor, route trả về một envelope. Khóa collection khớp với
loại tín hiệu:
next_cursor là một object chứa các trường để đọc tiếp, hoặc null ở trang
cuối. Các dòng được sắp xếp từ mới nhất đến cũ nhất. Xem phân trang bằng cursor.
Phản hồi log
Một trang cursor của log vớilimit=1:
level để tương thích và severity để hiển thị. Cả hai đều chứa giá trị
chuẩn. triage chứa kết quả của quy tắc mức độ nghiêm trọng. Xem
phản hồi quy tắc mức độ nghiêm trọng.
trace_id và span_id là null khi log không có liên kết trace. Khi đó,
next_action là inspect_related_logs với target telemetry_logs. Log, vấn đề
và hành động dùng chung 2 cặp next_action này.
GET /api/logs/{log_id} trả về một log với cùng cấu trúc.
Phản hồi vấn đề
GET /api/telemetry/issues/{issue_id} trả về một vấn đề đã gộp nhóm. Route danh
sách trả về các object giống hệt. Ví dụ này dùng phiên bản phản hồi mặc định 1:
status là unresolved, resolved hoặc ignored. Với vấn đề
đã lưu trữ, triage.ignored là true. Về các cặp next_action và các lượt
đọc tiếp theo, xem
Điều tra một vấn đề.
first_seen_at và last_seen_at là thời điểm của lần xảy ra đầu tiên và gần
nhất. Hai giá trị này không đổi khi trạng thái thay đổi.
Một số trường chỉ xuất hiện khi LogBrew có dữ liệu:
symbolication.status là resolved, invalid_metadata,
artifact_not_found, source_not_resolved hoặc unavailable. Route danh
sách, thao tác đổi trạng thái và thao tác đổi quy tắc không trả về
symbolication.
Với response_version=2, vấn đề có cùng các trường, kèm các thay đổi sau:
high cho error
và critical, medium cho warning, và low cho info. Mức ưu tiên này dựa
trên triage.effective_severity, nên quy tắc mức độ nghiêm trọng của vấn đề có
thể thay đổi nó.
Với response_version=3, vấn đề có mọi trường của phiên bản 2 và thêm
assignee. assignee là null khi vấn đề chưa có người phụ trách:
Vấn đề không hiển thị người phụ trách khi thành viên được giao không còn đọc
được dự án.
Với
response_version=4, assignee có thêm type. Người phụ trách user có
user_id, name và email, giống phiên bản 3. Người phụ trách team có
team_id, slug và name. Phiên bản 3 hiển thị nhóm phụ trách là null.
CLI yêu cầu phiên bản 4:
response_version khác trả về 422 với code: validation_failed. Một
trang cursor dùng cùng phiên bản cho mọi vấn đề trong issues.
Phản hồi danh sách người phụ trách
GET /api/telemetry/issues/assignees?project_id=<project_id> trả về mọi tài
khoản có thể được giao vấn đề trong dự án:
response_version=2 để nhận thêm teams: mọi nhóm trong tổ chức của dự
án, kèm team_id, slug và name.
Nếu tài khoản không đọc được dự án, route trả về 404 với
code: not_found.
Phản hồi hành động
distinct_id theo dõi một đối tượng thực hiện hoặc một phiên. Coi distinct_id
và session_id là ID opaque (không diễn giải nội dung). session_id và
trace_id là null khi chưa ghi nhận. span_id bị lược bỏ khi chưa ghi nhận.
Hành động không có mức độ nghiêm trọng. Xem Ghi nhận sự kiện sản phẩm.
Phản hồi chỉ số
unit, temporality, trace_id và span_id là null khi chưa ghi nhận.
Giá trị null không phải là 0.
Phản hồi bản phát hành
trace_health.status là unknown khi dòng không có trace, hoặc là
no_errors_observed hay errors_observed. error_rate_basis_points là tỷ lệ
trace có span lỗi, từ 0 đến 10000. Đây không phải tỷ lệ lỗi của mọi yêu
cầu.
next_action trỏ đến loại tín hiệu đầu tiên có dữ liệu, theo thứ tự sau:
Xem Bản phát hành.
Phản hồi khám phá trace
GET /api/telemetry/traces?pagination=cursor trả về một dòng cho mỗi trace,
kèm biên nhận naming_quality cho trang được trả về:
naming_quality chỉ áp dụng cho trang được trả về. Đây không phải điểm số cho
toàn tài khoản. truncated: true nghĩa là còn trang khác. Khi trang có tên
chung chung, route không khớp hoặc thao tác chung chung, next_action là
improve_trace_naming với target sdk_configuration. Nếu không có
pagination=cursor, route trả về một mảng trace trần và không có
naming_quality.
next_cursor chứa time và trace_id. Gửi chúng dưới dạng cursor_time và
cursor_trace_id.
GET /api/telemetry/traces/{trace_id} trả về các span của một trace.
GET /api/telemetry/traces/{trace_id}/summary trả về span gốc, các span lỗi,
dịch vụ, thời lượng và đường đi chậm nhất, không kèm thuộc tính thô của span.
404 ở bản tóm tắt nghĩa là không có trace nào khớp với toàn bộ phạm vi. Không
bỏ bộ lọc để thử lại. Xem phản hồi span và bản tóm tắt trace.
Danh sách trống và bản ghi không tồn tại
Lượt đọc danh sách có thể không có kết quả khớp. Lượt đọc chi tiết tuân theo quy ước khác:
Log không tồn tại trả về
404 sau:
"error": "issue not found". Bản tóm tắt trace không
tồn tại dùng "error": "trace not found". ID không xác định và ID mà tài khoản
không đọc được đều trả về cùng một phản hồi.
Danh sách với một project_id mà tài khoản không đọc được trả về 200 với danh
sách trống. Kiểm tra ID dự án trước khi báo rằng không có dữ liệu.
Lựa chọn dự án bị từ chối
Danh sách log, vấn đề, hành động, chỉ số, bản phát hành và trace nhận một dự án quaproject_id, hoặc từ 2 đến 50 dự án qua project_ids. Danh mục thuộc tính
log nhận cùng các tham số chọn này. Lịch sử lần xảy ra của vấn đề không nhận
chúng.
Yêu cầu có cả project_id lẫn project_ids trả về 422:
project_ids có UUID không hợp lệ, có ID lặp lại, hoặc có ít hơn 2 hay nhiều
hơn 50 ID cũng trả về 422 với code: validation_failed.
Nếu tài khoản không đọc được một dự án trong tập project_ids, toàn bộ yêu cầu
trả về 404. Yêu cầu không trả về các dự án còn lại thành kết quả một phần:
403 với
code: forbidden cho dự án nằm ngoài phạm vi kết nối đó. Xem
phạm vi dự án.
Lỗi cursor
Log, vấn đề, hành động, chỉ số và lần xảy ra của vấn đề dùngcursor_time và
cursor_id. Cursor bị từ chối trả về 422 với code: validation_failed.
Các lỗi này không có nghĩa là danh sách trống.
Ví dụ:
next_cursor từ trang trước. Không thay cursor_time bằng
thời gian hiện tại. Nếu bạn làm mất cursor, bắt đầu lại với
pagination=cursor và các bộ lọc ban đầu. Tham số truy vấn không xác định hoặc giá
trị sai kiểu trả về 422 với "error": "invalid query parameters".
Phản hồi cursor của bản phát hành
Cursor của bản phát hành có 5 trường. Yêu cầu thành công nhưng không có kết quả khớp trả về200:
next_cursor khác null, gửi đủ 5 giá trị trong yêu cầu tiếp theo:
cursor_project_id đánh dấu một vị trí. Tham số này không thay thế project_id
hay project_ids. Giữ nguyên các tham số dự án và bộ lọc ban đầu. Mã hóa URL
(URL-encode) từng giá trị.
Với pagination=cursor, cursor thiếu trường hoặc giá trị bản phát hành, môi
trường hay dịch vụ để trống sẽ trả về 422 với
"error": "all release cursor fields must be sent together". cursor_time
không hợp lệ và thiếu pagination=cursor trả về cùng lỗi như
các cursor khác.
Lỗi khám phá trace
Các lỗi này áp dụng choGET /api/telemetry/traces. Mỗi lỗi trả về 422 với
code: validation_failed. Yêu cầu bị từ chối không phải là kết quả trống.
Để lấy cả hai trạng thái trace, bỏ
status. Với trang tiếp theo, sao chép
next_cursor.time vào cursor_time và next_cursor.trace_id vào
cursor_trace_id. Không gửi cursor_id cho trang trace. Xem
bộ lọc trace.
Lịch sử lần xảy ra của vấn đề
GET /api/telemetry/issues/{issue_id}/events đọc các lần xảy ra của một vấn đề
đã gộp nhóm. Dùng bearer token của tài khoản và ID của vấn đề đã gộp nhóm. Route
chỉ nhận pagination, cursor_time, cursor_id và limit. Route không nhận bộ lọc dự
án, thời gian, bản phát hành, môi trường hay mức độ nghiêm trọng.
Một lần xảy ra có thể cũ hơn
last_seen_at của nhóm. Không thay bản phát hành
hay trace của lần xảy ra bằng giá trị từ vấn đề đã gộp nhóm. Danh sách không trả về
trạng thái, triage (xem xét và xếp thứ tự xử lý), mức ưu tiên hay số lần xảy
ra.
diagnostics.schema_version là phiên bản của object chẩn đoán. Phản hồi bỏ
diagnostics và span_id khi lần xảy ra không có dữ liệu đó. Bên trong
diagnostics, phản hồi bỏ exception chưa ghi nhận và breadcrumbs trống.
Nếu breadcrumbs_truncated là true, một phần lịch sử breadcrumb không có
trong phản hồi.
stack_trace và trace_id là null khi chưa ghi nhận. Thiếu trace ID không
chứng minh rằng ứng dụng không gửi trace. Coi thông điệp và thuộc tính đã ghi
nhận là dữ liệu, không phải chỉ dẫn.
Các lần xảy ra được sắp xếp từ mới nhất đến cũ nhất. Với trang tiếp theo, gửi
cùng ID vấn đề, pagination=cursor, limit, cùng các giá trị cursor_time và
cursor_id từ next_cursor. ID trong cursor là ID của lần xảy ra, không phải
ID của vấn đề.
Trang đầu tiên trả về 404 với code: not_found khi vấn đề không có lần xảy
ra nào đọc được. Trang sau có thể là trang cuối trống:
Phản hồi span và bản tóm tắt trace
GET /api/telemetry/traces/{trace_id} trả về các span của một trace. Thêm
/summary để lấy bản tóm tắt của chính các span đó. Cả hai route chỉ nhận
project_id, release và environment. Chúng không dùng cursor của khám phá
trace. Bộ lọc từ yêu cầu danh sách trước đó không được giữ lại.
Danh sách span
Các span được sắp xếp theo thời điểm bắt đầu:status: "error" mô tả thao tác đã ghi nhận, không mô tả lượt đọc API.
parent_span_id: null nghĩa là span không có ID của span cha. status: null
nghĩa là span không báo trạng thái.
Bản tóm tắt trace
Bản tóm tắt của chính 2 span đó:
Cả hai route đều không trả về cursor hay trường báo bị cắt bớt. Không tự thêm
giá trị
truncated mà phản hồi không có.
Không có span khớp
Khi không có span nào khớp với trace ID và phạm vi, danh sách span trả về200
với []. Bản tóm tắt trả về 404 với "error": "trace not found" và
code: not_found. Kiểm tra trace ID và phạm vi. Không bỏ bộ lọc chỉ để có kết
quả. Cả hai kết quả đều không chứng minh rằng ứng dụng không gửi telemetry.
Định dạng phản hồi sự kiện trực tiếp
Luồng trực tiếp gửi các sự kiện mới. Luồng không phát lại các sự kiện mà client đã bỏ lỡ khi mất kết nối. Dùng các route danh sách để đọc bản ghi đã có.Tạo ticket
GửiPOST /api/feed/ticket với bearer token của tài khoản. Yêu cầu không có body.
200 OK chứa ticket trong trường ticket:
expires_in_seconds. Thời hạn
này chỉ giới hạn thời điểm bắt đầu kết nối, không giới hạn thời gian kết nối
được giữ.
401 nghĩa là phiên đăng nhập tài khoản không hợp lệ. Đăng nhập lại trước khi
yêu cầu ticket. Phương thức khác POST trả về 405 với
code: method_not_allowed.
Mở kết nối
Kết nối một WebSocket client tớiwss://api.logbrew.co/api/feed/live?ticket=<feed-ticket>. Mã hóa URL cho
ticket. Không đặt bearer token của tài khoản hay bearer token gửi dữ liệu vào URL.
401 nghĩa là ticket hoặc phiên đăng nhập tài khoản không hợp lệ. Tạo ticket
mới sau khi đăng nhập lại.
Chờ một lúc trước khi kết nối lại sau lỗi. Không kết nối lại trong vòng lặp
không có thời gian chờ.
Đọc các thông điệp
Mỗi thông điệp là một envelope{ "type": "...", "data": ... }. Đọc type
trước khi phân tích cú pháp data. Bỏ qua các loại mà client không hỗ trợ.
native_issue dùng phản hồi vấn đề phiên bản 1: vấn đề đã lưu trữ hiển
thị là ignored, và sự kiện không có mức ưu tiên. Chỉ số và bản phát hành không
phải là loại sự kiện trực tiếp. Đọc chúng bằng route danh sách tương ứng. Ticket
không chọn dự án. Kiểm tra project_id của từng sự kiện trước khi hiển thị
trong giao diện của một dự án. logbrew watch --json dùng luồng này. Xem
Tham khảo CLI.
Xử lý kết nối bị đóng
Các lần mất kết nối khác có thể không kèm lý do từ LogBrew. Sau khi kết nối lại,
đọc lại các route danh sách và đối chiếu bản ghi theo ID.
Ví dụ phản hồi khi đổi trạng thái vấn đề
PATCH /api/telemetry/issues/{issue_id} với { "status": "resolved" }
trả về 200 OK cùng vấn đề đã gộp nhóm sau khi cập nhật, theo cùng cấu trúc với
phản hồi vấn đề. Tham số truy vấn response_version chọn
phiên bản. Phản hồi không trả về cờ thành công.
Body đặt 1 hoặc nhiều trường trong số status, priority và assignee.
status nhận unresolved, resolved hoặc archived. ignored là tên cũ của
archived. Xem Cập nhật một vấn đề.
Kiểm tra id, status và priority được trả về trước khi báo thành công.
Không dựng kết quả từ các giá trị đã gửi. Đổi trạng thái không xóa các lần xảy
ra và không thay đổi first_seen_at hay last_seen_at. Thao tác này cũng
không thay đổi severity hay quy tắc mức độ nghiêm trọng.
Thay đổi bị từ chối trả về 422 với code: validation_failed:
Trường đã có giá trị được yêu cầu sẽ không thay đổi. Sau khi hết thời gian chờ
hoặc mất phản hồi, gửi lại đúng yêu cầu đó, hoặc đọc vấn đề trước. Không gửi một
thay đổi khác trước khi đọc trạng thái hiện tại. Xem
Thao tác ghi.
POST /api/telemetry/issues/bulk trả về 200 OK với 1 kết quả cho mỗi ID vấn
đề được yêu cầu, theo thứ tự trong yêu cầu. Mỗi vấn đề tìm thấy dùng cấu trúc
phiên bản 3. Kết quả not_found có issue: null:
outcome là updated,
unchanged hoặc not_found. Yêu cầu gửi lại trả về unchanged và không thay
đổi gì. Xem
Cập nhật hàng loạt vấn đề.
Yêu cầu hàng loạt thất bại toàn bộ trong các trường hợp sau:
Phạm vi yêu cầu phân tích
Các route phân tích, route chuỗi chỉ số và route lượng tín hiệu đọc một dự án trong một khoảng thời gian. Mọi yêu cầu đều cầnproject_id và since.
since nhận một thời lượng rút gọn như 24h hoặc 7d, hoặc một dấu thời gian
RFC3339. until nhận một dấu thời gian RFC3339 và mặc định là thời điểm gửi
yêu cầu. Khoảng thời gian bao gồm since, không bao gồm until và không được
vượt quá 31 ngày.
service_name, release và environment là các bộ lọc khớp chính xác, không
bắt buộc. Mỗi giá trị phải có từ 1 đến 256 ký tự sau khi LogBrew cắt khoảng
trắng. Route so sánh phân khúc đặt các bộ lọc này bên trong từng phân khúc,
không đặt ở cấp cao nhất.
Nếu tài khoản không đọc được dự án, các route này trả về 200 OK với số đếm
bằng 0. Chúng không trả về 404. Kết quả trống không xác nhận quyền truy cập
dự án. So sánh project_id với các dự án mà tài khoản đọc được. Yêu cầu qua một
kết nối MCP không bao gồm dự án trả về 403 và forbidden.
Mỗi phản hồi bắt đầu bằng
schema_version, query và purpose. query
lặp lại phạm vi có hiệu lực. Trường này bỏ các bộ lọc mà bạn không gửi.
purpose là văn bản thuần giải thích route trả lời câu hỏi gì.
Một tỷ lệ bị lược bỏ khi mẫu số của nó bằng 0. Tỷ lệ bị lược bỏ không phải là 0
và cũng không phải là null. Đọc coverage trước khi tin vào một tỷ lệ.
Các lỗi này dùng HTTP
422 và validation_failed:
Ví dụ, yêu cầu thiếu
project_id trả về:
error riêng. Các mục bên dưới của từng route liệt kê những lỗi đó.
Tham số truy vấn không xác định trả về 422 với phản hồi
tham số truy vấn không hợp lệ.
Trường JSON không xác định, thiếu trường JSON bắt buộc hoặc giá trị enum không
được hỗ trợ trả về invalid_json. Xem
JSON không hợp lệ. Yêu cầu dùng sai
phương thức HTTP trả về 405 và method_not_allowed. Văn bản next của phản
hồi nêu phương thức và các trường được hỗ trợ. Xem
Phương thức không được hỗ trợ.
Phản hồi tổng quan phân tích sản phẩm
GET /api/telemetry/analytics/overview cho thấy hoạt động trong một dự án:
lượng hành động, người dùng, phiên, một chuỗi thời gian, các hành động hàng đầu,
cùng các lượt xem trang, lượt xem màn hình và tương tác đã phân loại. Dùng route
này để tìm tên sự kiện chính xác cho các route phân tích khác.
Gửi response_version=3. Phiên bản 1 và 2 trả về cùng số đếm, nhưng giá trị
estimation.method của chúng là chuỗi giá trị cũ. Phiên bản 1 không kiểm tra loại chủ
thể khi đếm người dùng đã định danh. Phiên bản 2 và 3 chỉ đếm chủ thể loại
user, và thêm số đếm chủ thể ẩn danh cùng subject_coverage.
Yêu cầu này đọc một giờ, chia thành các khoảng gộp năm phút, và trả về hai dòng
trong mỗi danh sách hàng đầu:
Tổng quan thành công
Trong kết quả giả lập này, dự án có 120 hành động nằm trong hai trên mười hai khoảng gộp. Hai mươi hành động đến từ chủ thể ẩn danh. Mọi hành động đều có ID phiên. Một nửa số hành động có trace ID.Đọc tổng quan
Năm số đếm trongsubject_coverage cộng lại bằng tổng số sự kiện của phần
tương ứng. Chỉ identified_user_events được tính vào người dùng.
anonymous_actions bằng summary.actions trừ identified_actions.
series chỉ chứa các khoảng gộp có hoạt động. expected_buckets là số khoảng
gộp có thể có trong khoảng thời gian. Không vẽ khoảng gộp bị thiếu thành giá trị
0 đo được, trừ khi biểu đồ của bạn ghi rõ quy tắc đó. Các khoảng gộp được căn
theo ranh giới thời gian UTC. Khoảng thời gian bắt đầu giữa một khoảng gộp sẽ
bao gồm phần khoảng gộp chưa đầy đủ đó.
classified_activity đếm lượt xem trang, lượt xem màn hình và tương tác. Lượt
xem màn hình và tương tác cũng là hành động. Lượt xem trang thì không. Không
cộng summary.actions với classified_activity.summary.events.
Sao chép kind và event_name từ classified_activity.top_events vào các bước
phễu, tham số chọn tỷ lệ quay lại, tham số chọn vòng đời, điểm neo đường dẫn và
mục tiêu của phân khúc. Giá trị true trong top_events_truncated nghĩa là còn
các tên có lượng thấp hơn. Tăng top_limit tối đa đến 20 để xem thêm.
analysis_level là no_data, event_only, user_level hoặc
user_and_session. Nếu dự án không có hành động và không có sự kiện đã phân
loại, next_action.code là capture_product_activity. Xem
Phân tích sản phẩm.
Lỗi tổng quan
Ngoài lỗi phạm vi dùng chung, route tổng quan trả về422 và validation_failed cho các giá trị sau:
interval mặc định là auto. Giá trị này chọn độ dài khoảng gộp nhỏ nhất cần
tối đa 300 khoảng gộp. top_limit mặc định là 10.
Phản hồi phễu theo thứ tự
POST /api/telemetry/analytics/funnel đo mức hoàn thành theo thứ tự qua 2 đến
8 bước. Sao chép chính xác từng kind và event_name từ
classified_activity.top_events trong tổng quan. Tên hành động tương tự không
được tính là khớp. Body yêu cầu này đếm các phiên xem /pricing rồi hoàn tất
đăng ký trong vòng một giờ:
analysis_unit là session hoặc identified_user. Mặc định là session.
kind của bước là page_view, screen_view hoặc interaction. Route phễu
không nhận response_version.
Phễu thành công
Phản hồi200 OK:
coverage trước khi tin vào một tỷ lệ.
selected_unit_coverage_rate là tỷ lệ sự kiện của các bước đã chọn mà LogBrew
dùng được. Phản hồi không trả về định danh thô. Xem
Phân tích sản phẩm.
Đọc chuyển đổi và độ bao phủ
entry_rate bằng entered_units chia cho candidate_units: 50 trên 60.
overall_conversion_rate bằng completed_units chia cho entered_units:
15 trên 50, tức 30%. Đây không phải 15 chia cho mọi ứng viên. Các số đếm này
không giải thích vì sao các đơn vị dừng lại.
Độ bao phủ đếm sự kiện, không đếm phiên. Ở đây, 120 sự kiện khớp với một bước,
và 20 sự kiện trong số đó không có ID phiên. Kết quả loại 20 sự kiện này khỏi số
đếm phiên. Không coi chúng là 20 phiên thất bại.
Bước đầu tiên không có conversion_from_previous. Bước cuối cùng không có
drop_off_to_next_units và drop_off_to_next_rate.
Một đơn vị chỉ đạt tới các bước phía sau nếu thời điểm của các bước tăng dần
nghiêm ngặt. Các sự kiện có cùng dấu thời gian không thể thỏa mãn hai bước liên tiếp.
Bước cuối phải diễn ra trong vòng conversion_window_seconds tính từ bước đầu
tiên.
Chế độ phiên đếm phiên, không đếm người. Chỉ dùng identified_user cho các sự
kiện mang ID chủ thể opaque loại user. Chế độ đó có thể ghép các sự kiện từ
nhiều phiên khác nhau trong cửa sổ chuyển đổi. Giữ nguyên đơn vị và
các bước khi so sánh kết quả.
conversion_window_seconds mặc định là 24 giờ hoặc độ dài khoảng thời gian, tùy
giá trị nào ngắn hơn. Giá trị tối đa là độ dài khoảng thời gian tính bằng giây
nguyên, làm tròn lên.
Phễu không có kết quả
Phản hồi trống thành công vẫn liệt kê các bước đã yêu cầu vớiunits bằng 0.
Nếu không có đơn vị ứng viên nào, summary bỏ entry_rate và
overall_conversion_rate. Route không trả về 404 khi không có sự kiện nào
khớp.
Đọc coverage và next_action để tìm nguyên nhân:
Yêu cầu phễu bị từ chối
Ngoài lỗi phạm vi dùng chung, các yêu cầu sau trả về422 và validation_failed. Ít hơn 2 hoặc nhiều hơn 8 bước:
conversion_window_seconds bằng 0, hoặc lớn hơn độ dài khoảng thời gian:
event_name để trống, dài hơn 256 ký tự hoặc chứa ký tự điều khiển sẽ trả về
product analytics funnel event_name must be non-empty, control-free, and at most 256 characters.
Bước interaction cũng phải là tên hành động hợp lệ. Nếu không, lỗi là
product analytics interaction event_name must be a bounded stable action name.
Sửa yêu cầu trước khi gửi lại. Không bỏ bước hay đổi đơn vị phân tích chỉ để có
kết quả không trống.
Phân tích theo sự kiện chính xác và phân tích tự động
Tỷ lệ quay lại và vòng đời nhận hai cấu trúc yêu cầu. Dùngresponse_version
để chọn cấu trúc trả lời đúng câu hỏi của bạn:
Một tham số chọn chính xác chứa
kind và event_name. kind là page_view,
screen_view hoặc interaction. Sao chép event_name từ
classified_activity.top_events. Không đoán tên sự kiện từ nhãn của nút.
Cả hai cấu trúc chỉ đếm người dùng: các ID chủ thể opaque loại user. Chủ thể
ẩn danh và sự kiện không có ID chủ thể dùng được không được tính là người dùng.
Phản hồi không bao giờ trả về ID chủ thể.
Các kỳ cố định là hour, day, week và thirty_day. Đây là các thời lượng
cố định. thirty_day là 30 ngày, không phải một tháng theo lịch. Nếu bạn bỏ
interval, API dùng hour cho khoảng thời gian từ 48 giờ trở xuống, và day
cho khoảng thời gian dài hơn.
Yêu cầu tỷ lệ quay lại theo sự kiện chính xác
Gửi body này tớiPOST /api/telemetry/analytics/retention. Yêu cầu này hỏi liệu
người dùng có hoàn tất thêm một lần thanh toán sau lần thanh toán đầu tiên của
họ trong khoảng thời gian hay không:
until. Hai tham số chọn có thể là cùng một sự kiện.
Tỷ lệ quay lại theo sự kiện chính xác thành công
Trong ví dụ giả lập này, hai người dùng hoàn tất thanh toán. Người dùng thứ nhất hoàn tất thanh toán lúc 12:00 ngày 1 tháng 6 và lần nữa lúc 13:00. Người dùng thứ hai hoàn tất thanh toán lúc 12:00 ngày 2 tháng 6. Lúc 13:00 ngày 2 tháng 6, người dùng thứ hai xem một trang nhưng không hoàn tất thêm lần thanh toán nào.Đọc tỷ lệ quay lại
Độ bao phủ đếm cả bốn sự kiện đã phân loại, nhưng chỉ ba sự kiện khớp với mỗi tham số chọn thanh toán. Lượt xem trang không được tính là lần quay lại. Một trong hai người dùng thanh toán lại, nênreturn_rate_after_start là 0.5.
Chỉ người dùng thứ nhất có trọn một ngày quan sát sau mốc neo. Người dùng đó
quay lại trong ngày, nên tỷ lệ trên đường cong là 1.0. Người dùng thứ hai chỉ
có 12 giờ quan sát. Người dùng đó không đủ điều kiện cho kỳ 0, nên ô của nhóm
người dùng (cohort) thứ hai bỏ retention_rate. Không tính người dùng đó là đã rời bỏ.
weighted_retention_rate chia tổng số người dùng quay lại cho tổng số người dùng
đủ điều kiện. fully_observed_cohort_average_rate là trung bình cộng đơn giản
của tỷ lệ ở các nhóm người dùng mà mọi người dùng đều đủ điều kiện. Nhóm người
dùng là các khoảng gộp cố định bắt đầu từ since. cohorts chỉ chứa các nhóm
người dùng có người dùng.
Với mode: "return_on_or_after", đường cong bỏ window_end_seconds.
Tỷ lệ quay lại tự động
Gửiresponse_version: 2 và không gửi start_event hay return_event. Mọi
lượt xem trang, lượt xem màn hình và tương tác được hỗ trợ đều được tính là lần
bắt đầu và lần quay lại. Phiên bản này chọn một tập sự kiện. Nó không chọn định
dạng ghi nhận của SDK.
summary, curve, cohorts và next_action với
phản hồi theo sự kiện chính xác. Đoạn trích này hiển thị các trường thay đổi.
Trong ví dụ này, cùng hai người dùng đó có ba sự kiện và không có lượt xem
trang:
start_events và return_events đều bằng
classified_events. Các số đếm này là sự kiện, không phải người dùng.
Tỷ lệ quay lại khi không có người dùng đủ điều kiện
Kết quả thành công có thể không có người dùng nào trong nhóm người dùng. Đoạn trích này cho thấy một kỳ đã yêu cầu nhưng không có nhóm người dùng nào:coverage và next_action. Hai trường này phân biệt phạm vi không có sự
kiện đã phân loại (capture_product_activity) với sự kiện không có người dùng
(identify_product_users hoặc identify_returning_users). Tỷ lệ bị thiếu
không phải giá trị 0 đo được.
Lỗi tỷ lệ quay lại
Ngoài lỗi phạm vi dùng chung, các yêu cầu sau trả về422 và validation_failed:
Giới hạn số ô dựa trên khoảng thời gian và số kỳ, không dựa trên số người dùng.
Khoảng thời gian 30 ngày với
interval: "hour" có 720 khoảng gộp nhóm người
dùng. Với interval_count: 1, tức là 720 ô, nhiều hơn 500:
Yêu cầu vòng đời theo sự kiện chính xác
Gửi body này tớiPOST /api/telemetry/analytics/lifecycle. Yêu cầu này phân
loại người dùng theo một sự kiện, không theo mọi hoạt động trong dự án:
history_period_count đặt số kỳ đầy đủ trước since mà LogBrew đọc làm lịch
sử. Trường này nhận 2 đến 31. Mặc định là 2. Một người dùng có thể ở
trạng thái không hoạt động với sự kiện này trong khi vẫn làm các hoạt động khác.
Vòng đời theo sự kiện chính xác thành công
Ví dụ giả lập này dùng hai ngày lịch sử và hai ngày phân tích. Các chữ cái chỉ dùng để đánh dấu người dùng trong ví dụ. Phản hồi không trả về ID người dùng.
C cũng xem một trang vào ngày 2 tháng 6. Sự kiện đó không khớp với tham số chọn
thanh toán.
Đọc vòng đời
Ngày 1 tháng 6, A là quay lại, B là hoạt động trở lại, C là mới và D là không hoạt động. Ngày 2 tháng 6, A và B là quay lại, còn C không hoạt động với sự kiện thanh toán dù có lượt xem trang. Thay đổi ròng ngày 2 tháng 6 là2 - 3 = -1.
Trong mỗi khoảng gộp, số người dùng mới, quay lại và hoạt động trở lại cộng lại
bằng active_subjects. returning_subjects cộng dormant_subjects bằng
previous_active_subjects. net_active_change bằng active_subjects trừ
previous_active_subjects.
Không cộng số người dùng hoạt động theo ngày để có số người dùng riêng biệt. Ở
đây, các số đếm theo ngày cộng lại bằng 5, nhưng
analysis_active_subjects là 3. Có bốn người dùng riêng biệt xuất hiện trong
lịch sử và giai đoạn phân tích.
fully_observed là false với khoảng gộp cuối kết thúc sau until. Số đếm
của khoảng gộp đó có thể thay đổi khi quan sát được trọn kỳ. next_action gợi
ý một hướng điều tra. Trường này không chỉ ra nguyên nhân.
Vòng đời tự động
Gửiresponse_version: 2 và không gửi tham số chọn event. Mọi lượt xem
trang, lượt xem màn hình và tương tác được hỗ trợ đều được tính là hoạt động:
summary, buckets và next_action với phản hồi
theo sự kiện chính xác. Đoạn trích này hiển thị các trường thay đổi:
coverage.selected_events bằng
coverage.analysis_classified_events. Mục thứ năm trong limitations là
Returning, resurrected, and dormant compare any supported classified product activity; no event is ranked, selected, or inferred.
Vòng đời khi không có người dùng
Nếu cả khoảng thời gian phân tích lẫn lịch sử đều không có người dùng dùng được,buckets trống và summary bỏ latest_fully_observed_period:
Lỗi vòng đời
Ngoài lỗi phạm vi dùng chung, các yêu cầu sau trả về422 và validation_failed:
Ví dụ, mười kỳ lịch sử
week cần 70 ngày:
Đọc phạm vi phân tích đã chọn
Phản hồi theo sự kiện chính xác cóschema_version: 1. query của chúng lặp
lại các tham số chọn và bỏ activity_scope. Phản hồi tự động có
schema_version: 2 và query.activity_scope: "all_classified_activity".
Chúng bỏ các tham số chọn. Một tham số chọn khác có thể làm kết quả thay đổi
dù hoạt động đã ghi nhận không đổi.
Phản hồi chuỗi chỉ số
GET /api/telemetry/metrics/series đọc đúng một tên chỉ số trong một dự án.
Sao chép tên từ GET /api/telemetry/metrics. Yêu cầu này nhóm một bộ đếm delta
theo dịch vụ:
Chuỗi chỉ số thành công
Phản hồi giả lập này chứa một chuỗi bộ đếm delta. Ba mẫu với giá trị2, 3
và 5 nằm trong khoảng gộp đầu tiên. Hai mẫu với giá trị 1 và 4 nằm trong
khoảng gộp cuối cùng. Khoảng gộp ở giữa không có mẫu nào, nên phản hồi không có
điểm dữ liệu cho khoảng gộp đó.
Đọc chuỗi chỉ số
Điểm dữ liệu đầu tiên ghi nhận 10 công việc đã hoàn thành, không phải 10 mẫu.rate_per_second chia mức thay đổi đó cho khoảng gộp 300 giây. last là mức
thay đổi được ghi nhận cuối cùng, không phải tổng. Xem
ý nghĩa của phép tổng hợp chỉ số.
Loại và temporality của một chuỗi quyết định aggregation.code của chuỗi đó và
các giá trị thống kê trong mỗi điểm dữ liệu. Điểm dữ liệu bỏ giá trị thống kê
không áp dụng. Giá trị thống kê bị thiếu không phải là 0.
limited là phản hồi thành công, không phải lỗi. Trạng thái này thêm
aggregation.limitation để giải thích vì sao LogBrew chỉ hiển thị giá trị thô.
ready không chứng minh dữ liệu đã được ghi nhận đầy đủ.
Đọc coverage trước khi vẽ biểu đồ:
samplesđếm mẫu của mọi chuỗi khớp, kể cả các chuỗi mà phản hồi không trả về.seriesđếm số chuỗi khớp.returned_seriesvàpointsđếm dữ liệu được trả về.truncatedlàtruekhiseries_limitđã loại các chuỗi có lượng thấp hơn.expected_buckets_per_serieslà số khoảng gộp có thể có trong khoảng thời gian.
trace_exemplars.
Một trace exemplar liên kết một mẫu với một trace. Nó không giải thích mọi mẫu
trong khoảng gộp. Nếu không điểm dữ liệu nào có trace exemplar,
next_action.target là metric_samples.
Phạm vi và lỗi của chuỗi chỉ số
project_id, name và since là bắt buộc. name có tối đa 200 ký tự.
interval là auto, 1m, 5m, 15m, 1h, 6h hoặc 1d. Mặc định là
auto, giá trị này chọn độ dài khoảng gộp nhỏ nhất cần tối đa 300 khoảng gộp.
Độ dài khoảng gộp chỉ định rõ không được cần quá 500 khoảng gộp.
group_by là none, service_name, release hoặc environment. Mặc định là
none. Khi không nhóm, các loại, đơn vị và temporality khác nhau vẫn nằm trong
các chuỗi riêng. series_limit nhận 1 đến 20. Mặc định là 10.
Kết quả trống trả về 200 với series: [] và samples bằng 0. Object
coverage bỏ first_seen_at và last_seen_at. Điều này không chứng minh
rằng ứng dụng chưa từng gửi chỉ số đó. Kiểm tra dự án, tên chỉ số và khoảng thời
gian.
Thiếu name trả về 422:
422:
422 khác là metric series group_by is not supported,
metric series interval is not supported và
metric series_limit must be between 1 and 20.
Phản hồi phân tích đường dẫn
POST /api/telemetry/analytics/paths tìm các sự kiện có tên xảy ra trước hoặc
sau một sự kiện đã chọn trong cùng phiên. Sự kiện đã chọn là điểm neo. Sao chép
kind và event_name của nó từ classified_activity.top_events. Route trả về
schema_version: 1. Route không nhận response_version hay analysis_unit.
direction và anchor là bắt buộc.
Đường dẫn thành công
Trong kết quả giả lập này, bốn phiên chứa điểm neo. Hai đường dẫn được trả về đại diện cho ba trong số các phiên đó. Một đường dẫn xếp hạng thấp hơn không được trả về.Đọc đường dẫn
share_of_anchored_sessions chia số phiên của một đường dẫn cho cả bốn phiên
có điểm neo. Tỷ lệ là 50% và 25%, không phải 67% và 33%.
unrepresented_sessions đếm các phiên có điểm neo mà không đường dẫn nào được
trả về đại diện. paths_truncated: true nghĩa là kết quả chưa đầy đủ.
Độ bao phủ đếm sự kiện, không đếm phiên. Ở đây, năm sự kiện khớp với điểm neo,
nhưng một sự kiện không có ID phiên. Sự kiện đó không thể nằm trong đường dẫn.
Mỗi đường dẫn trả về tối đa 3 trace exemplar. Dùng trace ID từ chính phản hồi
của bạn. Liên kết trace không cho biết điều gì gây ra hành động của người dùng
hay một lỗi.
Các nút được sắp xếp theo thời gian ở cả hai hướng. Đường dẫn không phải bản
phát lại đầy đủ của phiên. LogBrew đọc tối đa 1024 sự kiện có tên trong mỗi
phiên trước khi chọn điểm neo: các sự kiện sớm nhất với
following và các sự
kiện muộn nhất với preceding. Điểm neo nằm ngoài giới hạn đó có thể bị lược
bỏ.
Lọc điểm neo theo thuộc tính
Gửi tối đa bốnproperty_filters, mỗi bộ lọc có đúng một key và value.
Sao chép khóa từ danh mục thuộc tính. Bộ lọc chỉ
áp dụng cho điểm neo, không áp dụng cho các sự kiện xung quanh. Giá trị phân
biệt chữ hoa chữ thường. Khi có bộ lọc, query lặp lại chúng, và
coverage.anchor_property_filters báo cáo:
Thiếu khóa và khác giá trị cần cách sửa khác nhau. Không cộng hai số này với
nhau. Object này bị lược bỏ khi yêu cầu không có bộ lọc thuộc tính.
Đường dẫn trống và yêu cầu bị từ chối
Mảngpaths trống có thể là phản hồi 200 thành công. Đọc summary,
coverage và next_action. Các mã sau phân biệt nguyên nhân:
capture_product_activity, choose_captured_path_anchor,
capture_anchor_properties, improve_anchor_property_coverage,
verify_anchor_property_values, sessionize_product_activity và
narrow_or_move_path_anchor.
Ngoài lỗi phạm vi dùng chung, các yêu cầu sau trả về
422 và validation_failed:
Ví dụ,
depth: 0 trả về:
Danh mục thuộc tính phân tích
GET /api/telemetry/analytics/properties liệt kê các khóa thuộc tính trên sự
kiện sản phẩm đã phân loại trong một dự án. Dùng các khóa này trong
so sánh phân khúc và bộ lọc điểm neo đường dẫn.
Danh mục trả về khóa và số đếm. Danh mục không bao giờ trả về giá trị thuộc tính
hay định danh.
Đọc các khóa thuộc tính có sẵn
Gửiproject_id và since. Bạn cũng có thể gửi until, service_name,
release, environment, limit và response_version. limit nhận từ 1
đến 50 khóa. Mặc định là 20. Gửi response_version=2 để nhận giá trị
estimation.method công khai.
Danh mục thuộc tính thành công
Trong kết quả giả lập này, có 100 sự kiện đã phân loại. Năm sự kiện trong số đó được ghi nhận trước khi có chỉ mục thuộc tính hiện tại.Diễn giải danh mục
source là standard_context với khóa ngữ cảnh chuẩn, chẳng hạn
resource.runtime.name, hoặc custom_tag với khóa bắt đầu bằng tag..
value_type luôn là string. properties được sắp xếp theo events, từ cao
xuống thấp.
tag.plan có trên 60 trong 100 sự kiện đã phân loại. Khóa này có khoảng 3 giá
trị khác nhau. Phần mô tả khóa không hiển thị các giá trị đó. Dùng các giá trị
mà bạn biết từ ứng dụng của mình. Không đoán giá trị từ số đếm. Một sự kiện có
thể có nhiều khóa, nên không cộng các số đếm events của từng khóa.
Mảng
properties trống không chứng minh rằng dự án không có sự kiện sản phẩm.
Đọc summary, coverage và next_action.
Lỗi danh mục thuộc tính
Ngoài lỗi phạm vi dùng chung,limit=0 hoặc
limit=51 trả về 422:
response_version khác 1 hoặc 2 trả về
product analytics response_version must be 1 or 2. LogBrew kiểm tra
response_version trước các giá trị khác.
Yêu cầu POST trả về 405:
So sánh phân khúc phân tích
POST /api/telemetry/analytics/segments/compare so sánh tần suất các phiên hoặc
người dùng đạt tới một sự kiện chính xác trên 2 đến 4 phân khúc trong một dự
án. Một phân khúc chọn sự kiện theo dịch vụ, bản phát hành, môi trường và giá
trị thuộc tính. Phân khúc đầu tiên là phân khúc mốc.
Định nghĩa phép so sánh
Gửi body JSON này cùng xác thực tài khoản vàContent-Type: application/json. Ở đây, basic và premium là giá trị gói của
ứng dụng ví dụ, không phải gói của LogBrew:
target và segments là bắt buộc. analysis_unit là session hoặc
identified_user. Mặc định là session, tức là đếm phiên, không đếm người.
interval nhận cùng các giá trị như route tổng quan. Mặc định là auto.
Mỗi phân khúc cần một key duy nhất, một label và một tập bộ lọc khác biệt:
key: 1 đến 32 byte. Bắt đầu bằng chữ cái ASCII viết thường hoặc chữ số. Chỉ dùng chữ cái ASCII viết thường, chữ số,_và-.label: 1 đến 80 ký tự, không chứa ký tự điều khiển.service_name,release,environment: không bắt buộc. Mỗi giá trị có 1 đến 256 ký tự, không chứa ký tự điều khiển.property_filters: 0 đến 4 bộ lọc. Mỗi khóa chỉ xuất hiện một lần trong một phân khúc. Sự kiện phải khớp với mọi bộ lọc của phân khúc. Giá trị phân biệt chữ hoa chữ thường, dài 1 đến 256 ký tự, và LogBrew cắt khoảng trắng ở đầu và cuối.
So sánh phân khúc thành công
Trong kết quả giả lập này, phân khúc mốc đạt tới bước thanh toán ở 10 trên 50 phiên. Phân khúc premium đạt tới bước đó ở 18 trên 60 phiên.Đọc tỷ lệ và mức chênh lệch
eligible_units ước tính số phiên hoặc người dùng có hoạt động đã phân loại
trong phân khúc. reached_units ước tính bao nhiêu trong số đó đã đạt tới mục
tiêu. reach_rate bằng reached_units chia cho eligible_units. Sự kiện
không có ID của đơn vị đã chọn không được tính vào các đơn vị này.
Tỷ lệ của phân khúc mốc là 20%. Tỷ lệ của phân khúc premium là 30%. Mức chênh
lệch là 10 điểm phần trăm. Mức tăng tương đối là 50%, không phải 10%. Các sai
số thập phân nhỏ đến từ phép tính dấu phẩy động. Làm tròn tỷ lệ khi hiển thị,
nhưng tính toán bằng các giá trị được trả về. Phân khúc mốc không có
comparison_to_baseline. Mức tăng tương đối bị lược bỏ khi tỷ lệ đạt tới của
phân khúc mốc bằng 0.
Trong query, bộ lọc phân khúc mà bạn không gửi là null. Danh sách
property_filters trống bị lược bỏ.
coverage.property_filters có cùng các trường như
độ bao phủ của bộ lọc điểm neo đường dẫn. Ở
đây, matching_events bằng classified_events. Tách riêng trường hợp thiếu
khóa và khác giá trị. Các phân khúc có thể chồng lấn, và một phiên có thể xuất
hiện trong nhiều khoảng gộp. Không cộng số đơn vị giữa các phân khúc hay các
khoảng gộp.
Phép so sánh này chỉ mang tính mô tả. confidence.causal_inference là
not_established và confidence.statistical_significance là not_tested.
Tỷ lệ 30% so với 20% không cho thấy một gói đã khiến số lượt thanh toán tăng
lên.
Lỗi so sánh phân khúc
Ngoài lỗi phạm vi dùng chung, các yêu cầu sau trả về422 và validation_failed:
Các lỗi của
interval giống với lỗi tổng quan.
Ví dụ, hai phân khúc có khóa khác nhau nhưng bộ lọc giống hệt nhau trả về:
GET trả về 405:
Phản hồi lượng tín hiệu
GET /api/telemetry/summary/volume đếm các tín hiệu được giữ lại của một dự án
trong một khoảng thời gian. Route này yêu cầu project_id và since. Route
không nhận project_ids.
until không được ở tương lai. Nếu bỏ until, thời điểm kết thúc là lúc gửi
yêu cầu. since dạng rút gọn như 24h được tính lùi từ until. interval là
auto, 1m, 5m, 15m, 1h, 6h hoặc 1d. Giá trị mặc định auto chọn
độ dài khoảng gộp nhỏ nhất cần tối đa 120 khoảng gộp. Một yêu cầu không được
cần quá 500 khoảng gộp. response_version duy nhất là 1.
Số đếm tín hiệu
Phản hồi giả lập này bao gồm hai khoảng gộp một phút. Yêu cầu chạy lúc 12:02 UTC và không cóuntil. Tài khoản có chính sách giữ dữ liệu 30 ngày. Đọc chính
sách và mốc cắt được trả về. Đừng giả định các giá trị này áp dụng cho tài khoản
của bạn.
Đọc mỗi số đếm theo đơn vị riêng của nó
total là tổng số đếm của các khoảng gộp trong chuỗi. peak là số đếm lớn nhất
của một khoảng gộp. non_empty_buckets đếm các khoảng gộp có số đếm lớn hơn 0.
Năm chuỗi luôn xuất hiện theo thứ tự này. Không gộp số đếm của các tín hiệu khác
nhau thành một điểm tác động duy nhất.
Các khoảng gộp bắt đầu tại query.since. Mỗi khoảng gộp bao gồm thời điểm bắt
đầu và không bao gồm thời điểm kết thúc. Khoảng gộp cuối có thể ngắn hơn độ dài
khoảng gộp. Phản hồi không có chuỗi đếm bản phát hành. Không hiểu
release_volume_not_included là không có bản phát hành nào.
Khoảng thời gian trống và bị rút ngắn
Nếu không có tín hiệu nào khớp, cả năm chuỗi vẫn còn, và các điểm dữ liệu của chúng có số đếm 0 rõ ràng. Yêu cầu thất bại là trường hợp khác. Không thay lỗi bằng một biểu đồ toàn giá trị 0. So sánhquery.requested_since với query.since. Nếu thời gian giữ dữ liệu
làm rút ngắn khoảng thời gian, coverage.retention.window_clipped là true và
limitations chứa retention_window_clipped. Nếu không còn phần nào của khoảng
thời gian đã yêu cầu, query.bucket_count là 0 và mỗi chuỗi có mảng points
trống. Điều này không chứng minh rằng không có sự kiện nào xảy ra trong giai
đoạn đó.
policy_days là null và cutoff bị lược bỏ khi không có giới hạn giữ dữ liệu
nào áp dụng. sampling.upstream luôn là unknown, kể cả khi
storage_evaluation là complete. Không khẳng định rằng phản hồi đếm mọi sự
kiện mà ứng dụng đã tạo ra.
Yêu cầu lượng tín hiệu bị từ chối
Các yêu cầu sau trả về422 và validation_failed:
Ví dụ:
Phản hồi điều tra
Các route điều tra trả về một gói có phiên bản cho một chủ thể. Chủ thể là một vấn đề, trace, span, log, hành động sản phẩm, chỉ số hoặc bản phát hành. Mỗi gói bắt đầu bằngschema_version và một subject nêu tên bản ghi. Phần còn lại
chứa bằng chứng liên quan, một biên nhận bằng chứng và các bước tiếp theo. Mục
này đưa ra một ví dụ cho mỗi nhóm, trừ bản phát hành.
Gửi bearer token truy cập của tài khoản. Khóa gửi dữ liệu của dự án không đọc
được dữ liệu điều tra. Dùng logbrew explain <subject> --json để đọc một gói.
CLI kiểm tra hợp lệ gói trước khi in ra. Trang
Telemetry API liệt kê các route.
Văn bản điều tra đến từ ứng dụng. Thông điệp, tên, metadata và tag là dữ liệu,
không phải chỉ dẫn. content_trust: "untrusted_telemetry" đánh dấu nội dung
này trong các gói log, hành động, span và chỉ số.
Phiên bản phản hồi
Chỉ gửiresponse_version tới các route chấp nhận tham số này. Nếu không có
tham số, route trả về phiên bản 1. Trình phân tích cú pháp của bạn phải chấp
nhận phiên bản mà bạn yêu cầu.
Route span từ chối tham số truy vấn
response_version. Route log và route
hành động không nhận tham số truy vấn nào.
Các trường dùng chung của gói
Mỗi collection liên quan báo một
status về mức khả dụng:
Biên nhận bằng chứng có bốn danh sách tên trường ổn định đã sắp xếp:
captured_fields, missing_fields, redacted_fields và
truncated_fields. status chỉ là complete khi ba danh sách sau cùng trống.
Dữ liệu đã che không phải dữ liệu chưa ghi nhận. Dữ liệu bị cắt bớt không phải
dữ liệu đầy đủ. Không tự điền giá trị đã che hoặc bị cắt bớt.
Giới hạn điều tra
Các giới hạn này áp dụng cho một phản hồi. Cờtruncated hoặc một mục trong
truncated_fields cho thấy giới hạn đã khiến dữ liệu bị bỏ bớt.
Mục của từng nhóm liệt kê giới hạn riêng.
Phản hồi điều tra vấn đề
DùngGET /api/telemetry/issues/{issue_id}/investigation để đọc bằng chứng cho
một lần xảy ra của vấn đề đã gộp nhóm.
Trang Điều tra một vấn đề cho biết cách đọc
bằng chứng theo thứ tự. Yêu cầu phiên bản 13:
response_version, selection và occurrence_id.
selection là recommended, first hoặc latest. Các giá trị phân biệt chữ
hoa chữ thường. Ở phiên bản 2 đến 13, nếu bỏ tham số chọn, route dùng
recommended. Phiên bản 1 trả về lần xảy ra gần nhất được giữ lại và không nhận
tham số chọn. Bộ lọc của danh sách vấn đề không áp dụng cho lượt đọc này.
Ví dụ điều tra vấn đề phiên bản 13
Ví dụ điều tra vấn đề phiên bản 13
Phản hồi
200 OK giả lập này có một lần xảy ra TypeError đã xử lý, kèm một
trace được liên kết. Phản hồi không có bằng chứng về yêu cầu, breadcrumb, log
liên quan hay lần triển khai, nên evidence.status là partial.
Khóa của phiên bản sau không có trong phiên bản trước. Không hiểu khóa bị thiếu
là
null.
subject.status và các trạng thái trong lifecycle báo vấn đề đã lưu trữ là
ignored. Phản hồi danh sách và chi tiết vấn đề dùng archived từ phiên bản
phản hồi 2 trở đi.
Giới hạn của vấn đề: phần đề xuất đọc tối đa 50 lần xảy ra được giữ lại. Xu
hướng có tối đa 30 khoảng gộp. Mỗi phân bố trả về tối đa 10 giá trị. Một dấu
vết ngăn xếp (stack trace) có tối đa 32 khung.
Lỗi yêu cầu điều tra vấn đề
Chỉ dùngselection hoặc occurrence_id. Không gửi cả hai, kể cả khi chúng
chọn cùng một lần xảy ra:
Lần xảy ra không tồn tại không có nghĩa là vấn đề không tồn tại.
404 không cho
biết liệu tài khoản khác có đọc được vấn đề hay không.
Phản hồi điều tra trace
DùngGET /api/telemetry/traces/{trace_id}/investigation để đọc một trace cùng
đường đi lỗi, đường đi chậm nhất và các tín hiệu liên quan. Các tham số truy vấn là
response_version, project_id, release và environment. Tất cả đều không
bắt buộc. Yêu cầu phiên bản 3:
cause và fix vào mỗi vấn đề liên quan. Phiên bản 3 thêm
span_id vào các vấn đề, hành động và chỉ số liên quan khi đã ghi nhận.
Ví dụ điều tra trace phiên bản 3
Ví dụ điều tra trace phiên bản 3
Phản hồi giả lập này có một span gốc phía máy chủ và một span phía client bị
lỗi. Span lỗi cũng là span con chậm nhất. Các span không có ngữ cảnh có cấu
trúc, nên
spans.context không có.trace.parentage không có khi một span trỏ đến span cha mà LogBrew không giữ
lại. Bản xem trước span có tối đa 64 span. Mỗi đường đi phân tích có tối đa 64
span. Các lượt đọc liên quan dùng tối đa 8 phạm vi triển khai.
Hành động tiếp theo có target trace_span nêu một span_id trong gói này. Để
đọc span đó, gửi route span kèm project_id, environment và release của
span.
Phản hồi điều tra span
DùngGET /api/telemetry/traces/{trace_id}/spans/{span_id}/investigation để
đọc một thao tác trong trace. Gửi project_id, environment và release. Cả
ba đều bắt buộc. Sao chép chúng từ span đã chọn. Không gửi id của dòng span
làm span_id.
Ví dụ điều tra span
Ví dụ điều tra span
Phản hồi giả lập này mô tả span phía client bị lỗi trong ví dụ trace ở trên.
Một log lỗi có cùng span ID. Span chạy lâu hơn phân vị thứ 95 ước tính của các
span cùng loại được giữ lại.
Mốc so sánh đọc 24 giờ trước lúc span bắt đầu.
since được tính vào khoảng thời
gian, còn until thì không. error_rate_basis_points: 500 nghĩa là 5%.
subject_percentile_basis_points: 9500 nghĩa là 95% các span cùng loại được giữ
lại chạy không lâu hơn span này. Các phân vị là giá trị ước tính. Giữ
baseline.limitations đi kèm các giá trị. Mốc so sánh not_found không có
span cùng loại nào được giữ lại. Mốc so sánh unavailable là lượt đọc thất bại,
không phải số đếm bằng 0.
parent_chain_status: "complete" nghĩa là chuỗi span được giữ lại đi đến một
span gốc. Điều này không chứng minh LogBrew đã giữ lại mọi span của yêu cầu.
Cấu trúc liên kết trả về tối đa 64 span tổ tiên, 50 span con trực tiếp và 50
cạnh nối giữa các dịch vụ.
Phản hồi điều tra log
DùngGET /api/logs/{log_id}/investigation để đọc một log và bằng chứng liên
quan. Route này không có tham số truy vấn. Sao chép ID log từ một danh sách log.
Ví dụ điều tra log
Ví dụ điều tra log
Phản hồi giả lập này có một log cảnh báo không có ngữ cảnh trace và một log lân
cận. Phản hồi không dựng liên kết trace từ dấu thời gian.
Trace ID có thể có mặt khi trạng thái trace là
not_found hoặc
unavailable. Bản tóm tắt trace khả dụng không bảo đảm có exact_span.
Phản hồi điều tra hành động
DùngGET /api/telemetry/actions/{action_id}/investigation để đọc một hành động
sản phẩm, trạng thái được báo cáo của nó và bằng chứng liên quan. Route này
không có tham số truy vấn. Các lượt đọc liên quan dùng cùng khoảng thời gian và
phạm vi như điều tra log.
correlations, timeline và next_actions dùng cấu trúc của điều tra log.
Các hành động liên quan không bao gồm hành động chủ thể.
Ví dụ điều tra hành động
Ví dụ điều tra hành động
Phản hồi giả lập này mô tả một hành động thanh toán thất bại của một người dùng
đã đăng nhập. Hành động không có trace ID.
Phản hồi không bao giờ trả về định danh chủ thể hay định danh phiên. Biên nhận
bằng chứng luôn liệt kê
subject.distinct_id là đã che, và cả
subject.session_id khi đã ghi nhận phiên. Vì vậy, mọi gói hành động đều là
partial và có improve_capture. Không gỡ các biện pháp bảo vệ quyền riêng tư
chỉ để đáp ứng gợi ý đó.
Phản hồi điều tra chỉ số
DùngGET /api/telemetry/metrics/investigation để đọc một tên chỉ số trong một
dự án và một khoảng thời gian. Phản hồi có chuỗi hiện tại, phép so sánh với
khoảng thời gian liền trước có cùng độ dài, mẫu gần nhất, các trace exemplar và
các lần triển khai đã hoàn tất. Phiên bản 2 thêm mô tả chỉ số lấy từ mẫu gần
nhất được giữ lại. Phiên bản 1 luôn báo
description_status: "not_captured".
project_id, name và since là bắt buộc. since được tính vào khoảng thời
gian, còn until thì không. until mặc định là thời điểm hiện tại. Phép so
sánh cũng đọc khoảng thời gian liền trước có cùng độ dài.
Ví dụ điều tra chỉ số phiên bản 2
Ví dụ điều tra chỉ số phiên bản 2
Histogram giả lập này có 5 mẫu trong hai khoảng gộp 5 phút. Khoảng gộp gần nhất
có p95 là 48 ms. Khoảng gộp gần nhất của khoảng thời gian trước có p95 là 24 ms.
relative_change_percent bằng (current - previous) / abs(previous) * 100.
Giá trị này là null khi giá trị trước bằng 0 hoặc bị thiếu. expected_buckets_per_series
đếm số khoảng gộp có thể có, không phải số khoảng gộp có dữ liệu. Không vẽ
khoảng gộp trống thành giá trị 0. Một lần triển khai gần thời điểm thay đổi
không chứng minh rằng nó gây ra thay đổi đó.
Dự án mà tài khoản không đọc được trả về 200 OK với
analysis.status: "no_samples", không phải 404. Kết quả trống không mô tả các
loại tín hiệu khác.
Giới hạn của chỉ số: khoảng thời gian tối đa 31 ngày. Mỗi chuỗi có tối đa 500
khoảng gộp. series_limit từ 1 đến 20, mặc định là 10. Phản hồi trả về tối đa
20 exemplar và 20 lần triển khai.
interval là auto, 1m, 5m, 15m, 1h, 6h hoặc 1d. group_by là
none, service_name, release hoặc environment. Các giá trị khác trả về
422.
Lỗi điều tra
404 nghĩa là không dự án nào đọc được có bản ghi đó. Mỗi route cũng trả về
401 khi không có xác thực hợp lệ và 405 với phương thức khác GET.
Xem Lỗi API để biết các phản hồi
không tìm thấy,
đường dẫn,
xác thực và
phương thức.
Một lượt đọc bằng chứng không bắt buộc có thể thất bại bên trong phản hồi
200 OK. Khi đó, collection báo unavailable. Không hiển thị nó thành
not_found hay thành 0 bản ghi.
Giá trị mức độ nghiêm trọng
Các giá trị mức độ nghiêm trọng hiển thị cho người dùng làinfo, warning,
error và critical. SDK và runtime có thể gửi các bí danh phổ biến như
trace, debug, warn hoặc fatal. Phản hồi REST và phản hồi trực tiếp luôn
trả về giá trị chuẩn. Ví dụ, LogBrew nhận warn làm đầu vào và trả về
warning. Khi tiếp nhận dữ liệu, LogBrew từ chối các giá trị mức độ nghiêm
trọng không xác định.
Phản hồi quy tắc mức độ nghiêm trọng
Quy tắc mức độ nghiêm trọng thay đổi cách LogBrew hiển thị một log hoặc một vấn đề. Quy tắc không thay đổi mức độ nghiêm trọng mà ứng dụng đã ghi nhận. Log và vấn đề trả về objecttriage:
Dùng
triage.effective_severity để hiển thị. Giữ severity là giá trị đã ghi
nhận. Theo mặc định, danh sách log không hiển thị các log bị bỏ qua. Gửi status=ignored
hoặc status=all trong GET /api/logs để lấy cả các log đó.
Tài khoản phải có quyền quản lý vấn đề trong dự án. Quyền đọc là chưa đủ. Nếu
không có quyền này, thao tác đổi quy tắc trả về 403 với code: forbidden.
Đổi quy tắc log
PUT /api/logs/{log_id}/triage-rule đặt quy tắc cho log này và cho các log sau
có cùng chữ ký. Body cần cả severity lẫn ignored:
200 OK chứa toàn bộ log. severity của log vẫn là
warning. triage của log thể hiện quy tắc:
severity trong yêu cầu là
source, info, warning, error hoặc critical. source khôi phục mức độ
nghiêm trọng đã ghi nhận. Giá trị này không làm log bị bỏ qua hoạt động trở lại.
Để hiển thị lại log, gửi "ignored": false.
Đổi quy tắc vấn đề
PUT /api/telemetry/issues/{issue_id}/triage-rule đặt mức độ nghiêm trọng hiển
thị của một vấn đề đã gộp nhóm và các lần xảy ra sau đó. Body chỉ nhận
severity:
200 OK chứa toàn bộ vấn đề ở phiên bản 1.
severity đã ghi nhận và status không thay đổi:
response_version=2 hoặc 3 để xem mức ưu tiên đó.
Mức độ nghiêm trọng không được hỗ trợ trả về 422:
status trong quy tắc vấn đề, trả
về 422 với code: invalid_json. Log hoặc vấn đề không tồn tại hay không đọc
được trả về 404 với code: not_found. Nếu mất phản hồi, đọc lại log hoặc vấn
đề trước khi gửi lại quy tắc.
Định dạng phản hồi lỗi
Lỗi ứng dụng trả về một envelope JSON. Ví dụ này cho thấy một yêu cầu bị từ chối; văn bảnerror và next tùy thuộc vào lỗi cụ thể:
code để rẽ nhánh trong chương trình và next_action cho tự động hóa.
Hiển thị error và next cho người đọc dưới dạng văn bản thuần. Không phân tích
cú pháp câu chữ của chúng. Một số lỗi có thêm trường, chẳng hạn limit,
reset_at hoặc retry_after_seconds. Phản hồi không có body JSON thì không có
code của LogBrew. Xem Lỗi API để biết mọi mã lỗi.
Đọc dữ liệu bằng CLI
CLI đọc cùng các route và trả về cùng JSON khi dùng--json. Bắt đầu với phạm
vi rộng, rồi thu hẹp dần:
--pagination cursor để nhận envelope cursor. CLI yêu cầu phản hồi vấn đề
phiên bản 4. Xem Đọc trang tiếp theo
và Theo dõi trực tiếp.