Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về
Apigee X. thông tin
Chủ đề này tham khảo về các chỉ số, phương diện và bộ lọc Analytics. Để biết thêm thông tin về cách sử dụng các tính năng này, hãy xem bài viết Tổng quan về API Analytics.
Chủ đề này cho biết tên của các chỉ số và phương diện khi chúng xuất hiện trong giao diện người dùng, cũng như khi bạn cần sử dụng chúng trong các lệnh gọi API.
- Bạn sẽ thấy tên giao diện người dùng khi tạo Báo cáo tuỳ chỉnh.
- Hãy sử dụng tên dành riêng cho API khi nhận các chỉ số, tạo định nghĩa báo cáo hoặc cập nhật định nghĩa báo cáo.
Chỉ số
Sau đây là các chỉ số API mà bạn có thể truy xuất trong báo cáo tuỳ chỉnh và lệnh gọi API quản lý.
Tên báo cáo tuỳ chỉnh | Tên để sử dụng trong API quản lý | Hàm | Nội dung mô tả |
---|---|---|---|
Số lần giao dịch trung bình mỗi giây | điểm chuẩn | Không có |
Số giao dịch trung bình (tức là số yêu cầu 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 đã chọn, thì số 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 con số nhỏ hơn 2 chữ số thập phân. Cú pháp API: |
Số lượt truy cập vào bộ nhớ đệm | cache_hit | tổng |
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 của dịch vụ mục tiêu. Cú pháp API: |
Số phần tử bộ nhớ đệm L1 | ax_cache_l1_count | trung bình, tối thiểu, tối đa |
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 Cú pháp API: |
Lỗi chính sách | policy_error | tổng |
Tổng số lỗi về chính sách trong khoảng thời gian cụ thể. 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 yêu cầu có khoá API không hợp lệ, còn chính sách Spike Arrest sẽ gửi 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 trong việc xác định các điểm sự cố tiềm ẩn trong API của bạn. Ví dụ: các chỉ số policy_error nhóm theo phương diện developer_app, có thể giúp bạn phát hiện ra rằng khoá API hoặc mã thông báo OAuth đã hết hạn đối với 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ửi rất nhiều lỗi Tăng đột biến, dẫn đến việc bạn nhận ra rằng giới hạn bắt giữ tăng đột biến của proxy không tính đến mức gia tăng lưu lượng truy cập vào dịp lễ. Lỗi chính sách chỉ được ghi lại trong Analytics nếu lỗi dẫn đến lỗi proxy API.
Ví dụ: nếu bạn đặt thuộc tính Phương diện Tên chính sách trên Lỗi (ax_execution_fault_policy_name) rất hữu ích khi 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 lỗi này được tính là lỗi proxy API (is_error). Cú pháp API: |
Lỗi proxy | is_error | tổng |
Tổng số lần proxy API không hoạt động trong khoảng thời gian chỉ định. Lỗi proxy có thể xảy ra khi một chính sách bị lỗi 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ụ mục tiêu. 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: |
Thời gian chờ xử lý yêu cầu | request_processing_latency | trung bình, tối thiểu, tối đa |
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ụ mục tiêu. Bằng cách 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 của nhà phát triển, khu vực, v.v. Cú pháp API: |
Yêu cầu kích thước | request_size | tổng, trung bình, tối thiểu, tối đa |
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: |
Đã thực thi bộ nhớ đệm phản hồi | ax_cache_executed | tổng |
Tổng số lần thực thi chính sách Bộ nhớ đệm phản hồi trong một khoảng thời gian nhất định. Vì chính sách Bộ nhớ đệm của phản hồi được đính kèm ở hai 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 hai lần trong một lệnh gọi API. Mỗi bộ nhớ đệm "get" và bộ nhớ đệm "put" được tính là một lượt thực thi. Tuy nhiên, giá trị thực thi bộ nhớ đệm phản hồi sẽ là 0 nếu phần tử 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 Cú pháp API: |
Độ trễ xử lý phản hồi | response_processing_latency | trung bình, tối thiểu, tối đa |
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 của API. Thời gian bắt đầu từ thời điểm 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 tới 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: |
Kích thước phản hồi | response_size | tổng, trung bình, tối thiểu, tối đa |
Kích thước của tải trọng phản hồi được trả về ứng dụng, tính bằng byte. Cú pháp API: |
Lỗi mục tiêu | target_error | tổng |
Tổng số phản hồi 5xx từ dịch vụ đích. Đây là những lỗi dịch vụ mục tiêu không phải do Apigee gây ra. Cú pháp API: |
Thời gian phản hồi mục tiêu | target_response_time | tổng, trung bình, tối thiểu, tối đa |
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ủ mục tiêu phản hồi một lệnh gọi. Chỉ số này cho bạn biết hiệu suất của 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ụ 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 một lệnh gọi API trả về một 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ờ đến được dịch vụ mục tiêu và không có chỉ số nào về thời gian phản hồi mục tiêu được ghi lại. Cú pháp API: |
Tổng thời gian phản hồi | total_response_time | tổng, trung bình, tối thiểu, tối đa |
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ừ ứng dụng đến khi Edge gửi lại phản hồi cho ứng dụng. Thời gian này bao gồm cả mức hao tổn 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), độ 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). Bằng cách 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 của nhà phát triển, khu vực, v.v. Cú pháp API: |
Tình hình giao thông | message_count | tổng |
Tổng số lệnh gọi API mà Edge xử lý trong khoảng thời gian đã chỉ định. Sử dụng thứ nguyên để nhóm số lượng lưu lượng truy cập theo cách có ý nghĩa nhất đối với bạn. Cú pháp API: |
Kích thước
Phương diện cho phép bạn xem các chỉ số trong các nhóm phù hợp. Ví dụ: việc xem tổng lưu lượng truy cập sẽ hữu ích hơn nhiều khi bạn xem chúng cho từng ứng dụng của nhà phát triển hoặc proxy API.
Sau đây là các kích thước mà Apigee cung cấp ngay từ đầu. Ngoài ra, bạn có thể tạo các phương diện riêng như mô tả trong bài viết Phân tích nội dung thông báo API bằng công cụ phân tích tuỳ chỉnh.
Tên Báo cáo tuỳ chỉnh | Tên để sử dụng trong API quản lý | Nội dung mô tả |
---|---|---|
Thực thể API | ||
Mã truy cập | access_token | Mã truy cập OAuth của người dùng cuối của ứng dụng. |
Sản phẩm API | api_product |
Tên của sản phẩm API có 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 liên kết với một hoặc nhiều sản phẩm API chứa proxy API. Đồng thời, những proxy đang được gọi phải kiểm tra xem có khoá API hoặc mã thông báo OAuth được gửi bằng lệnh gọi API hay không. 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 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 tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Hãy xem thêm phần Giá trị thực thể phân tích "(chưa đặt)" có nghĩa là gì?. |
Khoá bộ nhớ đệm | ax_cache_key |
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 bộ nhớ đệm 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 mà sẽ đọc hoặc ghi vào bộ nhớ đệm, bạn có thể thấy giá trị này trong biến luồng của |
Tên bộ nhớ đệm | ax_cache_name |
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ì môi trường là "test" và tên bộ nhớ đệm là "myCache", thì ax_cache_name sẽ 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 |
Nguồn bộ nhớ đệm | ax_cache_source |
Cấp bộ nhớ đệm ("L1" trong bộ nhớ hoặc cơ sở dữ liệu "L2") mà từ đó Bộ nhớ đệm phản hồi được truy xuất. Phương diện này cũng cho thấy "bộ nhớ đệm" '' GHIM_MISS" khi phản hồi được phân phố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 khóa bộ nhớ đệm trong yêu cầu không hợp lệ. Khoá bộ nhớ đệm có kích thước giới hạn ở 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 Để biết thêm thông tin về các cấp bộ nhớ đệm, hãy xem phần Bộ nhớ đệm nội bộ. |
Client ID | client_id |
Khoá người dùng (khoá API) trong ứng dụng của nhà phát triển thực hiện các lệnh gọi API, cho dù được chuyể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, bạn phải định cấu hình các proxy nhận lệnh gọi nhằm kiểm tra khoá API hoặc mã thông báo OAuth hợp lệ. Ứng dụng của nhà phát triển sẽ nhận được khoá API có thể 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 bài viết 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 tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Hãy xem thêm bài viết Giá trị thực thể phân tích "(chưa đặt)" có nghĩa là gì?. |
Ứng dụng dành cho nhà phát triển | developer_app |
Ứng dụng dành cho 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, đồng thời các proxy này phải kiểm tra xem có khoá API hoặc mã thông báo OAuth được gửi bằng lệnh gọi API hay không. Khoá hoặc mã thông báo 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 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 tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Hãy xem thêm bài viết Giá trị thực thể phân tích "(chưa đặt)" có nghĩa là gì?. |
Email của nhà phát triển | developer_email |
Email của những nhà phát triển đã đăng ký Edge 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ó các ứng dụng 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à các proxy đó phải kiểm tra khoá API hoặc mã thông báo OAuth được gửi bằng 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. Để biết thêm thông tin, hãy xem bài viết 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 tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Hãy xem thêm bài viết Giá trị thực thể phân tích "(chưa đặt)" có nghĩa là gì?. |
Mã nhà phát triển | nhà phát triển |
Mã nhà phát triển duy nhất 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 liên kết với một hoặc nhiều sản phẩm API chứa proxy API đang được gọi, đồng thời các proxy đó phải kiểm tra khoá API hoặc mã thông báo OAuth được gửi bằng 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 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 tiêu chí ở trên, bạn sẽ thấy giá trị "(chưa đặt)". Hãy xem thêm bài viết Giá trị thực thể phân tích "(chưa đặt)" có nghĩa là gì?. |
Môi trường | môi trường | Môi trường Edge mà trong đó proxy API được triển khai. Ví dụ: "test" hoặc "prod". |
Mã lỗi khi gặp lỗi | ax_edge_execution_fault_code |
Mã lỗi của lỗi đó. Ví dụ: |
Tên luồng khi gặp lỗi | ax_execution_fault _flow_name |
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 đủ để sử dụng trong API quản lý là ax_execution_fault_flow_name, không có dấu ngắt dòng. Khi không có lỗi nào xảy ra, bạn sẽ thấy giá trị "(chưa đặt)". |
Tài nguyên luồng | flow_resource | Chỉ sử dụng Apigee. Hãy xem bài đăng này trên thẻ Cộng đồng nếu bạn muốn biết. |
Trạng thái luồng khi gặp lỗi | ax_execution_fault _flow_state |
Tên của luồng proxy API đã nêu ra các lỗi, chẳng hạn như "PROXY_REQ_FLOW" hoặc "TARGET_RESP_FLOW". Xin lưu ý rằng tên đầy đủ để sử dụng trong API quản lý là ax_execution_fault_flow_state và không có dấu ngắt dòng. |
Mã luồng cổng vào | gateway_flow_id | Khi lệnh gọi API di chuyển qua Edge, mỗi lệnh gọi sẽ nhận được mã luồng cổng riêng. Ví dụ: rrt329ea-12575-114653952-1. Mã nhận dạng luồng cổng vào giúp phân biệt các chỉ số trong các trường hợp có chỉ số TPS cao khi các phương diện khác như tổ chức, môi trường và dấu thời gian giống hệt nhau giữa các lệnh gọi. |
Tổ chức | tổ chức | Tổ chức Edge mà trong đó các proxy API được triển khai. |
Tên chính sách về lỗi | ax_execution_fault _policy_name |
Tên của chính sách gửi 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 đủ để sử dụng trong API quản lý là ax_execution_fault_policy_name, không có dấu ngắt dòng. Nếu chính sách báo lỗi nhưng thuộc tính gốc của chính sách |
Proxy | apiproxy | Tên máy (không phải Tên hiển thị) của proxy API. |
Đường dẫn cơ sở proxy | proxy_basepath |
BasePath được định cấu hình trên ProxyEndpoint API API. Đườ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 proxy API là https://apigeedocs-test.apigee.net/releasenotes/, thì đường dẫn cơ sở sẽ là /releasenotes. Giá trị này cũng được lưu trữ trong biến luồng |
Hậu tố đường dẫn proxy | proxy_pathsuffix |
Đườ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 proxy API là Nếu không có pathuffix 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 |
Bản sửa đổi proxy | apiproxy_revision | Số bản sửa đổi của proxy API đã xử lý lệnh gọi API. Điều này không nhất thiết là bản sửa đổi mới nhất của proxy API. Nếu một proxy API có 10 bản sửa đổi thì bản sửa đổi thứ 8 có thể được triển khai. Ngoài ra, một API có thể triển khai nhiều bản sửa đổi, miễn là các bản sửa đổi đó có nhiều đường dẫn cơ sở, như mô tả trong phần Triển khai proxy trong giao diện người dùng. |
IP ứng dụng đã được giải quyết | ax_resolved_client_ip |
Chứa địa chỉ IP của ứng dụng gốc. Giá trị của phương diện Xin lưu ý rằng khi sử dụng các sản phẩm định tuyến như Akamai để thu thập địa chỉ IP thực của ứng dụng, IP ứng dụng sẽ được chuyển đến Edge trong tiêu đề HTTP Giá trị của phương diện
|
Mã trạng thái phản hồi | response_status_code | Mã trạng thái phản hồi HTTP được chuyển tiếp từ Apigee đến ứng dụng khách, chẳng hạn như 200, 404, 503, v.v. Trong Edge, mã trạng thái phản hồi từ mục tiêu có thể bị ghi đè bằng các chính sách như Gán thông báo và Tăng lỗi. Đó là lý do phương diện này có thể khác với Mã phản hồi mục tiêu (target_Response_code). |
Máy chủ ảo | virtual_host | Tên của máy chủ ảo mà lệnh gọi API được thực hiện. Ví dụ: các tổ chức có 2 máy chủ ảo theo mặc định: default (http) và secure (https). |
Đến/Khách hàng | ||
Địa chỉ IP ứng dụng | client_ip | Địa chỉ IP của hệ thống đánh vào bộ định tuyến, chẳng hạn như ứng dụng ban đầu (proxy_client_ip) 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ê. |
Danh mục thiết bị | ax_ua_device_category | Loại thiết bị mà lệnh gọi API được thực hiện, chẳng hạn như "Máy tính bảng" hoặc "Điện thoại thông minh". |
Dòng hệ điều hành | ax_ua_os_family | Nhóm hệ điều hành của thiết bị thực hiện cuộc gọi, chẳng hạn như "Android" hoặc "iOS". |
Phiên bản hệ điều hành | ax_ua_os_version |
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 phương diện "xem chi tiết" thứ hai với Nhóm hệ điều hành (ax_ua_os_family) để xem các phiên bản của hệ điều hành. |
IP ứng dụng proxy | proxy_client_ip |
Địa chỉ IP của ứng dụng gọi, được lưu trữ trong biến luồng |
IP ứng dụng được giới thiệu | ax_true_client_ip | Khi sử dụng các sản phẩm định tuyến như Akamai để thu thập địa chỉ IP thực của ứng dụng, IP của ứng dụng sẽ được truyền đến Edge trong tiêu đề HTTP Để xác định Địa chỉ IP của ứng dụng ban đầu, được truy cập thông qua phương diện |
Đường dẫn yêu cầu | request_path |
Đường dẫn tài nguyên (không bao gồm miền) đến dịch vụ mục tiêu, ngoại trừ các tham số truy vấn. Ví dụ: mục tiêu mẫu của Apigee là |
URI yêu cầu | request_uri |
Đường dẫn tài nguyên (không bao gồm miền) đến dịch vụ mục tiêu, bao gồm cả các tham số truy vấn. Ví dụ: mục tiêu mẫu Apigee được tạo bằng |
Yêu cầu động từ | request_verb | Động từ yêu cầu HTTP trong yêu cầu API, chẳng hạn như GET, POST, PUT, DELETE. |
Tác nhân người dùng | tác nhân người dùng |
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ụ:
|
Nhóm tác nhân người dùng | ax_ua_agent_family | Nhóm tác nhân người dùng, chẳng hạn như "Chrome Mobile" hoặc "cURL". |
Loại tác nhân người dùng | ax_ua_agent_type | Loại tác nhân người dùng, chẳng hạn như "Trình duyệt", "Trình duyệt trên thiết bị di động", "Thư viện", v.v. |
Phiên bản tác nhân người dùng | ax_ua_agent_version |
Phiên bản của tác nhân người dùng. Bạn nên sử dụng phương diện này làm phương diện "xem chi tiết" thứ hai 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. |
Đường liên kết ra ngoài/Mục tiêu | ||
Đường dẫn cơ sở mục tiêu | target_basepath |
Đường dẫn tài nguyên (không bao gồm miền) đến dịch vụ mục tiêu, ngoại trừ các tham số truy vấn được xác định trong 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à Nếu mục tiêu là: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> </HTTPTargetConnection> target_basepath sẽ rỗng. Trong Công cụ theo dõi, khi bạn chọn biểu tượng AX ở cuối sơ đồ luồng, biến luồng |
Máy chủ mục tiêu | target_host | Máy chủ lưu trữ của dịch vụ mục tiêu. Ví dụ: nếu một proxy API gọi http://mocktarget.apigee.net/help , thì target_host sẽ là mocktarget.apigee.net . |
Địa chỉ IP mục tiêu | target_ip | Địa chỉ IP của dịch vụ mục tiêu trả về phản hồi cho proxy API. |
Mã phản hồi mục tiêu | target_response_code |
Mã trạng thái phản hồi HTTP do dịch vụ mục tiêu trả về cho proxy API, chẳng hạn như 200, 404, 503, v.v. Giá trị "null" (rỗng) 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 theo chính sách Bộ nhớ đệm phản hồi hoặc khi quá trình xử lý yêu cầu bị lỗi. Phương diện này khác với phương diện Mã trạng thái phản hồi (Response_status_code). |
URL mục tiêu | target_url |
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à 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 Trong chuỗi proxy và khi sử dụng mục tiêu tập lệnh (Node.js), target_url trong proxy gọi là rỗng. |
X được chuyển tiếp cho | x_forwarded_for_ip | Danh sách địa chỉ IP trong tiêu đề Để xác định Địa chỉ IP của ứng dụng ban đầu, được truy cập thông qua phương diện |
Thời gian | ||
Ngày trong tuần | ax_day_of_week | Ngày viết tắt gồm ba chữ cái của tuần mà các lệnh gọi API được thực hiện. Ví dụ: thứ Hai, thứ Ba, thứ Tư. |
Tháng | ax_month_of_year | Tháng thực hiện các lệnh gọi API. Ví dụ: "03" cho tháng 3. |
Thời gian trong ngày | ax_hour_of_day |
Dựa trên đồng hồ 24 giờ, giờ gồm 2 chữ số mà các 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 một giờ từ 10 giờ tối đến 11 giờ đêm, thì ax_hour_of_day sẽ là 22. Giá trị thời gian theo giờ UTC. |
Múi giờ | ax_geo_timezone | Tên phổ biến của múi giờ dùng để thực hiện lệnh gọi API, chẳng hạn như America/New_Quốc và Châu Âu/Dublin. |
Tuần trong tháng | ax_week_of_month | Tuần bằng số trong tháng. Ví dụ: đối với các lệnh gọi API được thực hiện vào tuần thứ 3 của một tháng, giá trị ax_week_of_month là 3. |
Vị trí | ||
Thành phố | ax_geo_city | Thành phố nơi lệnh gọi API được thực hiện. |
Châu lục | ax_geo_continent | Mã châu lục gồm hai chữ cái của lục địa mà lệnh gọi API được thực hiện. Ví dụ: Bắc Mỹ cho Bắc Mỹ. |
Quốc gia | ax_geo_country | Mã gồm hai chữ cái của quốc gia thực hiện lệnh gọi API. Ví dụ: US cho Hoa Kỳ. |
Khu vực địa lý | ax_geo_region | Mã gạch nối cho khu vực địa lý, chẳng hạn như STATE-COUNTRY. Ví dụ: WA-US cho Washington-Hoa Kỳ. |
Vùng | ax_dn_region | Tên của trung tâm dữ liệu Apigee được triển khai các proxy API, chẳng hạn như us-east-1. |
Kiếm tiền | ||
Tin nhắn bỏ qua giao dịch đúc | x_apigee_mint_tx_ignoreMessage | Cờ chỉ định xem có bỏ qua thông báo liên quan đến hoạt động kiếm tiền hay không. Đặt thành false cho mọi tổ chức kiếm tiền. |
Trạng thái giao dịch đúc | x_apigee_mint_tx_status | Trạng thái của yêu cầu kiếm tiền, chẳng hạn như thành công, không thành công, không hợp lệ hoặc không có. |
Bộ lọc
Bộ lọc cho phép bạn giới hạn kết quả ở những chỉ số có các đặc điểm cụ thể. Sau đây là một số bộ lọc mẫu. Sử dụng tên kiểu API chỉ số và phương diện khi xác định bộ lọc.
Trả về chỉ số cho các proxy API có tên sách hoặc nhạc:
filter=(apiproxy in 'books','music')
Trả về chỉ số cho những proxy API có tên bắt đầu bằng "m":
filter=(apiproxy like 'm%')
Trả về chỉ số cho những proxy API có tên không bắt đầu bằng "m":
filter=(apiproxy not like 'm%')
Trả về các chỉ số cho các lệnh gọi API có mã trạng thái phản hồi từ 400 đến 599:
filter=(response_status_code ge 400 and response_status_code le 599)
Trả về các chỉ số cho lệnh gọi API có mã trạng thái phản hồi là 200 và mã phản hồi mục tiêu là 404:
filter=(response_status_code eq 200 and target_response_code eq 404)
Trả về chỉ số cho lệnh gọi API có mã trạng thái phản hồi là 500:
filter=(response_status_code eq 500)
Trả về các chỉ số cho lệnh gọi API không dẫn đến lỗi:
filter=(is_error eq 0)
Dưới đây là các toán tử bạn có thể sử dụng để tạo bộ lọc báo cáo.
Đơn vị tổ chức | Nội dung mô tả |
---|---|
in |
Thêm vào danh sách |
notin |
Loại trừ khỏi danh sách |
eq |
Bằng, == |
ne |
Không bằng != |
gt |
Lớn hơn, > |
lt |
Ít hơn, < |
ge |
Lớn hơn hoặc bằng >= |
le |
Nhỏ hơn hoặc bằng <= |
like |
Trả về true nếu mẫu chuỗi khớp với mẫu được cung cấp. |
not like |
Trả về false nếu mẫu chuỗi khớp với mẫu đã cung cấp. |
similar to |
Trả về true hoặc false tuỳ thuộc vào việc mẫu của giá trị này khớp với chuỗi đã cho. Hàm này tương tự như like ngoại trừ việc diễn giải mẫu bằng cách sử dụng định nghĩa của một biểu thức chính quy theo tiêu chuẩn SQL. |
not similar to |
Trả về false hoặc true tuỳ thuộc vào việc mẫu của giá trị này khớp với chuỗi đã cho. Hàm này tương tự như not like , ngoại trừ việc nó diễn giải mẫu bằng cách sử dụng định nghĩa của một biểu thức chính quy theo tiêu chuẩn SQL. |
and |
Cho phép bạn sử dụng logic 'và' để bao gồm nhiều biểu thức lọc. Bộ lọc bao gồm những dữ liệu đáp ứng tất cả các điều kiện. |
or |
Cho phép bạn dùng logic "hoặc" để đánh giá nhiều biểu thức lọc khả thi. Bộ lọc bao gồm những dữ liệu đáp ứng ít nhất một trong các điều kiện. |