Scrutiny SMART Monitoring

[haydibe]

Alles sehr merkwürdig...

 

[plang.pl]

Die Platten scheinen aber zu passen. Wenn ich den Container mit /dev/sda starte, kommt ein Error. Mit /dev/sata1 aber nicht

Ich habs jetzt noch mal so versucht:

version: '3.9'
services:
    scrutiny:
        image: 'ghcr.io/analogj/scrutiny:master-collector'
        container_name: scrutiny-collector
        environment:
            - 'COLLECTOR_API_ENDPOINT=http://10.1.1.10:8080'
        devices:
            - /dev/sata1
            - /dev/sata2
            - /dev/nvme0n1
            - /dev/nvme1n1
        cap_add:
            - SYS_RAWIO
            - SYS_ADMIN
        volumes:
            - '/run/udev:/run/udev:ro'
            - '/volume2/docker/scrutiny:/opt/scrutiny/config'
        restart: always

Ergebnis ist das Gleiche.

 

[haydibe]

Dann tricks die Kiste doch einfach aus, in dem Du die Host devices auf andere Devices im Container mappst:

        devices:
            - /dev/sata1:/dev/sda
            - /dev/sata2:/dev/sdb
            - /dev/nvme0n1
            - /dev/nvme1n1

 

[plang.pl]

Danke für deine Einfälle.
Das hat auch nix gebracht. Ich hatte ja vorher die collector.yaml angepasst, damit /dev/sata genommen wird. Wenn ich das wieder auf /dev/sda ändere, tut sich auch nix.
Ich hab auch mal das privileged flag hinzugefügt. Tut sich immer noch nix.
Ich denke, dass es mal wieder an irgendeiner Synology Eigenheit scheitert...

 

[plang.pl]

Ich hab jetzt auch mal den Part mit den Devices komplett weggelassen, so wie @Adama, es ist immer das gleiche Ergebnis

 

[haydibe]

Würde mich wundern, wenn es ohne device überhaupt geht.. Mehr fällt mir dazu leider auch nicht ein.
Aber wenn es selbst nicht im Container läuft, dann kann es ja eigentlich nur am Kernel liegen, da mehr von der Syno nicht verwendet wird. Leider ist auch der Syno-Kernel ein kleines Flickwerk ^^

 

[Adama]

Da das ja jetzt ein Container ist, teste das nun mal mit "privileged: true" statt des cap_add-Bereiches...

@haydibe Dafür nimmt er ja die collector.yaml.

Aber was das Flickwerk angeht, stimme ich dir zu...

 

[plang.pl]

Hab es nun noch mal so probiert:

version: '3.9'
services:
    scrutiny:
        image: 'ghcr.io/analogj/scrutiny:master-collector'
        container_name: scrutiny-collector
        environment:
            - 'COLLECTOR_API_ENDPOINT=http://10.1.1.10:8080'
        devices:
            - /dev/sata1
            - /dev/sata2
            - /dev/nvme0n1
            - /dev/nvme1n1
        volumes:
            - '/run/udev:/run/udev:ro'
            - '/volume2/docker/scrutiny:/opt/scrutiny/config'
        restart: always
        privileged: true

Mit und ohne den Part mit Devices kommt nix bei der API / am Webserver an.

 

[haydibe]

Priviliged bildet tatsächlich auch mehr ab, als man durch Capabilities hinzufügen erreichen kann. Würde mich aber wundern, wenn es notwendig wäre, da die Binary ja nur SYS_RAWIO benöigt und bei nvme zusätzlich noch SYS_ADMIN. Ich denke nicht das dem Container capabilities fehlen.

Hast Du in der Config mal `type: ['sat,auto']` probiert?

 

[Adama]

Bei meinem Einzelcontainer hat es ohne "privileged" nicht geklappt. Nur mit hat er Daten geliefert.

Konnte man auch im Log sehen...

 

[haydibe]

Ich lass es ohne privilged, dafür unter Angabe der Devices laufen.

 

[plang.pl]

Hast Du in der Config mal `type: ['sat,auto']` probiert?

Jap. Genau das Gleiche.
Es kommt ja auch kein Fehler im Log. Ich kann mir nur noch vorstellen, dass
-der Collector als Einzelcontainer an sich fehlerhaft ist
-irgendwas mit der Übertragung an die API auf dem anderen Server nicht hinhaut

Vielleicht schau ich morgen mal, ob der AIO (also der "master-omnibus") läuft. Und wenn ja, vielleicht kann ich auch von dem die Daten auf den zweiten Server abgreifen

 

[haydibe]

Exec doch mal in den Collector-Container und führ scrutiny-collector-metrics run aus. Dann siehst du ob er nur am Ende Fehler wirft, wenn er die Ergebnisse via api hochpumpen will, oder vorher schon bei den Laufwerken.

 

[plang.pl]

Aha!
Woher nimmst du diesen Befehl?
Es scheitert an den nvmes, wie es aussieht:

Komisch ist aber, dass an der API anscheinend gar nix ankommt. Laut Log hat er ja gesendet

 

[plang.pl]

Halt!
Kommando zurück.
Mit der manuellen Ausführung kommen die Daten an:



Nur die eine nvme will nicht.

 

[haydibe]

Die NVME sollte mit den beiden Capabilities oder dem Priviliged-Mode eigentlich laufen. Kann es sein, dasss der Cronjob einfach nur noch nicht ausgeführt wurde?

Update: achso technisch geht alles. Er ist nur der Meinung, dass das Drive nicht in Ordnung ist.

 

[plang.pl]

nicht ausgeführt wurde?

Das glaube ich mittlerweile auch.

Anscheinend passiert aber kein Fehler beim Auslesen...
Ich kann alle Werte in scrutiny sehen.
Keine Ahnung, warum der Befehl nen Error bei beiden nvmes schmeißt, obwohl die Daten ankommen.
Jetzt macht mir was anderes Sorgen: Heißt das, meine SSD ist im Ar***?



Bis auf die eine (defekte?) SSD sieht die UI nun gut aus:

 

[plang.pl]

Nun mal eben noch den Server am zweiten Standort mit eingebunden.
Interessant: An der 218+ ist es nicht /dev/sata wie bei der 720+, sondern /dev/sda.
Auch interessant: Dort funktioniert es mit ['sat,auto'] gar nicht und ich musste 'sat' nehmen.
Und da zeigt sich der nächste Knaller: Auch dort scheint eine SSD im Ar*** zu sein. So sieht sie aus:


Da im Backup-Server kein RAID besteht, geht das Internet am Standort erst mal flöten, wenn die Platte abraucht, da da nebenbei noch der AdGuard als DNS-Server läuft.
Alles in allem war es gut, dass ich jetzt den Container aufgesetzt habe und die Probleme (relativ) frühzeitig erkannt habe.

So sieht es insgesamt aus:



Mir gefällt das. Bis auf die aussteigenden Platten natürlich - aber da werde ich zeitnah Maßnahmen einleiten.

 

[haydibe]

Deine Posts haben mich inspiriert den Collector auch auf PVE auszurollen. Ich habe nicht mal eine collector.yaml angelegt, sondern alles über Parameter geregelt.

Ich bin ja schon fast neidisch das Deine NVMES so kühl sind. In meinen drei PVE Nodes liegen die Werte bei 40, 54 und 53. Wobei die mit 40c in einem vollumschließenden Kulhkörper Gehäuse lebt. Die 54 Lebt mit einem fetten Kühlkörper, die 53c in einem Tiny m920q ohne Kühlkörper.

Die Proxmox Installation hab ich angelehnt an die manuelle Installation aus Anleitung mit diesen Befehlen gemacht:

DSM_URL=http://dsm:8080

mkdir -p /opt/scrutiny/bin
curl --location https://github.com/AnalogJ/scrutiny/releases/download/v0.7.1/scrutiny-collector-metrics-linux-amd64 --output /opt/scrutiny/bin/scrutiny-collector-metrics
chmod +x /opt/scrutiny/bin/scrutiny-collector-metrics

# Probelauf
/opt/scrutiny/bin/scrutiny-collector-metrics run --api-endpoint "${DSM_URL}" --host-id ${HOSTNAME}

# bestehende Chronjobs auslesen
crontab -l > mycron
# neuen anfügen
echo "*/15 * * * * . /etc/profile; /opt/scrutiny/bin/scrutiny-collector-metrics run --api-endpoint ${DSM_URL} --host-id ${HOSTNAME}" >> mycron
# Cronjobs aus der Datei einlesen
crontab mycron
#Datei wieder entfernen
rm mycron

Wobei ich es eigentlich blödsinnig finde dafür extra ein Verzeichnis anzulegen. Hätte man auch direkt nach /usr/local/bin hterunterladen können. Dann ist es wenigstens auch im PATH-

 

[plang.pl]

nicht mal eine collector.yaml angelegt, sondern alles über Parameter geregelt.

Hab ich auch anfangs gemacht. Fand aber den Weg über die Config angenehmer. Da muss ich nicht beim manuellen Start daran denken, die Parameter mit anzugeben.

Die Installation hab ich im Prinzip genau so gemacht wie Du. Docker wollte ich auf den Nodes dann noch nicht ausrollen extra deswegen