Tài liệu tham khảo về chỉ số, phương diện và bộ lọc của Analytics

Số giao dịch trung bình (tức là các yêu cầu proxy API) mỗi giây. Xin lưu ý rằng nếu bạn có chỉ số số lượng giao dịch trong khoảng thời gian đó, số lượng giao dịch trung bình trên mỗi giây có thể có vẻ bằng 0 trong báo cáo tuỳ chỉnh giao diện người dùng nếu con số nhỏ hơn 2 chữ số thập phân.

Cú pháp API: tps

Số yêu cầu API thành công sử dụng Bộ nhớ đệm phản hồi thay vì từ dịch vụ mục tiêu.

Cú pháp API: sum(cache_hit)

Trả về số lượng phần tử trong bộ nhớ đệm L1 (trong bộ nhớ) cho mỗi giao dịch trong một giao dịch nhất định khoảng thời gian cụ thể. Ví dụ: nếu bạn chọn max cho khoảng thời gian là một ngày và trong ngày đó, số lượng phần tử cao nhất trong bộ nhớ đệm là 12 phần tử cho một giao dịch cụ thể, thì số lượng sẽ là 12. Đối với avg, nếu có 3 giao dịch trong khoảng thời gian bạn đang truy vấn và số bộ nhớ đệm của chúng là 5, 6 và 7, trung bình là 6. L1 bộ nhớ đệm là bộ nhớ đệm trong bộ nhớ khác với bộ nhớ đệm của cơ sở dữ liệu L2, như mô tả trong phần Bộ nhớ đệm nội bộ.

Cú pháp API: avg(ax_cache_l1_count)

Tổng số lỗi vi phạm chính sách trong khoảng thời gian đã chỉ định.

Lỗi chính sách thường xảy ra do thiết kế. Ví dụ: Chính sách Xác minh khoá API sẽ gửi lỗi khi khoá API không hợp lệ được chuyển trong yêu cầu và chính sách về Sự gia tăng Spike sẽ gửi lỗi nếu số lệnh gọi API vượt quá giới hạn được quy định trong chính sách. Loại đối thủ sau lượt đánh bóng chỉ số này rất hữu ích trong việc tìm kiếm các điểm tiềm ẩn sự cố trong API của bạn. Ví dụ: chỉ số policy_error, được nhóm theo phương diện developer_app, có thể giúp bạn khám phá khoá API hoặc mã thông báo OAuth đối với một ứng dụng cụ thể đã hết hạn; hoặc bạn có thể thấy rằng proxy API cụ thể đang tạo ra nhiều lỗi Spike Arrest, khiến bạn phát hiện ra rằng giới hạn bắt giữ tăng đột biến của proxy không tính đến sự gia tăng lưu lượng truy cập trong mùa lễ.

Lỗi chính sách chỉ được ghi vào Analytics nếu lỗi dẫn đến lỗi API proxy. Ví dụ: nếu bạn đặt thuộc tính continueOnError của một chính sách thành true, proxy API sẽ tiếp tục xử lý yêu cầu ngay cả khi chính sách này không thành công. Trong trường hợp đó, lỗi chính sách không được ghi lại vào số liệu phân tích.

Phương diện Tên chính sách về lỗi (ax_execution_fault_policy_name) rất hữu ích đối với nhóm các lỗi chính sách theo tên chính sách.

Lỗi mục tiêu (chẳng hạn như 404 hoặc 503) không được tính là lỗi chính sách. Những tính là lỗi proxy API (is_error).

Cú pháp API: sum(policy_error)

Tổng số lần proxy API bị lỗi trong khoảng thời gian được chỉ định. Proxy lỗi có thể xảy ra khi chính sách bị lỗi hoặc khi có lỗi thời gian chạy, chẳng hạn như 404 hoặc 503 của dịch vụ đích.

Phương diện Proxy (apiproxy) rất hữu ích để nhóm các lỗi proxy API theo proxy.

Cú pháp API: sum(is_error)

Lượng thời gian (trung bình, tối thiểu hoặc tối đa), tính bằng mili giây, Edge sẽ phải xử lý các yêu cầu gửi đến. Thời gian bắt đầu khi yêu cầu đạt đến Edge và kết thúc khi Edge chuyển tiếp yêu cầu này đến dịch vụ đích.

Khi sử dụng nhiều phương diện, bạn có thể kiểm tra độ trễ xử lý yêu cầu bằng proxy API, ứng dụng của nhà phát triển, khu vực, v.v.

Cú pháp API: max(request_processing_latency)

Kích thước của tải trọng yêu cầu mà Edge nhận được, tính bằng byte.

Cú pháp API: avg(request_size)

Tổng số lần thực thi một chính sách về Bộ nhớ đệm phản hồi trong một khoảng thời gian nhất định 6 tháng.

Do Chính sách về Bộ nhớ đệm phản hồi được đính kèm ở 2 vị trí trong proxy API (một lần trong và một lần trong phản hồi), mã này thường thực thi hai lần trong một lệnh gọi API. Bộ nhớ đệm "get" và bộ nhớ đệm "put" mỗi lần sẽ được tính là một lần thực thi.

Tuy nhiên, quá trình thực thi bộ nhớ đệm phản hồi là 0 nếu <SkipCacheLookup> trong chính sách có giá trị true (trong yêu cầu) và 0 nếu <SkipCachePopulation> trong chính sách có giá trị là true (trong phản hồi).

Trong công cụ Theo dõi, bạn có thể nhấp vào biểu tượng Bộ nhớ đệm phản hồi trong lệnh gọi API được thực thi và xem biến luồng responsecache.executed thành xem liệu có thực thi bộ nhớ đệm hay không (giá trị là 1).

Cú pháp API: sum(ax_cache_executed)

Lượng thời gian (trung bình, tối thiểu hoặc tối đa), tính bằng mili giây, Edge cần xử lý các phản hồi của API. Thời gian bắt đầu khi proxy API nhận được phản hồi của dịch vụ mục tiêu và kết thúc khi Apigee chuyển tiếp phản hồi đến phản hồi gốc người gọi.

Khi sử dụng nhiều phương diện, bạn có thể kiểm tra độ trễ xử lý phản hồi theo API proxy, khu vực, v.v.

Cú pháp API: min(response_processing_latency)

Kích thước của tải trọng phản hồi được trả về ứng dụng, theo byte.

Cú pháp API: max(response_size)

Tổng số phản hồi 5xx từ dịch vụ đích. Đây là các dịch vụ đích những lỗi không phải do Apigee gây ra.

Cú pháp API: sum(target_error)

Khoảng thời gian (tổng, trung bình, tối thiểu hoặc tối đa), theo mili giây để máy chủ mục tiêu phản hồi một lệnh gọi. Chỉ số này cho bạn biết máy chủ mục tiêu đang hoạt động như thế nào. Thời gian bắt đầu khi Edge chuyển tiếp một yêu cầu đối với dịch vụ mục tiêu và kết thúc khi Edge nhận được phản hồi.

Xin lưu ý rằng nếu lệnh gọi API trả về phản hồi từ bộ nhớ đệm (sử dụng Bộ nhớ đệm phản hồi chính sách cụ thể), cuộc gọi sẽ không bao giờ tiếp cận được dịch vụ mục tiêu và không có mục tiêu các chỉ số thời gian phản hồi được ghi nhật ký.

Cú pháp API: avg(target_response_time)

Khoảng thời gian (tổng, trung bình, tối thiểu hoặc tối đa), theo mili giây, kể từ khi Edge nhận được yêu cầu của ứng dụng cho đến khi Edge sẽ gửi lại phản hồi cho ứng dụng. Thời gian này bao gồm cả chi phí mạng (chẳng hạn như thời gian cần thiết để trình cân bằng tải và bộ định tuyến thực hiện công việc của chúng), yêu cầu xử lý độ trễ, độ trễ xử lý phản hồi và thời gian phản hồi mục tiêu (nếu phản hồi được phân phát từ dịch vụ đích thay vì bộ nhớ đệm).

Khi sử dụng các phương diện khác nhau, bạn có thể kiểm tra độ trễ xử lý bằng proxy API, ứng dụng của nhà phát triển, khu vực, v.v.

Cú pháp API: avg(total_response_time)

Tổng số lệnh gọi API mà Edge xử lý trong khoảng thời gian cụ thể.

Sử dụng phương diện để nhóm lưu lượng truy cập theo những cách có ý nghĩa nhất đối với bạn.

Cú pháp API: sum(message_count)

Tên của sản phẩm API chứa các proxy API đang được gọi. Để có được phương diện này, ứng dụng của nhà phát triển thực hiện lệnh gọi phải được liên kết với một hoặc nhiều API các sản phẩm chứa proxy API và proxy được gọi phải kiểm tra xem có API hoặc mã thông báo OAuth được gửi cùng với lệnh gọi API. Khoá hoặc mã thông báo được liên kết với một API của Google. Để biết thêm thông tin, hãy xem Trước tiên: Cách tạo dữ liệu phân tích hoàn chỉnh.

Nếu không đáp ứng các tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Xem thêm Giá trị của pháp nhân Analytics "(chưa đặt)" có nghĩa là gì?.

Khoá chứa giá trị Bộ nhớ đệm phản hồi đã được truy cập. Để biết thêm thông tin về cách tạo khoá cho bộ nhớ đệm phản hồi, hãy xem Chính sách về bộ nhớ đệm của phản hồi.

Trong công cụ Theo dõi, khi chọn một chính sách Bộ nhớ đệm phản hồi được đọc từ hoặc ghi vào bộ nhớ đệm, bạn có thể thấy giá trị này trong biến luồng responsecache.cachekey.

Tên của bộ nhớ đệm chứa các khoá/giá trị mà chính sách Bộ nhớ đệm phản hồi sử dụng, có tiền tố là orgName__envName__. Ví dụ: nếu tổ chức là "foo", thời gian là "thử nghiệm" và tên bộ nhớ đệm là "myCache" ax_cache_name là foo__test__myCache.

Trong công cụ Theo dõi, khi chọn một chính sách Bộ nhớ đệm phản hồi, bạn có thể thấy giá trị này trong Biến luồng responsecache.cachename.

Cấp bộ nhớ đệm (cơ sở dữ liệu "L1" trong bộ nhớ hoặc cơ sở dữ liệu "L2") mà từ đó Bộ nhớ đệm phản hồi đã truy xuất. Phương diện này cũng cho biết "CACHE_MISS" thời điểm phản hồi được gửi từ mục tiêu thay vì bộ nhớ đệm (và bộ nhớ đệm phản hồi đã được làm mới bằng phản hồi mục tiêu); hoặc khi khoá bộ nhớ đệm trong yêu cầu không hợp lệ. Khoá bộ nhớ đệm chỉ giới hạn ở Kích thước 2 KB.

Trong công cụ Theo dõi, khi chọn chính sách Bộ nhớ đệm phản hồi, bạn có thể thấy giá trị này trong Biến luồng responsecache.cachesource.

Để biết thêm thông tin về các cấp bộ nhớ đệm, hãy xem Bộ nhớ đệm nội bộ.

Khoá người dùng (khoá API) của ứng dụng của nhà phát triển thực hiện lệnh gọi API, cho dù đã truyền trong yêu cầu dưới dạng khoá API hoặc có trong mã thông báo OAuth.

Để nhận phương diện này, bạn phải định cấu hình các proxy nhận cuộc gọi để kiểm tra để có khoá API hoặc mã thông báo OAuth hợp lệ. Ứng dụng của nhà phát triển nhận được khoá API để dùng để tạo mã thông báo OAuth khi ứng dụng được đăng ký trong Edge. Để biết thêm thông tin, hãy xem Trước tiên: Cách tạo dữ liệu phân tích hoàn chỉnh.

