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à yêu cầu của proxy API) mỗi giây. Xin lưu ý rằng nếu bạn có số lượng giao dịch tương đối thấp trong khoảng thời gian đó, thì số lượng giao dịch trung bình mỗi giây có thể bằng 0 trong báo cáo tuỳ chỉnh trên giao diện người dùng nếu số lượng này nhỏ hơn 2 chữ số thập phân.

Cú pháp API: tps

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

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 khoảng thời gian nhất định. Ví dụ: nếu bạn chọn max cho khoảng thời gian một ngày và trong ngày đó, số lượng phần tử cao nhất trong bộ nhớ đệm là 12 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 mà bạn đang truy vấn và số lượng bộ nhớ đệm của các giao dịch đó là 5, 6 và 7, thì giá trị trung bình là 6. Bộ nhớ đệm L1 là bộ nhớ đệm trong bộ nhớ, không phải bộ nhớ đệm cơ sở dữ liệu L2, như mô tả trong phần Cấu trúc bộ nhớ đệm.

Cú pháp API: avg(ax_cache_l1_count)

Tổng số lỗi về chính sách trong khoảng thời gian cụ thể.

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

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

Phương diện Tên chính sách khi có lỗi (ax_execution_fault_policy_name) rất hữu ích khi bạn muốn 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ư lỗi 404 hoặc 503) không được tính là lỗi chính sách. Những yêu cầu đó được tính là lỗi của proxy API (is_error).

Cú pháp API: sum(policy_error)

Tổng số lần các proxy API không hoạt động trong khoảng thời gian nhất định. Lỗi proxy có thể xảy ra khi chính sách không thành công hoặc khi có lỗi thời gian chạy, chẳng hạn như lỗi 404 hoặc 503 từ dịch vụ đích.

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

Cú pháp API: sum(is_error)

Khoảng thời gian (trung bình, tối thiểu hoặc tối đa), tính bằng mili giây, mà Edge cần để xử lý các yêu cầu đến. Thời gian bắt đầu khi yêu cầu đến Edge và kết thúc khi Edge chuyển tiếp yêu cầu đế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 theo proxy API, ứng dụng 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 chính sách Response Cache được thực thi trong khoảng thời gian nhất định.

Vì chính sách Response Cache được đính kèm ở 2 vị trí trong một proxy API (một lần trong yêu cầu và một lần trong phản hồi), nên chính sách này thường thực thi 2 lần trong một lệnh gọi API. Mỗi thao tác "get" và "put" của bộ nhớ đệm đều đượ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 phần tử <SkipCacheLookup> trong chính sách đánh giá là true (trong yêu cầu) và 0 nếu phần tử <SkipCachePopulation> trong chính sách đánh giá 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 một lệnh gọi API đã thực thi và xem responsecache.executed biến luồng để biết có hoạt động thực thi bộ nhớ đệm hay không (giá trị là 1).

Cú pháp API: sum(ax_cache_executed)

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

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 proxy API, 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ề cho ứng dụng khách, tính bằng byte.

Cú pháp API: max(response_size)

Tổng số phản hồi 5xx từ dịch vụ mục tiêu. Đây là các lỗi dịch vụ đích 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), tính bằng mili giây, để máy chủ đích phản hồi một lệnh gọi. Chỉ số này cho biết hiệu suất của các máy chủ mục tiêu. Thời gian bắt đầu khi Edge chuyển tiếp một yêu cầu đến dịch vụ đích và kết thúc khi Edge nhận được phản hồi.

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

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), tính bằng mili giây, kể từ khi Edge nhận được yêu cầu từ một ứng dụng cho đến khi Edge gửi phản hồi lạ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 để bộ cân bằng tải và bộ định tuyến thực hiện công việc của chúng), độ trễ xử lý yêu cầu, độ 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ụ mục tiêu thay vì bộ nhớ đệm).

Khi sử dụng nhiều phương diện, bạn có thể kiểm tra độ trễ xử lý theo proxy API, ứng dụng 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 được Edge xử lý trong khoảng thời gian cụ thể.

