Per configurare l'osservabilità RHACM

Per installare l'operatore RHACM e abilitarne le funzionalità di osservabilità, procedere come segue:

1. Accedi alla tua istanza di OpenShift.
2. Nella sezione "Ecosistema" del Catalogo software
3. Scegli uno spazio dei nomi
4. Nella ricerca, cerca "Advanced Cluster Management" per Kubernetes
5. Selezionare "Installa" se non è già installato
6. Una volta installato, selezionalo nella sezione “Ecosistema” alla voce “Operatori installati”
7. Nella scheda " MultiClusterHub ", fare clic su "Crea" MultiClusterHub
8. Assegnagli un nome appropriato e fai clic su “Crea”
9. Vai alla sezione "Archiviazione" all'indirizzo StorageClasses
10. Assicurati che sia impostato un StorageClass come predefinito per la distribuzione dell'infrastruttura. Ad esempio, se si utilizza ODF, assicurarsi che la classe "ocs-storagecluster-ceph-rdb-virtualization" sia impostata sul valore predefinito. Se così non fosse, clicca sui 3 puntini accanto all' StorageClass e desiderata e seleziona "Imposta come predefinita"
11. Seguire i passaggi descritti all'indirizzo https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.14/html-single/observability/index#enabling-observability per abilitare i moduli di osservabilità di RHACM

Se si configura Thanos con IBM Cloud® Object Storage, il file thanos-object-storage.yaml avrà un aspetto simile al seguente:

apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  thanos.yaml: |
    type: s3
    config:
      bucket: <bucket-name>
      endpoint: s3.us-east.cloud-object-storage.appdomain.cloud
      insecure: true
      access_key: XXXX
      secret_key: XXXX

Le credenziali del servizio devono essere chiavi HMAC create nell'istanza di IBM Cloud Object Storage. I valori di access_key e secret_key saranno quelli HMAC forniti.

Avvisi

Panoramica

Gli avvisi di sistema predefiniti sono gestiti da uno stack di monitoraggio integrato di OpenShift's e riguardano aspetti a livello di piattaforma:
Ambito: Monitoraggio dell'infrastruttura a cluster singolo
Spazio dei nomi: openshift-monitoring su ciascun cluster gestito
Componenti:

• Operatore addetto al monitoraggio dei cluster
• Prometheus Operatore
• Prometheus (per le metriche del cluster)
• AlertManager (per gli avvisi relativi ai cluster)

Se gli avvisi di sistema predefiniti non sono sufficienti a coprire il tuo scenario aziendale, puoi configurare avvisi personalizzati, che possono essere gestiti dallo stack di osservabilità di RHACM e supportano scenari multi-cluster:
Ambito: monitoraggio di applicazioni multi-cluster e risorse personalizzate
Spazio dei nomi: open-cluster-management-observability sul cluster hub
Componenti:

• Query Thanos (vista delle metriche globali)
• Thanos Ruler (valutazione centralizzata degli allarmi)
• AlertManager (sistema di allerta multi-cluster)

Creazione di avvisi di sistema

Per gli avvisi di sistema (gestiti dallo spazio dei nomi openshift-monitoring ), seguire la procedura riportata di seguito per configurare gli avvisi. Il sistema di notifiche supporta l'integrazione con PagerDuty,, Slack ed e-mail.

1. Accedi alla tua istanza di OpenShift.
2. Nella sezione "Amministrazione" del cluster Settings88 su Alertmanager
3. Configurare uno dei ricevitori esistenti elencati nella tabella in basso oppure fare clic su “Crea ricevitore”
4. Assegnare un nome appropriato
5. Nella sezione "Tipo di ricevitore", selezionarne uno dal menu a tendina
   1. Se selezioni " PagerDuty, ", ti serviranno una chiave di instradamento e un " URL ".
   2. Se selezioni "Email", ti servirà un server SMTP.
   3. Se selezioni Slack, ti serviranno l' URL e del webhook e il nome del canale (può essere un nome utente per i messaggi diretti, senza il simbolo @).
6. Per l'instradamento delle etichette, seleziona in base agli avvisi per i quali desideri inviare una notifica.
   1. Ad esempio, severity = critical invia tutti gli avvisi critici, mentre severity = warning invia tutti gli avvisi di avvertimento.
   2. È possibile lasciare questo campo vuoto affinché tutti gli avvisi generino una notifica

