Console
    Contact Us Start free

    Using the Diagnostic collector

    The Diagnostic collector is a tool that captures diagnostic data on the Kubernetes components of an Apigee hybrid instance on demand, and stores them in Google Cloud storage buckets. You invoke the Diagnostic collector with the apigeectl diagnostic command.

    What System data is captured?

    Diagnostics collector captures following types of data:

    • Changing Log levels.
    • Jstack.
    • POD configuration yaml.
    • PS -ef output.
    • TCP dump.
    • TOP output.

    What happens to the data?

    When the Diagnostic collector captures the data, it is uploaded to a storage bucket in your Google Cloud project. You can view the stored data in the Google Cloud Platform: Cloud Storage browser .

    You can optionally choose to share this data with Google Apigee Support when you create a support ticket.

    Prerequisites for running Diagnostic collector

    Before using the Diagnostic collector, you must complete the following prerequisites:

    Google Cloud Storage bucket

    Create a Google Cloud Storage bucket with a unique name in your Google Cloud project. You can create and manage buckets with gcloud storage commands or in the Google Cloud Platform: Cloud Storage browser .

    For example:

    gcloud storage buckets create gs:// apigee_diagnostic_data 

    Creating gs://apigee_diagnostic_data/...

    See Creating storage buckets for instructions.

    Create a service account with the Storage Admin role ( roles/storage.admin ) in your project, and download the service account .json key file.

    The service account can have any unique name. This guide uses " apigee-diagnostic " for the service account name.

    For example:

    gcloud config set project ${PROJECT_ID} 

    gcloud iam service-accounts create apigee-diagnostic 

    gcloud projects add-iam-policy-binding ${PROJECT_ID} 
\
    --member="serviceAccount: apigee-diagnostic 
@ ${PROJECT_ID} 
.iam.gserviceaccount.com" \
    --role="roles/storage.admin"
     
    gcloud iam service-accounts keys create ${PROJECT_ID} 
- apigee-diagnostic 
.json \
    --iam-account= apigee-diagnostic 
@ ${PROJECT_ID} 
.iam.gserviceaccount.com

    See:

    Using Diagnostic collector

    The sequence to use the Diagnostic collector is:

    1. Configure the Diagnostic stanza in your overrides.yaml file to select the type of information, the Apigee container, and the individual pods you want diagnostic data from. See Configuring overrides.yaml for Diagnostic collector .
    2. Run Diagnostic collector with the following apigeectl command. 
      apigeectl diagnostic -f OVERRIDES_FILE

      Where OVERRIDES_FILE is the path to your overrides.yaml file.

    3. Check the logs:
      1. Get the pods in the apigee-diagnostic namespace. 
        kubectl get pods -n apigee-diagnostic
      2. Make note of the pod with the name containing diagnostic-collector
      3. Check the logs with the following command: 
        kubectl -n apigee-diagnostic logs -f POD_NAME

        Where POD_NAME is the name of the Diagnostic collector pod.

        You can also view the collected logs in the Google Cloud Platform: Cloud Storage browser .

    4. After you have collected the data, delete the Diagnostic collector. You cannot run it again until you have deleted it. 
      apigeectl diagnostic delete -f OVERRIDES_FILE

    Configuring overrides.yaml for Diagnostic collector

    Before you can run the Diagnostic collector, you need to configure it in your overrides.yaml file.

    For a complete reference of diagnostic configuration properties, see the Configuration property reference: diagnostic .

    Required properties

    The following properties are required for the Diagnostic collector to run.

    • diagnostic.serviceAccountPath : The path to a service account key file for the service account with the Storage Admin role in Prerequisites .
    • diagnostic.operation : Specifies whether to collect all statistics or just logs.

      Values are: "ALL" or "LOGGING"

      If you set diagnostic.operation to "LOGGING" , the following properties are required:

    • diagnostic.bucket : The name of the Google Cloud storage bucket where your diagnostic data will be deposited. This is the bucket you created in Prerequisites .
    • diagnostic.container : This specifies which type of pod you are capturing data from. The values can be one of:
      container value Apigee component Kubernetes namespace Example pod name in this container
      apigee-cassandra
      		Cassandra apigee apigee-cassandra-default-0
      istio-proxy
      		Istio ingress istio-system istio-ingressgateway-696879cdf8-9zzzf
      apigee-mart-server
      		MART apigee apigee-mart-hybrid-example-d89fed1-151-jj2ux-l7nlb
      apigee-runtime
      		Message Processor apigee apigee-runtime-hybrid-example-3b2ebf3-151-s64bh-g9qmv
      apigee-synchronizer
      		Synchronizer apigee apigee-synchronizer-hybrid-example-3b2ebf3-151-xx4z6cg78
      apigee-udca
      		UDCA apigee apigee-udca-hybrid-example-3b2ebf3-151-q4g2c-vnzg9
      apigee-watcher
      		Watcher apigee apigee-watcher-hybrid-example-d89fed1-151-cpu3s-sxxdf
    • diagnostic.namespace : The Kubernetes namespace in which the pods you are collecting data on reside. The namespace must be the correct one for the container you specify with diagnostic.container .
    • diagnostic.podNames : The names of the individual pods on which you want to collect diagnostic data. For example: 
       diagnostic 
 : 
  
