Creating a script to count API calls

Optionally create a script containing a query that counts the API calls for the IBM® API Connect Analytics subsystem.

Before you begin

Create a query to count the total number of API calls in the Analytics subsystem as explained in Counting total API calls for your Analytics service.

About this task

If you need to count your API calls to track the totals for your contract, then you must run the query to count API calls on a periodic basis. You can automate the process by creating a script that contains the query. To ensure you correctly track the API calls, schedule the script to run on a daily basis and store the accumulated daily totals where you can make sure they are backed up.

The example script includes the following changes to the original query. The changes make it easier to run the script repeatedly without editing it each time.

  • Accept the namespace and release name of the analytics service as input.

    If you only deployed one release in the namespace, then you can leave the release name blank. For appliance deployments, use default as the value of the namespace, and leave the release name blank.

  • Identify the analytics-storage pod automatically and saves it in the POD variable to be used by your query.
  • Change the query's time range variables from ISO format to date math syntax so that you can run the script again without editing the time range.

    You should run the script at the same time every day to ensure consistent counts. Using date math, you can use variables to calculate yesterday's date and today's date. Then, your script can use those dates to retrieve the total number of calls for the 24 hours that elapsed between the beginning of yesterday and the beginning of today.

    • Set the start date (gte) to the value now-1d/d, which represents the beginning of yesterday.
    • Set the end date (lt) to now/d, which represents the beginning of today.
    Note: Remember, the values for the time range variables are calculated from the current system time of the analytics-storage pod, which follows UTC time (Coordinated Universal Time). It's important to allow for any time difference when you run a query because your timing might cause an inadvertent date change for the results.

    For example, if today is January 2 in EST and your current time is 5:00 AM (2019-01-02T05:00:00), then the system time on the analytics-storage pod (in UTC) is 10:00 AM on January 2 (2019-01-02T10:00:00). The date math calculation for yesterday (now-1d/d) is equal to 2019-01-01T00:00:00, and the date math calculation for today (now/d) is equal to 2019-01-02T00:00:00. The query captures the API call counts for "yesterday", which is the 24 hours of the date 2019-01-01T00:00:00. But if your current time in EST is 8:00 PM on January 2, the time on the system time on the analytics-storage pod is 1:00 AM on January 3. "Yesterday" is now January 2 and "today" is now January 3, so the query returns the call count for January 2 instead of January 1.

Procedure

  1. Create the script.

    The following example shows the completed script. In the script, the kubectl exec statement must be on a single line.

    #!/bin/bash
      
    NAMESPACE=$1
    RELEASE_NAME=$2
    
    POD=`kubectl get po -n $NAMESPACE -o custom-columns=NAME:.metadata.name | grep -e "storage-master-0" | head -n 1`
    
    kubectl exec -it $POD  -n $NAMESPACE -- curl_es /apic-api-r/_search?pretty -H 'Content-Type: application/json' -d '{ "size": 0, "query": { "range": { "datetime": { "gte": "now-1d/d", "lt": "now/d" } } }, "aggs": { "status_codes": { "filters": { "filters": { "1xx": { "regexp": { "status_code": "1." } }, "2xx": { "regexp": { "status_code": "2." } }, "3xx": { "regexp": { "status_code": "3." } }, "4xx": { "regexp": { "status_code": "4." } }, "5xx":{ "regexp": { "status_code": "5.*" } } } } } } }'
  2. Save the file and make it executable, as shown in the following example.
    chmod +x path/to/my-script-filename.sh
  3. Run the script.

    Invoke it with your namespace and release name as shown in the following example:

    ./my-script-filename.sh namespace release_name

    Remember, you can omit the release name if it's not needed, as shown in the following example:

    .:count.sh apic

    For appliance deployments, you can use default as the namespace and omit the release name as shown in the following example:

    ./my-script-filename.sh default