Hi, I'm working with Message Logging wich is working finely in the develop environment (Apigee X), but in prod (Apigee Hybrid installed in openshift) the ML policy is not saving the logs. The flow of proxies where you deploy ML policies work correctly without any error in both environments. I looked for this logs generated by the ML policy in logs explorer filtering by resource like apigee-runtime and any other resources but I just find container logs. Also, I've already checked the traffic between the logging api and the service accounts with the logs.writter permission but I don't see any data transferred at all. What could be affecting?
This step-by-step approach should help you sort out logging from Apigee into Cloud Logging, via the MessageLogging policy with the CloudLogging element. You can do this from cloud shell. or your own *nix-like workstation. The general idea will also work from Windows powershell, but the way you reference the environment variables will be different.
# Set your project
PROJECT=my-apigee-project
# Insure logging is enabled on the project
gcloud services enable logging --project="$PROJECT"
SA_NAME=logging-test-20240709
# Create a service account. (If you already have one, you can skip this step)
gcloud iam service-accounts create "$SA_NAME" --project="$PROJECT"
# Add the "logWriter" role to the SA
SA_EMAIL="${SA_NAME}@${PROJECT}.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding "$PROJECT" \
--member="serviceAccount:${SA_EMAIL}" \
--role="roles/logging.logWriter"
# Verify that the SA has the appropriate role
gcloud projects get-iam-policy "$PROJECT" --flatten="bindings[].members" \
--format="table(bindings.members)" \
--filter="bindings.role:roles/logging.logWriter"
# In the output of the above you should see the service account you just created
# Now we will verify that this SA can write log records in this project.
# Grant yourself permissions to get a token on behalf of this particular service account
MY_EMAIL=$(gcloud config get-value core/account)
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
--member "user:${MY_EMAIL}" --role roles/iam.serviceAccountTokenCreator
# Verify that the correct role has been assigned
gcloud iam service-accounts get-iam-policy "$SA_EMAIL" \
--flatten="bindings[].members" \
--format="table(bindings.members)" \
--filter="bindings.role:roles/iam.serviceAccountTokenCreator"
# In the output of the above you should see your own email.
# Get an access token for that service account
SA_TOKEN=$(gcloud auth print-access-token --impersonate-service-account ${SA_EMAIL})
# Verify that the token "looks like a token"
echo $SA_TOKEN
# Get information about the token
curl -i https://www.googleapis.com/oauth2/v1/tokeninfo\?access_token=$SA_TOKEN
# The email shown in the JSON payload response of the above, should be the
# email of the service account.
# Use the token to write a log entry:
curl -i -X POST https://logging.googleapis.com/v2/entries:write \
-H "Authorization: Bearer ${SA_TOKEN}" \
-H "content-type: application/json" \
-d '{
"logName": "projects/'${PROJECT}'/logs/logging-test",
"resource" : {
"type": "api",
"labels": {
"service" : "my-example-service",
"version" : "12"
}
},
"labels": {
"flavor": "test"
},
"entries": [{
"severity" : "INFO",
"textPayload" : "Hello world ddeccb34-69d7-4753-a8c1-f310aa9c5a3c"
}
],
"partialSuccess": true
}'
# From the above you should see a 200 response with an empty JSON payload {}
# Now, read the logs, to verify that the entry you wrote above, is available:
gcloud logging read --project $PROJECT "logName=projects/$PROJECT/logs/logging-test"
# If you see a log entry, this shows that you have a service account, with the
# right permissions to write to the logs.
# The next step is to
# - construct a proxy that uses the MessageLogging policy, with the CloudLogging element
# - deploy that proxy with that same service account.
# Follow the documentation to build the MessageLogging policy into your proxy.
# When ready, deploy the proxy. The "deployer" is either the human user (like
# you), or the identity used by your automated CI/CD pipeline.
# Depending on which applies to you, use one of the following:
DEPLOYER_PRINCIPAL="user:${MY_EMAIL}"
DEPLOYER_PRINCIPAL="serviceAccount:${CICD_SERVICE_ACCOUNT_EMAIL}"
# now, grant the deployer principal, the correct permissions to get a token on
# behalf of this particular service account
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
--member "${DEPLOYER_PRINCIPAL}" \
--role="roles/iam.serviceAccountUser"
# then deploy your proxy, either using the UI, or your CI/CD pipeline, or the
# apigeecli tool, etc.
# Whatever tool you use, you must specify the service account.
# For example:
apiproxy=my-api-proxy
apigeecli apis deploy --wait --name "$apiproxy" --ovr --org $ORG --env $ENV --token $TOKEN --sa "${SA_EMAIL}"
# Then invoke the proxy. Maybe a few times.
# Then check the logs, with a command like so:
gcloud logging read --project $PROJECT "logName=projects/$PROJECT/logs/logging-test"
# You may have to adjust that command depending on the LogName you used in the
# MessageLogging policy.