Aller au contenu

Labels for monitoring (NGOT)#

Labels Prometheus#

  • obs_client :

    • valeur :
      • zones de type "service" : nom du client tel que défini dans les zones de type "contract" dans ngot-zones (exemple : zone.parent_zone_name).
      • zones de type "cluster" : nom de la zone parente (exemple : zone.parent_zone_name).
    • localisation : à placer dans tous les serviceMonitors/podMonitors/probes.

  • ngot_contract (seulement sur les services) :

    • valeur : contrat tel que défini dans la clé des zones de type "contract" dans ngot-zones.
    • localisation : à placer dans tous les serviceMonitors/podMonitors/probes.

  • namespace :

    • valeur : namespace tel que défini dans K8S.
    • localisation : est placé automatiquement par l’exporter.

  • cluster :

    • valeur : cluster tel que défini dans la clé des zones de type "cluster" dans ngot-zones.
    • localisation : placé dans dans un label externe de Prometheus (zone cluster).

  • ngot_service (seulement sur les services) :

    • valeur : service tel que défini dans la clé des zones de type "service" dans ngot-zones.
    • localisation : à placer dans tous les serviceMonitors/podMonitors/probes.

Tip

Label cluster : comme il s'agit d'un label externe sur les Prometheus des zones cluster, il n'existe pas sur les métriques lors de l'évaluation des PrometheusRules. Conséquences :

  • ce label ne doit pas être utilisé dans les PrometheusRules évaluées sur les Prometheus des zones cluster ;
  • il est posé automatiquement par Prometheus, en particulier sur les alertes qui auront donc bien ce label.

Labels k8s#

Labels k8S pour prise en compte par Prometheus-Operator#

CRDs concernés par ces labels :

  • serviceMonitor
  • podMonitor
  • probe
  • prometheusRules

CRDs PF cluster#

Namespace :

  • alerting rules : namespaces dédiés : prometheusrules (rules custom) et prometheusrules-dashboards-upstream (rules upstream)
  • recording rules : dans le namespace où on en a besoin (alerting rules ou dashboards)
  • podMonitor et serviceMonitor : dans le namespace de l'application
  • probe : à priori pas besoin. Si le besoin apparaît, on placera les probes dans le namespace de l'application.

Label : cloudservicesfactory/managed-by: "corp-cluster"

CRDs PF centraux#

Namespace :

  • rules :
    • alerting rules : namespace dédié : prometheusrules (le même que pour les CRDs PF cluster)
    • recording rules : dans le namespace où on en a besoin (alerting rules ou dashboards)
  • podMonitor et serviceMonitor : dans le namespace de l'application
  • probe : dans le namespace de l'application (pour Boyana, seulement le namespace de Blackbox-Exporter)

Label : cloudservicesfactory/managed-by: "corp-central"

CRDs clients#

Cette section concerne les custom resources prises en compte par le Prometheus des zones de supervision clientes.

Les custom resources peuvent être catégorisées ainsi :

  • les serviceMonitors déployés par nous pour scrapper :
    • les exporters que l'on fournit aux clients,
    • alertmanager;
  • les probes/prometheusRules déployées par les clients avec le gitops worflow.
ServiceMonitor#

Namespace : namespaces dédiés. Le namespace doit avoir un label avec le nom du contrat : servicemonitors-<nom du contrat>

Label : pas de label à poser.

Configuration Prometheus : 

serviceMonitorSelector: {
    matchExpressions: [{
        key:      "cloudservicesfactory/managed-by"
        operator: "NotIn"
        values: ["corp-central", "corp-cluster"]
    }]
}

Note

Ce serviceMonitorSelector est obligatoire. Avec ces valeurs, cela rend le serviceMonitor exclusif : soit il est exposé au client, soit il est exposé aux équipes PF. Il ne peut pas être les deux à la fois.

Probes/PrometheusRules#

Namespace : namespaces dédiés. Le namespace doit avoir un label avec le nom du contrat :

  • probes-<nom du contrat> pour les probes
  • rules-<nom du contrat> pour les rules

Label : pas de label à poser.

Configuration Prometheus : 

probeSelector: {
    matchExpressions: [{
        key:      "cloudservicesfactory/managed-by"
        operator: "NotIn"
        values: ["corp-central", "corp-cluster"]
    }]
}
ruleSelector: {
    matchExpressions: [{
        key:      "cloudservicesfactory/managed-by"
        operator: "NotIn"
        values: ["corp-central", "corp-cluster"]
    }]
}

Note

probeSelector et ruleSelector sont obligatoires. Avec ces valeurs, cela rend la probe ou la rule exclusive : soit elle est exposée au client, soit elle est exposée aux équipes PF. Elle ne peut pas être les deux à la fois.

Labels k8S pour prise en compte par Grafana : Datasources#

  • label : grafana_datasource: "1"
  • namespace : le namespace où est déployé Grafana qui utilise la datasource

Labels k8S pour prise en compte par Grafana : Dashboards#

Grafana central#

  • label : grafana_dashboard: "1"
  • namespace : dashboards-corp

Grafana des clients#

Pour les dashboards dédiés aux clients, avec le Gitops Workflow :

  • label : grafana_dashboard: "1"
  • namespace : grafana-dashboards-CONTRACT-NAME

Note

Le 28/02/2023, il est décidé de ne pas proposer le Gitops Workflow aux clients. Les labels ci-dessus ne sont donc indiqués qu'à titre informatif, au cas où la décision changerait.

Labels Karma/Alertmanager#

  • Confiuration Karma : 

    ui:
  multiGridLabel: obs_client

  • Configuration Alertmanager : 

    group_by:
  - cluster
  - alertname

  • Labels obligatoires dans les alertes :

    • severity
    • obs_client
    • namespace