È possibile fare clic sulla scheda "Regole di avviso", che mostrerà le regole di avviso predefinite esistenti relative agli avvisi di sistema. Prendiamo ad esempio le regole di allerta per il cluster di archiviazione Ceph, come illustrato di seguito: ciò significa che dovrebbe essere attivato un allarme se l'utilizzo dello spazio di archiviazione supera il 75%.

Creazione di avvisi personalizzati

Per gli avvisi personalizzati (gestiti dallo spazio dei nomi open-cluster-management-observability ):
Quando le regole di avviso predefinite non coprono uno scenario richiesto, è necessario creare regole di avviso personalizzate. L'esempio seguente crea un avviso su Slack quando una macchina virtuale nel namespace predefinito non è in stato di esecuzione. Questo scenario non è contemplato dalle regole di avviso predefinite e richiede una regola personalizzata in RHACM. Completa i seguenti passi:

1. Verificare se esiste la metrica " Prometheus " kubevirt_vm_info. Accedi al pod " observability-thanos-query " nel namespace " open-cluster-management-observability " ed esegui il seguente comando curl per verificare che la metrica esista: curl -s 'http://localhost:9090/api/v1/query' --data-urlencode 'query=kubevirt_vm_info'.

$ curl -s 'http://localhost:9090/api/v1/query' --data-urlencode 'query=kubevirt_vm_info'
{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"kubevirt_vm_info","cluster":"local-cluster","clusterID":"110b2032-b6b9-455a-abd5-9949482b61df","container":"virt-controller","endpoint":"metrics","flavor":"small","instance":"10.129.0.198:8443","job":"kubevirt-prometheus-metrics","machine_type":"pc-q35-rhel9.6.0","name":"centos-stream9-white-mink-62","namespace":"acm-test","os":"centos-stream9","pod":"virt-controller-7744b59dd8-dk7tw","receive":"true","service":"kubevirt-prometheus-metrics","status":"running","status_group":"running","tenant_id":"2c1cf409-966c-4c2d-bd57-f24c4c5a9393","workload":"server"},"value":[1762574206.765,"1"]},{"metric":{"__name__":"kubevirt_vm_info","cluster":"local-cluster","clusterID":"110b2032-b6b9-455a-abd5-9949482b61df","container":"virt-controller","endpoint":"metrics","instance":"10.129.0.198:8443","instance_type":"u1.medium","job":"kubevirt-prometheus-metrics","machine_type":"pc-q35-rhel9.6.0","name":"rhel-10-rose-damselfly-10","namespace":"acm-test","pod":"virt-controller-7744b59dd8-dk7tw","preference":"rhel.10","receive":"true","service":"kubevirt-prometheus-metrics","status":"running","status_group":"running","tenant_id":"2c1cf409-966c-4c2d-bd57-f24c4c5a9393"},"value":[1762574206.765,"1"]}],"analysis":{}}}

2. Creare un file YML di ConfigMap relativo alla regola di avviso personalizzata. Supponiamo che il nome della configmap sia " thanos-ruler-custom-rules.yaml ". Il contenuto può essere il seguente.

apiVersion: v1
kind: ConfigMap
metadata:
  name: thanos-ruler-custom-rules
  # need to ensure namespace is "open-cluster-management-observability"
  namespace: open-cluster-management-observability
  labels:
    # need this label to ensure custom alert rules are automatically mounted into Thanos Ruler pods
    thanos-ruler-rule: "true"
data:
  # name has to be custom_rules.yaml, custom alert rules are automatically mounted into Thanos Ruler pods successfully
  custom_rules.yaml: |
    groups:
    - name: VirtualMachineAlerts
      interval: 30s
      rules:
      - alert: VirtualMachineNotRunning
        expr: kubevirt_vm_info{status!="running"} > 0
        for: 2m
        annotations:
          summary: "VM {{ $labels.name }} is Not in running status on {{ $labels.cluster }}"
          description: "VM {{ $labels.name }} in namespace {{ $labels.namespace }} is not running."
        labels:
          severity: critical
          alert_type: vm_not_running

L'idea di fondo è quella di sfruttare le metriche esistenti di Prometheus, ovvero "kubevirt_vm_info" e PromQL kubevirt_vm_info {status!="running"} > 0, che possono generare un avviso qualora venga rilevato che alcune macchine virtuali non si trovano nello stato "Running".

