Scrutiny SMART Monitoring

[Adama]

Da ja in der DSM 7.2.1 die SMART-Werte nicht mehr direkt zu erreichen sind, hier ein Ansatz über einen Docker-Container mit scrutiny
https://github.com/AnalogJ/scrutiny

Mein Dank geht an @plang.pl der mit seinem Post meinen Spieltrieb geweckt hat.

Hier in aller Kürze meine docker-compose.yml:

version: '3.5'

services:
  scrutiny:
    container_name: scrutiny
    image: ghcr.io/analogj/scrutiny:master-omnibus
    cap_add:
      - SYS_RAWIO
      - SYS_ADMIN
    ports:
      - "8080:8080"
      - "8086:8086"
    volumes:
      - /run/udev:/run/udev:ro
      - /volume1/docker/scrutiny/config:/opt/scrutiny/config
      - /volume1/docker/scrutiny/influxdb:/opt/scrutiny/influxdb

Da das - natürlich - auf der Syno nicht so einfach mit den Devices in der docker-compose läuft, wie man sich wünscht, hab ich eine collector.yaml erstellen müssen. Diese muss im config-Ordner abgelegt werden:

devices:
  - device: /dev/sda
    type: 'sat'
  - device: /dev/sdb
    type: 'sat'
  - device: /dev/sdc
    type: 'sat'
  - device: /dev/sdd
    type: 'sat'
  - device: /dev/nvme0
    type: 'nvme'
  - device: /dev/nvme1
    type: 'nvme'

Diese ist für eine DS918+, bei anderen Modellen müsst ihr die Typen eventuell anpassen.

Das Ganze sieht dann so aus:

 

[plang.pl]

Danke für deine Anleitung! Dann muss ich schon nicht rumtesten.
Werde ich mal so auf der DS umsetzen und berichten!

 

[Adama]

Deine 720+ müsste ja die selbe Basis wie meine 420+ haben. Da tauchen ja die Laufwerke als /dev/sata1 etc. auf.

Ich vermute mal, dass das auf der 720+ genauso sein wird.

 

[plang.pl]

Ja, wird vermutlich ähnlich sein. Der Tag "latest" sollte ja laut Doku auch auf "master-omnibus" zeigen.
Ich werde das aber vermutlich anders umsetzen. Das hier ist ja sozusagen ein "All-In-One" Container. Man kann aber auch die Container einzeln installieren. Das sind dann 3 Stück. Die 3 (oder die AIO) muss auf einen Server und auf die anderen muss nur der Collector. So ist dann ein Server quasi die Zentrale mit Datenbank und Web UI und die sammelt vom eigenen System und von den anderen Systemen, wo nur der Collector drauf ist, die Daten.
Darauf bin ich gekommen, weil der Container für mich ja erstmal unsinnigerweise auf 8086 lauscht. Mit dem Wissen gibt das aber Sinn.

 

[Toby-ch]

Ich steh gerade vor diesem Problem:


In linie 16 gibt es aber keinen Fehler:

Hat dazu jemand eine Idee ?

 

[Adama]

Laut dem compose-Beispiel sollte der Devices-Bereich ja so aussehen:

    devices:
      - "/dev/sda"
      - "/dev/sdb"

Aber selbst das hatte bei mir nicht funktioniert. Deswegen hatte ich ja die Variante mit der collector.yaml probiert. Synology scheint ja die Anschlussart nicht sauber umzusetzen.

Was gibt denn "smartctl --scan" auf der Rackstation aus?

Edit: Ist "Devices" nicht zu weit eingerückt?

 

[alexhell]

Ja ist es. Muss einmal rausgerückt werden

 

[Toby-ch]

@Adama
Ich bin gerade am mischen der Anleitung der macht es so wie bei mir:
https://drfrankenstein.co.uk/2023/05/29/scrutiny-in-container-manager-on-a-synology-nas/

Was gibt denn "smartctl --scan" auf der Rackstation aus?

Device not found oder so habe den container danach nochmals gelöscht und wollte den so neu deployen.

 

[Adama]

Das hier ist ja sozusagen ein "All-In-One" Container. Man kann aber auch die Container einzeln installieren.

Ja, klar, wenn man mehrere Maschine überwachen will, macht das natürlich Sinn. Ich hab ja nur die eine ständig aktive Maschine.

 

[Toby-ch]

Ok Devices dürfen da glaube ich nicht rein:

 

[Adama]

Ich bin gerade am mischen der Anleitung der macht es so wie bei mir:

Wenn ich das richtig lese, macht der das doch auch mit einer collector.yaml

 

[alexhell]

Ich bin gerade am mischen der Anleitung der macht es so wie bei mir:

Nein... Bei ihm ist devices auch auf der selben Höhe wie volumes. Ansonsten ist es keine gültige Docker compose datei

 

[alexhell]

Wenn ich das richtig lese, macht der das doch auch mit einer collector.yaml

