Configurar Alertas por Email en Kasten K10

En este guía revisaremos la instalación y configuración de prometheus con el objetivo de obtener alertas vía correo utilizando la federación, reglas y alertmanager de prometheus en conjunto con el monitoreo de Kasten K10.

Contenidos

Pasos Iniciales

Como es de costumbre, siempre, revisaremos la documentación oficial de las soluciones que instalaremos y/o configuraremos en esta guía.

Prometheus: https://prometheus.io/

Kasten: https://docs.kasten.io/latest/operating/monitoring.html

Realizaremos la configuración en una primera parte con la integración de K10 Multi-Cluster Manager y luego veremos como configurar las reglas cuando sea una instalación sin la administración centralizada.

Que es Prometheus?

Prometheus es una solución enfocada en el monitoreo de los recursos de kubernetes basados en métricas en series temporales, es decir, monitoreo en tiempo real de las acciones que se tengan configuradas. Por ejemplo con prometheus podrías monitorear, vía reglas, el uso de CPU, Memoria, Conexiones, sesiones o lo que quieras configurar.

Ademas es la solución estándar para el monitoreo de clústers de kubernetes ya que permite tener una vista muy detallada de los recursos a monitorear como también ayudarnos a la solución de los errores que existan.

Kasten K10 y Prometheus

Kasten también utiliza Prometheus para su monitoreo interno de K10. De hecho, en el link anterior, podemos ver que hay muchas métricas que Kasten k10 exporta a Prometheus como por ejemplo:

catalog
jobs
actions
backup
restore
export
import
report
run

Entonces, como podemos realizar la configuración para que Prometheus nos envíe un email cuando por ejemplo, alguna política de respaldo no funcione correctamente?

Configuración Prometheus en Kasten K10

Como sabemos, prometheus ya viene pre-instalado en Kasten K10, pero para esta instancia no se recomienda que sea modificada, ya que es administrado por helm y tiene ciertas configuraciones que funcionan directamente con los reportes por defecto de Kasten K10 y también para K10 Multi-Cluster Manager si lo tienes activado. Por tanto la idea es federar Prometheus que viene pre-instalado (para no modificarlo) con una instancia nueva de Prometheus:

Instalación y Configuración Prometheus

Ahora procederemos a realizar la creación de un namespace para nuestra instancia de monitoreo, en este caso lo llamaremos alertas, para ello ejecutaremos lo siguiente en nuestro cluster de kubernetes:

kubectl create ns alertas

Y ahora agregaremos el repositorio para helm de Prometheus:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

Y crearemos un nuevo archivo de nombre “kasten_prometheus_values_smtp.yaml”:

defaultRules:
  create: false
alertmanager:
  config:
    global:
      resolve_timeout: 5m
    route:
      repeat_interval: 30m
      receiver: 'email'
      routes:
      - receiver: 'email'
        match:
          severity: kasten
    receivers:
      - name: 'email'
        email_configs:
          - to: [email protected]
            from: [email protected]
            smarthost: smtp.24xsiempre.com:25
            auth_username: SuperDuperUserName
            auth_password: SuperDuperPassword
prometheus:
  prometheusSpec:
    additionalScrapeConfigs:
      - job_name: k10
        scrape_interval: 15s
        honor_labels: true
        scheme: http
        metrics_path: '/k10/prometheus/federate'
        params:
          'match[]':
            - '{__name__=~"jobs.*"}'
            - '{__name__=~"catalog.*"}'
        static_configs:
          - targets:
            - 'prometheus-server.kasten-io.svc.cluster.local'
            labels:
              app: "k10"
#Valores para deshabilitar componentes que no son necesarios 
grafana:
  enabled: false
kubeApiServer:
  enabled: false
kubelet:
  enabled: false
kubeStateMetrics:
  enabled: false
kubeControllerManager:
  enabled: false
kubeEtcd:
  enabled: false
kubeProxy:
  enabled: false
coreDns:
  enabled: false
kubeScheduler:
  enabled: false

Donde se debe editar las siguientes lineas:

to: [email protected]
from: [email protected]
smarthost: smtp.24xsiempre.com:25
auth_username: SuperDuperUserName
auth_password: SuperDuperPassword

Modificar las variables anteriores con los datos correctos y guardar “kasten_prometheus_values_smtp.yaml”:

Y ahora realizamos la instalacion de Prometheus con el siguiente comando:

helm install prometheus prometheus-community/kube-prometheus-stack -n alertas -f kasten_prometheus_values_smtp.yaml

Y para validar que se haya instalado correctamente, ejecutamos:

kubectl --namespace alertas get pods -l "release=prometheus"

Creación de Reglas Prometheus para K10 Multi-Cluster Manager

Aquí realizaremos la configuración más importante, ya que estamos usando K10 Multi-Cluster Manager, debemos saber identificar correctamente cada uno de los clusters que esta siendo protegidos por Kasten K10, por tanto, al leer la documentación aparece un “Tip” clave, donde indica que para identificar los clusters secundarios hay que agregar la variable {cluster=”desarrollo”} donde el nombre del cluster es como lo identificamos en Multi-Cluster Manager. Y para el cluster primario debe ser {cluster=””}.

Para esta guía, tengo configurado 3 clusters:

produccion (cluster primario para K10 Multi-Cluster)
desarrollo (cluster secundario para K10 Multi-Cluster)
tanzu (cluster secundario para K10 Multi-Cluster)

Por tanto, crearemos el archivo de configuración con el nombre “alertas_cluster.yaml” y copiaremos el contenido:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    app: kube-prometheus-stack
    release: prometheus
  name: prometheus-kube-prometheus-kasten.rules
spec:
  groups:
  - name: kasten_alert
    rules:
    - alert: K10JobsFailsClusterProd
      expr: |-
        increase(catalog_actions_count{cluster="", status="failed"}[10m]) > 0
      for: 1m
      labels:
        severity: kasten
      annotations:
        summary: "Politicas de Kasten K10 con error hace 10 minutos"
        description: "Politica << {{ $labels.policy }} >> en cluster << produccion >> Ha fallado en los ultimos 10 minutos"
    - alert: K10JobsFailsClusterDev
      expr: |-
        increase(catalog_actions_count{cluster="desarrollo", status="failed"}[10m]) > 0
      for: 1m
      labels:
        severity: kasten
      annotations:
        summary: "Politicas de Kasten K10 con error hace 10 minutos"
        description: "Politica << {{ $labels.policy }} >> en cluster << {{ $labels.cluster }} >> Ha fallado en los ultimos 10 minutos"
    - alert: K10JobsFailsClusterTanzu
      expr: |-
        increase(catalog_actions_count{cluster="tanzu", status="failed"}[10m]) > 0
      for: 1m
      labels:
        severity: kasten
      annotations:
        summary: "Politicas de Kasten K10 con error hace 10 minutos"
        description: "Politica << {{ $labels.policy }} >> en cluster << {{ $labels.cluster }} >> Ha fallado en los ultimos 10 minutos"

Las variable a editar son en cada una de las alertas:

alert: Nombre de la Alerta
expr: SOLO editar el nombre del cluster (recuerda el tip anterior)
summary: Texto de resumen sin editar las variables
description: Texto descriptivo

La variable mas importante en el archivo anterior es “expr” la cual es la “query” o consulta a prometheus de acuerdo con las metricas de Kasten K10 para detectar la falla en los jobs, si deseas crear nuevas consultas puedes visitar:

https://prometheus.io/docs/prometheus/latest/querying/basics/

Y por ultimo crearemos las reglas en nuestra instancia de Prometheus:

kubectl apply -f alertas_cluster.yaml -n alertas

Y para validar la creación de la regla:

kubectl get prometheusrules.monitoring.coreos.com -n alertas

Creación de Reglas Prometheus sin K10 Multi-Cluster

En caso de que tengas instalado Kasten K10 sin la utilización de K10 Multi-Cluster, también, es posible configurar reglas sin la necesidad de declarar el nombre del cluster, la única diferencia es la creación de la regla que debe ser como la siguiente:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    app: kube-prometheus-stack
    release: prometheus
  name: prometheus-kube-prometheus-kasten.rules
spec:
  groups:
  - name: kasten_alert
    rules:
    - alert: K10JobsFail
      expr: |-
        increase(catalog_actions_count{status="failed"}[10m]) > 0
      for: 1m
      labels:
        severity: kasten
      annotations:
        summary: "Politicas de Kasten K10 con error hace 10 minutos"
        description: "Politica << {{ $labels.policy }} Ha fallado en los ultimos 10 minutos"

Prueba Alertas por Email

Para probar esta configuración, necesitamos generar errores en las políticas de respaldo de los clusters, para eso, en los políticas de respaldos existentes eliminaremos los repositorios de respaldo de Kasten K10 o “Location Profiles” para forzar el error, donde las políticas se mostrarán así:

Y por ultimo ejecutamos las políticas que generamos el error. Con esto deberíamos esperar que nos lleguen las alertas por email. Si ejecutamos el siguiente comando:

kubectl port-forward service/prometheus-kube-prometheus-prometheus 9090:9090 -n alertas

Podremos ingresar a la consola web de Prometheus para ver las reglas creadas:

El ejecutar las políticas de respaldo con errores, prometheus, detectara a través de las reglas que existen algunos errores:

Donde por ultimo lo marca y se ejecuta el envío de la alertas por email:

Algunos ejemplos de las notificaciones o alertas que llegan al correo, donde incluye el nombre de la política de respaldo y su respectivo cluster donde existe el error:

Recomendaciones

En algunos casos donde ya existan instancias de Prometheus, es posible, que al agregar la instancia para monitorear y federar prometheus de Kasten K10 no funcione correctamente, por ejemplo en Rancher, con “cattle-monitoring” es necesario deshabilitar el operator de prometheus, si no, ambas instancias trataran de sobreponerse con la otra obligando a los pods a reiniciarse.

Con respecto a las notificaciones o alertas de Kasten K10, es posible crear nuevas querys o consultas para obtener otros tipos de datos, como por ejemplo, licencias, espacio utilizado, etc.

Post Views: 179

24xSiempre

Disponibilidad 24xSiempre