Attenzione: per garantire che le regole di avviso personalizzate vengano integrate correttamente e in modo automatico nei pod di Thanos Ruler, è necessario che siano soddisfatte le seguenti 2 condizioni:

• Assicurati che la configmap sia etichettata con: thanos-ruler-rule: "true"
• Assicurarsi che l’impostazione “key” sia impostata su “ custom_rules.yaml ”

Attenzione: il valore di b: alert_type: vm_not_running deve corrispondere al segreto che verrà creato a breve.

3. Applicare la configmap eseguendo il comando "oc -n open-cluster-management-observability apply -f thanos-ruler-custom-rules.yaml ". Verifica quindi l'output " /etc/thanos/rules/thanos-ruler-custom-rules da thanos-ruler-custom-rules", che indica che la regola personalizzata è stata associata al pod "observability-thanos-rule".

% oc describe pod observability-thanos-rule-0

Supporti:

  /etc/thanos/config/thanos-ruler-config from thanos-ruler-config (ro)

  /etc/thanos/configmaps/alertmanager-ca-bundle from alertmanager-ca-bundle (rw)

  /etc/thanos/rules/thanos-ruler-custom-rules from thanos-ruler-custom-rules (rw)

  /etc/thanos/rules/thanos-ruler-default-rules from thanos-ruler-default-rules (rw)

  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c55nd (ro)

  /var/thanos/rule from data (rw)

4. Crea un file YAML segreto denominato “ alertmanager-config.yaml ”, che contenga le impostazioni relative al destinatario, all’URL del webhook di Slack, al canale Slack, ecc.

Attenzione: assicurarsi che il valore di alert_type corrisponda a quello definito nella configmap che verrà creata in seguito.

apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-config
  # namespace has to be open-cluster-management-observability
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  alertmanager.yaml: |
    global:
      resolve_timeout: 5m
      # your slack webhook url
      slack_api_url: 'https://hooks.slack.com/services/\<replace_with_your_webhook\>'
    route:
      receiver: 'default-receiver'
      group_by: ['alertname', 'cluster', 'namespace', 'name']
      group_wait: 10s
      group_interval: 5m
      repeat_interval: 12h
      # Specific sub-route for VM not running alerts
      routes:
        - match:
            # ensure the alert_type is consistent with the one defined in configmap
            alert_type: vm_not_running
          receiver: 'slack-vm-not-running'
          group_wait: 5s
          repeat_interval: 10m
    receivers:
      # default receiver (no-op)
      - name: 'default-receiver'
      # Slack receiver for VM not running alerts
      - name: 'slack-vm-not-running'
        slack_configs:
          # slack channel name, do NOT miss "#" before you type the channel name
          - channel: '#openshift-virt-observability-alerts'   # <-- adjust to your Slack channel
            title: '🚨 VM NOT RUNNING ALERT'
            text: |
              *Alert:* {{ .CommonLabels.alertname }}
              *VM Name:* {{ .CommonLabels.name }}
              *Namespace:* {{ .CommonLabels.namespace }}
              *Cluster:* {{ .CommonLabels.cluster }}
              *Severity:* {{ .CommonLabels.severity | toUpper }}
              *Status:* {{ .Status | toUpper }}
              {{ range .Alerts }}
              *Description:* {{ .Annotations.description }}
              {{ end }}
            send_resolved: true
            color: '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}'
            actions:
              - type: button
                text: 'View in Console'
                url: 'https://console-openshift-console.apps.{{ .CommonLabels.cluster }}/k8s/ns/{{ .CommonLabels.namespace }}/virtualmachines/{{ .CommonLabels.name }}'

5. Per applicare il segreto, eseguire il comando: oc -n open-cluster-management-observability apply -f alertmanager-config.yaml

6. Per arrestare una macchina virtuale, eseguire il comando: virtctl stop `` e attendere che la macchina virtuale si arresti

7. Controlla il canale Slack e verifica se è stato generato un avviso corrispondente, come quello riportato di seguito

È possibile verificare l'avviso generato anche tramite la console di gestione degli avvisi. Per aprire la console di Alert Manager, è possibile eseguire il comando: oc -n open-cluster-management-observability port-forward pod/observability-alertmanager-0 9093:9093, quindi accedere a http://localhost:9093/#/alerts per verificare se l'avviso viene generato in quella pagina. Ecco un esempio che mostra come viene generato l'avviso "slack-vm-not-running".

