Disabling the Analytics subsystem on VMware

Disable the Analytics subsystem by shutting down the VM that hosts it.

Before you begin

Disabling the Analytics subsystem stops the collection and storage of data as well as making the subsystem unavailable. If you just want to pause data collection without disabling the entire subsystem (for example, while renewing certificates), see Stopping Analytics data collection.

About this task

When you disable Analytics, there will be no data in either the API Manager Dashboards or third-party offloads.

Procedure

Back up your Analytics data as explained in Backing up and restoring the Analytics database on VMware.
Disable shard allocation for storage.

Disabling shard allocation is optional, but is recommended because it prevents new shards from being created for replication when a node is unavailable, and helps avoid corruption issues in full system restarts.
1. Connect to the virtual machine as the API Connect administrator by completing the following steps:
  1. Run the following command to connect as the API Connect administrator, replacing ip_address with the appropriate IP address:
```
ssh ip_address -l apicadm
```
  2. When prompted, select Yes to continue connecting.
  3. When you are connected, run the following command to receive the necessary permissions for working directly on the appliance:
```
sudo -i
```
2. Disable shard allocation for storage by running the following command:
```
kubectl -n namespace exec -it storage-master|shared_pod -- curl_es _cluster/settings -XPUT -d '{"persistent":{"cluster.routing.allocation.enable":"none"}}'
```
  where:
  - namespace is the namespace where the Analytics subsystem is installed.
  - storage-master|shared_pod is the name of any storage-master or storage-shared pod. You can get the name of your storage pods by running the following command and substituting in the namespace where Analytics is installed:
    kubectl -n namespace get po
When you disable shard allocation, the response looks like the following example:
```
{"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"none"}}}},"transient":{}}
```
Leave the connection open for the next step.
Perform a synced flush of storage.
Flushing the storage is optional, but is recommended because it helps to avoid losing the data that was not yet written to disk. This step flushes all current index operations synchronously and attempts to write everything that is in flux to disk. Perform a synced flush of storage by running the following command:
```
kubectl -n namespace exec -it storage-master|shared_pod -- curl_es _flush/synced -XPOST
```
When you flush storage, the response looks like the following example:
```
{"_shards":{"total":33,"successful":13,"failed":0},".export-status":{"total":1,"successful":1,"failed":0},".apic-config":{"total":1,"successful":1,"failed":0},".kibana-6":{"total":1,"successful":1,"failed":0},"apic-api-2020.06.19-000002":{"total":15,"successful":5,"failed":0},"apic-api-2020.06.18-1":{"total":15,"successful":5,"failed":0}}
```
The operation often fails, and it is safe to rerun it multiple times until it passes and there are all "failed" counts are zero. If it continues to fail after running multiple attempts over the span of a couple minutes, you can proceed to the next step.
Shut down the Analytics VMs.
You can shut down the VMs using one of the following methods:
- Use the VMware console
- ssh into the images and run the shutdown command