Ankündigung

Einklappen
Keine Ankündigung bisher.

Überwachung von Serverdiensten

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • saegefisch
    antwortet
    Intention: Überwachung aller anstehenden Updates auf allen Servern inkl. LXC + VM -> Anzeige in edomi
    Leider liefert telegraf zwar viele Daten an influxDB, aber keine Informationen zur aktuellen Distribution oder anstehender Update, erst recht nicht getrennt nach regulär, security.
    Auf dedizierten Servern (z.B. RevProxy) lasse ich ein kleines Script laufen, dass die Daten per MQTT an edomi liefert und per influxDB zu grafana. Für Proxmox fehlte mir das noch, weil ich dies für auch für alle LXC und VM abfragen wollte.

    Das folgende Script liefert genau dies für Proxmox Host, dynamisch alle LXC + VM und als Gesamtsumme im influxDB2-line format, um es per telegraf an influxDB2 und MQTT zu senden. Zum Beispiel:

    Code:
    update,host=HAL-proxmox regular=0i,security=1i,dist="Debian GNU/Linux 11 (bullseye)"
    update,host=HAL-ubuntu-LTS regular=0i,security=0i,dist="Ubuntu 22.04.1 LTS",vmid="103",object="lxc"
    update,host=HAL-edomi-dev regular=14i,security=5i,dist="Rocky Linux 8.6 (Green Obsidian)",vmid="20231",object="lxc"
    update,host=HAL-edomi-P1 regular=14i,security=5i,dist="Rocky Linux 8.6 (Green Obsidian)",vmid="20232",object="lxc"
    update,host=HAL-TVH regular=0i,security=0i,dist="Ubuntu 22.04.1 LTS",vmid="30018",object="lxc"
    update,host=HAL-30 regular=0i,security=0i,dist="Ubuntu 22.04.1 LTS",vmid="30019",object="lxc"
    update,host=HAL-pihole regular=0i,security=0i,dist="Ubuntu 22.04.1 LTS",vmid="30096",object="lxc"
    update,host=HAL-pihole-IOT regular=0i,security=0i,dist="Ubuntu 22.04.1 LTS",vmid="80096",object="lxc"
    update,host=HAL-AVAHI regular=0i,security=0i,dist="Ubuntu 18.04.5 LTS",vmid="99098",object="lxc"
    update,host=HAL-11 regular=0i,security=0i,dist="Ubuntu 22.04.1 LTS",vmid="10018",object="qemu"
    update,host=HAL-proxmox_SUM regular=28i,security=11i​
    ​
    Vielleicht finden das auch der ein oder andere hilfreich. Viel Spaß damit!

    Bleibt nur noch die Frage, wie man aus dem via MQTT kommenden JSON eine dynamische Liste machen kann, statt wie im folgenden Screenshot nur statisch...siehe anderes Thema Unbenannt.jpg Unbenannt2.jpg

    Code:
    sudo nano /etc/telegraf/script/upgrade_check_guest.sh
    Code:
    #!/usr/bin/env bash
    REG_SUM=()
    SEC_SUM=()
    REG=()
    SEC=()
    OUTPUT=""
    
    check_update_lxc () {
    HOST=$(sudo pct list | grep $1 | awk '{print $3}')
    DIST=$(sudo lxc-attach -n $1 -- cat /etc/*release | grep "\PRETTY" | sed -e 's/[^"]*"\(.*\)/"\1/g')
    ID_LIKE=$(sudo lxc-attach -n $1 -- cat /etc/*release | grep "\ID_LIKE" | sed -e 's/.*=\(.*\)/\1/' | sed 's/"//g')
    case "$ID_LIKE" in
    debian)
    sudo lxc-attach -n $1 -- apt-get update -qq
    REG=$(sudo lxc-attach -n $1 -- apt list --upgradable 2>/dev/null | grep "\/stable" | grep -v "\-security" | wc -l)
    SEC=$(sudo lxc-attach -n $1 -- apt list --upgradable 2>/dev/null | grep "\/stable" | grep "\-security" | wc -l)
    let "REG_SUM+=${REG}"
    let "SEC_SUM+=${SEC}"
    ;;
    "rhel centos fedora")
    sudo lxc-attach -n $1 -- yum --quiet check-update 1> /dev/null
    ALL=$(sudo lxc-attach -n $1 -- yum check-update | grep "\.el" | wc -l)
    SEC=$(sudo lxc-attach -n $1 -- yum check-update --security | grep "\.el" | wc -l)
    let "REG=${ALL}-${SEC}"
    let "REG_SUM+=${REG}"
    let "SEC_SUM+=${SEC}"
    ;;
    esac
    OUTPUT+="update,host=${HOST} regular=${REG}i,security=${SEC}i,dist=${DIST},vmid=\"${1}\",object=\"lxc\""$'\n'
    }​
    
    check_update_qemu () {
    HOST=$(sudo qm guest exec $1 "hostname" | jq -r '."out-data"')
    DIST=$(sudo qm guest exec $1 cat /etc/*release | jq -r '."out-data"' | grep "\PRETTY" | sed -e 's/[^"]*"\(.*\)/"\1/g')
    ID_LIKE=$(sudo qm guest exec $1 cat /etc/*release | jq -r '."out-data"' | grep "\ID_LIKE" | sed -e 's/.*=\(.*\)/\1/' | sed 's/"//g')
    case "$ID_LIKE" in
    debian)
    dummy=$(sudo qm guest exec $1 "apt-get" -- "update" "-qq")
    REG=$(sudo qm guest exec $1 "apt" -- "list" "--upgradable" | jq -r '."out-data"' | grep "\/stable" | grep -v "\-security" | wc -l)
    SEC=$(sudo qm guest exec $1 "apt" -- "list" "--upgradable" | jq -r '."out-data"' | grep "\/stable" | grep "\-security" | wc -l)
    let "REG_SUM+=${REG}"
    let "SEC_SUM+=${SEC}"
    ;;
    "rhel centos fedora")
    dummy=$(sudo qm guest exec $1 "yum" -- "--quiet" "check-update" "1> /dev/null")
    ALL=$(sudo qm guest exec $1 "yum" -- "check-update" | jq -r '."out-data"' | grep "\.el" | wc -l)
    SEC=$(sudo qm guest exec $1 "yum" -- "check-update" "--security" | jq -r '."out-data"' | grep "\.el" | wc -l)
    let "REG=${ALL}-${SEC}"
    let "REG_SUM+=${REG}"
    let "SEC_SUM+=${SEC}"
    ;;
    esac
    OUTPUT+="update,host=${HOST} regular=${REG}i,security=${SEC}i,dist=${DIST},vmid=\"${1}\",object=\"qemu\""$'\n'
    }​
    
    # A) Check upgrade for the Host
    # regular updates | security updates | hostname | distribution/version
    sudo apt-get update -qq
    REG=$(sudo apt list --upgradable 2>/dev/null | grep "\/stable" | grep -v "\-security" | wc -l)
    SEC=$(sudo apt list --upgradable 2>/dev/null | grep "\/stable" | grep "\-security" | wc -l)
    let "REG_SUM+=${REG}"
    let "SEC_SUM+=${SEC}"
    HOST1=$(hostname)
    DIST=$(sudo cat /etc/*release | grep "\PRETTY" | sed -e 's/[^"]*"\(.*\)/"\1/g')
    OUTPUT+="update,host=${HOST1} regular=${REG}i,security=${SEC}i,dist=${DIST}"$'\n '
    
    ## B) Check upgrades for all active LXC containers
    for cx in `sudo lxc-ls --active --line`; do
    # echo -e "LXC:$cx"
    check_update_lxc $cx
    done
    
    ## C) Ckeck upgrades for all active VM/QEMU
    for vm in $(sudo qm list | grep "\running" | awk '{print $1}'); do
    # echo -e "VM:$vm"
    check_update_qemu $vm
    done
    
    ## D) SUM over all
    OUTPUT+="update,host=${HOST1}_SUM regular=${REG_SUM}i,security=${SEC_SUM}i"$'\n'
    
    ## Final output with \n for influxDB line protocol (Lines separated by the newline character \n represent a single point in InfluxDB)
    # For MQTT-outbound processor option 'batch=true' is needed
    echo "$OUTPUT"​
    Code:
    sudo nano /etc/telegraf/telegraf.conf
    Ausschnitt
    Code:
    [[inputs.exec]]
    alias = "update_check"
    interval = "3600s"
    commands = [ "/etc/telegraf/script/upgrade_check_guest.sh" ]
    timeout = "120s"
    name_override = "update"
    data_format = "influx"
    
    [[outputs.influxdb_v2]]
    urls = <DEININFLUXDB2>
    token = <DEINTOKEN>
    organization = "orga"
    bucket = "technik"
    insecure_skip_verify = true
    precision = "s"
    namepass = ["update"]
    
    [[outputs.mqtt]]
    servers = <DEINMQTT>
    namepass = ["update"]
    topic_prefix = "status"
    qos = 2
    username = <USER>
    password = <DEINPW>
    insecure_skip_verify = true
    batch = true
    data_format = "json"​
    Leider muss man dem telegraf user eine ganze Reihe potenter SUDOs geben:
    Code:
    sudo visudo -f /etc/sudoers.d/telegraf
    Code:
    telegraf ALL=NOPASSWD:/usr/bin/apt-get update *,/usr/bin/apt list *,/usr/bin/cat /etc/*release, /usr/bin/lxc-ls *, /usr/sbin/pct list, /usr/bin/lxc-attach *,/usr/sbin/qm guest exec*,/usr/sbin/qm list
    UPDATE 06.11.2022: Script und Ausgabe aktualisiert, um auch mit rhel/centos/rocky klar zu kommen
    Zuletzt geändert von saegefisch; 15.11.2022, 22:40.

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Zitat von jonofe Beitrag anzeigen
    telegraf ALL=NOPASSWD:/usr/bin/apt-get
    Yepp, genau so funktioniert es jetzt!

    Code:
    sudo visudo -f /etc/sudoers.d/telegraf
    mit genau dem von Dir genannten Inhalt und es funzt: Script liefert nun sauber Daten
    --> GELÖST

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Hi André,
    noch nicht, aber nach den Erkenntnissen war ich schon auf die Suche gegangen und auf ähnliches gestoßen, aber noch keine Zeit zum testen gehabt. Ich denke, damit wird es lösbar sein. Warum die Fehler beim service nicht angezeigt wurden, verstehe ich noch immer nicht, aber egal - letztlich ist die Ursache gefunden und eine Lösung vermutlich machbar und nah.
    Ich werde berichten, wenn es läuft, wie es soll incl. dem ganzen Script.

    Dank' Dir!

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Funktioniert es denn damit nun?

    Ansonsten:

    Du könntest dem User telegraf sudo Rechte für das apt-get Kommando geben und dann ein 'sudo' vor dem apt-get einfügen.

    Wenn ich es richtig im Kopf habe in /etc/sudoers in etwa so:

    telegraf ALL=NOPASSWD:/usr/bin/apt-get

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Code:
    E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
    E: Unable to lock directory /var/lib/apt/lists/
    W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied)
    W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied)
    E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
    E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?
    das hätte ich im Log vom service dann auch erwartet.

    Code für Abfrage anstehender Updates mit sudo. $1 enthält die LXC-ID.
    Code:
    check_update () {
      sudo lxc-attach -n $1 -- apt-get update -qq
      res=$(sudo lxc-attach -n $1 -- apt-get upgrade --show-upgraded --assume-no)
    ...
    Zuletzt geändert von saegefisch; 01.11.2022, 20:17.

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Zitat von saegefisch Beitrag anzeigen
    Erstaunlich ist, dass der service mit den offenbar zu geringen Rechten nicht die Fehler auswirft, die man bekommt, wenn man es direkt ohne sudo aufruft.
    Welche Fehlermeldung ist es denn?

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Ursache: Aber ich habe jetzt mal die direkte Ausführung ohne sudo gemacht - und schon funktioniert es auch so nicht. Das Thema ist also nicht telegraf. Sondern das script braucht sudo-Rechte, um Daten zu liefern - konkret lxc-attach.

    Erstaunlich ist, dass der service mit den offenbar zu geringen Rechten nicht die Fehler auswirft, die man bekommt, wenn man es direkt ohne sudo aufruft. Sonst wäre ich ja direkt drauf gestoßen...

    Lösung?
    Wie löst man derlei, ohne ein Scheunentor zu öffnen?​ wie kann man genau einem Script das erlauben, ohne telegraf als ganzes als sudo laufen zu lassen.
    Und auch nicht, dass jemand das script manipuliert und mit Umweg so Unfug damit treiben könnte? Letzteres vermutlich banal - nur sudo darf es ändern.
    Zuletzt geändert von saegefisch; 01.11.2022, 19:53.

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Danke für Eure Impulse.
    Aus dem status des service ("sudo service telegraf status") den Pfad zur .service ermittelt:
    Code:
    ● telegraf.service - The plugin-driven server agent for reporting metrics into InfluxDB
    Loaded: loaded (/lib/systemd/system/telegraf.service; enabled; vendor preset: enabled)
    Active: active (running) since Mon 2022-10-31 19:11:52 CET; 23h ago
    Docs: https://github.com/influxdata/telegraf
    Main PID: 2707048 (telegraf)
    Tasks: 10 (limit: 38284)
    Memory: 35.9M
    CPU: 2min 30.493s
    CGroup: /system.slice/telegraf.service
    └─2707048 /usr/bin/telegraf -config /etc/telegraf/telegraf.conf -config-directory /etc/telegraf/telegraf.d
    sudo nano /lib/systemd/system/telegraf.service
    Code:
    [Unit]
    Description=The plugin-driven server agent for reporting metrics into InfluxDB
    Documentation=https://github.com/influxdata/telegraf
    After=network-online.target
    Wants=network-online.target
    
    [Service]
    Type=notify
    EnvironmentFile=-/etc/default/telegraf
    User=telegraf
    ExecStart=/usr/bin/telegraf -config /etc/telegraf/telegraf.conf -config-directory /etc/telegraf/telegraf.d $TELEGRAF_OPTS
    ExecReload=/bin/kill -HUP $MAINPID
    Restart=on-failure
    RestartForceExitStatus=SIGPIPE
    KillMode=control-group
    
    [Install]
    WantedBy=multi-user.target
    Der Pfad zur conf-Datei (/etc/telegraf/telegraf.conf) in der .service ist korrekt und zeigt auf meine aktuelle Datei - die direkt ausgeführt sauber funktioniert und eben als service nicht.

    Code:
    ll /etc/telegraf/
    total 400
    drwxr-xr-x 2 root root 4096 Nov 1 14:44 script
    -rw-r--r-- 1 root root 3395 Oct 31 18:32 telegraf.conf
    -rw-r--r-- 1 root root 395636 Oct 3 21:31 telegraf.conf.sample
    drwxr-xr-x 2 root root 4096 Dec 1 2020 telegraf.d
    Verzeichnis telegraf.d ist leer

    Zitat von jonofe Beitrag anzeigen
    Es kann noch an einer unterschiedlichen Ausführungsumgebung liegen (bash vs. sh) die ggf. mit unterschiedlichen environment settings kommt.


    Die .conf-Datei ist vermutlich erst mal frei davon. Meine beiden Skript sind ausführbar (rwxr-xr-x)
    • in beiden Aufrufen geht das hier 1. Script für NUT/USV mit "#!/bin/bash",
    • nur im direkt scheint das 2. Script zu laufen mit "#!/usr/bin/env bash"
    ...könnte das die Ursache auf einem Proxmox-Server sein?...ist beides bash und ähnlich, aber nicht gleich? Spannend...muss mich dazu mal schlau machen...

    -------
    Nachtrag:
    Ausführung service:
    Code:
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! Starting Telegraf 1.24.2
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! Available plugins: 222 inputs, 9 aggregators, 26 processors, 20 parsers, 57 outputs
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! Loaded inputs: exec (2x) socket_listener
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! Loaded aggregators:
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! Loaded processors: converter
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! Loaded outputs: influxdb_v2 (2x) mqtt
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! Tags enabled: host=proxmox
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:"proxmox", Flush Interval:10s
    Nov 01 18:56:07 HAL-proxmox systemd[1]: Started The plugin-driven server agent for reporting metrics into InfluxDB.
    Nov 01 18:56:07 HAL-proxmox telegraf[4158370]: 2022-11-01T17:56:07Z I! [inputs.socket_listener] Listening on udp://[::]:8089
    ​Ausführung direkt:
    Code:
    2022-11-01T18:05:03Z I! Starting Telegraf 1.24.2
    2022-11-01T18:05:03Z I! Available plugins: 222 inputs, 9 aggregators, 26 processors, 20 parsers, 57 outputs
    2022-11-01T18:05:03Z I! Loaded inputs: exec (2x) socket_listener
    2022-11-01T18:05:03Z I! Loaded aggregators:
    2022-11-01T18:05:03Z I! Loaded processors: converter
    2022-11-01T18:05:03Z I! Loaded outputs: influxdb_v2 (2x) mqtt
    2022-11-01T18:05:03Z I! Tags enabled: host=proxmox
    2022-11-01T18:05:03Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:"proxmox", Flush Interval:10s
    2022-11-01T18:05:03Z I! [inputs.socket_listener] Listening on udp://[::]:8089
    sieht beides gleich aus, beide zeigen 2x Script.
    Zuletzt geändert von saegefisch; 01.11.2022, 19:45.

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Wie sieht denn die telegraf.service Datei aus?
    Es kann noch an einer unterschiedlichen Ausführungsumgebung liegen (bash vs. sh) die ggf. mit unterschiedlichen environment settings kommt. In der telegraf.service sollte ja sichtbar sein, wie der genaue Aufruf ist.

    Einen Kommentar schreiben:


  • vento66
    antwortet
    Keine Ahnung von telegraf. Aber eventuell ist im startscript eine andere conf Datei angegeben…. Nur mal so als Vermutung.

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    ich habe (wissentlich) nur eine - die ich kenne. Könnte man das irgendwo sehen?
    Das wäre aber eine gute Erklärung. Mir kam in den Sinn, dass der Service die conf vielleicht als Snapshot in der alten Version irgendwo hin gelegt hat und weiter zieht. Aber wie sieht man das und wie kann man den Service zwingen, auch die aktuelle zu nehmen?

    Einen Kommentar schreiben:


  • vento66
    antwortet
    Gibt es evtl eine andere conf Datei, die der service nutzt?

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Schon wieder 2h versucht...ich verstehe es nicht... wie kann das sein:

    telegraf : Hat jemand eine Idee, warum direkt Ausführung und als service sich bei unveränderter(!) CONF unterschiedlich verhalten könnten?​

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Mal eine Frage zu telegraf auf dem proxmox-Server (also letztlich Debian)... ich habe das erstaunliche Phänomen, dass ich die telegraf.conf-Datei angepasst habe um einen weiteren INPUT (script "update_check.sh" - liefert die Anzahl anstehender update-Pakete). Wenn man telegraf mit
    Code:
    sudo telegraf --debug
    starte, wird alles korrekt ausgeführt und an InfluxDB2 in die beiden richtigen Buckets "proxmox" und "technik" mit richtigen Namen und Tags ausgegeben.
    Wenn ich aber mit
    Code:
    sudo service telegraf start
    starte, funktioniert es nicht vollständig

    Einzige Besonderheit: Verwendung von "namedrop" und "namepass" mit mehreren Einträgen. Wie gesagt...im direkten Aufruf geht alles wie erwartet, aber als Service kommt nur "proxmox" und "ups" in influxDB2 an, nicht aber "update"

    >>Hat jemand eine Idee, warum direkt und service sich unterschiedlich verhalten könnten?

    Reicht nach Änderung der .conf nicht stop und start des Dienstes, sondern es gibt ein Geheimnis? Habe auch schon disable und
    Code:
    sudo systemctl enable telegraf.service
    versucht - erfolglos.

    Code:
    # für Proxmox-Metriken (build-in)
    [[inputs.socket_listener]]
    interval = "10s"
    service_address = "udp://:8089"
    
    # Ausgabe an influxDB 2
    [[outputs.influxdb_v2]]
    urls = [ "https://<IP>:9926" ]
    token = "<TOKEN>"
    organization = "orga"
    bucket = "proxmox"
    namedrop = ["ups","update"]
    
    [[inputs.exec]]
    alias = "ups_check"
    interval = "60s"
    commands = [ "/etc/telegraf/script/exec_nut.sh" ]
    timeout = "5s"
    name_override = "ups"
    data_format = "influx"
    
    [[inputs.exec]]
    alias = "update_check"
    interval = "120s"
    commands = [ "/etc/telegraf/script/upgrade_check.sh" ]
    timeout = "50s"
    name_override = "update"
    data_format = "influx"
    
    # Ausgabe an influxDB 2
    [[outputs.influxdb_v2]]
    urls = [ "https://<IP>:9926" ]
    token = "<TOKEN>"
    organization = "orga"
    bucket = "technik"
    namepass = ["ups","update"]​
    Zuletzt geändert von saegefisch; 31.10.2022, 19:43.

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Anmerkung: mit InfluxDB 2.x kann man jetzt auch echten HTTP-Request-Check auf die - mit 2.x eingeführte - GUI machen und so verlässlich prüfen, ob influxDB2 noch "genug da ist", um eine valide Webseite anzubieten und z.B. die Version per API auszules​en.

    Mit Hostcheck und HTTP-Request kann man vieles in edomi sauber prüfen. z.B. dass mein nextcloud gerade nicht ok ist, aber influxDB2 erreichbar ist mit Version 2.4.0 und TVH eine saubere Senderliste liefert, also nicht down oder irgendwie anders fest steckt - alles schon gesehen...

    Unbenannt.jpg Unbenannt2.jpg
    Zuletzt geändert von saegefisch; 31.10.2022, 19:55.

    Einen Kommentar schreiben:

Lädt...
X