Überwachung von Postgres innerhalb von Openshift

Guten Tag, liebe Habr-Bewohner!

Heute möchte ich Ihnen erzĂ€hlen, wie wir dringend PostgreSQL und einige weitere EntitĂ€ten im OpenShift-Cluster ĂŒberwachen wollten und wie wir das umgesetzt haben.

Wir hatten Folgendes:

  • OpenShift
  • Helm
  • Prometheus


FĂŒr die Arbeit mit der Java-Anwendung war alles ziemlich einfach und klar, genauer gesagt:

1) HinzufĂŒgen zur build.gradle

 implementation "io.micrometer:micrometer-registry-prometheus"

2) Starten von Prometheus mit Konfiguration

 - job_name: 'job-name'
    metrics_path: '/actuator/prometheus'
    scrape_interval: 5s
    kubernetes_sd_configs:
    - role: pod
      namespaces:
        names: 
          - 'name'

3) HinzufĂŒgen der Anzeige in Grafana

Alles war ziemlich einfach und alltĂ€glich, bis der Zeitpunkt kam, an dem wir die Datenbanken ĂŒberwachen mussten, die sich in unserem Namespace befanden (ja, das ist schlecht, so macht es niemand, aber es gibt unterschiedliche Situationen).

Wie funktioniert das?

Neben dem Pod mit PostgreSQL und Prometheus benötigen wir noch eine weitere EntitÀt - den Exporter.

Ein Exporter ist im abstrahierten Sinne ein Agent, der Metriken von der Anwendung oder sogar Server. Der PostgreSQL-Exporter ist in Go geschrieben, funktioniert nach dem Prinzip der AusfĂŒhrung von SQL-Skripten auf der Datenbank und der anschließenden Abholung der Ergebnisse durch Prometheus. Dies ermöglicht auch die Erweiterung der gesammelten Metriken durch eigene.

Wir deployen ihn so (Beispiel deployment.yaml, unverbindlich):


---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: postgres-exporter
  labels:
    app: {{ .Values.name }}
    monitoring: prometheus
spec:
  serviceName: {{ .Values.name }}
  replicas: 1
  revisionHistoryLimit: 5
  template:
    metadata:
      labels:
        app: postgres-exporter
        monitoring: prometheus
    spec:
      containers:
      - env:
        - name: DATA_SOURCE_URI
          value: postgresdb:5432/pstgr?sslmode=disable
        - name: DATA_SOURCE_USER
          value: postgres
        - name: DATA_SOURCE_PASS
          value: postgres
        resources:
          limits:
            cpu: 100m
            memory: 50Mi
          requests:
            cpu: 100m
            memory: 50Mi
        livenessProbe:
          tcpSocket:
            port: metrics
          initialDelaySeconds: 30
          periodSeconds: 30
        readinessProbe:
          tcpSocket:
            port: metrics
          initialDelaySeconds: 10
          periodSeconds: 30
        image: exporter
        name: postgres-exporter
        ports:
        - containerPort: 9187
          name: metrics

Außerdem benötigten wir einen Service und einen ImageStream.

Nach dem Deployment wollen wir natĂŒrlich, dass sich alle gegenseitig sehen.

FĂŒgen Sie dem Prometheus-KonfigurationsstĂŒck Folgendes hinzu:

  - job_name: 'postgres_exporter'
    metrics_path: '/metrics'
    scrape_interval: 5s
    dns_sd_configs:
    - names:
      - 'postgres-exporter'
      type: 'A'
      port: 9187

Und hier hat alles funktioniert, es bleibt nur noch, all das in Grafana hinzuzufĂŒgen und das Ergebnis zu genießen.

Neben der Möglichkeit, eigene Anfragen hinzuzufĂŒgen, kann man in Prometheus die Einstellungen Ă€ndern, um gezielt die benötigten Metriken zu sammeln.

Auf die gleiche Weise wurde es gemacht fĂŒr:

  • Kafka
  • Elasticsearch
  • Mongo

P.S. Alle Daten zu Namen, Ports und anderem sind erfunden und enthalten keine Informationen.

NĂŒtzliche Links:
Liste verschiedener Exporter

Quelle: habr.com

ZuverlĂ€ssiges Hosting fĂŒr Websites mit DDoS-Schutz kaufen, VPS VDS Server đŸ”„ ZuverlĂ€ssiges Hosting fĂŒr Websites mit DDoS-Schutz kaufen, VPS VDS Server - ProHoster