Sử dụng phương diện để nhóm số lượt truy cập theo 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. Để nhận được phương diện này, các ứng dụng 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 sản phẩm API có chứa các proxy API và các proxy được gọi 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 được liên kết với một sản phẩm API. Để biết thêm thông tin, hãy xem bài viết Điều đầu tiên cần làm: Cách tạo dữ liệu phân tích đầy đủ.

Nếu không đáp ứng các tiêu chí nêu trên, bạn sẽ thấy giá trị "(not set)". Xem thêm Giá trị thực thể Analytics "(not set)" có nghĩa là gì?.

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

Trong Công cụ theo dõi, khi chọn một chính sách Response Cache (Bộ nhớ đệm phản hồi) đọc 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", môi trường là "test" và tên bộ nhớ đệm là "myCache", thì ax_cache_name là foo__test__myCache.

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

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

Trong Trace tool (Công cụ theo dõi), khi chọn chính sách Response Cache (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 phần Cấu trúc bên trong của bộ nhớ đệm.

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

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

Nếu không đáp ứng các tiêu chí nêu trên, bạn sẽ thấy giá trị "(not set)". Xem thêm bài viết Giá trị thực thể phân tích "(not set)" có nghĩa là gì?.

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

Để nhận được phương diện này, các ứng dụng phải được liên kết với một hoặc nhiều 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 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 này xác định ứng dụng của nhà phát triển. Để biết thêm thông tin, hãy xem bài viết Những điều cần làm trước tiên: Cách tạo dữ liệu phân tích đầy đủ.

Nếu không đáp ứng các tiêu chí nêu trên, bạn sẽ thấy giá trị "(not set)". Xem thêm bài viết Giá trị thực thể phân tích "(not set)" có nghĩa là gì?.

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

Để nhận được phương diện này, nhà phát triển phải có các ứng dụng được liên kết với một hoặc nhiều 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 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 này xác định ứng dụng của nhà phát triển. Để biết thêm thông tin, hãy xem bài viết Việc cần làm trước tiên: Cách tạo dữ liệu phân tích đầy đủ.

Nếu không đáp ứng các tiêu chí nêu trên, bạn sẽ thấy giá trị "(not set)". Xem thêm bài viết Giá trị thực thể Analytics "(not set)" có nghĩa là gì?.

Giá trị nhận dạng riêng biệt của nhà phát triển do Edge tạo ở dạng org_name@@@unique_id.

Để nhận được phương diện này, nhà phát triển phải có các ứng dụng được liên kết với một hoặc nhiều 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 khoá API hoặc mã thông báo OAuth được gửi cùng với các lệnh gọi API. Khoá hoặc mã thông báo xác định nhà phát triển. Để biết thêm thông tin, hãy xem bài viết Điều đầu tiên cần làm: Cách tạo dữ liệu phân tích đầy đủ.

Nếu không đáp ứng các tiêu chí nêu trên, bạn sẽ thấy giá trị "(not set)". Xem thêm bài viết Giá trị thực thể Analytics "(not set)" có nghĩa là gì?.

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

Luồng được đặt tên trong một proxy API đã gây ra 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 dùng trong API quản lý là ax_execution_fault_flow_name, không có dấu ngắt dòng.

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

Tên của các trạng thái luồng proxy API đã gây ra lỗi, chẳng hạn như "PROXY_REQ_FLOW" hoặc "TARGET_RESP_FLOW".

Xin lưu ý rằng tên đầy đủ cần dùng trong API quản lý là ax_execution_fault_flow_state, không có dấu ngắt dòng.

Tên của chính sách đã gâ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 dùng trong API quản lý là ax_execution_fault_policy_name, không có dấu ngắt dòng.

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

BasePath được định cấu hình trên ProxyEndpoint của API proxy. Đường dẫn cơ sở không bao gồm phần miền và cổng của URL proxy API. Ví dụ: nếu URL cơ sở của một proxy API là https://apigeedocs-test.apigee.net/releasenotes/, thì đườ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ở của proxy API. Ví dụ: nếu URL cơ sở của một proxy API là https://apigeedocs-test.apigee.net/hello/ và một lệnh gọi được thực hiện đến https://apigeedocs-test.apigee.net/hello/json, thì pathsuffix là /json.

Nếu không sử dụng pathsuffix, 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 ứng dụng khách ban đầu. Giá trị của phương diện ax_resolved_client_ip được tính từ các giá trị trong phương diện ax_true_client_ip và x_forwarded_for_ip.

Xin lưu ý rằng khi sử dụng các sản phẩm định tuyến như Akamai để ghi lại địa chỉ IP thực của các máy khách, IP máy khách sẽ được truyền đến Edge trong tiêu đề HTTP True-Client-IP. Sau đó, tiêu đề này đượ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 phải là giá trị rỗng và không chứa địa chỉ IP cục bộ, thì hãy đặ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 chỉ chứa địa chỉ IP cục bộ, thì hãy đặt ax_resolved_client_ip thành địa chỉ IP cục bộ đầu tiên trong x_forwarded_for_ip.
4. Nếu cả ax_true_client_ip và x_forwarded_for_ip đều rỗng, hãy đặ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 dùng phương diện này làm phương diện "đi sâu" thứ hai cùng với Họ hệ điều hành (ax_ua_os_family) để xem các phiên bản của hệ điều hành.

Địa chỉ IP của ứng dụng khách 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 lệnh gọi đến, là địa chỉ IP mà Edge nhận được từ lần bắt tay TCP bên ngoài gần đây nhất. Đây 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 được liệt kê.

Khi sử dụng các sản phẩm định tuyến như Akamai để ghi lại địa chỉ IP thực của máy khách, IP máy khách sẽ được truyền đến Edge trong tiêu đề HTTP True-Client-IP. Phương diện này ghi nhận những địa chỉ IP thực tế của máy khách từ tiêu đề đó.

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

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

Ví dụ: đích đến mẫu Apigee http://mocktarget.apigee.net bao gồm một số tài nguyên, trong đó có /user, trả về một lời chào. Bất kể cách proxy API của bạn gọi http://mocktarget.apigee.net/user, 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ả các tham số truy vấn.

Ví dụ: đích đến mẫu Apigee http://mocktarget.apigee.net bao gồm một số tài nguyên, trong đó có tài nguyên /user?user={name} và tham số truy vấn để trả về lời chào tuỳ chỉnh cho tên được cung cấp. Bất kể cách lệnh gọi proxy API của bạn http://mocktarget.apigee.net/user?user=Dude, 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ụ:

• Điện thoại Pixel XL thực hiện cuộc gọi 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
• iPad thực hiện cuộc gọi 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 useragent.

Bạn nên sử dụng chỉ số này làm phương diện "đi sâu" thứ hai với Phương diện Nhóm tác nhân người dùng (ax_ua_agent_family) để biết phiên bản của nhóm tác nhâ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 các tham số truy vấn, được xác định trong <TargetEndpoint> của proxy.

Ví dụ: giả sử một 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ẽ là giá trị rỗng.

Trong Trace tool (Công cụ theo dõi), khi bạn chọn biểu tượng AX ở cuối sơ đồ luồng, target.basepath biến luồng sẽ ánh xạ đến 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ụ đích. Điều này xảy ra khi phản hồi được cung cấp theo chính sách Bộ nhớ đệm phản hồi hoặc khi có lỗi trong quá trình xử lý yêu cầu.

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

URL đầy đủ của dịch vụ đích được xác định trong TargetEndpoint của một 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 chaining và khi sử dụng script targets (Node.js), target_url trong proxy gọi là null.

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 khách, được truy cập thông qua phương diện ax_resolved_client_ip, Edge sử dụng phương diện ax_true_client_ip và x_forwarded_for_ip.

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

Giá trị thời gian được tính theo giờ UTC.