8. Avvia una macchina virtuale eseguendo il comando: virtctl start ``, quindi attendi che la macchina virtuale si avvii.

Una volta che la macchina virtuale sarà tornata operativa, controlla il canale Slack in cui verrà segnalato che l'allerta è stata risolta, come mostra l'esempio seguente.

Funzionalità di monitoraggio aggiuntive

RHACM può essere utilizzato per monitorare metriche essenziali quali l'utilizzo della CPU, della memoria, della rete e dello spazio di archiviazione per un VM, un pod, un nodo del cluster o un intero cluster. La maggior parte di queste metriche può essere monitorata grazie alle funzionalità di osservabilità di base incluse in OpenShift,, ma RHACM consente all'utente di monitorare tali metriche su più cluster gestiti.

RHACM aggiunge dashboard preconfigurate di Grafana, progettate per monitorare metriche specifiche di VM. Ad esempio, all’interno della cartella “ACM / OpenShift Virtualization”, il dashboard “Executive dashboards / Single Virtual Machine View” mostra l’utilizzo della CPU, l’utilizzo della memoria, l’utilizzo della rete (trasmissione/ricezione, pacchetti persi), l'utilizzo dello spazio di archiviazione (IOPS/traffico) e l'utilizzo del filesystem per una singola macchina virtuale VM.

Per una breve panoramica delle metriche visualizzate in ogni dashboard preconfigurata fornita tramite RHACM, nonché delle funzionalità di osservabilità di base di OpenShift, consultare la tabella seguente:

Aggiunta/Personalizzazione dei dashboard

Non è possibile aggiungere nuovi dashboard con l'istanza Grafana predefinita, ma è possibile crearne e personalizzarne di nuovi creando prima un'istanza grafana-dev. Per farlo, è sufficiente seguire le istruzioni riportate nella documentazione sull'osservabilità di RHACM relative alla configurazione dell'istanza di sviluppo di Grafana utilizzando gli script disponibili all'indirizzo https://github.com/open-cluster-management/multicluster-observability-operator.

Se non si dispone dell'accesso all'utente kube:admin (come nel caso di Red Hat OpenShift su IBM Cloud ), creare invece una dashboard tramite una serie di comandi da terminale. Nel terminale, dopo aver eseguito il comando ./setup-grafana-dev.sh --deploy come indicato nelle istruzioni precedenti, eseguire quanto segue:

1. Imposta la variabile d'ambiente utilizzata nei comandi seguenti sul namespace "observability":

   export OBS_NS=open-cluster-management-observability
   

2. Esegui il seguente comando per creare una definizione JSON per il ConfigMap:

   cat <<'EOF' > full-dashboard.json
   {
     "id": null,
     "uid": "60EDAD96-69C2-4047-88AC-541C29BB74BA",
     "title": "VM Metrics Dashboard",
     "tags": ["control-plane", "cluster-metrics"],
     "timezone": "browser",
     "schemaVersion": 30,
     "version": 1,
     "panels": [
       {
         "type": "graph",
         "title": "Top 50 API Server Latency",
         "targets": [{"expr": "apiserver_request_latency_seconds_bucket"}]
       },
       {
         "type": "graph",
         "title": "etcd Latency",
         "targets": [{"expr": "etcd_disk_wal_fsync_duration_seconds_bucket"}]
       },
       {
         "type": "graph",
         "title": "Node CPU Usage",
         "targets": [{"expr": "node_cpu_seconds_total"}]
       },
       {
         "type": "graph",
         "title": "Node Memory Usage",
         "targets": [{"expr": "node_memory_MemAvailable_bytes"}]
       }
     ]
   }
   EOF
   

3. Crea l'oggetto ConfigMap utilizzando la definizione YAML:

   cat <<EOF > full-dashboard.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: full-dashboard
     namespace: $OBS_NS
     labels:
       grafana-custom-dashboard: "true"
     annotations:
       observability.open-cluster-management.io/dashboard-folder: Custom
   data:
     full-dashboard.json: |-
   $(sed 's/^/    /' full-dashboard.json)
   EOF
   

4. Applica il nuovo ConfigMap:

   oc apply -f full-dashboard.yaml
   