Weiter unten ist eine docker-compose

 

[Toby-ch]

Auszug aus dem Log:

___   ___  ____  __  __  ____  ____  _  _  _  _
/ __) / __)(  _ \(  )(  )(_  _)(_  _)( \( )( \/ )
\__ \( (__  )   / )(__)(   )(   _)(_  )  (  \  /
(___/ \___)(_)\_)(______) (__) (____)(_)\_) (__)
AnalogJ/scrutiny/metrics                                dev-0.7.1

time="2023-10-14T20:03:25Z" level=info msg="Verifying required tools" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --scan --json" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device sat /dev/sata6" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for sata6: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device sat /dev/sata8" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for sata8: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device nvme /dev/nvme1n1" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for nvme1n1: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device sat /dev/sata4" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for sata4: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device sat /dev/sata5" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for sata5: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device sat /dev/sata7" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for sata7: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device nvme /dev/nvme0n1" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for nvme0n1: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device sat /dev/sata1" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for sata1: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device sat /dev/sata2" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for sata2: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Executing command: smartctl --info --json --device sat /dev/sata3" type=metrics
time="2023-10-14T20:03:25Z" level=error msg="Could not retrieve device information for sata3: exit status 2" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="Sending detected devices to API, for filtering & validation" type=metrics
time="2023-10-14T20:03:25Z" level=info msg="127.0.0.1 - b1630ee3eb82 [14/Oct/2023:20:03:25 +0000] \"POST /api/devices/register\" 200 40 \"\" \"Go-http-client/1.1\" (1ms)" clientIP=127.0.0.1 hostname=b1630ee3eb82 latency=1 method=POST path=/api/devices/register referer= respLength=40 statusCode=200 type=web userAgent=Go-http-client/1.1
time="2023-10-14T20:03:25Z" level=info msg="Main: Completed" type=metrics

fdisk -l


Docker/scrutiny/config/collector.yaml

devices:
  - device: /dev/sata1
    type: 'sat'
  - device: /dev/sata2
    type: 'sat'
  - device: /dev/sata3
    type: 'sat'
  - device: /dev/sata4
    type: 'sat'
  - device: /dev/sata5
    type: 'sat'
  - device: /dev/sata6
    type: 'sat'
  - device: /dev/sata7
    type: 'sat'
  - device: /dev/sata8
    type: 'sat'
  - device: /dev/nvme0n1
    type: 'nvme'
  - device: /dev/nvme1n1
    type: 'nvme'

Sollte eigentlich klappen

 

[Adama]

Soweit hatte ich gar nicht gelesen.

Ich hab jetzt noch mal den Healtcheck aus der hubspoke-Config ergänzt und spiele grade mit der cron-Variable...

@Toby-ch Ja, sieht eigentlich gut aus.

 

[Toby-ch]

Ich weiss nicht evtl sat gegen Ata ersetzten, weil mein Skript sieht so aus:

smartctl -a -d ata /dev/sata1
smartctl -a -d ata /dev/sata2
smartctl -a -d ata /dev/sata3
smartctl -a -d ata /dev/sata4
smartctl -a -d ata /dev/sata5
smartctl -a -d ata /dev/sata6
smartctl -a -d ata /dev/sata7
smartctl -a -d ata /dev/sata8

Brachte nichts...

 

[Adama]

Ich hab grad durch die Spielerei mit cron festgestellt, dass die Daten nicht aktualisieren.

@Toby-ch Ersetz mal im docker-compose den Bereich

    cap_add:
      - SYS_RAWIO
      - SYS_ADMIN

mit

privileged: true

Dann die Datenbank-Dateien in config und influxdb löschen und den Container wieder starten.

Erst dadurch haben sich bei mir die Daten wieder erneuert. Ich hatte eben die selben Fehlermeldungen wie du.

 

[Toby-ch]

Ich habe es hinbekommen:
https://drfrankenstein.co.uk/2022/07/28/scrutiny-in-docker-on-a-synology-nas/

Wichtig! fehlt eine Festplatte darf die nicht in der Config unter Device enthalten sein, ansonsten fliegt das auf die schnauze...

 

[Adama]

Und es geht mit den "cap_add"-Einträgen?

Bei mir klappt es nur, wenn ich den Container "privileged" laufen lasse...

 

[plang.pl]

Ich hab da jetz schon mal ewig rum, bis der Webserver lief...
Der sucht immer nach der InfluxDB unter localhost:8086, was in den Docker Bridged Networks nicht zu klappen scheint, auch nicht in einem selbst angelegten. Dort erwartet er eine frische InfluxDB Installation, um die über die API konfigurieren zu können. Diverse Versuche von mir, dieses Verhalten irgendwie zu verändern (selbst mit der in der Doku angepriesenen YML Config File), scheiterten. Jetzt läuft der Webserver halt gemeinsam mit einer jungfräulichen InfluxDB im Host-Network. Anders habe ich es nicht geschafft.