Closed amitkrjha1 closed 3 years ago
The issue regarding the analytics API being unstable should be fixed by adding a header Accept="application/json" This fix is in the current develop branch and will form part of and upcoming release
We were unable to replicate the 403 issues you report - to replicate I created a new user, granted the user Org Admin permissions in each Business Group, then executed a metrics lookup for AMQ and Object Store. No 403s occurred.
If you are certain you have granted Org Admin permissions in each BG and still see 403 please reach out and we can investigate.
Note you will see 403 for Runtime Manager related requests if you do not provide CloudHub Admin access.
For the Too Many Requests - this is a limit enforced by the platform API and so not within our control.
Hi Richard,
About 403 issue - As per the documentation -
So I am reading it as Org Admin is required only in Master Org and CloudHub Admin is required in all environments of Sub Orgs and Master Org if any environments exist in Master Org. If we need to provide user with an Org Admin role in each Sub Orgs as well then in my opinion we should update the documentation.
Regards, Amit Jha
On Mon, Sep 13, 2021 at 8:12 AM richardmckinley @.***> wrote:
The issue regarding the analytics API being unstable should be fixed by adding a header Accept="application/json" This fix is in the current develop branch and will form part of and upcoming release
We were unable to replicate the 403 issues you report - to replicate I created a new user, granted the user Org Admin permissions in each Business Group, then executed a metrics lookup for AMQ and Object Store. No 403s occurred.
If you are certain you have granted Org Admin permissions in each BG and still see 403 please reach out and we can investigate.
Note you will see 403 for Runtime Manager related requests if you do not provide CloudHub Admin access.
For the Too Many Requests - this is a limit enforced by the platform API and so not within our control.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mulesoft-catalyst/metrics-accelerator/issues/126#issuecomment-918129910, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKUNSB44UIJIKERNSQS6FRDUBXTDZANCNFSM5DZUDMXQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Hi Amit, Thanks for the feedback! Re-reading the docs with this in mind I can see how it could be read as you described. I will update the docs to be more explicit. Richard
Documentation has been updated. Release 1.8.0 contained a patch to fix analytics API call issue
apma
1) HTTP POST on resource 'https://anypoint.mulesoft.com:443/analytics/1.0/{{orgId}}/environments/{{envId}}/query' failed: bad request (400).
osv2
1) HTTP GET on resource 'https://object-store-stats.anypoint.mulesoft.com:443/api/v1/organizations/{{orgId}}/environments/{{envId}}' failed: too many requests (429). 2) HTTP GET on resource 'https://object-store-stats.anypoint.mulesoft.com:443/api/v1/organizations/{{orgId}}/environments/{{envId}}' failed: forbidden (403).
amq
1) HTTP GET on resource 'https://anypoint.mulesoft.com:443/mq/admin/api/v1/organizations/{{orgId}}/environments/{{envId}}/regions/ca-central-1/destinations' failed: forbidden (403).
It returns expected data sometimes and at other times it returns errors. It is an important KPI to track. Can we please look at replacing this API call with an alternative call to get the same information or fixing the error?
Can we please include specific permission associated with different collectors? For most of them the connected app does a good job of breakdown. However, AMQ and OSV2 seem to be missing.