Nếu không đáp ứng các tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Xem thêm Giá trị của pháp nhân Analytics "(chưa đặt)" có nghĩa là gì?.

Ứng dụng của nhà phát triển đã đăng ký Edge thực hiện lệnh gọi API.

Để nhận được phương diện này, ứng dụng phải liên kết với một hoặc nhiều sản phẩm API có chứa proxy API đang được gọi và proxy phải kiểm tra khoá API hoặc Mã thông báo OAuth được gửi cùng với lệnh gọi API. Khoá hoặc mã thông báo giúp xác định ứng dụng của nhà phát triển. Cho để biết thêm thông tin, hãy xem bài viết Những điều đầu tiên: Cách tạo dữ liệu phân tích hoàn chỉnh.

Nếu không đáp ứng các tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Xem thêm Giá trị của pháp nhân Analytics "(chưa đặt)" có nghĩa là gì?.

Email của các nhà phát triển đã đăng ký Edge và có ứng dụng thực hiện lệnh gọi API.

Để nhận được phương diện này, nhà phát triển phải có ứng dụng liên kết với ít nhất một Sản phẩm API có chứa các proxy API đang được gọi và các proxy phải kiểm tra để tìm Khoá API hoặc mã thông báo OAuth được gửi cùng với lệnh gọi API. Khoá hoặc mã thông báo giúp xác định nhà phát triển . Để biết thêm thông tin, hãy xem bài viết Những điều đầu tiên: Cách tạo dữ liệu phân tích hoàn chỉnh.

Nếu không đáp ứng các tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Xem thêm Giá trị của pháp nhân Analytics "(chưa đặt)" có nghĩa là gì?.

Mã nhà phát triển duy nhất do Edge tạo ở dạng org_name@@@org_name.

Để nhận được phương diện này, nhà phát triển phải có ứng dụng liên kết với ít nhất một Các sản phẩm API có chứa proxy API đang được gọi và proxy phải kiểm tra để tìm Khoá API hoặc mã thông báo OAuth được gửi cùng với lệnh gọi API. Khoá hoặc mã thông báo sẽ nhận dạng nhà phát triển. Để biết thêm thông tin, hãy xem bài viết Những điều đầu tiên: Cách tạo dữ liệu phân tích hoàn chỉnh.

Nếu không đáp ứng các tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Xem thêm Giá trị của pháp nhân Analytics "(chưa đặt)" có nghĩa là gì?.

Mã lỗi của lỗi. Ví dụ: messaging.adaptors.http.flow.GatewayTimeout

flow được đặt tên trong một proxy API đã phát sinh lỗi. Ví dụ: "PreFlow", "PostFlow", hoặc tên của một luồng có điều kiện mà bạn đã tạo.

Xin lưu ý rằng tên đầy đủ cần sử dụng trong API quản lý là ax_execution_fault_flow_name, mà không có ngắt dòng.

Nếu không có lỗi nào xảy ra, bạn sẽ thấy giá trị "(chưa đặt)".

Tên của luồng proxy API cho biết đã phát sinh lỗi, chẳng hạn như "PROXY_REQ_FLOW" hoặc "TARGET_RESP_FLOW".

Lưu ý rằng tên đầy đủ cần sử dụng trong API quản lý là ax_execution_fault_flow_state, mà không có ngắt dòng.

Tên của chính sách đã xảy ra lỗi và khiến lệnh gọi API không thực hiện được.

Xin lưu ý rằng tên đầy đủ cần sử dụng trong API quản lý là ax_execution_fault_policy_name, mà không có ngắt dòng.

Nếu một chính sách gửi ra lỗi nhưng thuộc tính gốc của chính sách continueOnError được đặt thành true, luồng proxy API sẽ tiếp tục mà không bị lỗi và chính sách này lỗi không được tính trong phương diện này.