Dopo aver applicato l' ConfigMap,, dovrebbe essere stata creata una nuova dashboard " Grafana " per i clienti, che potrà essere ulteriormente modificata.

È possibile creare nuovi dashboard utilizzando le query PromQL attingendo da un’ampia selezione di metriche dei componenti KubeVirt e altre metriche Kubernetes.

Le metriche personalizzate possono essere esportate sia dalle fonti " Piattaforma " che dalle fonti " Carico di lavoro utente ", come descritto nella sezione " Configurazione avanzata dell'osservabilità ". È possibile visualizzare un elenco dei target delle metriche relative alla piattaforma o al carico di lavoro degli utenti disponibili accedendo alla sezione "Observe" all'indirizzo Pagina degli obiettivi e filtrando la "Fonte" rispettivamente per "Piattaforma" o "Utente".

Se non si ha accesso all'utente kube:admin (come nel caso di Red Hat OpenShift su IBM Cloud ), potrebbe essere necessario eseguire i seguenti comandi per creare una serie di metriche personalizzate. Di seguito sono riportati alcuni esempi di ConfigMaps che è possibile creare:

Ecco alcune metriche di base relative a Node Memory e API Server:

1. Crea un file YAML denominato " ConfigMap ":

   cat <<EOF > observability-platform-metrics.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: observability-metrics-custom-allowlist
     namespace: open-cluster-management-observability
   data:
     metrics_list.yaml: |
       names:
         - node_memory_MemTotal_bytes
         - node_memory_MemAvailable_bytes
         - kubelet_runtime_operations_duration_seconds
       recording_rules:
         - record: apiserver_request_duration_seconds:histogram_quantile_90
           expr: histogram_quantile(0.90,sum(rate(apiserver_request_duration_seconds_bucket{job="apiserver", verb!="WATCH"}[5m])) by (verb,le))
         - record: etcd_disk_wal_fsync_duration_seconds:histogram_quantile_90
           expr: histogram_quantile(0.90,sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance,le))
   EOF
   

2. Applicare il file appena creato ConfigMap:

   oc apply -f observability-platform-metrics.yaml
   

Per alcune metriche relative al carico di lavoro degli utenti:

1. Crea un file YAML denominato " ConfigMap ":

   cat <<EOF > observability-uwl-metrics.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: observability-metrics-custom-allowlist
     namespace: open-cluster-management-observability
   data:
     uwl_metrics_list.yaml: |
       names:
         - node_memory_MemTotal_bytes
         - node_memory_MemAvailable_bytes
   EOF
   

2. Applicare il file appena creato ConfigMap:

   oc apply -f observability-uwl-metrics.yaml
   

RightSizing Pannello di controllo delle raccomandazioni

RHACM fornisce inoltre una dashboard che mostra i consigli per ottimizzare l'allocazione della CPU e della memoria in base all'utilizzo delle risorse, qualora la funzionalità Right-Sizing sia abilitata nella risorsa personalizzata " MultiClusterObservability " sul cluster hub.

Visualizzazione delle metriche e dei dashboard

Per visualizzare le metriche di osservabilità e i dashboard inclusi nell'installazione di base di OpenShift:

1. Dal pannello di sinistra della console OpenShift, selezionare "Observability".
2. Seleziona "Metrics" per generare una visualizzazione grafica a partire da una query " PromQL ".
3. Seleziona "Dashboard" e scegli tra una serie di dashboard preconfigurate nell'elenco a discesa "Dashboard".

Per visualizzare le metriche di osservabilità e i dashboard con RHACM installato:

1. Dalla console di OpenShift, seleziona "Tutti i cluster" dal menu a tendina in alto.
   1. ![Menu a tendina di navigazione "Tutti i cluster" nella console OpenShift](../../images/openshift/openshift-observ-dashboard-view-1.png " Menu a tendina di navigazione "Tutti i cluster"")
2. Dalla pagina "Cluster", seleziona il link " Grafana " sulla destra.

   1. 

3. Verrà visualizzata la pagina delle dashboard di Grafana con un elenco di dashboard preconfigurate incluse nell'installazione di RHACM.

Introduzione generale

