Hi 

Would like to seek advise on some questions regarding APIC analytics data. We are currently using APIC 10.0.5 and deployed on-premises using OVA file. 

Question 1:

Understand that retaining analytics data for more than 3 months (for 3 replica deployment) will impact APIC performance. Would like to check that is it only impacting Analytics subsystem performance, or it will impact both Analytics and Gateway subsystems?

Question 2:

If analytics data offload to third party system, does IBM accept to use log from third party system to troubleshoot the issue if the issue happened in APIC 3 months ago and the log already offloaded to third party system and deleted from APIC Analytics subsystem?

Question 3: 

 If we performing some testing in APIC in DR data center, how to delete unwanted analytics data after the testing done?

Question 4:

I saw from IBM documentation (see below) that summary analytics data that is created from API event records is retained for 1 year. This documentation is for APIC 10.0.x. Is this statement still valid for APIC 10.0.5.x? Is it possible to share what information is included in summary analytics data?

https://www.ibm.com/docs/en/api-connect/10.0.x?topic=usage-key-concepts-api-connect-analytics

Thank you. 

Hiya

1. The more analytics data you keep the more analytics resources you need - both memory, nodes and storage. It does not directly affect other subsystems like the gateway, but if analytics runs out of memory or disk space (the low watermark is 70% - after which you will start to see bad effects), then analytics can be offline which means the gateway will discard api event information (the events will still be processed by the gateway but there will be no record of them).
2. I am not sure what scenario you are imagining here. Analytics simply records that an event happened, it doesn't contain debugging information - you're more likely to want gateway logs for that. But yes, if evidence of a specific transaction happening months ago was needed I can't see why information from an offloaded system wouldn't be accepted. This feels a very artificial scenario though.
3. You can delete the analytics subsystem (wipe the PVCs) and redeploy it? You can wait until the following day and then delete the previous day's index via the analytics clustermgmt API? but generally speaking analytics is not a system you can delete select data from. It is not a relational database. Once events are written to it they cannot be individually deleted or updated. They are removed by the retention policy once they have aged out.
4. No, the new CD releases will obviously have new features in them that do not apply to previous releases - if they did then the docs would be in the previous versions too! That functionality is only in 10.0.6+. Always make sure you are looking at the documentation for the version you are actually using. Long term summary information is for long term trend analysis. It records that a specific application made a call to a specific operation/path on an api/product and what response code it got. It does not include headers, payloads, latency information or anything like that. It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act.
   Roughly speaking 10 months' worth of summary data needs the same resources as 1 month's api event data (at activity+headers log level).

If you are looking at storing considerable amounts of analytics data, either at long retention or high TPS then I would very strongly advise using the containers based form factors of APIC (kubernetes or openshift). We allow horizontal scaling on those form factors using dedicated storage so you can scale up to have lots of analytics data nodes which works very nicely (e.g. we have customers with 20+ analytics data nodes). That is not possible on OVAs which are limited to either 1 or 3 nodes.

Hope that helps!

Chris

Hi 

Would like to seek advise on some questions regarding APIC analytics data. We are currently using APIC 10.0.5 and deployed on-premises using OVA file. 

Question 1:

Understand that retaining analytics data for more than 3 months (for 3 replica deployment) will impact APIC performance. Would like to check that is it only impacting Analytics subsystem performance, or it will impact both Analytics and Gateway subsystems?

Question 2:

If analytics data offload to third party system, does IBM accept to use log from third party system to troubleshoot the issue if the issue happened in APIC 3 months ago and the log already offloaded to third party system and deleted from APIC Analytics subsystem?

Question 3: 

 If we performing some testing in APIC in DR data center, how to delete unwanted analytics data after the testing done?

Question 4:

I saw from IBM documentation (see below) that summary analytics data that is created from API event records is retained for 1 year. This documentation is for APIC 10.0.x. Is this statement still valid for APIC 10.0.5.x? Is it possible to share what information is included in summary analytics data?

https://www.ibm.com/docs/en/api-connect/10.0.x?topic=usage-key-concepts-api-connect-analytics

Thank you. 

Hi Chris,

Yes, it is helpful. 

Just further clarifications for your reply regarding my question 3 and 4.

3. We cannot delete the analytics subsystem (wipe the PVCs) and redeploy it. However I think we can wait until the following day and then delete the previous day's index via the analytics clustermgmt API. Could you share me some documentation how to use analytics clustermgmt API to do it?

I remember from somewhere I saw or I was advised that analytics data is stored in database. It is not stored in relational database? 

4. "It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act."

