Observability

This page covers log collection, monitoring, tracing, and resource sizing for a running GoodData.CN deployment.

For information about audit logs, such as those used to investigate incidents or track system changes, refer to the Audit Log section.

The fastest way to see the health of a running deployment is the ready-made Grafana Dashboards. When something is already wrong, start with the Runbooks for step-by-step incident response.

Log Collection

Set up a centralized logging system to collect logs from all Kubernetes workloads and components automatically. GoodData.CN log messages are structured JSON, so they are easy to ingest and analyze. Every log line carries tracing information (traceId and spanId), so you can pull together related logs from several sources and see the wider context.

Monitoring and tracing

Most GoodData.CN components expose Prometheus metrics. These metrics can be collected by a monitoring system, visualized, and used to trigger alerts when issues arise. If you use Prometheus Operator, the Helm chart can create PodMonitor objects for you.

Grafana Dashboards

GoodData maintains a ready-made Grafana dashboard that shows the recommended baseline monitoring coverage for a GoodData.CN deployment. The Overall Health dashboard covers cluster health, API traffic, service resource usage, background job queues, analytics engine latency, and exports. Use it as a starting point and adapt it to your own observability stack.

Setting Up Distributed Tracing

GoodData.CN services are fully instrumented for distributed tracing. For configuration details, supported exporters, and collector setup, see Distributed Tracing.

Resource Sizing

Each GoodData.CN microservice runs with its own replica count and its own CPU and memory requests and limits. You set them per application in your Helm values:

someApplication:
  replicaCount: 2
  resources:
    requests:
      cpu: 200m
      memory: 300Mi
    limits:
      cpu: 500m
      memory: 600Mi

Applications running in the JVM need JVM options as well:

someJavaApplication:
  jvmOptions: "-XX:ReservedCodeCacheSize=100M -Xms320m -Xmx320m -XX:MaxMetaspaceSize=170M"

The chart defaults are minimal. They bring the platform up, but they will not carry a busy deployment. As your concurrent user count grows, raise CPU and memory limits and add replicas to spread the load across more pods.

When you give a JVM application more memory, raise its heap size (-XmxNNNm) to match. The service ignores the extra memory otherwise.

Then check what the services actually consume. Watch RSS memory and CPU throttling in your monitoring system, and for JVM applications also the memory regions and garbage collection. Size on those numbers rather than on estimates.

For the per-application defaults, see the default Helm chart values.