BasePath được định cấu hình trên ProxyEndpoint proxy API. Đường dẫn cơ sở không bao gồm miền và phần cổng của URL proxy API. Ví dụ: nếu URL cơ sở của proxy API là https://apigeedocs-test.apigee.net/releasenotes/, đường dẫn cơ sở là /releasenotes.

Giá trị này cũng được lưu trữ trong biến luồng proxy.basepath.

Đường dẫn tài nguyên được thêm vào đường dẫn cơ sở proxy API. Ví dụ: nếu proxy API URL cơ sở là https://apigeedocs-test.apigee.net/hello/ và lệnh gọi được thực hiện đến https://apigeedocs-test.apigee.net/hello/json thì hậu tố đường dẫn là /json.

Nếu không có đường dẫn nào được sử dụng, thì giá trị sẽ trống.

Giá trị này cũng được lưu trữ trong biến luồng proxy.pathsuffix.

Chứa địa chỉ IP ban đầu của ứng dụng. Giá trị của ax_resolved_client_ip phương diện được tính từ các giá trị trong ax_true_client_ip và x_forwarded_for_ip phương diện.

Lưu ý rằng khi sử dụng các sản phẩm định tuyến như AVD để thu thập địa chỉ IP thực của khách hàng, IP máy khách được chuyển cho Edge trong tiêu đề HTTP True-Client-IP, tức là sau đó được dùng để đặt phương diện ax_true_client_ip.

Giá trị của phương diện ax_resolved_client_ip được tính như sau:

1. Nếu ax_true_client_ip không rỗng và không chứa địa chỉ IP cục bộ, sau đó đặt ax_resolved_client_ip thành ax_true_client_ip.
2. Nếu không, hãy đặt ax_resolved_client_ip thành địa chỉ IP không phải cục bộ đầu tiên trong x_forwarded_for_ip
3. Nếu cả ax_true_client_ip và x_forwarded_for_ip đều chứa chỉ địa chỉ IP cục bộ, sau đó đặt ax_resolved_client_ip thành địa chỉ IP đầu tiên trong x_forwarded_for_ip.
4. Nếu cả ax_true_client_ip và x_forwarded_for_ip đều rỗng, đặt ax_resolved_client_ip thành (not set).
5. Nếu ax_true_client_ip là địa chỉ IP cục bộ và x_forwarded_for_ip là giá trị rỗng, hãy đặt ax_resolved_client_ip thành (not set).

Phiên bản hệ điều hành của thiết bị thực hiện cuộc gọi.

Bạn nên sử dụng thông tin này làm "thông tin chi tiết" thứ hai phương diện với Nhóm hệ điều hành (ax_ua_os_family) để xem phiên bản của các hệ điều hành.

Địa chỉ IP của ứng dụng gọi, được lưu trữ trong proxy.client.ip biến luồng. Đây thường là địa chỉ X-Forwarded-For của cuộc gọi đến, là địa chỉ IP mà Edge nhận được từ cơ chế bắt tay TCP bên ngoài gần đây nhất. Điều này có thể có thể là ứng dụng khách gọi hoặc trình cân bằng tải. Khi có nhiều IP trong Tiêu đề X-Forwarded-For, đây là IP cuối cùng trong danh sách.

Khi sử dụng các sản phẩm định tuyến như AVD để thu thập địa chỉ IP thực của khách hàng, các IP của máy khách được chuyển đến Edge trong tiêu đề HTTP True-Client-IP. Chiến dịch này sẽ thu thập các IP ứng dụng khách thực sự đó từ tiêu đề đó.

Để xác định Địa chỉ IP ban đầu của ứng dụng, được truy cập thông qua ax_resolved_client_ip , Edge sử dụng phương diện ax_true_client_ip và x_forwarded_for_ip phương diện.

Đường dẫn tài nguyên (không bao gồm miền) đến dịch vụ đích, không bao gồm truy vấn tham số.