Sono disponibili due opzioni di registrazione – “ LokiStack ” e “ IBM Cloud Logs” – poiché ciascuna risponde a esigenze diverse. LokiStack offre funzionalità personalizzabili di raccolta e conservazione dei log all’interno del cluster, mentre IBM Cloud Logs garantisce un’esperienza di registrazione dei log gestita, nativa per il cloud e di facile utilizzo. È possibile sceglierne una o utilizzarle entrambe, a seconda delle risorse, delle dimensioni e delle esigenze di visibilità. Le sezioni seguenti illustrano i requisiti di ciascuna opzione e descrivono in dettaglio le funzionalità incluse, in modo da consentirvi di decidere quale soluzione, o combinazione di soluzioni, si adatti meglio al vostro ambiente.

Cose da tenere a mente:

• IBM Cloud Logs supporta una facile integrazione quando l'istanza di Red Hat® OpenShift® Kubernetes Service è gestita.
• LokiStack La funzione di registrazione è disponibile sia per le configurazioni gestite che per quelle RYO e offre un'integrazione nativa all'interno della console nell'ambiente OpenShift.
• OpenShift RHACM è uno strumento per la gestione centralizzata di più cluster di OpenShift, mentre LokiStack funge da sistema di aggregazione dei log all’interno di un singolo cluster di OpenShift.
• Non è necessario avere installato OpenShift Advanced Cluster Management (RHACM) per utilizzare LokiStack per la registrazione dei log.

Installazione e configurazione

Per configurare i log di IBM Cloud e collegarli al proprio cluster OpenShift, procedere come segue:

1. Crea un'istanza di Logs c IBM Cloud
   1. rif.: Istanza di provisioning
   2. È possibile farlo tramite l'interfaccia utente e la riga di comando
2. Crea un bucket di dati di archiviazione
   1. rif.: Configurazione del bucket
   2. Ciò è necessario se si desidera conservare i dati a lungo termine o effettuare ricerche. L'istanza standard di Cloud Logs prevede una conservazione dei log prioritari compresa tra un minimo di 7 giorni e un massimo di 90 giorni
3. Abilitare la registrazione nel cluster Red Hat OpenShift Kubernetes Service
   1. rif.: Collegare ICL con Red Hat OpenShift Kubernetes Service

Rollback/eliminazione dei log - Log di IBM Cloud

Per rimuovere l'integrazione " IBM Cloud Logs" ed eliminare le risorse associate, procedere come segue:

1. Elimina l'istanza di Cloud Logs
   1. rif.: Elimina l'istanza " ICL "
2. Elimina il bucket dei dati di archiviazione
   1. rif.: Elimina bucket

Interfaccia utente di registrazione - Registri di IBM Cloud

Confronto con i log di Aria di VMware ( vRealize: Log Insight vs log di IBM Cloud )

Panoramica dei componenti

Operatore: LokiOperator ( LokiStack )
versione: 6.3.1
fornitore: Red Hat
note: Inoltra i log alla combinazione supportata di Loki e proxy web con integrazione dell'autenticazione OpenShift Container Platform. LokiStack's Il proxy utilizza l'autenticazione OpenShift Container Platform per garantire il multi-tenancy
documentazione: Dimensionamento di Loki

Operatore: Registrazione del sistema " Red Hat OpenShift " ( ClusterLogForwarder (CLF))
versione: 6.3.1
fornitore: Red Hat
note: Il CLF ( ClusterLogForwarder ) consente l'inoltro flessibile dei dati di log verso varie destinazioni, permettendo agli utenti di selezionare i messaggi di log da più fonti, elaborarli tramite pipeline e inviarli a una o più destinazioni. Supporta input per la selezione dei log, output per l'inoltro a sistemi esterni, filtri per la trasformazione o l'eliminazione dei messaggi di log e pipeline che collegano input, filtri e output in un flusso di lavoro completo per l'inoltro dei log.
documentazione: Configurazione di Log Forwarder

Operatore: Operatore per l'osservabilità dei cluster (COO)
versione: 1.3.0
fornitore: Red Hat
note: Il Cluster Observability Operator (COO) è un componente opzionale di OpenShift che consente agli amministratori di implementare stack di monitoraggio personalizzati e altamente configurabili, fornendo un’osservabilità a livello di namespace più approfondita rispetto al sistema predefinito. È in grado di gestire l' Prometheus, per le metriche di alta disponibilità e il supporto alla scrittura remota; Thanos Querier, per l'esecuzione centralizzata di query tra cluster; Alertmanager, per un sistema di avvisi flessibile; i plugin dell'interfaccia utente, per interfacce avanzate di monitoraggio, registrazione e tracciamento; e Incident Detection, per raggruppare gli avvisi correlati in incidenti e aiutare a identificare le cause alla radice.
documento: Funzione del Direttore operativo(COO )