[Guo Jun] yes, that is what customer wants to see. They want to see one year API usage instead of specific payload, headers or latency information. So for APIC 10.0.5.x_lts OVA deployment, does it have two different retention policies?   

Hiya

1. The more analytics data you keep the more analytics resources you need - both memory, nodes and storage. It does not directly affect other subsystems like the gateway, but if analytics runs out of memory or disk space (the low watermark is 70% - after which you will start to see bad effects), then analytics can be offline which means the gateway will discard api event information (the events will still be processed by the gateway but there will be no record of them).
2. I am not sure what scenario you are imagining here. Analytics simply records that an event happened, it doesn't contain debugging information - you're more likely to want gateway logs for that. But yes, if evidence of a specific transaction happening months ago was needed I can't see why information from an offloaded system wouldn't be accepted. This feels a very artificial scenario though.
3. You can delete the analytics subsystem (wipe the PVCs) and redeploy it? You can wait until the following day and then delete the previous day's index via the analytics clustermgmt API? but generally speaking analytics is not a system you can delete select data from. It is not a relational database. Once events are written to it they cannot be individually deleted or updated. They are removed by the retention policy once they have aged out.
4. No, the new CD releases will obviously have new features in them that do not apply to previous releases - if they did then the docs would be in the previous versions too! That functionality is only in 10.0.6+. Always make sure you are looking at the documentation for the version you are actually using. Long term summary information is for long term trend analysis. It records that a specific application made a call to a specific operation/path on an api/product and what response code it got. It does not include headers, payloads, latency information or anything like that. It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act.
   Roughly speaking 10 months' worth of summary data needs the same resources as 1 month's api event data (at activity+headers log level).

If you are looking at storing considerable amounts of analytics data, either at long retention or high TPS then I would very strongly advise using the containers based form factors of APIC (kubernetes or openshift). We allow horizontal scaling on those form factors using dedicated storage so you can scale up to have lots of analytics data nodes which works very nicely (e.g. we have customers with 20+ analytics data nodes). That is not possible on OVAs which are limited to either 1 or 3 nodes.

Hope that helps!

Chris

Hi 

Would like to seek advise on some questions regarding APIC analytics data. We are currently using APIC 10.0.5 and deployed on-premises using OVA file. 

Question 1:

Understand that retaining analytics data for more than 3 months (for 3 replica deployment) will impact APIC performance. Would like to check that is it only impacting Analytics subsystem performance, or it will impact both Analytics and Gateway subsystems?

Question 2:

If analytics data offload to third party system, does IBM accept to use log from third party system to troubleshoot the issue if the issue happened in APIC 3 months ago and the log already offloaded to third party system and deleted from APIC Analytics subsystem?

Question 3: 

 If we performing some testing in APIC in DR data center, how to delete unwanted analytics data after the testing done?

Question 4:

I saw from IBM documentation (see below) that summary analytics data that is created from API event records is retained for 1 year. This documentation is for APIC 10.0.x. Is this statement still valid for APIC 10.0.5.x? Is it possible to share what information is included in summary analytics data?

https://www.ibm.com/docs/en/api-connect/10.0.x?topic=usage-key-concepts-api-connect-analytics

Thank you. 

Here is the API doc for the delete index clustermgmt operation: https://apic-api.apiconnect.ibmcloud.com/v10/10.0.5.LATEST.html#/IBMAPIConnectAnalyticsAPI_200/operation/%2F{analytics-service}%2Fcloud%2Fclustermgmt%2Fstorage%2F{index}/delete

There is an equivalent apic CLI command too.
Make sure you DO NOT delete the most recent index or you will get into a world of trouble. (Thats why need to wait for the next day)

The data is stored in a database but its not a relational database, its opensearch (and you have no direct access to it - only via our API).

No I thought I made it clear 10.0.5 will never get new CD features backported to it. The idea of long term summary data is introduced in 10.0.6+ it will never be possible in 10.0.5.

I think it is very unlikely you will be able to keep a year's worth of api event data on an OVA deployment, especially with payload logging as well. You will need to offload or upgrade to APIC 10.0.7 - but thats a CD release not LTS. There will be a new LTS release (10.0.8) at the end of Q2 this year and that will include all the capabilities of 10.0.7 plus more - so you could plan for an upgrade to that in Q3 this year which will then allow you to benefit from long term summary data.

From an analytics point of view I would recommend looking at migration to containers instead of OVAs too - they scale so much better.

Hi Chris,

Yes, it is helpful. 

Just further clarifications for your reply regarding my question 3 and 4.

3. We cannot delete the analytics subsystem (wipe the PVCs) and redeploy it. However I think we can wait until the following day and then delete the previous day's index via the analytics clustermgmt API. Could you share me some documentation how to use analytics clustermgmt API to do it?

I remember from somewhere I saw or I was advised that analytics data is stored in database. It is not stored in relational database? 

4. "It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act."

[Guo Jun] yes, that is what customer wants to see. They want to see one year API usage instead of specific payload, headers or latency information. So for APIC 10.0.5.x_lts OVA deployment, does it have two different retention policies?   

Hiya

1. The more analytics data you keep the more analytics resources you need - both memory, nodes and storage. It does not directly affect other subsystems like the gateway, but if analytics runs out of memory or disk space (the low watermark is 70% - after which you will start to see bad effects), then analytics can be offline which means the gateway will discard api event information (the events will still be processed by the gateway but there will be no record of them).
2. I am not sure what scenario you are imagining here. Analytics simply records that an event happened, it doesn't contain debugging information - you're more likely to want gateway logs for that. But yes, if evidence of a specific transaction happening months ago was needed I can't see why information from an offloaded system wouldn't be accepted. This feels a very artificial scenario though.
3. You can delete the analytics subsystem (wipe the PVCs) and redeploy it? You can wait until the following day and then delete the previous day's index via the analytics clustermgmt API? but generally speaking analytics is not a system you can delete select data from. It is not a relational database. Once events are written to it they cannot be individually deleted or updated. They are removed by the retention policy once they have aged out.
4. No, the new CD releases will obviously have new features in them that do not apply to previous releases - if they did then the docs would be in the previous versions too! That functionality is only in 10.0.6+. Always make sure you are looking at the documentation for the version you are actually using. Long term summary information is for long term trend analysis. It records that a specific application made a call to a specific operation/path on an api/product and what response code it got. It does not include headers, payloads, latency information or anything like that. It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act.
   Roughly speaking 10 months' worth of summary data needs the same resources as 1 month's api event data (at activity+headers log level).

If you are looking at storing considerable amounts of analytics data, either at long retention or high TPS then I would very strongly advise using the containers based form factors of APIC (kubernetes or openshift). We allow horizontal scaling on those form factors using dedicated storage so you can scale up to have lots of analytics data nodes which works very nicely (e.g. we have customers with 20+ analytics data nodes). That is not possible on OVAs which are limited to either 1 or 3 nodes.

Hope that helps!

Chris

Hi 

Would like to seek advise on some questions regarding APIC analytics data. We are currently using APIC 10.0.5 and deployed on-premises using OVA file. 

Question 1:

Understand that retaining analytics data for more than 3 months (for 3 replica deployment) will impact APIC performance. Would like to check that is it only impacting Analytics subsystem performance, or it will impact both Analytics and Gateway subsystems?

Question 2:

If analytics data offload to third party system, does IBM accept to use log from third party system to troubleshoot the issue if the issue happened in APIC 3 months ago and the log already offloaded to third party system and deleted from APIC Analytics subsystem?

Question 3: 

 If we performing some testing in APIC in DR data center, how to delete unwanted analytics data after the testing done?

Question 4:

I saw from IBM documentation (see below) that summary analytics data that is created from API event records is retained for 1 year. This documentation is for APIC 10.0.x. Is this statement still valid for APIC 10.0.5.x? Is it possible to share what information is included in summary analytics data?

https://www.ibm.com/docs/en/api-connect/10.0.x?topic=usage-key-concepts-api-connect-analytics

Thank you. 

Here is the API doc for the delete index clustermgmt operation: https://apic-api.apiconnect.ibmcloud.com/v10/10.0.5.LATEST.html#/IBMAPIConnectAnalyticsAPI_200/operation/%2F{analytics-service}%2Fcloud%2Fclustermgmt%2Fstorage%2F{index}/delete

There is an equivalent apic CLI command too.
Make sure you DO NOT delete the most recent index or you will get into a world of trouble. (Thats why need to wait for the next day)

The data is stored in a database but its not a relational database, its opensearch (and you have no direct access to it - only via our API).

No I thought I made it clear 10.0.5 will never get new CD features backported to it. The idea of long term summary data is introduced in 10.0.6+ it will never be possible in 10.0.5.

I think it is very unlikely you will be able to keep a year's worth of api event data on an OVA deployment, especially with payload logging as well. You will need to offload or upgrade to APIC 10.0.7 - but thats a CD release not LTS. There will be a new LTS release (10.0.8) at the end of Q2 this year and that will include all the capabilities of 10.0.7 plus more - so you could plan for an upgrade to that in Q3 this year which will then allow you to benefit from long term summary data.

From an analytics point of view I would recommend looking at migration to containers instead of OVAs too - they scale so much better.

Hi Chris,

Yes, it is helpful. 

Just further clarifications for your reply regarding my question 3 and 4.

3. We cannot delete the analytics subsystem (wipe the PVCs) and redeploy it. However I think we can wait until the following day and then delete the previous day's index via the analytics clustermgmt API. Could you share me some documentation how to use analytics clustermgmt API to do it?

I remember from somewhere I saw or I was advised that analytics data is stored in database. It is not stored in relational database? 

4. "It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act."

[Guo Jun] yes, that is what customer wants to see. They want to see one year API usage instead of specific payload, headers or latency information. So for APIC 10.0.5.x_lts OVA deployment, does it have two different retention policies?   

Hiya

1. The more analytics data you keep the more analytics resources you need - both memory, nodes and storage. It does not directly affect other subsystems like the gateway, but if analytics runs out of memory or disk space (the low watermark is 70% - after which you will start to see bad effects), then analytics can be offline which means the gateway will discard api event information (the events will still be processed by the gateway but there will be no record of them).
2. I am not sure what scenario you are imagining here. Analytics simply records that an event happened, it doesn't contain debugging information - you're more likely to want gateway logs for that. But yes, if evidence of a specific transaction happening months ago was needed I can't see why information from an offloaded system wouldn't be accepted. This feels a very artificial scenario though.
3. You can delete the analytics subsystem (wipe the PVCs) and redeploy it? You can wait until the following day and then delete the previous day's index via the analytics clustermgmt API? but generally speaking analytics is not a system you can delete select data from. It is not a relational database. Once events are written to it they cannot be individually deleted or updated. They are removed by the retention policy once they have aged out.
4. No, the new CD releases will obviously have new features in them that do not apply to previous releases - if they did then the docs would be in the previous versions too! That functionality is only in 10.0.6+. Always make sure you are looking at the documentation for the version you are actually using. Long term summary information is for long term trend analysis. It records that a specific application made a call to a specific operation/path on an api/product and what response code it got. It does not include headers, payloads, latency information or anything like that. It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act.
   Roughly speaking 10 months' worth of summary data needs the same resources as 1 month's api event data (at activity+headers log level).

If you are looking at storing considerable amounts of analytics data, either at long retention or high TPS then I would very strongly advise using the containers based form factors of APIC (kubernetes or openshift). We allow horizontal scaling on those form factors using dedicated storage so you can scale up to have lots of analytics data nodes which works very nicely (e.g. we have customers with 20+ analytics data nodes). That is not possible on OVAs which are limited to either 1 or 3 nodes.

Hope that helps!

Chris

Hi 

Would like to seek advise on some questions regarding APIC analytics data. We are currently using APIC 10.0.5 and deployed on-premises using OVA file. 

Question 1:

Understand that retaining analytics data for more than 3 months (for 3 replica deployment) will impact APIC performance. Would like to check that is it only impacting Analytics subsystem performance, or it will impact both Analytics and Gateway subsystems?

Question 2:

If analytics data offload to third party system, does IBM accept to use log from third party system to troubleshoot the issue if the issue happened in APIC 3 months ago and the log already offloaded to third party system and deleted from APIC Analytics subsystem?

Question 3: 

 If we performing some testing in APIC in DR data center, how to delete unwanted analytics data after the testing done?

Question 4:

I saw from IBM documentation (see below) that summary analytics data that is created from API event records is retained for 1 year. This documentation is for APIC 10.0.x. Is this statement still valid for APIC 10.0.5.x? Is it possible to share what information is included in summary analytics data?

https://www.ibm.com/docs/en/api-connect/10.0.x?topic=usage-key-concepts-api-connect-analytics

Thank you. 

Hi Chris,

As we discussed previously that we can below API to delete analytics data. Just a further question, can we delete the analytics data based on the specified date? For example, I want to delete analytics data that generated between 3rd July 2024 to 26th July 2024? 

https://apic-api.apiconnect.ibmcloud.com/v10/10.0.5.LATEST.html#/IBMAPIConnectAnalyticsAPI_200/operation/%2F{analytics-service}%2Fcloud%2Fclustermgmt%2Fstorage%2F{index}/delete

Here is the API doc for the delete index clustermgmt operation: https://apic-api.apiconnect.ibmcloud.com/v10/10.0.5.LATEST.html#/IBMAPIConnectAnalyticsAPI_200/operation/%2F{analytics-service}%2Fcloud%2Fclustermgmt%2Fstorage%2F{index}/delete

There is an equivalent apic CLI command too.
Make sure you DO NOT delete the most recent index or you will get into a world of trouble. (Thats why need to wait for the next day)

The data is stored in a database but its not a relational database, its opensearch (and you have no direct access to it - only via our API).

No I thought I made it clear 10.0.5 will never get new CD features backported to it. The idea of long term summary data is introduced in 10.0.6+ it will never be possible in 10.0.5.

I think it is very unlikely you will be able to keep a year's worth of api event data on an OVA deployment, especially with payload logging as well. You will need to offload or upgrade to APIC 10.0.7 - but thats a CD release not LTS. There will be a new LTS release (10.0.8) at the end of Q2 this year and that will include all the capabilities of 10.0.7 plus more - so you could plan for an upgrade to that in Q3 this year which will then allow you to benefit from long term summary data.

From an analytics point of view I would recommend looking at migration to containers instead of OVAs too - they scale so much better.

Hi Chris,

Yes, it is helpful. 

Just further clarifications for your reply regarding my question 3 and 4.

3. We cannot delete the analytics subsystem (wipe the PVCs) and redeploy it. However I think we can wait until the following day and then delete the previous day's index via the analytics clustermgmt API. Could you share me some documentation how to use analytics clustermgmt API to do it?

I remember from somewhere I saw or I was advised that analytics data is stored in database. It is not stored in relational database? 

4. "It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act."

[Guo Jun] yes, that is what customer wants to see. They want to see one year API usage instead of specific payload, headers or latency information. So for APIC 10.0.5.x_lts OVA deployment, does it have two different retention policies?   

Hiya

1. The more analytics data you keep the more analytics resources you need - both memory, nodes and storage. It does not directly affect other subsystems like the gateway, but if analytics runs out of memory or disk space (the low watermark is 70% - after which you will start to see bad effects), then analytics can be offline which means the gateway will discard api event information (the events will still be processed by the gateway but there will be no record of them).
2. I am not sure what scenario you are imagining here. Analytics simply records that an event happened, it doesn't contain debugging information - you're more likely to want gateway logs for that. But yes, if evidence of a specific transaction happening months ago was needed I can't see why information from an offloaded system wouldn't be accepted. This feels a very artificial scenario though.
3. You can delete the analytics subsystem (wipe the PVCs) and redeploy it? You can wait until the following day and then delete the previous day's index via the analytics clustermgmt API? but generally speaking analytics is not a system you can delete select data from. It is not a relational database. Once events are written to it they cannot be individually deleted or updated. They are removed by the retention policy once they have aged out.
4. No, the new CD releases will obviously have new features in them that do not apply to previous releases - if they did then the docs would be in the previous versions too! That functionality is only in 10.0.6+. Always make sure you are looking at the documentation for the version you are actually using. Long term summary information is for long term trend analysis. It records that a specific application made a call to a specific operation/path on an api/product and what response code it got. It does not include headers, payloads, latency information or anything like that. It is aimed at long term trends not problem determination. Thats why we now have the two different retention policies.  Realistically the chance of wanting to look at the specific payload/headers send on an individual transaction months after it was made is very unlikely, what is more interesting is being able to show api usage for different apis and consumers over multiple quarters/years. As ever it is a balancing act.
   Roughly speaking 10 months' worth of summary data needs the same resources as 1 month's api event data (at activity+headers log level).

If you are looking at storing considerable amounts of analytics data, either at long retention or high TPS then I would very strongly advise using the containers based form factors of APIC (kubernetes or openshift). We allow horizontal scaling on those form factors using dedicated storage so you can scale up to have lots of analytics data nodes which works very nicely (e.g. we have customers with 20+ analytics data nodes). That is not possible on OVAs which are limited to either 1 or 3 nodes.

Hope that helps!

Chris

Hi 

Would like to seek advise on some questions regarding APIC analytics data. We are currently using APIC 10.0.5 and deployed on-premises using OVA file. 

Question 1:

Understand that retaining analytics data for more than 3 months (for 3 replica deployment) will impact APIC performance. Would like to check that is it only impacting Analytics subsystem performance, or it will impact both Analytics and Gateway subsystems?

Question 2:

If analytics data offload to third party system, does IBM accept to use log from third party system to troubleshoot the issue if the issue happened in APIC 3 months ago and the log already offloaded to third party system and deleted from APIC Analytics subsystem?

Question 3: 

 If we performing some testing in APIC in DR data center, how to delete unwanted analytics data after the testing done?

Question 4:

I saw from IBM documentation (see below) that summary analytics data that is created from API event records is retained for 1 year. This documentation is for APIC 10.0.x. Is this statement still valid for APIC 10.0.5.x? Is it possible to share what information is included in summary analytics data?

https://www.ibm.com/docs/en/api-connect/10.0.x?topic=usage-key-concepts-api-connect-analytics

Thank you.