Ví dụ: mục tiêu mẫu Apigee http://mocktarget.apigee.net bao gồm một số tài nguyên (bao gồm cả /user) trả về một lời chào. Bất kể proxy API của bạn gọi http://mocktarget.apigee.net/user bằng cách nào, đường dẫn request_path là /user.

Đường dẫn tài nguyên (không bao gồm miền) đến dịch vụ đích, bao gồm cả truy vấn tham số.

Ví dụ: mục tiêu mẫu Apigee http://mocktarget.apigee.net bao gồm một số tài nguyên, bao gồm tài nguyên và truy vấn /user?user={name} để trả về lời chào tuỳ chỉnh cho tên đã cung cấp. Bất kể API của bạn như thế nào proxy gọi http://mocktarget.apigee.net/user?user=Dude, thì request_uri là /user?user=Dude

Tên của tác nhân người dùng hoặc tác nhân phần mềm, được dùng để thực hiện lệnh gọi API. Ví dụ:

• Pixel XL gọi điện qua Chrome: Mozilla/5.0 (Linux; Android 7.1.2; Pixel XL Build/NHG47N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
• Trên iPad đang gọi điện qua Chrome: Mozilla/5.0 (iPad; CPU OS 10_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/54.0.2840.91 Mobile/14C92 Safari/602.1
• cURL từ một thiết bị đầu cuối: curl/7.51.0

Phiên bản của tác nhân người dùng.

Bạn nên sử dụng thông tin này làm "thông tin chi tiết" thứ hai phương diện với Nhóm tác nhân người dùng (ax_ua_agent_family) để tải phiên bản của nhóm tác nhân này.

Đường dẫn tài nguyên (không bao gồm miền) đến dịch vụ đích, không bao gồm truy vấn tham số được xác định trong <TargetEndpoint> của proxy.

Ví dụ: giả sử proxy API gọi mục tiêu sau:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

Trong ví dụ này, target_basepath là /user.

Nếu mục tiêu là:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net</URL>
</HTTPTargetConnection>

target_basepath sẽ trống.

Trong công cụ Theo dõi, khi bạn hãy chọn biểu tượng AX ở cuối sơ đồ luồng, target.basepath biến luồng liên kết với phương diện target_basepath.

Mã trạng thái phản hồi HTTP do dịch vụ đích trả về cho proxy API, chẳng hạn như 200, 404, 503, v.v.

Giá trị "null" có nghĩa là yêu cầu không bao giờ đến được dịch vụ mục tiêu. Điều này xảy ra khi phản hồi được phân phát bởi chính sách Bộ nhớ đệm phản hồi hoặc khi có lỗi yêu cầu đang xử lý.

Mã này khác với Mã trạng thái phản hồi phương diện (response_status_code).

URL đầy đủ của dịch vụ mục tiêu được xác định trong TargetEndpoint của proxy API.

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

Trong ví dụ này, target_url là http://mocktarget.apigee.net/user?user=Dude.

Xin lưu ý rằng bạn cũng có thể ghi đè URL trong quá trình xử lý proxy API bằng Biến luồng target.url.

Trong proxy tạo chuỗi và khi sử dụng tập lệnh (Node.js), thì target_url trong proxy gọi là rỗng.

Danh sách địa chỉ IP trong tiêu đề X-Forwarded-For.

Để xác định Địa chỉ IP ban đầu của ứng dụng, được truy cập thông qua ax_resolved_client_ip , Edge sử dụng phương diện ax_true_client_ip và x_forwarded_for_ip phương diện.

Dựa trên đồng hồ 24 giờ, giờ gồm 2 chữ số mà lệnh gọi API được thực hiện. Ví dụ: Lệnh gọi API được thực hiện trong khoảng thời gian từ 10 giờ tối đến 11 giờ tối, ax_hour_of_day sẽ là 22.

Giá trị thời gian theo giờ UTC.