Chapter 2. Custom logging alerts
You can configure the LokiStack deployment to produce customized alerts and recorded metrics. If you want to use customized alerting and recording rules, you must enable the LokiStack ruler component.
LokiStack log-based alerts and recorded metrics are triggered by providing LogQL (Grafana documentation) expressions to the ruler component.
To provide these expressions, you must create an AlertingRule
custom resource (CR) containing alerting rules, or a RecordingRule
CR containing Prometheus-compatible recording rules (Prometheus documentation).
Administrators can configure log-based alerts or recorded metrics for application
, audit
, or infrastructure
tenants. Users without administrator permissions can configure log-based alerts or recorded metrics for application
tenants of the applications that they have access to.
Application, audit, and infrastructure alerts are sent by default to the OpenShift Container Platform monitoring stack Alertmanager in the openshift-monitoring
namespace, unless you have disabled the local Alertmanager instance. If the Alertmanager that is used to monitor user-defined projects in the openshift-user-workload-monitoring
namespace is enabled, application alerts are sent to the Alertmanager in this namespace by default.
2.1. Configuring the ruler Copy linkLink copied to clipboard!
When the LokiStack
ruler component is enabled, users can define a group of LogQL (Grafana documentation) expressions that trigger logging alerts or recorded metrics.
Administrators can enable the ruler by modifying the LokiStack
custom resource (CR).
Prerequisites
- You have installed the Red Hat OpenShift Logging Operator and the Loki Operator.
-
You have created a
LokiStack
CR. - You have administrator permissions.
Procedure
Enable the ruler by ensuring that the
LokiStack
CR has the following spec configuration:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Enable Loki alerting and recording rules in your cluster.
- 2
- Specify the selector for the alerting and recording resources.
- 3
- Add a custom label that can be added to namespaces where you want to enable the use of logging alerts and metrics.
- 4
- Specify the namespaces in which the alerting and recording rules are defined for the Loki Operator. If undefined, only the rules defined in the same namespace as the
LokiStack
are used. - 5
- Add a custom label that can be added to namespaces where you want to enable the use of logging alerts and metrics.
2.2. Authorizing LokiStack rules RBAC permissions Copy linkLink copied to clipboard!
Administrators can allow users to create and manage their own alerting and recording rules by binding cluster roles to usernames. Cluster roles are defined as ClusterRole
objects that contain necessary role-based access control (RBAC) permissions for users.
The following cluster roles for alerting and recording rules are available for LokiStack:
Rule name | Description |
---|---|
|
Users with this role have administrative-level access to manage alerting rules. This cluster role grants permissions to create, read, update, delete, list, and watch |
|
Users with this role can view the definitions of Custom Resource Definitions (CRDs) related to |
|
Users with this role have permission to create, update, and delete |
|
Users with this role can read |
|
Users with this role have administrative-level access to manage recording rules. This cluster role grants permissions to create, read, update, delete, list, and watch |
|
Users with this role can view the definitions of Custom Resource Definitions (CRDs) related to |
|
Users with this role have permission to create, update, and delete |
|
Users with this role can read |
2.2.1. Examples Copy linkLink copied to clipboard!
To apply cluster roles for a user, you must bind an existing cluster role to a specific username.
Cluster roles can be cluster or namespace scoped, depending on which type of role binding you use. When a RoleBinding
object is used, as when using the oc adm policy add-role-to-user
command, the cluster role only applies to the specified namespace. When a ClusterRoleBinding
object is used, as when using the oc adm policy add-cluster-role-to-user
command, the cluster role applies to all namespaces in the cluster.
The following example command gives the specified user create, read, update and delete (CRUD) permissions for alerting rules in a specific namespace in the cluster:
Example cluster role binding command for alerting rule CRUD permissions in a specific namespace
oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>
$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>
The following command gives the specified user administrator permissions for alerting rules in all namespaces:
Example cluster role binding command for administrator permissions
oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>
$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>
2.3. Creating a log-based alerting rule with Loki Copy linkLink copied to clipboard!
The AlertingRule
CR contains a set of specifications and webhook validation definitions to declare groups of alerting rules for a single LokiStack
instance. In addition, the webhook validation definition provides support for rule validation conditions:
-
If an
AlertingRule
CR includes an invalidinterval
period, it is an invalid alerting rule -
If an
AlertingRule
CR includes an invalidfor
period, it is an invalid alerting rule. -
If an
AlertingRule
CR includes an invalid LogQLexpr
, it is an invalid alerting rule. -
If an
AlertingRule
CR includes two groups with the same name, it is an invalid alerting rule. - If none of the above applies, an alerting rule is considered valid.
Tenant type | Valid namespaces for AlertingRule CRs |
---|---|
audit |
|
infrastructure |
|
application | All other namespaces. |
Prerequisites
- Red Hat OpenShift Logging Operator 5.7 and later
- OpenShift Container Platform 4.13 and later
Procedure
Create an
AlertingRule
custom resource (CR):Example infrastructure AlertingRule CR
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The namespace where this
AlertingRule
CR is created must have a label matching the LokiStackspec.rules.namespaceSelector
definition. - 2
- The
labels
block must match the LokiStackspec.rules.selector
definition. - 3
AlertingRule
CRs forinfrastructure
tenants are only supported in theopenshift-*
,kube-*
, ordefault
namespaces.- 4
- The value for
kubernetes_namespace_name:
must match the value formetadata.namespace
. - 5
- The value of this mandatory field must be
critical
,warning
, orinfo
. - 6
- This field is mandatory.
- 7
- This field is mandatory.
Example application AlertingRule CR
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The namespace where this
AlertingRule
CR is created must have a label matching the LokiStackspec.rules.namespaceSelector
definition. - 2
- The
labels
block must match the LokiStackspec.rules.selector
definition. - 3
- Value for
kubernetes_namespace_name:
must match the value formetadata.namespace
. - 4
- The value of this mandatory field must be
critical
,warning
, orinfo
. - 5
- The value of this mandatory field is a summary of the rule.
- 6
- The value of this mandatory field is a detailed description of the rule.
Apply the
AlertingRule
CR:oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow