Sink Architecture in Enterprise PKS
Page last updated:
Warning: Pivotal Container Service (PKS)
v1.4 is no longer supported because it has reached the End
of General Support (EOGS) phase as defined by the
Support Lifecycle Policy.
To stay up to date with the latest software and security updates, upgrade to a supported version.
This topic describes how sinks are implemented in Enterprise Pivotal Container Service (Enterprise PKS) workloads.
Enterprise PKS provides the following types of sinks for collecting logs and metrics:
- A log sink for monitoring your cluster and namespace logs.
- A metric sink for monitoring your cluster metrics.
Enterprise PKS clusters include an observability manager that manages log sink and metric sink configurations within a cluster.
The following diagram details Enterprise PKS observability manager architecture:
If you want to use sinks, you must enable Enable Log Sink Resources or Enable Metric Sink Resources in the Enterprise PKS tile. When you select these fields, Ops Manager requests that BOSH enable the observability manager with these configurations.
For more information, see (Optional) Logging in the Installing topic for your IaaS.
The Enterprise PKS log sink aggregates workload logs and forwards them to a common log destination.
The following diagram details Enterprise PKS log sink architecture:
Logs are monitored and aggregated by a set of fluent-bit daemons running as a pod on a single node.
An event-controller collects Kubernetes API events and sends them to a second fluent-bit daemon pod for aggregation.
All aggregated log entries are marshaled to a common log destination.
Note: When sinks are added or removed, all of the fluent-bit pods are refreshed with new sink information.
The Enterprise PKS metric sink aggregates workload metrics and forwards them to a common metrics destination. The following diagram details Enterprise PKS metric sink architecture:
A metric sink collects and writes metrics from a cluster to specified outputs using input and output plugins.
Workload metrics are monitored by a set of third-party plugins. The plugins forward the metrics to a Telegraph service pod.
A pair of kubelets monitor Kubernetes and forward Kubernetes metrics to a pair of Telegraph service pods.
To define the collected unstructured metrics, a metric-controller monitors Kubernetes for custom resource definitions and forwards those definitions to the Telegraph services.
The Telegraph services collect, process, and aggregate gathered metrics. All aggregated metrics are marshaled to an additional plugin for forwarding to a third-party application.
Note: When sinks are added or removed, all of the Telegraph pods are refreshed with new sink information.
For more information about sinks in Enterprise PKS, see the following topics:
- For information about creating sinks in Enterprise PKS, see Creating Sink Resources.
- For information about using sinks for monitoring, see Monitoring Enterprise PKS with Log Sinks.
Please send any feedback you have to firstname.lastname@example.org.