Observability Configuration
Configure metrics and logs provider directly into the Plural UI
Articles in this section
Plural can query multiple backends for standard observability data and integrate them directly into the mainline Plural experience. In particular, these are:
- Prometheus for timeseries metrics
- Elastic (and others) for log aggregation
- Kubecost for Kubernetes cost observability
All observability implementations are designed to be multi-cluster by default, and we also provide out-of-the-box installs in case you haven't yet adopted a proper solution for any of the main observability providers.
There are a few major benefits of integrating this data with Plural:
- Single-Pane-Of-Glass for Operations - a unified infrastructure management and observability platform reduces context switching for engineers, and makes it easier for team members to ramp up on their operational responsibilities.
- AI - this is the most powerful benefit. As Plural gets access to more data, we can integrate it with our unified AI engine and automate more of the tedious root cause analysis and troubleshooting you'd otherwise do manually.
Plural AI + Observability
Generally, Plural AI is a broad RAG system that ultimately calls into mainline LLMs. This means the more data we can access, the more likely we can find that diamond in the rough that solves your specific problem.
In particular, there are a few major workflows our observability integration pairs with Plural AI:
- Log analysis of low-level Kubernetes components: a few tools, especially external-dns and cert-manager, provide very little error reporting outside of their logs. With an easier way to extract these, we can automatically root cause failures around DNS registration and certificate issuance, which are both common annoyances with Kubernetes operators. This is true of several other tools as well, especially solutions like CSI drivers.
- Application Code Failures - common failure modes like failing health checks, 500 error codes, etc., are usually due to bugs in application code rather than the infrastructure. With a combination of log analysis and searchable PR data, we can RCA these issues and cross-reference them to the offending code changes.
CRD Configurability
For the most part, these settings are configurable via one of our Kubernetes custom resources, DeploymentSettings. A kitchen-sink example of this is below:
apiVersion: deployments.plural.sh/v1alpha1
kind: DeploymentSettings
metadata:
name: global # this is a singleton resource that is always at this location
namespace: plrl-deploy-operator
spec:
managementRepo: pluralsh/plrl-boot-aws
cost: # configuring recommendations from kubecost data
recommendationCushion: 15
recommendationThreshold: 1
ai:
enabled: true
vectorStore: # elastic can be repurposed as a vector store too
enabled: true
vectorStore: ELASTIC
elastic:
host: https://{your-elastic-fqdn}
user: plrl
index: plrl-ai-vectors
passwordSecretRef:
name: plrl-elastic-user
key: password
logging:
enabled: true
driver: ELASTIC
elastic:
host: https://{your-elastic-fqdn}
user: plrl
index: plrl-logs-*
passwordSecretRef:
name: plrl-elastic-user
key: password
prometheusConnection:
host: https://{your-prometheus-url}
user: plrl
passwordSecretRef:
name: basic-auth-prom
key: passwordObservability Webhooks
Plural supports integrations with third-party alerting and monitoring tools via webhooks, allowing you to establish connections to popular observability platforms. These are configured through the Plural UI.
Supported Integrations
- Datadog - Forward metrics, logs, and alerts from Datadog to the Plural Console.
- Grafana - Forward alerts from Grafana to the Plural Console for centralized monitoring and incident management.