Centralized/common logging

General
1

We are currently running Pega Platform 25.1.2 on-premises and are exploring options for implementing centralized logging for containerized deployments on Kubernetes.

During our investigation, we came across the following Pega documentation:

Could you please advise whether there are any other recommended approaches, architectures, or best practices for centralized/common logging in a Kubernetes-based Pega deployment?

2

The best choice often depends on your existing observability stack. Since the underlying infrastructure is unknown, I would recommend one of these two approaches:

Option 1: Leverage the organization’s existing enterprise logging platform

Do you already have a centralized logging solution such as Splunk, Elastic/OpenSearch, Azure Monitor, CloudWatch, or similar? In this scenario, configure Kubernetes log collectors (for example Fluent Bit or Fluentd) to collect Pega application logs and forward them to the enterprise platform.

Benefits:

  • Aligns with existing operational processes and monitoring practices.
  • Avoids introducing another observability platform to maintain.
  • Enables centralized search, alerting, retention, and compliance across all applications.
  • Simplifies correlation between Pega events and infrastructure events.

Option 2: Deploy a dedicated Kubernetes-native logging stack

If no enterprise logging solution exists, a common pattern is:

  • Fluent Bit (log collection)
  • OpenSearch/Elasticsearch or Grafana Loki (log storage)
  • Kibana/OpenSearch Dashboards or Grafana (visualization)

Benefits:

  • Cloud and infrastructure agnostic.
  • Well-established Kubernetes logging pattern.
  • Supports centralized collection of Pega logs, Kubernetes events, and container logs.
  • Provides a complete observability foundation when an enterprise platform is not already available.