…  
 podNames 
 : 
  
 - 
  
 apigee 
 - 
 runtime 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 8 
 vfoj 
 - 
 2 
 wcjn 
  
 - 
  
 apigee 
 - 
 runtime 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 8 
 vfoj 
 - 
 6 
 xzn2

    Properties required only when the operation is set to LOGGING

    The following properties are required only when running Diagnostic collector with diagnostic.operation is LOGGING .

    • diagnostic.loggerNames : Specifies by name which loggers to collect data from. For Apigee hybrid version 1.6.0, the only value supported is ALL , meaning all loggers. For example: 
       diagnostic 
 : 
  
…  
 loggingDetails 
 : 
  
 loggerNames 
 : 
  
 - 
  
 ALL
    • diagnostic.logLevel : Specifies the granularity of the logging data to collect. In Apigee hybrid 1.6, Only FINE is supported.
    • diagnostic.logDuration : The duration in milliseconds of the log data collected. A typical value is 30000 .

    Optional properties

    The following properties are optional.

    • diagnostic.tcpDumpDetails.maxMsgs : Sets the maximum number of tcpDump messages to collect. Apigee recommends a maximum value no greater than 1000 .
    • diagnostic.tcpDumpDetails.timeoutInSeconds : Sets the amount of time in seconds to wait for tcpDump to return messages.
    • diagnostic.threadDumpDetails.delayInSeconds : The delay in seconds between collecting each thread dump. Must be used with diagnostic.threadDumpDetails.iterations .
    • diagnostic.threadDumpDetails.iterations : The number of jstack thread dump iterations to collect. Must be used with diagnostic.threadDumpDetails.delayInSeconds .

    General example

    The following is an example diagnostic stanza showing all possible entries:

    diagnostic:
  # required properties:
  serviceAccountPath: "service-accounts/apigee-diagnostics.json"
  operation: "ALL"
  bucket: "diagnostics_data"
  container: "apigee-runtime"
  namespace: "apigee"
  podNames: - 
apigee-runtime-hybrid-example-3b2ebf3-150-8vfoj-2wcjn - 
apigee-runtime-hybrid-example-3b2ebf3-150-8vfoj-6xzn2

  # required if operation is Logging
  loggingDetails:
    loggerNames: - 
