Hello, we are serving our permit-pdp in a sidecar ...
# permit-saas
e
Hello, we are serving our permit-pdp in a sidecar in GKE, and also use GCP Logs. We notice regardless of the log environment permit-pdp spits out, they come across as 'errors' in GCP log explorer. I was having trouble finding how to resolve this to minimize log noise but came across an open issue with loguru regarding this. Is there anything on our end? or permits end that we could do so that logs surface accurately?
a
Hi @Engineering Swantide, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
Based on the available sources, I don't have specific documentation about configuring the PDP's log output format for GCP Logs compatibility. The deployment guide for GCP Cloud Run (1) covers container configuration, environment variables, and health checks, but doesn't address log formatting for GCP's log severity detection. The sources do mention that the PDP uses various logging components internally (2) (3) (4) (5) , but don't provide configuration options to change the log output format to match GCP's expected severity levels. To help investigate this further, could you provide: 1. Which Workspace / Project / Env you are using 2. What calls are you performing (as SDK code or CURL) 3. Which PDP version you are running 4. Relevant logs from your PDP showing the severity mismatch This will help our engineers investigate whether there's a configuration option or if this requires a fix on Permit's end. ​*Potential workarounds to explore:*​ • Check if GCP Logs allows custom severity parsing rules for your log stream • Consider using a log processing layer (like Fluent Bit) between the PDP and GCP Logs to transform the severity levels • Review if there are any PDP environment variables related to log formatting (though none are documented in the available sources)
To learn more, see the sources I considered: [[1] Deploying PDP on GCP Cloud Run](https://docs.permit.io/how-to/deploy/cloud-hosts/gcp-cloud-run) [[2] Unable to push the policy data since OPA is not ready yet in sidecar pattern](https://github.com/permitio/PDP/issues/266) [[3] Secure data is being logged](https://github.com/permitio/opal/discussions/575) [[4] Logging mode can't be changed by accessor function](https://github.com/permitio/fastapi_websocket_rpc/issues/56) [[5] LOGURU mode logging doesn't work.](https://github.com/permitio/fastapi_websocket_rpc/issues/57)
e
Screenshot 2026-05-11 at 13.07.30.png
d
Hi @Engineering Swantide, What you're seeing isn't a loguru bug exactly, it's a mismatch between how loguru structures its JSON output and what GCP Cloud Logging expects. A couple of things going on: 1. Why everything looks like an error: GCP's logging agent classifies anything written to stderr as ERROR severity by default. Loguru writes all log levels to stderr regardless of whether they're INFO, WARNING, or ERROR. 2. Why GCP isn't using the level from the JSON: The problem is GCP looks for a top-level
severity
field to set the log level, but loguru nests it under
record.level.name
. Since GCP can't find
severity
at the top level, it falls back to the stderr default → everything shows as ERROR. What you can do on your end: The fix is in your log forwarder config, not the PDP. Add a filter that promotes
record.level.name
to a top-level
severity
field. Depending on what you're running: • Fluent Bit sidecar: a
modify
filter with
Rename record.level.name severity
, or a small Lua filter if you need to handle the nesting. • GCP Ops Agent: a
modify_fields
processor that sets
severity
from
jsonPayload.record.level.name
. Once GCP sees a top-level
severity
, it should classify each log line correctly (INFO as INFO, ERROR as ERROR, etc.). https://cloud.google.com/kubernetes-engine/docs/concepts/about-logs https://cloud.google.com/logging/docs/structured-logging https://docs.fluentbit.io/manual/data-pipeline/outputs/stackdriver_special_fields
e
sweet thank you!