Architettura di registrazione centralizzata

Installazione e configurazione (versione breve con riferimenti)

Per configurare rapidamente la registrazione centralizzata all'interno del cluster utilizzando OpenShift Logging e LokiStack,, procedere come segue:

1. Installare l' LokiOperator,, l' Red Hat OpenShift, il Logging Operator e il Cluster Observability Operator (COO) dal catalogo software.
   1. rif.: Come installare gli operatori
2. Creare e configurare un account di servizio come richiesto dalla funzione di registrazione dei log del cluster
   1. rif.: Impostazioni dell'account di servizio
3. Crea un'istanza di LokiStack
   1. rif.: Crea LokiStack
4. Creare l'interfaccia utente per la registrazione centralizzata
   1. rif.: Creazione dell'interfaccia utente
5. Creare l'istanza di " ClusterLogForwarder " (CLF)
   1. rif.: Creazione di un Log Forwarder

Installazione e configurazione (dettagliata, personalizzata)

Per implementare una configurazione personalizzata di registrazione di LokiStack con account di servizio e specifiche delle risorse dettagliate, procedere come segue:

1. Installare l' LokiOperator,, l' Red Hat OpenShift, il Logging Operator e il Cluster Observability Operator (COO) dal catalogo software.
   1. rif.: Come installare gli operatori
2. Creare e configurare un account di servizio come richiesto dalla funzione di registrazione dei log del cluster
   1. rif.: Impostazioni dell'account di servizio
   2. Comandi per configurare l'account di servizio:

oc create sa loki-collector-sa -n openshift-logging
oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z loki-collector-sa  -n openshift-logging
oc adm policy add-cluster-role-to-user collect-application-logs -z loki-collector-sa -n openshift-logging
oc adm policy add-cluster-role-to-user collect-audit-logs -z loki-collector-sa -n openshift-logging
oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z loki-collector-sa -n openshift-logging

• In questo modo, l'account creato disporrà delle autorizzazioni corrette per i vari tipi di log

3. Crea una risorsa personalizzata " LokiStack " utilizzando un file YAML come input
   1. rif.: Crea LokiStack
   2. Il file YAML personalizzato rappresenta l'esempio migliore di un'istanza funzionante con le ottimizzazioni già implementate:

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  managementState: Managed
  size: 1x.medium
  storage:
    schemas:
      - effectiveDate: "2024-11-11"
        version: v13
    secret:
      name: logging-loki-secret
      type: s3
  storageClassName: ocs-storagecluster-ceph-rbd
  tenants:
    mode: openshift-logging
  template:
    compactor:
      replicas: 1
      resources:
        limits:
          cpu: "1"
          memory: "2Gi"
        requests:
          cpu: "250m"
          memory: "1Gi"
    distributor:
      replicas: 1
    gateway:
      replicas: 1
    indexGateway:
      replicas: 1
    ingester:
      replicas: 2
    querier:
      replicas: 2
    queryFrontend:
      replicas: 2
    ruler:
      replicas: 1
  lokiConfig:
    query_range:
      align_queries_with_step: true
      max_retries: 5
      parallelise_shardable_queries: true
      cache_results: true
      results_cache:
        cache_validity: 10m
        background_writeback: true
    frontend_worker:
      frontend_address: query-frontend-http.logging-loki.svc.cluster.local:9095
      grpc_client_config:
        max_send_msg_size: 104857600
        max_recv_msg_size: 104857600
    querier:
      query_ingesters_within: 12h
      engine:
        timeout: 5m
        max_look_back_period: 672h
    compactor:
      retention_enabled: true
      retention_delete_delay: 2h
      retention_delete_worker_count: 150
      working_directory: /var/loki/compactor
      compaction_window: 24h
      retention_stream:
        default: 30d

• Una volta creato uno spazio di archiviazione PVC, è possibile aumentarlo facilmente, ma non è così semplice ridurlo. Per ridurla, è necessario ridistribuire l'istanza con una nuova serie di valori minimi.
  • L'area di archiviazione può anche essere un bucket di s3.