ALL
    logLevel: FINE
    logDuration: 30000

  # optional properties:
  tcpDumpDetails:
    maxMsgs: 10
    timeoutInSeconds: 100

  threadDumpDetails:
    iterations: 5
    delayInSeconds: 2

    Common use cases

    The following examples show how to configure and use Diagnostic collector in some common situations.

    High Proxy Latency

    In this case Apigee-runtime is taking a long time to process requests, causing customers to see high proxy latencies. You need to collect Jstack and TOP output.

    1. Select any 2 runtime pods.
    2. Create your diagnostic stanza with the following structure: 
       diagnostic 
 : 
  
 serviceAccountPath 
 : 
  
 "service-accounts/apigee-diagnostics.json" 
  
 operation 
 : 
  
 "ALL" 
  
 bucket 
 : 
  
 "diagnostics_data" 
  
 container 
 : 
  
 "apigee-runtime" 
  
 namespace 
 : 
  
 "apigee" 
  
 podNames 
 : 
  
 - 
  
 apigee 
 - 
 runtime 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 8 
 vfoj 
 - 
 2 
 wcjn 
  
 - 
  
 apigee 
 - 
 runtime 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 8 
 vfoj 
 - 
 6 
 xzn2 
  
 tcpDumpDetails 
 : 
  
 maxMsgs 
 : 
  
 10 
  
 threadDumpDetails 
 : 
  
 iterations 
 : 
  
 15 
  
 delayInSeconds 
 : 
  
 1
    3. After configuring the diagnostic stanza, run the Diagnostic collector. 
      apigeectl diagnostic -f OVERRIDES_FILE
    4. Collect the logs and delete the Diagnostic collector. 
      apigeectl diagnostic delete -f OVERRIDES_FILE

    Network / connectivity problems

    You need to run diagnostics on apigee-runtime as well as ingress gateway pods.

    1. Select any 2 runtime pods.
    2. Create your diagnostic stanza with the following structure: 
       diagnostic 
 : 
  
 serviceAccountPath 
 : 
  
 "service-accounts/apigee-diagnostics.json" 
  
 operation 
 : 
  
 "ALL" 
  
 bucket 
 : 
  
 "diagnostics_data" 
  
 container 
 : 
  
 "apigee-runtime" 
  
 namespace 
 : 
  
 "apigee" 
  
 podNames 
 : 
  
 - 
  
 apigee 
 - 
 runtime 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 8 
 vfoj 
 - 
 2 
 wcjn 
  
 - 
  
 apigee 
 - 
 runtime 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 8 
 vfoj 
 - 
 6 
 xzn2 
  
 tcpDumpDetails 
 : 
  
 maxMsgs 
 : 
  
 1000
    3. After configuring the diagnostic stanza, run the Diagnostic collector. 
      apigeectl diagnostic -f OVERRIDES_FILE
    4. Collect the logs and delete the Diagnostic collector. 
      apigeectl diagnostic delete -f OVERRIDES_FILE
    5. Select two pods from the Istio ingress gateway.
    6. Reconfigure your diagnostic stanza with the Istio ingress pods: 
       diagnostic 
 : 
  
 serviceAccountPath 
 : 
  
 "service-accounts/apigee-diagnostics.json" 
  
 operation 
 : 
  
 "ALL" 
  
 bucket 
 : 
  
 "diagnostics_data" 
  
 container 
 : 
  
 "istio-proxy" 
  
 namespace 
 : 
  
 "istio-system" 
  
 podNames 
 : 
  
 - 
  
 istio 
 - 
 ingressgateway 
 - 
 696879 
 cdf8 
 - 
 9 
 zzzf 
  
 - 
  
 istio 
 - 
 ingressgateway 
 - 
 696879 
 cdf8 
 - 
 6 
 abc7 
  
 tcpDumpDetails 
 : 
  
 maxMsgs 
 : 
  
 1000
    7. After configuring the diagnostic stanza, run the Diagnostic collector. 
      apigeectl diagnostic -f OVERRIDES_FILE
    8. Collect the logs and delete the Diagnostic collector. 
      apigeectl diagnostic delete -f OVERRIDES_FILE

    Proxies are throwing unexpected errors or new contracts are not getting applied

    In this case you need to change log levels to debug for at least 5 minutes, or even 10 minutes as in this example. This will increase the amount of logs but helpful information will be logged. You will run Diagnostic collector twice, once on Apigee runtime then on Apigee synchronizer.

    1. Select any 2 runtime pods.
    2. Create your diagnostic stanza with the following structure: 
       diagnostic 
 : 
  
 serviceAccountPath 
 : 
  
 "service-accounts/apigee-diagnostics.json" 
  
 operation 
 : 
  
 "LOGGING" 
  
 bucket 
 : 
  
 "diagnostics_data" 
  
 namespace 
 : 
  
 "apigee" 
  
 container 
 : 
  
 "apigee-runtime" 
  
 podNames 
 : 
  
 - 
  
 apigee 
 - 
 runtime 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 8 
 vfoj 
 - 
 2 
 wcjn 
  
 - 
  
 apigee 
 - 
 runtime 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 8 
 vfoj 
 - 
 6 
 xzn2 
  
 loggingDetails 
 : 
  
 loggerNames 
 : 
  
 - 
  
 ALL 
  
 logLevel 
 : 
  
 FINE 
  
 logDuration 
 : 
  
 60000
    3. After configuring the diagnostic stanza, run the Diagnostic collector. 
      apigeectl diagnostic -f OVERRIDES_FILE
    4. Collect the logs and delete the Diagnostic collector. 
      apigeectl diagnostic delete -f OVERRIDES_FILE
    5. Select any 2 synchronizer pods.
    6. Create your diagnostic stanza with the following structure: 
       diagnostic 
 : 
  
 serviceAccountPath 
 : 
  
 "service-accounts/apigee-diagnostics.json" 
  
 operation 
 : 
  
 "LOGGING" 
  
 bucket 
 : 
  
 "diagnostics_data" 
  
 namespace 
 : 
  
 "apigee" 
  
 container 
 : 
  
 "apigee-synchronizer" 
  
 podNames 
 : 
  
 - 
  
 apigee 
 - 
 synchronizer 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 xx4z 
 - 
 6 
 cg78 
  
 - 
  
 apigee 
 - 
 synchronizer 
 - 
 hybrid 
 - 
 example 
 - 
 3 
 b2ebf3 
 - 
 150 
 - 
 xx4z 
 - 
 1 
 a2b3 
  
 loggingDetails 
 : 
  
 loggerNames 
 : 
  
 - 
  
 ALL 
  
 logLevel 
 : 
  
 FINE 
  
 logDuration 
 : 
  
 60000
    7. After configuring the diagnostic stanza, run the Diagnostic collector. 
      apigeectl diagnostic -f OVERRIDES_FILE
    8. Collect the logs and delete the Diagnostic collector. 
      apigeectl diagnostic delete -f OVERRIDES_FILE
    Design a Mobile Site
    View Site in Mobile | Classic
    Share by: