Product/components used and version/fix level:

Detailed explanation of the problem:

I have installed software AG API gateway 10.15 in my kubernetes cluster on testing environment and i am able to access integration server and webMethods API gateway UI. I need to enable metering for my apigateway and I want to generate report of metering from metering.softwareag.cloud, I followed some documentations and now i have access to the metering app inside my dashboard in softwareag.cloud tanent but it is not showing any data.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/f5f0fd1b312121442024472a1825f42cf1b11e82_2_1035x427.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/f5f0fd1b312121442024472a1825f42cf1b11e82.png 2x" data-dominant-color="F1F7FB">

image1366×565 24.5 KB

How do i configure my Integration Server to send data to my metering.softwareag.cloud dashboard?

Error messages / full error message screenshot / log file:

Question related to a free trial, or to a production (customer) instance?

Have you followed this documentation? https://documentation.softwareag.com/webmethods/wmsuites/wmsuite10-15/webhelp/wsi-webhelp/#page/wsi-webhelp%2Fto-mta.html%23

If so, can you please connect to one of your pods, run the diagnostic tool and share the output? https://documentation.softwareag.com/webmethods/wmsuites/wmsuite10-15/webhelp/wsi-webhelp/#page/wsi-webhelp%2Fmetering.diagnostic.tool.html%23

@Stephane.TAILLAND_emp
I ran the metering-agent.jar file and this is the output:

Entering diagnostic tool.

=== Start diagnostic: Agent version ===
Success: true
Trace:

The metering agent version is: ‘10.15.0.0003-0540’

=== End of diagnostic: Agent version ===

=== Start diagnostic: Server connectivity ===
Success: true
Trace:

Server url is ‘https://metering.softwareag.cloud/api/measurements’. Sending OPTIONS request to server.
Request sent: OPTIONS https://metering.softwareag.cloud/api/measurements
Response status: 200
Response payload: null
Connection established: true

=== End of diagnostic: Server connectivity ===

=== Start diagnostic: Configuration ===
Success: true
Trace:

Checking configuration:

‘[Configuration] : {
server url: https://metering.softwareag.cloud/api/measurements
proxy: DIRECT
proxy user: null
proxy pass:
serverConnectTimeout: 60000
serverReadTimeout: 60000
serverWriteChunkSize: 8192
accPeriod: 1800
reportPeriod: 3600
storage: /opt/softwareag/common/metering/storage
userProvidedTrustStore: null
sagRootFile: /opt/softwareag
logLevel: INFO
instanceIdentifier: apigateway-7c57446c74-7b7pn_/opt/softwareag/common/metering/lib
maxLogSize: 1000000
cloudID: null
runtimeAlias: null
}’

Checking server url: ‘https://metering.softwareag.cloud/api/measurements’.
Server url is valid.
Checking report period: ‘3600’
Report period is valid.
Checking accumulation period: ‘1800’
Accumulation period is valid.
Report period is greater or equal to accumulation period.
Configuration is valid: ‘true’

=== End of diagnostic: Configuration ===

=== Start diagnostic: Measurement log files ===
Success: true
Trace:

Checking storage directory with path: ‘/opt/softwareag/common/metering/storage’
Validating measurement log files in storage directory: ‘/opt/softwareag/common/metering/storage’.
Start check for file ‘c-1163719787_YAI_r346610810_0000800348.mlog’
Measurement log file ‘c-1163719787_YAI_r346610810_0000800348.mlog’ is valid: ‘true’
Checking measurement log files finished with success: ‘true’

=== End of diagnostic: Measurement log files ===

Finish diagnostic with overall status: SUCCESS

So, the simulator tells us your metering agent is correctly configured to send metering data to Cloud metering.

Report period is set to 3600 seconds so your transactions will be sent to cloud metering on a hourly basis.

If this is not the case, you could also increate the “0176 Metering” log level and check what you get in the logs, to confirm or not that your agent collects the metering data and sends them to the Cloud metering.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/390cbb77cba94f2dae0f7f0fc09ee8ccc113c76f_2_1035x636.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/390cbb77cba94f2dae0f7f0fc09ee8ccc113c76f_2_1380x848.png 2x" data-dominant-color="ECF0F4">

image1470×905 111 KB

If it’s not working, there’s a possibility that the local runtime license isn’t valid for metering, or that it does not match the Cloud metering configuration. But before asking SAG support to do these checks, let’s first ensure that your pods do send metering data.

@Stephane.TAILLAND_emp Thanks for the response.
In my Software AG_directory/common/metering/conf/metering.agent.properties

metering.server.url is set to
https://metering.softwareag.cloud/api/measurements, Whereas my cloud url is
https://my-environment-name.metering.softwareag.cloud/route/analytics?contractNumber=2******&startDate=2024-05-01&endDate=2024-05-31

Is my agent sending metering data to correct cloud endpoint? or do i need to change it? if so then how? i’m unable to see anything related to this in my kubernetes API-gateway deployment.

https://metering.softwareag.cloud/api/measurements is the correct url. The other url is for you to consult the metering data in SAG Cloud.

If the metering diagnostic tool ran well without you doing any change, then let’s keep the default configuration.
Check if you have a folder /opt/softwareag/common/metering/storage in your containers. There should be a few files there, it’s where the local runtime caches the metering data before it’s sent to the Cloud.
Also check your server logs to see anything related to metering (and increase the verbosity of the metering logs in necessary, using the instructions of my previous post.)

To repeat myself, we need to ensure the metering agent does its job of collecting the metrics and sending them to the Cloud server without any error.

Thank you for your help. The issue was with license, i was applying the wrong license i changed it and i started seeing the data however when i run diagnostic tool i get cloudId and runtimeAlise as null, is this an issue? how can i set these values?

'[Configuration] : {
server url: https://metering.softwareag.cloud/api/measurements
proxy: DIRECT
proxy user: null
proxy pass:
serverConnectTimeout: 60000
serverReadTimeout: 60000
serverWriteChunkSize: 8192
accPeriod: 1800
reportPeriod: 3600
storage: /opt/softwareag/common/metering/storage
userProvidedTrustStore: null
sagRootFile: /opt/softwareag
logLevel: INFO
instanceIdentifier: apigateway-0_/opt/softwareag/common/metering/lib
maxLogSize: 1000000

cloudID: null

runtimeAlias: null

}’

cloudID: I don’t know what this is for, probably not important.

runtimeAlias: this one’s more interesting, it allows you to label your on-promise runtimes. If you have multiple IS / MSR / API GW deployments, you can assign a label to them in order to easily recognize them in the Cloud metering UI.

In this page https://documentation.softwareag.com/webmethods/wmsuites/wmsuite10-15/webhelp/wsi-webhelp/#page/wsi-webhelp%2Fre-mta_properties.html%23 you have a set of properties to configure your metering agent.
Since you’re running in Kubernetes, you should inject an environment variable METERING_RUNTIME_ALIAS into your API Gateway container in order to set the value of runtimeAlias.
Add something like the following in your deployment descriptor, at the level of your API GW container spec:

          env:
- name: METERING_RUNTIME_ALIAS
value: your-desired-alias

Hello @Stephane.TAILLAND_emp,
I’m encountering another issue need your help please, i have API gateways running on 2 different environments. One on prod and other on dev. i set the METERING_RUNTIME_ALIAS value to “value-dev” on dev and “value-prod” on prod.

The issue is, the value i set on one environment starts reflecting on other as well even though i set both values different. The licenses are different too for both gateways.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/52ad4a948e732206897d267daeb4da3cda23584b.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/52ad4a948e732206897d267daeb4da3cda23584b.png 2x" data-dominant-color="F7F8F9">

image922×538 82 KB

You might have a server with a production license that references the BTEB_ECR_DEV alias.
Either it’s a prod server that has the wrong alias, or a dev server that wrongly uses a prod license.

Prod server mlog file output:
{product: “YAI”, client: “7501411”, runtimeUId: “-274861873”, licenseSerialNumber: “0000800342”, runtimeAlias: “BTEB_ECR_PROD”}

Dev server mlog file output:
{product: “YAI”, client: “7501411”, runtimeUId: “-274861873”, licenseSerialNumber: “0000800348”, runtimeAlias: “BTEB_ECR_DEV”}

you can see both have different license serial number, i also checked the license key its different.

OK. Please check the dev servers, one of them possibly has a production license.