Scrutiny SMART Monitoring

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
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:
Code:
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.
 
Zuletzt bearbeitet:

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.518
Punkte für Reaktionen
404
Punkte
103
Dann tricks die Kiste doch einfach aus, in dem Du die Host devices auf andere Devices im Container mappst:
Code:
        devices:
            - /dev/sata1:/dev/sda
            - /dev/sata2:/dev/sdb
            - /dev/nvme0n1
            - /dev/nvme1n1
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
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

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Ich hab jetzt auch mal den Part mit den Devices komplett weggelassen, so wie @Adama, es ist immer das gleiche Ergebnis
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.518
Punkte für Reaktionen
404
Punkte
103
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

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
05. Mrz 2013
Beiträge
2.130
Punkte für Reaktionen
721
Punkte
154
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

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Hab es nun noch mal so probiert:
Code:
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

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.518
Punkte für Reaktionen
404
Punkte
103
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

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
05. Mrz 2013
Beiträge
2.130
Punkte für Reaktionen
721
Punkte
154
Bei meinem Einzelcontainer hat es ohne "privileged" nicht geklappt. Nur mit hat er Daten geliefert.

Konnte man auch im Log sehen...
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
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

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.518
Punkte für Reaktionen
404
Punkte
103
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.
 
  • Like
Reaktionen: plang.pl

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Aha!
Woher nimmst du diesen Befehl?
Es scheitert an den nvmes, wie es aussieht:
1.png
Komisch ist aber, dass an der API anscheinend gar nix ankommt. Laut Log hat er ja gesendet
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Halt!
Kommando zurück.
Mit der manuellen Ausführung kommen die Daten an:
1697405356844.png


Nur die eine nvme will nicht.
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.518
Punkte für Reaktionen
404
Punkte
103
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

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
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***?
1.png


Bis auf die eine (defekte?) SSD sieht die UI nun gut aus:
2.png
 
  • Like
Reaktionen: haydibe

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
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:
1.png

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:
2.png


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

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.518
Punkte für Reaktionen
404
Punkte
103
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:
Code:
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-
 
  • Like
Reaktionen: plang.pl

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
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 :ROFLMAO:
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat