1. Llegir un missatge de la cua            ~2 ms de CPU
2. Consultar les dades de la reserva       ~5 ms de CPU + 8 ms esperant PostgreSQL
3. Renderitzar la plantilla del correu     ~12 ms de CPU
4. Connectar amb el servidor SMTP i enviar ~3 ms de CPU + 450 ms ESPERANT
5. Confirmar el missatge a la cua          ~1 ms de CPU

Total: ~23 ms de CPU i ~458 ms d'espera.
Proporcio CPU/temps total: 23 / 481 = 4,8 %

ratio = 60 / 210 = 0,286
repliquesDesitjades = sostre(2 x 0,286) = 1

L'HPA vol BAIXAR a 1 replica.

Cua: 40.000 missatges.
Un worker processa ~2 missatges/segon (limitat pel SMTP).
Objectiu: buidar la cua en 20 minuts = 1.200 segons.

Missatges per segon necessaris: 40.000 / 1.200 = 33,3
Workers necessaris: 33,3 / 2 = 17 workers.

Conditions:
  Type           Status  Reason                 Message
  ----           ------  ------                 -------
  ScalingActive  False   FailedGetExternalMetric  unable to get external metric
                         rutas-norte-pro/longitud_cua_correus/nil:
                         no custom metrics API (external.metrics.k8s.io/v1beta1)
                         registered

- type: Pods
  pods:
    metric:
      name: peticions_per_segon
    target:
      type: AverageValue
      averageValue: "85"

- type: Object
  object:
    describedObject:
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      name: rutas-norte-public
    metric:
      name: peticions_per_segon
    target:
      type: Value
      value: "5000"

- type: External
  external:
    metric:
      name: longitud_cua_correus
      selector:
        matchLabels:
          cua: notificacions-confirmacio
    target:
      type: AverageValue
      averageValue: "2500"

kubectl get apiservices | grep metrics

NAME                                    SERVICE                              AVAILABLE   AGE
v1beta1.metrics.k8s.io                  kube-system/metrics-server           True        41d
v1beta1.external.metrics.k8s.io         keda/keda-operator-metrics-apiserver  True        12d

# Fragment de la configuracio de prometheus-adapter
rules:
  - seriesQuery: 'peticions_http_total{namespace!="",pod!=""}'
    resources:
      overrides:
        namespace: {resource: "namespace"}
        pod: {resource: "pod"}
    name:
      matches: "^peticions_http_total$"
      as: "peticions_per_segon"
    metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/rutas-norte-pro/pods/*/peticions_per_segon" \
  | python3 -m json.tool

# Amb Helm (ho veurem a fons a 10-03)
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace

# Verificacio
kubectl get pods -n keda

NAME                                              READY   STATUS    RESTARTS   AGE
keda-admission-webhooks-6d8f7c9b4d-x2klm          1/1     Running   0          2m
keda-operator-7d9c5f8b6b-4mnpq                    1/1     Running   0          2m
keda-operator-metrics-apiserver-5f7b8c9d6a-9wrtz  1/1     Running   0          2m

kubectl get crd | grep keda

clustertriggerauthentications.keda.sh    2026-04-20T11:32:14Z
scaledjobs.keda.sh                       2026-04-20T11:32:14Z
scaledobjects.keda.sh                    2026-04-20T11:32:14Z
triggerauthentications.keda.sh           2026-04-20T11:32:14Z

kubectl get hpa -n rutas-norte-pro

NAME                                 REFERENCE                         TARGETS        MINPODS  MAXPODS  REPLICAS
keda-hpa-worker-notificacions        Deployment/worker-notificacions   1847/2500 (avg)  1        25       8

kubectl get hpa keda-hpa-worker-notificacions -n rutas-norte-pro -o yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: keda-hpa-worker-notificacions
  namespace: rutas-norte-pro
  labels:
    app.kubernetes.io/managed-by: keda-operator
    scaledobject.keda.sh/name: worker-notificacions
  ownerReferences:
    - apiVersion: keda.sh/v1alpha1
      kind: ScaledObject
      name: worker-notificacions
      controller: true
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker-notificacions
  minReplicas: 1
  maxReplicas: 25
  metrics:
    - type: External
      external:
        metric:
          name: s0-rabbitmq-notificacions-confirmacio
          selector:
            matchLabels:
              scaledobject.keda.sh/name: worker-notificacions
        target:
          type: AverageValue
          averageValue: "2500"

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-notificacions
  namespace: rutas-norte-pro
spec:
  # A QUINA carrega s'aplica.
  scaleTargetRef:
    apiVersion: apps/v1        # Opcional, per defecte apps/v1
    kind: Deployment           # Opcional, per defecte Deployment
    name: worker-notificacions
    envSourceContainerName: worker   # De quin contenidor llegir variables d'entorn

  # CADA QUANT consulta KEDA la font externa.
  pollingInterval: 15

  # QUANT espera sense activitat abans de baixar a ZERO.
  cooldownPeriod: 300

  # Repliques quan NO hi ha activitat. 0 = escalat a zero.
  minReplicaCount: 0
  maxReplicaCount: 25

  # Repliques en estat "inactiu" DIFERENT de zero.
  idleReplicaCount: 0

  # Que fer si la font de metriques NO RESPON.
  fallback:
    failureThreshold: 3
    replicas: 6

  # Configuracio avancada.
  advanced:
    restoreToOriginalReplicaCount: false
    horizontalPodAutoscalerConfig:
      name: hpa-worker-notificacions
      behavior:
        scaleUp: {}
        scaleDown: {}

  # QUE observa. Es una llista: n'hi pot haver diversos.
  triggers:
    - type: rabbitmq
      metadata:
        queueName: notificacions-confirmacio
        mode: QueueLength
        value: "2500"
      authenticationRef:
        name: rabbitmq-credencials

minReplicaCount: 3       # Quan hi ha activitat, minim 3
idleReplicaCount: 1      # Quan NO hi ha activitat, baixa a 1

fallback:
  failureThreshold: 3    # Despres de 3 consultes fallides consecutives...
  replicas: 6            # ...fixar 6 repliques i mantenir-les

advanced:
  horizontalPodAutoscalerConfig:
    name: hpa-worker-notificacions      # Nom personalitzat de l'HPA generat
    behavior:
      scaleUp:
        stabilizationWindowSeconds: 0
        selectPolicy: Max
        policies:
          - type: Percent
            value: 100
            periodSeconds: 30
          - type: Pods
            value: 5
            periodSeconds: 30
      scaleDown:
        stabilizationWindowSeconds: 300
        selectPolicy: Min
        policies:
          - type: Percent
            value: 25
            periodSeconds: 60

triggers:
  - type: rabbitmq        # Senyal principal: la cua
    metadata: {...}
  - type: cpu             # Xarxa de seguretat: si la CPU es dispara, escalar igual
    metricType: Utilization
    metadata:
      value: "80"

- type: prometheus
  metadata:
    serverAddress: http://prometheus-operated.monitoratge.svc.cluster.local:9090
    query: |
      sum(rate(api_reserves_peticions_total{namespace="rutas-norte-pro"}[2m]))
    threshold: "85"
    # Quin valor fer servir si la consulta no retorna res (serie buida)
    ignoreNullValues: "true"
    unsafeSsl: "false"

- type: rabbitmq
  metadata:
    protocol: amqp
    queueName: notificacions-confirmacio
    mode: QueueLength        # QueueLength o MessageRate
    value: "2500"
    # activationValue: per sota d'aixo, es considera INACTIU (per al 0)
    activationValue: "10"
  authenticationRef:
    name: rabbitmq-credencials

- type: cron
  metadata:
    timezone: Europe/Madrid
    start: "30 9 * * *"       # A les 9:30
    end: "0 14 * * *"         # Fins a les 14:00
    desiredReplicas: "25"

- type: postgresql
  metadata:
    query: "SELECT COUNT(*) FROM tasques_pendents WHERE estat = 'pendent'"
    targetQueryValue: "50"
    activationTargetQueryValue: "1"
  authenticationRef:
    name: postgres-credencials

metadata:
  value: "2500"              # 1 replica per cada 2500 missatges
  activationValue: "10"      # Amb menys de 10 missatges, es considera inactiu

# 1. El Secret amb les credencials (modul 3 i 08-05)
apiVersion: v1
kind: Secret
metadata:
  name: rabbitmq-credencials
  namespace: rutas-norte-pro
type: Opaque
stringData:
  # Cadena de connexio completa amb usuari i contrasenya.
  host: "amqp://keda_lector:[email protected]:5672/"
---
# 2. El TriggerAuthentication que la referencia
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: rabbitmq-credencials
  namespace: rutas-norte-pro
spec:
  secretTargetRef:
    - parameter: host          # Nom del parametre que espera l'escalador
      name: rabbitmq-credencials
      key: host                # Clau dins del Secret

triggers:
  - type: rabbitmq
    metadata:
      queueName: notificacions-confirmacio
      mode: QueueLength
      value: "2500"
    authenticationRef:
      name: rabbitmq-credencials

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: aws-sqs-identitat
  namespace: rutas-norte-pro
spec:
  podIdentity:
    provider: aws
    roleArn: arn:aws:iam::000000000000:role/rutas-norte-keda-sqs

apiVersion: keda.sh/v1alpha1
kind: ClusterTriggerAuthentication
metadata:
  name: prometheus-lectura        # Sense namespace
spec:
  secretTargetRef:
    - parameter: bearerToken
      name: prometheus-token
      key: token

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: processador-factures
  namespace: rutas-norte-pro
spec:
  jobTargetRef:
    parallelism: 1
    completions: 1
    backoffLimit: 3
    template:
      spec:
        restartPolicy: Never
        containers:
          - name: processador
            image: registry.rutasnorte.example/processador-factures:2.1.0
            resources:
              requests: {cpu: 500m, memory: 512Mi}
              limits: {cpu: "2", memory: 2Gi}

  pollingInterval: 30
  maxReplicaCount: 20
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 10

  # Com calcular quants Jobs crear a partir del valor de la metrica.
  scalingStrategy:
    strategy: "default"

  triggers:
    - type: rabbitmq
      metadata:
        queueName: factures-pendents
        mode: QueueLength
        value: "1"          # UN Job per missatge
      authenticationRef:
        name: rabbitmq-credencials

# k8s/entorns/pro/scaledobject-worker-notificacions.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-notificacions
  namespace: rutas-norte-pro
  labels:
    app: worker-notificacions
    app.kubernetes.io/part-of: rutas-norte
    entorn: pro
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker-notificacions

  # Consulta a RabbitMQ cada 15 s. Prou rapid perque la
  # reactivacio des de zero sigui gairebe immediata, i prou lent per
  # no matxucar l'API de gestio de RabbitMQ.
  pollingInterval: 15

  # 10 minuts sense activitat abans d'apagar del tot. Es generos a proposit:
  # les reserves arriben a rafegues, i apagar i encendre cada dos minuts costaria
  # mes (en arrencades en fred) que mantenir un pod.
  cooldownPeriod: 600

  # ESCALAT A ZERO. Fora de temporada no hi ha rao per mantenir workers
  # encesos les 24 hores esperant un correu cada uns quants minuts.
  minReplicaCount: 0

  # Sostre: 25 workers x 2 correus/s = 50 correus/s = 3.000 correus/minut.
  # Els 40.000 correus del pont es buiden en ~14 minuts. Suficient.
  # A mes: 25 x 120m = 3 nuclis, que caben al pla de capacitat de 09-03.
  maxReplicaCount: 25

  # Si RabbitMQ deixa de respondre, no ens quedem congelats: fixem 6
  # repliques, que es el cabal d'un dia normal amb marge. Millor un numero
  # segur conegut que un numero congelat desconegut.
  fallback:
    failureThreshold: 3
    replicas: 6

  advanced:
    # En esborrar el ScaledObject, tornar el Deployment a les seves repliques originals.
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      name: hpa-worker-notificacions
      behavior:
        scaleUp:
          # Sense espera: si hi ha cua, hi ha feina pendent ARA.
          stabilizationWindowSeconds: 0
          selectPolicy: Max
          policies:
            - type: Percent
              value: 100
              periodSeconds: 30
            - type: Pods
              value: 5
              periodSeconds: 30
        scaleDown:
          # 5 minuts de calma. Menys conservador que api-reserves perque
          # arrencar un worker es barat (no te cache que escalfar) i
          # perque no hi ha cap usuari esperant una resposta.
          stabilizationWindowSeconds: 300
          selectPolicy: Min
          policies:
            - type: Percent
              value: 30
              periodSeconds: 60

  triggers:
    # DISPARADOR PRINCIPAL: la longitud de la cua.
    - type: rabbitmq
      metadata:
        protocol: amqp
        queueName: notificacions-confirmacio
        mode: QueueLength
        # 1 worker per cada 2.500 missatges a la cua.
        #
        # Calcul: volem buidar 40.000 missatges en ~15 minuts.
        #   40.000 / 900 s = 44,4 missatges/s necessaris
        #   44,4 / 2 (per worker) = 22,2 workers
        #   40.000 / 22,2 = 1.800 missatges per worker
        # Arrodonim a 2.500 per no arribar al sostre amb marge just:
        #   40.000 / 2.500 = 16 workers -> buida en ~21 minuts. Acceptable.
        value: "2500"
        # Per sota de 10 missatges, es considera inactiu i pot baixar a zero.
        # No hi posem 0 perque sempre hi ha 1-2 missatges residuals en transit.
        activationValue: "10"
      authenticationRef:
        name: rabbitmq-credencials

    # DISPARADOR SECUNDARI: xarxa de seguretat per CPU.
    # Si per alguna rao imprevista els workers se saturen de CPU (una
    # plantilla de correu patologica, per exemple) escalem igual, encara que
    # la cua sigui curta. Guanya el disparador que demana MES repliques.
    - type: cpu
      metricType: Utilization
      metadata:
        value: "80"

kubectl apply -f k8s/entorns/pro/scaledobject-worker-notificacions.yaml
kubectl get scaledobject -n rutas-norte-pro

NAME                   SCALETARGETKIND      SCALETARGETNAME        MIN  MAX  TRIGGERS   AUTHENTICATION         READY  ACTIVE  FALLBACK  AGE
worker-notificacions   apps/v1.Deployment   worker-notificacions   0    25   rabbitmq   rabbitmq-credencials   True   False   False     34s

kubectl get deployment worker-notificacions -n rutas-norte-pro

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
worker-notificacions   0/0     0            0           89d

kubectl get deployment worker-notificacions -n rutas-norte-pro --watch

# Simular 30.000 correus de confirmacio (obertura de la venda)
kubectl exec -n rutas-norte-pro rabbitmq-0 -- \
  rabbitmqadmin publish routing_key=notificacions-confirmacio \
  payload='{"reserva":"RN-2026-054321","destinatari":"[email protected]"}' \
  --count=30000

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
worker-notificacions   0/0     0            0           89d
worker-notificacions   0/1     0            0           89d     <- KEDA activa: 0 -> 1
worker-notificacions   1/1     1            1           89d
worker-notificacions   1/6     1            1           89d     <- L'HPA pren el comandament
worker-notificacions   6/6     6            6           89d
worker-notificacions   6/12    6            6           89d
worker-notificacions   12/12   12           12          89d
worker-notificacions   12/12   12           12          89d     <- Estable: 30000/2500 = 12

kubectl get hpa hpa-worker-notificacions -n rutas-norte-pro

NAME                       REFERENCE                         TARGETS            MINPODS  MAXPODS  REPLICAS
hpa-worker-notificacions   Deployment/worker-notificacions   2483/2500 (avg)    1        25       12

worker-notificacions   12/12   12   12   89d
worker-notificacions   12/8    12   12   89d     <- L'HPA baixa (despres d'estabilitzacio)
worker-notificacions   8/3     8    8    89d
worker-notificacions   3/1     3    3    89d
worker-notificacions   1/1     1    1    89d     <- Es queda en 1 (minim de l'HPA)
                                                    ...passen 10 minuts de cooldownPeriod...
worker-notificacions   0/0     0    0    89d     <- KEDA apaga: 1 -> 0

# HELP api_reserves_peticions_total Total de peticions HTTP ateses
# TYPE api_reserves_peticions_total counter
api_reserves_peticions_total{metode="GET",ruta="/rutes",codi="200"} 1847293
api_reserves_peticions_total{metode="POST",ruta="/reserves",codi="201"} 92841

# HELP api_reserves_duracio_segons Duracio de les peticions
# TYPE api_reserves_duracio_segons histogram
api_reserves_duracio_segons_bucket{ruta="/reserves",le="0.1"} 78201
api_reserves_duracio_segons_bucket{ruta="/reserves",le="0.5"} 91043
...

# HELP api_reserves_confirmades_total Reserves confirmades
# TYPE api_reserves_confirmades_total counter
api_reserves_confirmades_total 92841

# k8s/entorns/pro/scaledobject-api-reserves.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-reserves
  namespace: rutas-norte-pro
  labels:
    app: api-reserves
    app.kubernetes.io/part-of: rutas-norte
    entorn: pro
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-reserves

  pollingInterval: 15
  cooldownPeriod: 300

  # NO escalem a zero. api-reserves es l'API que sosté la venda: una
  # arrencada en fred davant d'un usuari que vol comprar es inacceptable.
  # 4 repliques es el terra de disponibilitat acordat (09-01, i 09-05).
  minReplicaCount: 4
  maxReplicaCount: 30

  fallback:
    failureThreshold: 3
    # Si Prometheus cau, fixem 12 repliques: el triple del minim. Es un
    # numero conservador que aguanta un dia normal amb folganca i ens dona temps
    # a arreglar Prometheus sense risc de caiguda.
    replicas: 12

  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      name: hpa-api-reserves
      behavior:
        # El MATEIX behavior asimetric de 09-01: pujar en zero segons,
        # baixar despres de deu minuts de calma sostinguda.
        scaleUp:
          stabilizationWindowSeconds: 0
          selectPolicy: Max
          policies:
            - type: Percent
              value: 100
              periodSeconds: 30
            - type: Pods
              value: 6
              periodSeconds: 30
        scaleDown:
          stabilizationWindowSeconds: 600
          selectPolicy: Min
          policies:
            - type: Percent
              value: 20
              periodSeconds: 120
            - type: Pods
              value: 3
              periodSeconds: 120

  triggers:
    # DISPARADOR PRINCIPAL: peticions per segon, mesurades a Prometheus.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitoratge.svc.cluster.local:9090
        # Nom amb el qual apareixera la metrica a l'HPA generat.
        metricName: api_reserves_peticions_per_segon
        query: |
          sum(
            rate(
              api_reserves_peticions_total{
                namespace="rutas-norte-pro",
                app="api-reserves"
              }[2m]
            )
          )
        # 85 peticions per segon i replica.
        #
        # Calcul (de la prova de carrega de 09-06): una replica d'api-reserves
        # amb 412m de CPU sosté ~120 rps abans que la latencia p95 superi
        # els 300 ms. Deixem un 30 % de marge per absorbir el temps
        # d'arrencada de les repliques noves: 120 x 0,7 = 84 -> 85 rps.
        threshold: "85"
        activationThreshold: "5"
        ignoreNullValues: "true"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

    # XARXA DE SEGURETAT 1: CPU. Si per el que sigui les peticions son molt mes
    # cares de l'habitual (una consulta patologica, un client abusiu), la
    # CPU ho detectara encara que el nombre de peticions sigui normal.
    - type: cpu
      metricType: Utilization
      metadata:
        value: "70"

sum(
  rate(
    api_reserves_peticions_total{
      namespace="rutas-norte-pro",
      app="api-reserves"
    }[2m]
  )
)

kubectl get hpa hpa-api-reserves -n rutas-norte-pro

NAME               REFERENCE                 TARGETS                   MINPODS  MAXPODS  REPLICAS
hpa-api-reserves   Deployment/api-reserves   1247/85 (avg), 34%/70%    4        30       15

Valor total de la consulta: 1.247 rps (totes les repliques juntes)
Repliques actuals: 15
Valor per replica: 1.247 / 15 = 83,1 rps
Objectiu: 85 rps

ratio = 83,1 / 85 = 0,978  ->  dins de la banda de tolerancia. Estable.

# 1. Esborrar l'HPA manual
kubectl delete hpa api-reserves -n rutas-norte-pro

# 2. Crear el ScaledObject
kubectl apply -f k8s/entorns/pro/scaledobject-api-reserves.yaml

# 3. Verificar que KEDA ha creat el seu
kubectl get hpa -n rutas-norte-pro

Error from server: admission webhook "vscaledobject.kb.io" denied the request:
the workload 'api-reserves' of type 'apps/v1.Deployment' is already managed by
the hpa 'api-reserves'

09:59:50  4 repliques d'api-reserves. Transit normal: 180 rps.
10:00:00  S'obre la venda. El transit salta a 2.400 rps en 40 segons.
10:00:15  Prometheus recol·lecta. El rate[2m] encara reflecteix la mitjana dels
          ultims 2 minuts, que inclou 1m50s de calma: ~400 rps.
10:00:15  KEDA/HPA: 400/4 = 100 rps per replica. Ratio 1,18. Demana 5 repliques.
          <- MOLT PER SOTA del necessari. El rate[2m] SUAVITZA el pic.
10:00:45  El rate ja reflecteix millor la realitat: ~1.500 rps. Demana 18 repliques.
10:01:15  Els primers pods nous estan Ready.
10:02:30  S'assoleixen les 28 repliques necessaries.

DEGRADACIO: dos minuts i mig al moment de mes valor de l'any.

# k8s/entorns/pro/scaledobject-api-reserves.yaml (fragment afegit)
  triggers:
    - type: prometheus
      # ... (el disparador principal de dalt, sense canvis)

    - type: cpu
      # ... (la xarxa de seguretat, sense canvis)

    # DISPARADOR DE PREESCALFAMENT: el pont de maig.
    #
    # La venda obre a les 10:00 del 25 d'abril. A les 9:30 ja volem
    # 25 repliques ARRENCADES I CALENTES: pool de connexions a PostgreSQL
    # establert, cache de rutes poblada, JIT de Node.js escalfat.
    #
    # Recorda la regla de l'HPA: GUANYA EL DISPARADOR QUE DEMANA MES REPLIQUES.
    # Entre les 9:30 i les 14:00, el terra son 25 repliques. Si el transit
    # real en demana mes, el disparador de Prometheus puja fins a 30.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "30 9 25 4 *"        # 25 d'abril a les 9:30
        end: "0 14 25 4 *"          # 25 d'abril a les 14:00
        desiredReplicas: "25"

    # Preescalfament diari de la franja de mes venda.
    # De dilluns a diumenge, de 9:30 a 13:00, terra de 10 repliques.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "30 9 * * *"
        end: "0 13 * * *"
        desiredReplicas: "10"

    # Reforc de cap de setmana: divendres tarda i dissabte mati concentren
    # les reserves d'escapada.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "0 16 * * 5"         # Divendres a les 16:00
        end: "0 22 * * 6"           # Dissabte a les 22:00
        desiredReplicas: "15"

# k8s/entorns/pro/scaledobject-farciment-capacitat.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: farciment-capacitat
  namespace: rutas-norte-pro
spec:
  scaleTargetRef:
    name: farciment-capacitat
  minReplicaCount: 2
  maxReplicaCount: 10
  cooldownPeriod: 300
  triggers:
    # Ampliar el coixi UNA HORA ABANS que les repliques d'api-reserves.
    # Aixi el Cluster Autoscaler te temps d'arrencar els nodes, i a les
    # 9:30, quan el cron d'api-reserves demani 25 repliques, hi ha lloc.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "30 8 25 4 *"        # 8:30, una hora abans
        end: "0 15 25 4 *"
        desiredReplicas: "10"

08:30  El cron amplia el farciment de 2 a 10 pods.
       8 pods de farciment passen a Pending.
08:31  El Cluster Autoscaler detecta els pendents, demana 3 nodes.
08:35  Els nodes estan Ready. El farciment es col·loca.
       CAPACITAT LLESTA I PAGADA, pero ocupada per pods que no fan res.
09:30  El cron d'api-reserves demana 25 repliques.
       El planificador DESALLOTJA els pods de farciment (prioritat -10).
09:30  Les 25 repliques es col·loquen en SEGONS. No cal esperar nodes.
09:31  Els pods de farciment passen a Pending -> el CA arrenca mes nodes ->
       el coixi es regenera per al que vingui.
09:32  25 repliques Ready i calentes.
10:00  OBERTURA. Zero degradacio.

t=0     Arriba un missatge a la cua.
t=0-15  KEDA ho detecta al seu seguent cicle (pollingInterval).
t=15    KEDA escala el Deployment de 0 a 1.
t=16    El planificador col·loca el pod. Si NO hi ha lloc -> +3 min (09-03).
t=17    El kubelet descarrega la imatge. Si esta cachejada, ~2 s; si no, 20-60 s.
t=20    El contenidor arrenca. Node.js: ~15 s fins a estar llest.
t=35    Connexio a PostgreSQL i a RabbitMQ establerta.
t=36    Es processa el primer missatge.

RETARD TOTAL: entre 35 segons i 4 minuts.

# k8s/entorns/dev/scaledobject-apagat-nocturn.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-reserves-horari
  namespace: rutas-norte-dev
  labels:
    app: api-reserves
    entorn: dev
spec:
  scaleTargetRef:
    name: api-reserves
  # Fora de l'horari laboral: ZERO. L'entorn s'apaga sol.
  minReplicaCount: 0
  maxReplicaCount: 3
  cooldownPeriod: 300
  triggers:
    # De dilluns a divendres, de 7:45 a 19:30: 1 replica encesa.
    # 7:45 perque estigui calenta quan arribi l'equip a les 8:00.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "45 7 * * 1-5"
        end: "30 19 * * 1-5"
        desiredReplicas: "1"

spec:
  # Quan HI HA activitat: minim 4 repliques.
  minReplicaCount: 4
  # Quan NO hi ha activitat: 1 replica encesa.
  idleReplicaCount: 1

kubectl get scaledobject -n rutas-norte-pro

NAME                   SCALETARGETKIND      SCALETARGETNAME        MIN  MAX  READY  ACTIVE  FALLBACK  AGE
worker-notificacions   apps/v1.Deployment   worker-notificacions   0    25   False  False   False     4m

kubectl describe scaledobject worker-notificacions -n rutas-norte-pro

Status:
  Conditions:
    Type:     Ready
    Status:   False
    Reason:   ScalerFailed
    Message:  error creating scaler for trigger 0: error parsing rabbitmq metadata:
              no host setting given
Events:
  Type     Reason         Age   From           Message
  ----     ------         ----  ----           -------
  Warning  ScalerFailed   4m    keda-operator  error creating scaler for trigger 0

kubectl describe hpa keda-hpa-worker-notificacions -n rutas-norte-pro

Conditions:
  Type           Status  Reason                   Message
  ----           ------  ------                   -------
  AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
  ScalingActive  False   FailedGetExternalMetric  unable to get external metric
                         rutas-norte-pro/s0-rabbitmq-notificacions-confirmacio/&LabelSelector{...}:
                         unable to fetch metrics from external metrics API:
                         rpc error: code = Unknown desc = error inspecting rabbitMQ:
                         Object Not Found

kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/rutas-norte-pro/s0-rabbitmq-notificacions-confirmacio?labelSelector=scaledobject.keda.sh%2Fname%3Dworker-notificacions" \
  | python3 -m json.tool

{
    "kind": "ExternalMetricValueList",
    "apiVersion": "external.metrics.k8s.io/v1beta1",
    "items": [
        {
            "metricName": "s0-rabbitmq-notificacions-confirmacio",
            "metricLabels": null,
            "timestamp": "2026-05-01T10:14:32Z",
            "value": "29800"
        }
    ]
}

kubectl logs -n keda deployment/keda-operator --tail=100 | grep -i "worker-notificacions"

ERROR  scale_handler  error getting scale decision  {"scaledObject.Namespace": "rutas-norte-pro",
       "scaledObject.Name": "worker-notificacions",
       "error": "dial tcp 10.96.42.17:5672: connect: connection refused"}

kubectl logs -n keda deployment/keda-operator-metrics-apiserver --tail=50

# Pot KEDA arribar a RabbitMQ?
kubectl run prova-connectivitat --rm -it --restart=Never \
  -n keda --image=busybox:1.36 -- \
  wget -qO- --timeout=5 http://rabbitmq.rutas-norte-pro.svc.cluster.local:15672/api/overview

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: permetre-keda-a-rabbitmq
  namespace: rutas-norte-pro
spec:
  podSelector:
    matchLabels:
      app: rabbitmq
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: keda
      ports:
        - protocol: TCP
          port: 5672
        - protocol: TCP
          port: 15672

kubectl port-forward -n monitoratge svc/prometheus-operated 9090:9090

# Errors de l'escalador: si puja, KEDA no pot consultar la font
sum(rate(keda_scaler_errors_total[5m])) by (scaledObject, scaler) > 0

# Valor de la metrica que KEDA esta reportant
keda_scaler_metrics_value{scaledObject="worker-notificacions"}

# ScaledObjects en fallback: senyal que una font esta caiguda
keda_scaled_object_errors_total > 0

kubectl get scaledobject -n rutas-norte-pro

NAME                   SCALETARGETKIND      MIN  MAX  READY  ACTIVE  FALLBACK  AGE
worker-notificacions   apps/v1.Deployment   0    25   True   True    True      3h

kubectl describe hpa keda-hpa-worker-notificacions -n rutas-norte-pro

Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Metrics:
  ( current / target )
  "s0-rabbitmq-notificacions-confirmacio" (target average value):  6 / 2500
Events: <none>

kubectl logs -n keda deployment/keda-operator --tail=20 | grep worker

ERROR  scale_handler  error getting metric for scaler  {"scaledObject.Name": "worker-notificacions",
       "scaler": "rabbitmqScaler",
       "error": "Get \"https://rabbitmq.rutas-norte-pro.svc.cluster.local:15671/api/queues/%2F/notificacions-confirmacio\":
       dial tcp 10.96.42.17:15671: i/o timeout"}

Cada factura: 8 segons, processades d'una en una.
Factures per segon per worker = 1 / 8 = 0,125 factures/s

12.000 factures en 4 hores = 12.000 / 14.400 s = 0,833 factures/s d'entrada.

Si el sistema processes just a la velocitat d'entrada, la cua no creixeria
pero tampoc es buidaria, i una factura esperaria... depen de la cua
acumulada. Necessitem processar MES RAPID que l'entrada.

Enfocament per l'objectiu de 30 minuts:
  En 30 minuts (1.800 s) entren 0,833 x 1.800 = 1.500 factures.
  Perque cap no esperi mes de 30 min, cal processar 1.500 factures
  en menys de 1.800 s: capacitat >= 1.500 / 1.800 = 0,833 factures/s.

Amb marge del 100 % (per absorbir rafegues, que l'entrada no es uniforme):
  Capacitat objectiu: 1,67 factures/s

Workers = 1,67 / 0,125 = 13,3  ->  14 workers

Primera hora: 6.000 factures = 1,67 factures/s d'entrada.
Amb 14 workers: 14 x 0,125 = 1,75 factures/s de capacitat.
Capacitat > entrada: la cua no creix de forma sostinguda. Correcte.

Acumulacio maxima estimada: ~500 factures.
Temps de buidatge d'aquestes 500: 500 / 1,75 = 286 s = 4,8 minuts.
MOLT per sota dels 30 minuts. De sobres.

14 workers x 250m = 3,5 nuclis
Quota lliure: 8 nuclis.

Hi caben. I hi ha marge per pujar el maxReplicaCount a 25:
  25 x 250m = 6,25 nuclis < 8. Tambe hi cap.

Memoria: 14 x 512Mi = 7 GiB. Sense problema.

Al pic, quants missatges hi ha a la cua?

L'acumulacio maxima estimada es ~500 factures (calculat a dalt). Pero
si l'escalat triga a arrencar, l'acumulacio inicial es mes gran: en els
primers 2 minuts amb 1 sola replica, entren 1,67 x 120 = 200 factures
i se'n processen 0,125 x 120 = 15. Acumulacio: ~185.

Volem que amb ~500 missatges a la cua hi hagi 14 workers:
  threshold = 500 / 14 = 35,7  ->  arrodonim a 35

Verificacio amb altres valors de cua:
  100 missatges -> sostre(100/35) = 3 workers
  300 missatges -> sostre(300/35) = 9 workers
  500 missatges -> sostre(500/35) = 15 workers  (objectiu assolit)
  700 missatges -> sostre(700/35) = 20 workers  (sostre)

Durada de la tasca: 8 segons.
Temps d'arrencada d'un pod: ~15 segons.

8 < 15: la tasca dura MENYS que l'arrencada.
-> ScaledObject. Un ScaledJob gastaria mes temps arrencant que treballant.

# k8s/entorns/pro/scaledobject-worker-factures.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-factures
  namespace: rutas-norte-pro
  labels:
    app: worker-factures
    app.kubernetes.io/part-of: rutas-norte
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker-factures

  pollingInterval: 20

  # 15 minuts sense activitat abans d'apagar. Generos perque les factures
  # arriben a rafegues despres dels tancaments de venda, i apagar entre rafegues
  # costaria mes en arrencades en fred que mantenir un pod.
  cooldownPeriod: 900

  # ESCALAT A ZERO. Ningu espera una factura en temps real: l'objectiu
  # son 30 minuts, i l'arrencada en fred son 35 segons. Sobra marge.
  # Fora de temporada es generen poques factures al dia.
  minReplicaCount: 0

  # 20 workers = 5 nuclis, dins dels 8 lliures de la quota.
  # 20 x 0,125 = 2,5 factures/s = 9.000 factures/hora. Molt per sobre
  # de les 3.000/hora del pic del pont.
  maxReplicaCount: 20

  fallback:
    failureThreshold: 3
    # Si el magatzem de la cua no respon, 5 workers: suficient per al
    # cabal habitual mentre s'investiga.
    replicas: 5

  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      name: hpa-worker-factures
      behavior:
        scaleUp:
          # Sense espera: si hi ha cua, hi ha feina pendent.
          stabilizationWindowSeconds: 0
          selectPolicy: Max
          policies:
            - type: Percent
              value: 100
              periodSeconds: 30
            - type: Pods
              value: 5
              periodSeconds: 30
        scaleDown:
          # 10 minuts: les factures arriben a rafegues despres de cada tancament
          # de venda, i no volem destruir workers entre rafega i rafega.
          stabilizationWindowSeconds: 600
          selectPolicy: Min
          policies:
            - type: Percent
              value: 30
              periodSeconds: 120

  triggers:
    - type: rabbitmq
      metadata:
        protocol: amqp
        queueName: factures-pendents
        mode: QueueLength
        # 1 worker per cada 35 factures a la cua.
        #
        # Calcul: un worker processa 1 factura cada 8 s = 0,125 factures/s.
        # L'entrada al pic del pont es 0,833 factures/s (12.000 en 4 h).
        # Amb marge del 100 % per a rafegues: capacitat objectiu 1,67 factures/s.
        # Workers necessaris: 1,67 / 0,125 = 14.
        # Acumulacio de cua esperada al pic: ~500 missatges.
        # threshold = 500 / 14 = 35.
        #
        # Objectiu de negoci: cap factura no espera mes de 30 minuts.
        # Amb 14 workers, el temps de buidatge de 500 factures es ~5 minuts.
        value: "35"
        # Per sota de 3 factures, es considera inactiu. Permet
        # l'escalat a zero sense que 1-2 missatges residuals ho impedeixin.
        activationValue: "3"
      authenticationRef:
        name: rabbitmq-credencials

    # Xarxa de seguretat: si el magatzem d'objectes s'alenteix i les factures
    # triguen 30 s en lloc de 8, la cua creixera i el disparador principal
    # ja ho detectara. Pero si el problema es de CPU (un PDF patologic),
    # aquest disparador ho cobreix.
    - type: cpu
      metricType: Utilization
      metadata:
        value: "80"

Get "https://rabbitmq.rutas-norte-pro.svc.cluster.local:15671/api/queues/..."
dial tcp 10.96.42.17:15671: i/o timeout

KEDA vol que l'HPA calculi 6 repliques.
L'HPA calcula: sostre(repliquesActuals x valor / threshold)

Pero com que l'HPA fa servir AverageValue, la mecanica del fallback de KEDA es
reportar un valor tal que el resultat siguin les repliques del fallback.

A la sortida veiem "6 / 2500", que es el valor de fallback reportat.
L'HPA amb 1 replica calcula sostre(1 x 6/2500) = sostre(0,0024) = 1.

# 1. Existeix el Service i respon?
kubectl get svc rabbitmq -n rutas-norte-pro
kubectl get endpoints rabbitmq -n rutas-norte-pro

# 2. Hi ha una NetworkPolicy nova?
kubectl get networkpolicy -n rutas-norte-pro
kubectl describe networkpolicy -n rutas-norte-pro

# 3. Provar la connectivitat DES DEL namespace de KEDA
kubectl run prova --rm -it --restart=Never -n keda --image=busybox:1.36 -- \
  wget -qO- --timeout=5 http://rabbitmq.rutas-norte-pro.svc.cluster.local:15672/api/overview

# k8s/entorns/pro/networkpolicy-keda-rabbitmq.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: permetre-keda-a-rabbitmq
  namespace: rutas-norte-pro
spec:
  podSelector:
    matchLabels:
      app: rabbitmq
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: keda
      ports:
        - protocol: TCP
          port: 15672      # API de gestio HTTP
        - protocol: TCP
          port: 5672       # AMQP

# Si RabbitMQ no te TLS configurat al port de gestio, el
# TriggerAuthentication ha d'apuntar a http://...:15672, no https://...:15671
stringData:
  host: "amqp://keda_lector:[email protected]:5672/"

spec:
  # Durant la temporada alta, no escalem a zero. El fallback funciona
  # de forma fiable i l'arrencada en fred no penalitza en el pitjor moment.
  minReplicaCount: 2
  idleReplicaCount: 1     # Fora d'activitat, 1 replica encesa
  fallback:
    failureThreshold: 3
    replicas: 8

# 1. LA MES IMPORTANT: KEDA en mode fallback.
#    Si aixo es dispara, l'escalat NO esta funcionant encara que tot sembli normal.
keda_scaled_object_errors_total > 0

# 2. Errors de l'escalador: KEDA no pot consultar la font.
sum(rate(keda_scaler_errors_total[5m])) by (scaledObject, scaler) > 0

# 3. Alerta de negoci: la cua creix sense que creixin els workers.
#    Aquesta es la que hauria detectat el problema en 2 minuts.
(
  rabbitmq_queue_messages{queue="notificacions-confirmacio"} > 5000
)
and
(
  kube_deployment_status_replicas{deployment="worker-notificacions"} < 5
)

# 4. Antiguitat del missatge mes vell de la cua: l'indicador de negoci real.
rabbitmq_queue_head_message_timestamp_seconds > 600

motor-preus            -> Deployment + ScaledObject (API HTTP)
recalcul-preus         -> CronJob (proces nocturn)

# k8s/entorns/pro/scaledobject-motor-preus.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: motor-preus
  namespace: rutas-norte-pro
  labels:
    app: motor-preus
    app.kubernetes.io/part-of: rutas-norte
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: motor-preus

  pollingInterval: 15
  cooldownPeriod: 300

  # NO escalem a zero. Es al cami critic de cada cerca de rutes:
  # la seva latencia entra directament a la d'api-reserves. Una arrencada en fred
  # de 35 s amb usuaris esperant es inacceptable, i a mes esgotaria el pool
  # de connexions sortints d'api-reserves: degradacio en cascada.
  #
  # 3 repliques de terra: 3 x 180 = 540 rps, molt per sobre del minim de 50.
  # El terra el marca la DISPONIBILITAT (09-05), no la capacitat.
  minReplicaCount: 3

  # Sostre: 2.500 rps / 180 rps per replica = 13,9 -> 14.
  # Amb marge del 40 %: 20 repliques.
  maxReplicaCount: 20

  fallback:
    failureThreshold: 3
    # Si Prometheus cau, 8 repliques = 1.440 rps de capacitat. Cobreix el
    # transit habitual amb folganca mentre s'arregla.
    replicas: 8

  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      name: hpa-motor-preus
      behavior:
        scaleUp:
          # Sense espera. Es un servei intern amb latencia critica: qualsevol
          # retard es propaga a la cerca de rutes de l'usuari final.
          stabilizationWindowSeconds: 0
          selectPolicy: Max
          policies:
            - type: Percent
              value: 100
              periodSeconds: 30
            - type: Pods
              value: 5
              periodSeconds: 30
        scaleDown:
          # 10 minuts. El transit de cerques es molt irregular (rafegues de
          # usuaris comparant rutes) i no volem destruir capacitat entre
          # rafega i rafega.
          stabilizationWindowSeconds: 600
          selectPolicy: Min
          policies:
            - type: Percent
              value: 20
              periodSeconds: 120

  triggers:
    # DISPARADOR PRINCIPAL: peticions per segon.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitoratge.svc.cluster.local:9090
        metricName: motor_preus_peticions_per_segon
        query: |
          sum(
            rate(
              motor_preus_peticions_total{
                namespace="rutas-norte-pro",
                app="motor-preus"
              }[2m]
            )
          )
        # 125 rps per replica.
        #
        # Calcul: una replica sosté 180 rps abans que la latencia p95
        # superi els 80 ms. Apliquem un marge del 30 % per cobrir el temps
        # d'arrencada de les repliques noves: 180 x 0,7 = 126 -> 125.
        #
        # Amb 2.500 rps: sostre(2500/125) = 20 repliques. Just el maxReplicaCount.
        threshold: "125"
        activationThreshold: "10"
        ignoreNullValues: "true"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

    # DISPARADOR SECUNDARI: la LATENCIA, que es el que importa al negoci.
    #
    # Si el p95 supera els 60 ms (75 % de l'objectiu de 80 ms), escalem
    # encara que les peticions per segon estiguin dins del normal. Aixo cobreix
    # el cas de peticions anormalment CARES: rutes amb moltes combinacions,
    # o una degradacio d'una dependencia.
    #
    # NOTA IMPORTANT: escalar per latencia es una arma de doble tall. Si la
    # latencia puja per una causa que NO es resol amb mes repliques (per
    # exemple, PostgreSQL saturat), escalar empitjora les coses (09-01, el
    # coll d'ampolla real). Per aixo el llindar es conservador i el
    # maxReplicaCount esta acotat.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitoratge.svc.cluster.local:9090
        metricName: motor_preus_latencia_p95
        query: |
          histogram_quantile(0.95,
            sum(rate(motor_preus_duracio_segons_bucket{
              namespace="rutas-norte-pro"
            }[2m])) by (le)
          ) * 1000
        threshold: "60"
        activationThreshold: "1"
        ignoreNullValues: "true"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

    # XARXA DE SEGURETAT: CPU.
    - type: cpu
      metricType: Utilization
      metadata:
        value: "70"

# k8s/entorns/pro/cronjob-recalcul-preus.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: recalcul-preus
  namespace: rutas-norte-pro
  labels:
    app: recalcul-preus
    app.kubernetes.io/part-of: rutas-norte
spec:
  schedule: "0 3 * * *"
  timeZone: "Europe/Madrid"      # CronJob suporta timeZone des de 1.27
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 2
      # Si a les 2 hores no ha acabat, tallar. Evita que un proces penjat
      # ancori un node (09-03) i se solapi amb el transit del mati.
      activeDeadlineSeconds: 7200
      ttlSecondsAfterFinished: 86400
      template:
        metadata:
          labels:
            app: recalcul-preus
          annotations:
            # NO desallotjar durant l'execucio: perdriem 45 minuts de
            # feina. El Cluster Autoscaler respectara aquesta anotacio (09-03).
            cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
        spec:
          restartPolicy: OnFailure
          containers:
            - name: recalcul
              image: registry.rutasnorte.example/motor-preus:4.2.0
              command: ["node", "recalcular-matriu.js"]
              resources:
                requests:
                  cpu: "4"
                  memory: 4Gi
                limits:
                  cpu: "4"
                  memory: 4Gi
                  # requests == limits -> QoS Guaranteed. S'executa a les 3:00
                  # amb el cluster buit: no li traiem capacitat a ningu i
                  # garantim que no el desallotgin per pressio de memoria.

# k8s/entorns/pro/vpa-recalcul-preus.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: recalcul-preus
  namespace: rutas-norte-pro
spec:
  targetRef:
    apiVersion: batch/v1
    kind: CronJob
    name: recalcul-preus
  updatePolicy:
    # Initial: cada execucio nova neix amb els recursos apresos. Mai
    # desallotgem un Job a mig cami.
    updateMode: "Initial"
  resourcePolicy:
    containerPolicies:
      - containerName: recalcul
        minAllowed:
          cpu: "2"
          memory: 2Gi
        maxAllowed:
          cpu: "8"
          memory: 8Gi
        controlledValues: RequestsAndLimits

# Latencia alta AMB les repliques al maxim: el problema NO es resol escalant
(
  histogram_quantile(0.95, sum(rate(motor_preus_duracio_segons_bucket[5m])) by (le)) * 1000 > 80
)
and
(
  kube_deployment_status_replicas{deployment="motor-preus"} >= 20
)