Scrutiny | SMART-Monitoring mit Client-Server Prinzip

[plang.pl]

@Adama hat hier bereits das Aufsetzen des Containers als All-In-One Container gezeigt. Da läuft dann die Datenbank, der Webserver und der Collector in einem Container. Ideal, wenn man nur ein einziges System (beispielsweise die DS) überwachen will. Hat man mehrere Geräte laufen, die man überwachen möchte, kann man Scrutiny auch folgendermaßen konfigurieren: Es gibt Webserver + Datenbank (+ Collector) auf einem Host und auf den anderen Hosts läuft nur der Collector, welcher die Daten regelmäßig an den Webserver meldet. Somit kann man in einer Weboberfläche sämtliche Geräte darstellen lassen. So sieht das beispielsweise bei mir aus:


Vorwort
Diese Anleitung ist aktuell eher noch als "BETA" zu betrachten. Ich werde sie nach und nach ausbessern / erweitern.
Achtung: Es kommt in den Configs mehrmals der Passus IP_DES_SERVERS vor. Das müsst ihr natürlich anpassen. Damit ist der Server gemeint, auf dem der Webserver von Scrutiny läuft. Der Part, der in der collector.yaml nach id: steht, könnt ihr auch austauschen. Das ist der Name, den der Host später in der Websansicht hat.

Wie kommt man dahin?
Schritt 1: Aufsetzen des Scrutiny Servers
Schritt 1.1: Die Datenbank

version: "3"
services:
  InfluxDB-scrutiny:
    container_name: InfluxDB-scrutiny
    hostname: influxdb
    image: influxdb:2.2
    networks:
      - host
    ports:
      - 8086:8086/tcp
      - 8086:8086/udp
    restart: always
    volumes:
      - /volume1/docker/scrutiny/db/var:/var/lib/influxdb2
      - /volume1/docker/scrutiny/db/etc:/etc/influxdb2
networks:
  host:
    external: true

Schritt 1.2: Der Webserver

version: "3"
services:
  scrutiny-web:
    container_name: scrutiny-web
    hostname: scrutiny-web
    image: ghcr.io/analogj/scrutiny:master-web
    networks:
      - host
    ports:
      - 8080:8080/tcp
    restart: always
    volumes:
      - /volume1/docker/scrutiny/web:/opt/scrutiny/config
networks:
  host:
    external: true

Schritt 2: Aufsetzen der Clients
Methode 2.1: Scrutiny Collector über Docker
Hier ein Beispiel, wie es auf meiner DS aussieht:

version: "3"
services:
  scrutiny-collector:
    container_name: scrutiny-collector
    devices:
      - CgroupPermissions: rwm
        PathInContainer: /dev/sata1
        PathOnHost: /dev/sata1
      - CgroupPermissions: rwm
        PathInContainer: /dev/sata2
        PathOnHost: /dev/sata2
      - CgroupPermissions: rwm
        PathInContainer: /dev/nvme0n1
        PathOnHost: /dev/nvme0n1
      - CgroupPermissions: rwm
        PathInContainer: /dev/nvme1n1
        PathOnHost: /dev/nvme1n1
    environment:
      - COLLECTOR_API_ENDPOINT=http://IP_DES_SERVERS:8080
    hostname: scrutiny-collector
    image: docker.io/ghcr.io/analogj/scrutiny:master-collector
    privileged: true
    restart: always
    volumes:
      - /volume1/docker/scrutiny/collector:/opt/scrutiny/config
      - /run/udev:/run/udev:ro

In das Verzeichnis /volume1/docker/scrutiny/collector muss eine Datei mit dem Namen collector.yaml mit folgendem Inhalt (am Beispiel meiner DS):

# Commented Scrutiny Configuration File
#
# The default location for this file is /opt/scrutiny/config/collector.yaml.
# In some cases to improve clarity default values are specified,
# uncommented. Other example values are commented out.
#
# When this file is parsed by Scrutiny, all configuration file keys are
# lowercased automatically. As such, Configuration keys are case-insensitive,
# and should be lowercase in this file to be consistent with usage.

######################################################################
# Version
#
# version specifies the version of this configuration file schema, not
# the scrutiny binary. There is only 1 version available at the moment
version: 1

# The host id is a label used for identifying groups of disks running on the same host
# Primiarly used for hub/spoke deployments (can be left empty if using all-in-one image).
host:
  id: "File-Server"

# This block allows you to override/customize the settings for devices detected by
# Scrutiny via `smartctl --scan`
# See the "--device=TYPE" section of https://linux.die.net/man/8/smartctl
# type can be a 'string' or a 'list'
devices:
  - device: /dev/sata1
    type: ['sat,auto']
  - device: /dev/sata2
    type: ['sat,auto']
  - device: /dev/nvme0n1
    type: ['sat,auto']
  - device: /dev/nvme1n1
    type: ['sat,auto']

#log:
#  file: '' #absolute or relative paths allowed, eg. web.log
#  level: INFO
#
api:
  endpoint: 'http://IP_DES_SERVERS:8080'
#  endpoint: 'http://localhost:8080/custombasepath'
# if you need to use a custom base path (for a reverse proxy), you can add a suffix to the endpoint.
#  See docs/TROUBLESHOOTING_REVERSE_PROXY.md for more info,

# example to show how to override the smartctl command args globally
#commands:
#  metrics_smartctl_bin: 'smartctl' # change to provide custom `smartctl` binary path, eg. `/usr/sbin/smartctl`
#  metrics_scan_args: '--scan --json' # used to detect devices
#  metrics_info_args: '--info --json' # used to determine device unique ID & register device with Scrutiny
#  metrics_smart_args: '--xall --json' # used to retrieve smart data for each device.

########################################################################################################################
# FEATURES COMING SOON
#
# The following commented out sections are a preview of additional configuration options that will be available soon.
#
########################################################################################################################

#collect:
#  long:
#    enable: false
#    command: ''
#  short:
#    enable: false
#    command: ''

Eigentlich sollte der Collector automatisch Daten senden. Da er das bei mir aber nicht tut, habe ich eine Aufgabe in der Aufgabenplanung (als root!) angelegt, die den Collector auffordert, die Daten jetzt zu senden:
docker exec scrutiny-collector scrutiny-collector-metrics run

Methode 2.2: Scrutiny Collector nativ ohne Docker
Download: https://github.com/AnalogJ/scrutiny/releases
Weitere Infos folgen!

Spoiler: Agenda

Der Thread ist noch im Aufbau. Weitere Infos / Verbesserungen folgen, wenn ich die Zeit / Lust dazu finde!

v1 BETA

Spoiler: Changelog

24-02-10 | v1.0
-erste Veröffentlichung

 

[Monacum]

Aufgabe in der Aufgabenplanung

Hallo und danke für diese Anleitung. In welchem Intervall läuft bei Dir diese Aufgabe oder reicht es, den Befehl einmal zu senden?

Und aus der Anleitung geht nicht so klar hervor, wieviele yaml zu erstellen sind, vielleicht kannst du das noch anpassen.

 

[plang.pl]

Ja, ist wie geschrieben nur eine erste Version.
Du musst für den Collector genau eine yaml erstellen und die muss genauso heißen, wie oben geschrieben. Also pro Collector-Node halt eine.
Die Aufgabe triggert einmalig das Auslesen der SMART-Werte und dessen Versand an den Webserver. Läuft bei mir alle 15min.