• Anche se si utilizza Ceph/PVC locale, è necessario un segreto S3 valido.

4. Creare l'interfaccia utente per la registrazione centralizzata
   1. rif.: Creazione dell'interfaccia utente
   2. File YAML personalizzato utilizzato per creare l'interfaccia utente a partire dal COO installato in precedenza:

apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki
    timeout: 30s
    schema: otel

5. Creare la risorsa personalizzata (CR) "Inoltro dei log" utilizzando il metodo YAML
   1. rif.: Creazione di un Log Forwarder
   2. Ecco un esempio di log forwarder in esecuzione per Lokistack:

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: loki-forwarder
  namespace: openshift-logging
spec:
  collector:
    resources:
      requests:
        cpu: 500m
        memory: 4Gi
      limits:
        cpu: 6
        memory: 6Gi
  serviceAccount:
    name: loki-collector-sa
  outputs:
    - name: forward-to-lokistack
      type: lokiStack
      lokiStack:
        authentication:
          token:
            from: serviceAccount
        target:
          name: logging-loki
          namespace: openshift-logging
        tuning:
          deliveryMode: AtLeastOnce
          compression: none
          maxWrite: 10Mi
          minRetryDuration: 2
          maxRetryDuration: 30
  pipelines:
    - name: default-pipeline
      inputRefs:
        - application
        - infrastructure
        - audit
      outputRefs:
        - forward-to-lokistack

• È necessario definire i requisiti minimi di risorse prima della distribuzione, per evitare che il collector smetta di funzionare su ogni Node
• C'è un solo daemonset di raccolta per Node

Note importanti

Taglie Loki:

rif.: documento sulle taglie di Loki

• Al momento della distribuzione, questi sono i limiti massimi generali delle risorse consentiti per ciascuna dimensione
• Una volta impostate le dimensioni dei dischi, non è possibile ridurle; è possibile solo aumentarle. È necessario eliminare la distribuzione e ridistribuire lo stack con i nuovi requisiti minimi.
  • Questo elimina i log, a meno che non ne sia stato effettuato un backup esterno
• Ceph PVC non è necessario; è possibile utilizzare una configurazione di archiviazione esterna o un'altra configurazione di tipo " S3 "

Raccoglitore di dati di log

• Il forwarding richiede un elevato utilizzo di risorse hardware e la memoria dovrà essere dimensionata in modo da adeguarsi alle dimensioni dell'ambiente

Soluzioni di inoltro dei log di terze parti supportate:

• azureMonitor
  • Inoltra i log al monitor " Azure ".
• CloudWatch
  • Inoltra i log a AWS e CloudWatch.
• elasticsearch
  • Inoltra i log a un'istanza esterna di Elasticsearch.
• googleCloudLogging
  • Inoltra i log al sistema di registrazione di Google Cloud.
• http
  • Inoltra i log a un endpoint generico HTTP.
• kafka
  • Inoltra i log a un broker Kafka.
• otlp
  • Inoltra i log utilizzando l' OpenTelemetry Protocol.
• Splunk
  • Invia i log a Splunk.
• syslog
  • Invia i log a un server syslog esterno.

rif.: Uscite di inoltro dei log

Interfaccia utente di registrazione - LokiStack

Confronto con i log di Aria di VMware ( vRealize Log Insight vs LokiStack )

Annullamento/eliminazione delle registrazioni - LokiStack

Per disinstallare LokiStack e rimuovere i componenti di registrazione all'interno del cluster, procedere come segue:

1. Accedi a ciascun operatore ed elimina tutte le istanze create. Questa operazione eliminerà tutti i componenti associati utilizzati per l'esecuzione dei pod dei servizi.
   1. Rif.: Disinstallazione della registrazione

Suite Aria

OpenShift è in grado di riprodurre le funzionalità della suite Aria di VMware tramite l'installazione di base e alcuni operatori aggiuntivi. Per Aria Log Insight sarà necessaria la registrazione dei log di " OpenShift ", mentre gran parte delle funzionalità di Aria Operations sarà disponibile fin dall'inizio. RHACM Observability introduce ulteriori funzionalità per renderlo più in linea con i componenti più ampi di Aria Operations.

IBM Cloud Monitoraggio/Sysdig