I am evaluating the logging strategy for Pega Platform running on Azure Kubernetes Service (AKS), specifically for collecting application logs such as PegaRULES.log and PegaRULES-ALERT.log, and forwarding them to Azure Log Analytics.
As far as I understand, when log output is directed to standard output, Azure Monitor Agent can collect and send these logs to Log Analytics. However, since the logs are aggregated into a single container log table, it is difficult to manage and distinguish between different log types (e.g., PegaRULES.log vs. PegaRULES-ALERT.log).
To enable log separation and detection by log type, we are considering a solution where Fluent Bit is deployed as a sidecar container with the Pega Pod, and the log file paths are shared via a mounted volume. Fluent Bit configuration would be managed using Kubernetes ConfigMap.
Could you please clarify whether this architecture is officially recommended or supported by Pega Platform? If there are any best practices, previous case studies, or documentation related to this approach, it would be appreciated if you could share them. Additionally, please advise us on any Pega-specific configuration considerations or potential restrictions when implementing log file collection via sidecar containers.
Your proposed architecture is technically sound and aligns with common Kubernetes logging patterns, but there are a few Pega-specific considerations.
Is a Fluent Bit sidecar officially recommended by Pega?
To my knowledge, Pega does not officially recommend or require a Fluent Bit sidecar for collecting PegaRULES.log and PegaRULES-ALERT.log on Kubernetes. Pega’s deployment guidance is generally focused on:
-Writing application logs to stdout/stderr where possible so the platform’s logging infrastructure can collect them.
-Allowing customers to integrate with the logging solution native to their Kubernetes platform (Azure Monitor, EFK, Loki, Splunk, Datadog, etc.).
In other words, the log aggregation solution is considered part of the Kubernetes platform architecture rather than the Pega application architecture.
Is your proposed architecture supported?
A Fluent Bit sidecar that:
shares a volume with the Pega container,
tails PegaRULES.log and PegaRULES-ALERT.log,
enriches records with metadata, and
forwards them to Azure Log Analytics
is a standard Kubernetes design pattern. Since it does not modify the Pega runtime or interfere with application execution, it is generally considered a supported platform customization rather than a Pega customization.