View metrics

Stay organized with collections Save and categorize content based on your preferences.

target_type

target_endpoint

response_code

target_type

target_endpoint

response_code

target_type

target_endpoint

The total number of faults for the server application.

For example, the application could be apigee-runtime, apigee-synchronizer, or apigee-udca. Use the pod_name label to filter results by application.

type

The total number of requests received by the server application.

For example, the application could be apigee-runtime, apigee-synchronizer, or apigee-udca. Use the pod_name label to filter results by application.

response_code
type

Total number of responses sent by the server application.

For example, the application could be apigee-runtime, apigee-synchronizer, or apigee-udca. Use the pod_name label to filter results by application.

response_code
type

Latency is the latency in millisecs introduced by the server application.

For example, the application could be apigee-runtime, apigee-synchronizer, or apigee-udca. Use the pod_name label to filter results by application.

type

The number of requests sent by the server application to its upstream application.

For example, for the apigee-synchronizer, the control plane is upstream. So upstream/request_count for apigee-synchronizer is a metric that indicates the requests that apigee-synchronizer made to the control plane.

response_code

type

The number of responses received by the server application from its upstream application.

For example, for the apigee-synchronizer, the control plane is upstream. So upstream/response_count for apigee-synchronizer is a metric that indicates the requests that apigee-synchronizer received from the control plane.

response_code
type

The latency incurred at the upstream server application in milliseconds.

For example, for the apigee-synchronizer, the control plane is upstream. So upstream/latencies for apigee-synchronizer is a metric that indicates the latency from the control plane.

state

The timestamp, in milliseconds since the start of the Unix Epoch, for the oldest file in the dataset.

This is computed every 60 seconds and does not reflect the state in real time. If the UDCA is up to date and there are no files waiting to be uploaded when this metric is computed, then this value will be 0.

If this value keeps increasing, then old files are still on disk.

state

The timestamp, in milliseconds since the start of the Unix Epoch, for the latest file on disk by state.

This is computed every 60 seconds and does not reflect the state in real time. If the UDCA is up to date and there are no files waiting to be uploaded when this metric is computed, then this value will be 0.

state

A count of the number of files on disk in the data collection pod.

Ideally, the value will be close to 0. A consistent high value indicates that files are not being uploaded or that the UDCA is not able to upload them fast enough.

This value is computed every 60 seconds and does not reflect the state of the UDCA in real time.

The time interval, in seconds, between the data file being created and the data file being successfully uploaded.

Buckets will be 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s, and 64s.

Histogram for total latency from file creation time to successful upload time.

The total time, in seconds, that UDCA spent uploading a data file.

Buckets will be 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s, and 64s.

The metrics will display a histogram for total upload latency, including all upstream calls.

dataset

response_code

The total count of HTTP errors that UDCA encountered. This metric is useful to help determine which part of the UDCA external dependencies are failing and for what reason.

These errors can arise for various services (getDataLocation, Cloud storage, Token generator) and for various datasets (such as api and trace) with various response codes.

dataset

The upstream latency of services, in seconds.

Buckets will be 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s, and 64s.

Histogram for latency from upstream services.

The size of the file being uploaded to the Apigee services, in bytes.

Buckets will be 1KB, 10KB, 100KB, 1MB, 10MB, 100MB, and 1GB.

Histogram for file size by dataset, organization and environment.

Note that:

• The event dataset value should keep growing.
• The api dataset value should keep growing if org/env has constant traffic.
• The trace dataset value should increase when you use the Apigee trace tools to debug or inspect your requests.

state

The space occupied by the data files on the data collection pod's disk, in bytes.

An increase in this value over time:

• ready_to_upload implies agent is lagging behind.
• failed implies files are piling up on disk and not being uploaded. This value is computed every 60 seconds.

state

A count of the number of files, by dataset, that UDCA is retrying to upload.

After 3 retries for each file, UDCA moves the file to the /failed subdirectory and removes it from this cache. An increase in this value over time implies that the cache is not being cleared, which happens when files are moved to the /failed subdirectory after 3 retries.

unit