Monitoring Kubernetes mit Prometheus

This entry is part 5 of 5 in the series Kubernetes - so startest Du durch!

Monitoring – für viele eine gewisse Hass-Liebe. Die einen mögen es, die anderen verteufeln es. Ich gehöre zu denen, die es meist eher verteufeln, dann aber meckern, wenn man gewisse Metriken und Informationen nicht einsehen kann. Unabhängig der persönlichen Neigungen zu diesem Thema ist der Konsens aller jedoch sicher: Monitoring ist wichtig und ein Setup ist auch nur so gut wie sein dazugehöriges Monitoring.

Wer seine Anwendungen auf Basis von Kubernetes entwickeln und betreiben will, stellt sich zwangsläufig früher oder später die Frage, wie man diese Anwendungen und den Kubernetes Cluster überwachen kann. Eine Variante ist der Einsatz der Monitoringlösung Prometheus; genauer gesagt durch die Verwendung des Kubernetes Prometheus Operators. Eine beispielhafte und funktionale Lösung wird in diesem Blogpost gezeigt.

Kubernetes Operator

Kubernetes Operators sind kurz erklärt Erweiterungen, mit denen sich eigene Ressourcentypen erstellen lassen. Neben den Standard-Kubernetes-Ressourcen wie Pods, DaemonSets, Services usw. kann man mit Hilfe eines Operators auch eigene Ressourcen nutzen. In unserem Beispiel kommen neu hinzu: Prometheus, ServiceMonitor und weitere. Operators sind dann von großem Nutzen, wenn man für seine Anwendung spezielle manuelle Tasks ausführen muss, um sie ordentlich betreiben zu können. Das könnten beispielsweise Datenbank-Schema-Updates bei Versionsupdates sein, spezielle Backupjobs oder das Steuern von Ereignissen in verteilten Systemen. In der Regel laufen Operators – wie gewöhnliche Anwendungen auch – als Container innerhalb des Clusters.

Wie funktioniert es?

Die Grundidee ist, dass mit dem Prometheus Operator ein oder viele Prometheus-Instanzen gestartet werden, die wiederum durch den ServiceMonitor dynamisch konfiguriert werden. Das heißt, es kann an einem gewöhnlichen Kubernetes Service mit einem ServiceMonitor angedockt werden, der wiederum ebenfalls die Endpoints auslesen kann und die zugehörige Prometheus-Instanz entsprechend konfiguriert. Verändern sich der Service respektive die Endpoints, zum Beispiel in der Anzahl oder die Endpoints haben neue IPs, erkennt das der ServiceMonitor und konfiguriert die Prometheus-Instanz jedes Mal neu. Zusätzlich kann über Configmaps auch eine manuelle Konfiguration vorgenommen werden.

Voraussetzungen

Voraussetzung ist ein funktionierendes Kubernetes Cluster. Für das folgende Beispiel verwende ich einen NWS Managed Kubernetes Cluster in der Version 1.16.2.

Installation Prometheus Operator

Zuerst wird der Prometheus-Operator bereitgestellt. Es werden ein Deployment, eine benötigte ClusterRole mit zugehörigem ClusterRoleBinding und einem ServiceAccount definiert.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-operator
subjects:
- kind: ServiceAccount
  name: prometheus-operator
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
rules:
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - create
- apiGroups:
  - apiextensions.k8s.io
  resourceNames:
  - alertmanagers.monitoring.coreos.com
  - podmonitors.monitoring.coreos.com
  - prometheuses.monitoring.coreos.com
  - prometheusrules.monitoring.coreos.com
  - servicemonitors.monitoring.coreos.com
  - thanosrulers.monitoring.coreos.com
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - update
- apiGroups:
  - monitoring.coreos.com
  resources:
  - alertmanagers
  - alertmanagers/finalizers
  - prometheuses
  - prometheuses/finalizers
  - thanosrulers
  - thanosrulers/finalizers
  - servicemonitors
  - podmonitors
  - prometheusrules
  verbs:
  - '*'
- apiGroups:
  - apps
  resources:
  - statefulsets
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - configmaps
  - secrets
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list
  - delete
- apiGroups:
  - ""
  resources:
  - services
  - services/finalizers
  - endpoints
  verbs:
  - get
  - create
  - update
  - delete
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: controller
      app.kubernetes.io/name: prometheus-operator
  template:
    metadata:
      labels:
        app.kubernetes.io/component: controller
        app.kubernetes.io/name: prometheus-operator
        app.kubernetes.io/version: v0.38.0
    spec:
      containers:
      - args:
        - --kubelet-service=kube-system/kubelet
        - --logtostderr=true
        - --config-reloader-image=jimmidyson/configmap-reload:v0.3.0
        - --prometheus-config-reloader=quay.io/coreos/prometheus-config-reloader:v0.38.0
        image: quay.io/coreos/prometheus-operator:v0.38.0
        name: prometheus-operator
        ports:
        - containerPort: 8080
          name: http
        resources:
          limits:
            cpu: 200m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 100Mi
        securityContext:
          allowPrivilegeEscalation: false
      nodeSelector:
        beta.kubernetes.io/os: linux
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
      serviceAccountName: prometheus-operator
---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
  namespace: default
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
  namespace: default
spec:
  clusterIP: None
  ports:
  - name: http
    port: 8080
    targetPort: http
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
$ kubectl apply -f 00-prometheus-operator.yaml
clusterrolebinding.rbac.authorization.k8s.io/prometheus-operator created
clusterrole.rbac.authorization.k8s.io/prometheus-operator created
deployment.apps/prometheus-operator created
serviceaccount/prometheus-operator created
service/prometheus-operator created

Role Based Access Control

Zusätzlich werden entsprechende Role Based Access Control (RBAC) Policies benötigt. Die Prometheus-Instanzen (StatefulSets), gestartet durch den Prometheus-Operator, starten Container unter dem gleichnamigen ServiceAccount “Prometheus”. Dieser Account benötigt lesenden Zugriff auf die Kubernetes API, um später die Informationen über Services und Endpoints auslesen zu können.

Clusterrole

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  verbs: ["get"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
$ kubectl apply -f 01-clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/prometheus created

 

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: default
$ kubectl apply -f 01-clusterrolebinding.yaml
clusterrolebinding.rbac.authorization.k8s.io/prometheus created

 

ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
$ kubectl apply -f 01-serviceaccount.yaml
serviceaccount/prometheus created

Monitoring von Kubernetes Cluster Nodes

Es gibt diverse Metriken, die aus einem Kubernetes Cluster ausgelesen werden können. In diesem Beispiel wird zunächst nur auf die Systemwerte der Kubernetes Nodes eingegangen. Für die Überwachung der Kubernetes Cluster Nodes bietet sich die ebenfalls vom Prometheus-Projekt bereitgestellte Software “Node Exporter” an. Diese liest sämtliche Metriken über CPU, Memory sowie I/O aus und stellt diese Werte unter /metrics zum Abruf bereit. Prometheus selbst “crawlet” diese Metriken später in regelmäßigen Abständen. Ein DaemonSet steuert, dass jeweils ein Container/Pod auf einem Kubernetes Node gestartet wird. Mit Hilfe des Services werden alle Endpoints unter einer Cluster IP zusammengefasst.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
      name: node-exporter
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - image: quay.io/prometheus/node-exporter:v0.18.1
        name: node-exporter
        ports:
        - containerPort: 9100
          hostPort: 9100
          name: scrape
        resources:
          requests:
            memory: 30Mi
            cpu: 100m
          limits:
            memory: 50Mi
            cpu: 200m
        volumeMounts:
        - name: proc
          readOnly:  true
          mountPath: /host/proc
        - name: sys
          readOnly: true
          mountPath: /host/sys
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: node-exporter
  annotations:
    prometheus.io/scrape: 'true'
  name: node-exporter
spec:
  ports:
  - name: metrics
    port: 9100
    protocol: TCP
  selector:
    app: node-exporter
$ kubectl apply -f 02-exporters.yaml
daemonset.apps/node-exporter created
service/node-exporter created

Service Monitor

Mit der sogenannten Third Party Ressource “ServiceMonitor”, bereitgestellt durch den Prometheus Operator, ist es möglich, den zuvor gestarteten Service, in unserem Fall node-exporter, für die zukünftige Überwachung aufzunehmen. Die TPR selbst erhält ein Label team: frontend, das wiederum später als Selector für die Prometheus-Instanz genutzt wird.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: node-exporter
  labels:
    team: frontend
spec:
  selector:
    matchLabels:
      app: node-exporter
  endpoints:
  - port: metrics
$ kubectl apply -f 03-service-monitor-node-exporter.yaml
servicemonitor.monitoring.coreos.com/node-exporter created

Prometheus-Instanz

Es wird eine Prometheus-Instanz definiert, die nun alle Services anhand der Labels sammelt und von deren Endpoints die Metriken bezieht.

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
spec:
  serviceAccountName: prometheus
  serviceMonitorSelector:
    matchLabels:
      team: frontend
  resources:
    requests:
      memory: 400Mi
  enableAdminAPI: false
$ kubectl apply -f 04-prometheus-service-monitor-selector.yaml
prometheus.monitoring.coreos.com/prometheus created

Prometheus Service

Die gestartete Prometheus-Instanz wird mit einem Service-Objekt exponiert. Nach einer kurzen Wartezeit ist ein Cloud-Loadbalancer gestartet, der aus dem Internet erreichbar ist und Anfragen zu unserer Prometheus-Instanz durchreicht.

apiVersion: v1
kind: Service
metadata:
  name: prometheus
spec:
  type: LoadBalancer
  ports:
  - name: web
    port: 9090
    protocol: TCP
    targetPort: web
  selector:
    prometheus: prometheus
$ kubectl apply -f 05-prometheus-service.yaml
service/prometheus created
$ kubectl get services
NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
prometheus   LoadBalancer   10.254.146.112    pending      9090:30214/TCP   58s

Sobald die externe IP-Adresse verfügbar ist, kann diese über http://x.x.x.x:9090/targets aufgerufen werden und man sieht alle seine Kubernetes Nodes, deren Metriken ab sofort regelmäßig abgerufen werden. Kommen später weitere Nodes hinzu, so werden diese automatisch mit aufgenommen bzw. wieder entfernt.

Visualisierung mit Grafana

Die gesammelten Metriken, lassen sich leicht und ansprechend mit Grafana visualisieren. Grafana ist ein Analyse-Tool, das diverse Datenbackends unterstützt.

apiVersion: v1
kind: Service
metadata:
  name: grafana
spec:
#  type: LoadBalancer
  ports:
  - port: 3000
    targetPort: 3000
  selector:
    app: grafana
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: grafana
  name: grafana
spec:
  selector:
    matchLabels:
      app: grafana
  replicas: 1
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - image: grafana/grafana:latest
        name: grafana
        imagePullPolicy: Always
        ports:
        - containerPort: 3000
        env:
          - name: GF_AUTH_BASIC_ENABLED
            value: "false"
          - name: GF_AUTH_ANONYMOUS_ENABLED
            value: "true"
          - name: GF_AUTH_ANONYMOUS_ORG_ROLE
            value: Admin
          - name: GF_SERVER_ROOT_URL
            value: /api/v1/namespaces/default/services/grafana/proxy/
$ kubectl apply -f grafana.yaml
service/grafana created
deployment.apps/grafana created
$ kubectl proxy
Starting to serve on 127.0.0.1:8001

Sobald die Proxy-Verbindung durch kubectl verfügbar ist, kann die gestartete Grafana-Instanz via http://localhost:8001/api/v1/namespaces/default/services/grafana/proxy/ im Browser aufgerufen werden. Damit die in Prometheus vorliegenden Metriken jetzt auch visuell ansprechend dargestellt werden können, sind nur noch wenige weitere Schritte notwendig. Zuerst wird eine neue Data-Source vom Typ Prometheus angelegt. Dank des kuberneteseigenen und -internen DNS lautet die URL http://prometheus.default.svc:9090. Das Schema ist servicename.namespace.svc. Alternativ kann natürlich auch die Cluster-IP verwendet werden.

Für die gesammelten Metriken des node-exporters gibt es bereits ein sehr vollständiges Grafana-Dashboard, das sich über die Import-Funktion importieren lässt. Die ID des Dashboards ist 1860.

Nach dem erfolgreichem Import des Dashboards können jetzt die Metriken begutachtet werden.

Monitoring weiterer Anwendungen

Neben diesen eher technischen Statistiken sind auch weitere Metriken der eigenen Anwendungen möglich, beispielsweise HTTP Requests, SQL Queries, Business-Logik und vieles mehr. Hier werden einem durch das sehr flexible Datenformat kaum Grenzen gesetzt. Um seine eigenen Metriken zu sammeln, gibt es wie immer mehrere Lösungsansätze. Einer davon ist, seine Anwendung mit einem /metrics Endpunkt auszustatten. Manche Frameworks wie z.B. Ruby on Rails haben bereits brauchbare Erweiterungen. Ein weiterer Ansatz sind sogenannte Sidecars. Ein Sidecar ist ein zusätzlicher Container, der neben dem eigentlichen Anwendungscontainer mitläuft. Beide zusammen ergeben einen Pod, der sich Namespace, Netzwerk etc. teilt. In dem Sidecar läuft dann Code, der die Anwendung prüft und die Ergebnisse als parsebare Werte für Prometheus zur Verfügung stellt. Im Wesentlichen können beide Ansätze, wie im oben gezeigten Beispiel, mit dem Prometheus Operator verknüpft werden.

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Kubernetes Custom Resources with Kubeless and Metacontroller by Michael Grüner | OSDC 2019

This entry is part of 6 in the series OSDC 2019 | Recap

 

This talk is about our journey from Nginx & Docker Swarm to Traefik & Nomad. At the Open Source Data Center Conference (OSDC) 2019 in Berlin, Jan Martens invited to audience to travel with him in his talk „Evolution of a Microservice-Infrastructure”. You have missed him speaking? We got something for you: See the video of Michael’s presentation and read a summary (below).

The former OSDC will be held for the first time in 2020 under the new name stackconf. With the changes in modern IT in recent years, the focus of the conference has increasingly shifted from a mainly static infrastructure approach to a broader spectrum that includes agile methods, continuous integration, container, hybrid and cloud solutions. This development is taken into account by changing the name of the conference and opening the topic area for further innovations.

Due to concerns around the coronavirus (COVID-19), the decision was made to hold stackconf 2020 as an online conference. The online event will now take place from 16 to 18 June 2020. Join us, live online! Save your ticket now at: stackconf.eu/ticket/


 

Kubernetes Custom Resources with Kubeless and Metacontroller

Mostly Michael is working with all the Kubernetes stuff in his company (also with Foreman). Developing additional tools e.g. scripts and tools for deploy applications. Custom Resources from Kubernetes and how to use them.

The goal of Michael‘s talk: Create your own Kubernetes resources that look like, behave like and can be used like every other Kubernetes resource. For example, if you want to let your users manage helm for Kubernetes, you have to give them access to your instance, what means, they can control the hole cluster. That’s not what you want.

The recipe:

  • A resource definition
  • Some logic to make it do something
  • Some API magic to make it all stick together

 

1) Resource definition

CustomResourceDefinition = It is used to tell Kubernetes about your new resource.

It consists of three parts:

  • API group
  • some metadata
  • the kind (the name of your resource)

 

2) Some logic to make it to something

For this, Michael uses a tool called Kubeless. It is a so called function as a service framework. It is basically a framework where you can say ‘Here is my code, make it work as a webservice’. (That’s a very oversimplified description of what it is, but for the use case in this presentation it is enough.)

Use Kubeless to create our actual resource logic in form of a web service. How do we do that? As everytime in Kubernetes we use a Kubernetes resource (in this case it is a function).

Example:

  • API
  • kind (function)
  • metadata (name, namespace, etc.)
  • spec (runtime, handler, checksum, function-content-type, the actual function)

The function (logic) can now be found at http://hello-world.test:8080.

 

3) Some API magic to make it all stick together

How to connect your custom resource with your logic? As always, we use a Kubernetes resource. The special feature here is to give the resource the parentResource, that means, the apiVersion of the custom resource. We also have to tell, what childResource it has to create. In our case just “pods”. 

Furthermore, we have to define what to do if the resource changes. For example, what should happen if we change the parent resource or add some configuration? At the end of the configuration we have to tell where to find the logic we built. In our example it is http://hello-world.test:8080.

And this ties our two pieces together. It connects our custom resource definition with our logic. Now we have on the right our logic, on the left our resource definition and meta controller for the communication in the middle.

 

If the user now creates a new instance of our custom resource, the logic gets notified by the API, that ensures the meta controller gets notified. After this, the meta controller calls our function and returns a JSON structure containing the status and the list of children. Meta Controller then uses these information to do whatever API requests are necessary to create these children.

If you are interested now, watch the full video to have a look at a live demo how this works!

Tobias Bauriedel
Tobias Bauriedel
Junior Consultant

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns macht er zurzeit seine Ausbildung zum Fachinformatiker. In seiner Freizeit ist er viel unterwegs und unternimmt gern etwas mit Freunden.

GUDE Netzwerkthermometer: Expert Sensor Box 7213 und 7214-Serie im direkten Vergleich

Gude-Expert Sensor Box 7214-Serie und Gude-Expert Sensor Box 7213-Serie, zwei Produkte, die sich sehr ähneln. Um Ihnen die Entscheidung bei einem Kauf leichter zu machen, werden diese zwei Geräte heute in einen direkten Vergleich gestellt.

 

GUDE und das Qualitätsversprechen

GUDE ist seit über 30 Jahren Hersteller von innovativen Geräten für den IT-Bereich. Sie ermöglichen die Optimierung und Erweiterung von IT-Infrastrukturen in Netzwerk-, Server- und Medienschränken. Die Einsatzbereiche der Kunden reichen von Unternehmensnetzwerken über Mediensteuerungen bis hin zu Rechenzentren und Industrieumgebungen. Beide Geräte eignen sich perfekt für kleinere Serverräume, was auch an der Größe und den Montagemöglichkeiten der 7213 und 7214 Geräten liegt. Mit entsprechenden Klammern lassen sich die Netzwerkthermometer auch bequem auf Hutschiene montieren.

GUDE setzt bei all seinen Produkten auf “Made in Germany”. Dies ist genauso wie bei den “großen” Geräten auch bei den kleinen sofort erkennbar: Alle Geräte zeichnen sich durch exzellente Verarbeitung aus, die unter anderem durch die Auswahl und Verarbeitung der Materialien gewährleistet wird, hier zum Beispiel das robuste rostfreie Stahlgehäuse. Flexible Bedienmöglichkeiten und ein sparsamer Betrieb runden dabei das überzeugende Erscheinungsbild ab.

 

Vorteile haben beide der Produkte, aber was können sie genau?

Der Vorteil dieser Netzwerk Thermometer besteht darin, dass sie Umgebungsrisiken, wie Überhitzung, Feuer, Wasser, erhöhte Luftfeuchtigkeit, erhöhter Luftdruck und Vandalismus frühzeitig erkennen. Diese Geräte überwachen diese Risiken mit Hilfe von den anzuschließenden oder schon integrierten Sensoren. So kann der Serverraum oder andere IT-Umgebungen über Netzwerk gemonitored werden bevor es zum Ausfall kommt. Dies schützt Ihre kritische IT-Infrastruktur gegen Ausfälle und spart Ihnen am Ende Geld.

  • Überhitzung: Überwachung mit dem Temperatursensor
  • Feuer: Überwachung mit dem Rauchmeldesensor
  • Wasser: Überwachung mit dem Leckage-Sensor
  • Vandalismus: Überwachung mit dem Türkontaktsensor
  • Erhöhte Luftfeuchtigkeit
  • Erhöhter Luftdruck

 

Merkmale und Ausstattung der Serien
Integrierter Temperatur-, Luftfeuchtigkeit- und Luftdrucksensor
2 weitere Anschlüsse (RJ45) für optionale Sensoren
Redundante Stromversorgung beim 7214, beide Serien auch mit Power-over-Ethernet erhältlich
Verfügbare Protokolle: IPv6, DHCP, SNMPv3, SSL, Telnet, Radius, Modbus TCP
Verschlüsselung mithilfe von SNMPv3, SSL, HTTPS, TLS
Zugriffsschutz durch IP-Zugriffskontrolle
Versenden von Alarmen und Nachrichten per E-Mail, Syslog und SNMP-Traps
Das 7214 verfügt über einen passiven Signaleingang und einen schaltbaren Relaisausgang (jeweils 3-fach Industrieklemme)
Eigenständiger LAN-Sensor für Environment Monitoring, beim 7214 auch für I/O-Monitoring
Robustes gepulvertes Stahlblechgehäuse mit Befestigungslaschen
Kostenlose Smartphone-Apps für Android und iOS für remote Zugriff
Netzwerkanschluss RJ45 mit 10/100 Mbit/s
Konfiguration über Telnet, Webbrowser oder Windows- bzw. Linux-Software
Software Updates im laufenden Betrieb ohne Neustart des Gerätes

 

Bei uns erhältliche Varianten

Beide Netzwerkthermometerserien können bei uns mit folgenden integrierten Sensoren geliefert werden:

  • LAN-Temperatur Sensor
  • LAN-Temperatur / Luftfeuchte Sensor
  • LAN Temperatur / Luftfeuchte / Luftdruck Sensor
  • LAN-Temperatur Sensor (PoE)
  • LAN-Temperatur / Luftfeuchte Sensor (PoE)
  • LAN-Temperatur / Luftfeuchte / Luftdruck Sensor (PoE)

 

Anschließbare Sensoren und Zubehör

 

FAZIT

Gude-Expert Sensor Box 7214-Serie und Gude-Expert Sensor Box 7213-Serie unterscheiden sich kaum im direkten Vergleich. Der Unterschied beruht insbesondere darauf, dass die 7214-Serie passiven Signaleingang und einen Relaisausgänge aufweist als der 7213. Weiterhin bietet der 7214 eine redundante Stromversorgung. Wer also remote steuern und noch weitere Sensoren, wie Rauchmelder oder Leckage-Sensor oder Türkontakte anschließen möchte, der kommt am der Gude-Expert Sensor Box 7214-Serie nicht vorbei.

Wir sind jederzeit für Euch erreichbar per Mail: shop@netways.de oder telefonisch unter der 0911 92885-44. Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team. Bleibt gesund – wir freuen uns auf Euch!

Natalie Regn
Natalie Regn
Junior Office Manager

Natalie macht seit September 2019 ihre Ausbildung zur Kauffrau für Büromanagement hier bei NETWAYS. Vor ihrer Zeit bei NETWAYS war sie ein Jahr als Au-pair in Schottland unterwegs. Passend dazu widmet sie sich seit vielen Jahren dem Spielen der Great Highland Bagpipe. Natalie ist in ihrer Freizeit nicht nur musikalisch unterwegs, sondern auch sportlich. Sie trainiert im Fitnessstudio und geht gerne in den Kletterpark, in die Trampolinhalle oder zum Wandern in die fränkische Schweiz.

Ein kleiner Exkurs zu SNMP

Wer sich schon einmal mit SNMP beschäftigt hat, der weiß, dass das Verarbeiten sowie Auswerten von SNMP-Traps eine wichtige Rolle beim Monitoring spielt. Eine fast genauso große Rolle spielt hierbei das oft mühselige „ergoogeln“ der MIBs und OIDs. Für diesen Fall kann ich folgende Webseite empfehlen. Das eigentliche Problem ist allerdings, wenn man, wie in meinem Fall, einen Check entwickeln möchte, aber sich auf Grund von COVID-19 im Homeoffice befindet. Nicht ein Jeder hat bspw. Cisco Supervisor Module bei sich zu Hause stehen, die für das Testen benötigt werden. Nun, wie kann man sich dabei helfen? Man benutzt die override Option in snmpd.conf .

Ich gehe bei den weiteren Schritten davon aus, dass SNMP bereits auf dem System richtig konfiguriert wurde

Im Folgenden werde ich zeigen wie man beispielhaft den „Redundanz-Status“ eines Cisco-Gerätes mit selbst eingetragenen Werten überprüfen kann. Es handelt sich genauer gesagt um folgende OID.

Wenn ich versuche diese OID auf meinem lokalen Gerät auszulesen, stelle ich fest das diese unbekannt ist:
# snmpwalk -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
SNMPv2-SMI::enterprises.9.9.176.1.1.2 = No Such Object available on this agent at this OID

Das heisst, man muss zunächst dem lokalen System die entsprechende MIB zur Verfügung stellen. Ich speichere die MIB also in den Pfad der konfiguriert ist und “aktiviere” diese anschließend:

Auslesen des Standardpfades:
# net-snmp-config --default-mibdirs
/root/.snmp/mibs:/usr/share/snmp/mibs

Herunterladen der benötigten MIBs:
# wget -O .snmp/mibs/CISCO-RF-MIB.mib http://www.circitor.fr/Mibs/Mib/C/CISCO-RF-MIB.mib
# wget -O .snmp/mibs/CISCO-SMI.my https://www.cisco.com/iam/PGW_MIBS/973/CISCO-SMI.my

Laden bzw. “aktivieren” der MIBs:
# cat .snmp/snmp.conf
mibs +CISCO-RF-MIB
mibs +CISCO-SMI

Nun kann man ein weiteres Mal testen ob die MIBs korrekt geladen wurden und ob das lokale System diese auch benutzt:
snmpwalk -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
CISCO-RF-MIB::cRFStatusUnitState = No Such Object available on this agent at this OID

Wie in der oberen Ausgabe zu erkennen, kann mein lokales System nun die OID verarbeiten und erkennt diese auch. Das Problem an dieser Stelle ist aber nun, dass es sich bei meinem System nicht um ein CiscoGerät mit dem Redundancy-Feature handelt, Daher auch die Meldung No Such Object available on this agent at this OID.
Das können wir beheben, indem man dem SNMP-Daemon mitteilt, welchen Status das Objekt haben soll:
# cat /etc/snmp/snmpd.conf
override 1.3.6.1.4.1.9.9.176.1.1.2 integer 14

Nach einem Neustart des Dienstes wird nun der “gewollte” Wert vom SNMP-Daemon zurück geliefert:
# systemctl restart snmpd
# snmpget -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
CISCO-RF-MIB::cRFStatusUnitState = INTEGER: active(14)

Wie man sieht kann diese manuelle Überschreibung von einzelnen OIDs sehr hilfreich bei einer Pluginentwicklung sein. Dadurch hat man die Möglichkeit verschiedene Zustände zu prüfen, ohne das man diese extra herbeiführen muss.

Bildquelle: https://pixabay.com/photos/cup-of-coffee-laptop-office-macbook-1280537/

Philipp Dorschner
Philipp Dorschner
Consultant

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kollegen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Alles neu macht der Mai: NETWAYS Trainings – Online und vor Ort

Alles neu macht der Mai. Und nicht nur der! Wir haben in den kommenden Monaten jede Menge neuen Input in spannenden NETWAYS Trainings für Dich. Online oder vor Ort: Das entscheidest Du. Wir haben aktuell beide Varianten im Portfolio. So kannst Du Dir das Wissen zu Deinem Open Source-Tool entweder ganz bequem und auf dem schnellen Weg zu Hause im Online Training aneignen. Oder Du kommst nach Nürnberg, Hamburg, München oder Berlin, um Dir gemeinsam mit anderen vor Ort neuen Input abzuholen.

Wir bringen Dir das state-of-the-art Praxiswissen bei!

MONITORING TRAININGS

Ein leistungsstarkes Tool zur Überwachung der Verfügbarkeit und Leistung aller Teile Deines Systems: Icinga zeigt Dir alle relevanten Daten an und gibt Warnmeldungen aus, um Dich auf dem Laufenden zu halten. Lerne Icinga von der Pike auf in unseren Schulungen und setze mit unseren Icinga Workshops noch eine Portion Profiwissen drauf!

Icinga 2 Fundamentals
Online | 7.–10. Juli 2020
Nürnberg | 22.–25. September 2020
Icinga 2 Advanced
Online | 21.–23. Juli 2020
Berlin | 6.–8. Oktober 2020
Icinga & Puppet Workshop
Nürnberg | 22.–23. September 2020
Icinga Director Workshop
Nürnberg | 20.–21. Oktober 2020

AUTOMATION TRAININGS

Der Trend zur Virtualisierung nahezu aller IT-Plattformen und Umgebungen erhöht den Bedarf an flexibler und vor allem schneller Verwendung der verfügbaren Ressourcen. Wir helfen Dir dabei, mit dieser Geschwindigkeit nicht nur Schritt zu halten, sondern ihr sogar einen Schritt voraus zu sein.

Ansible
Nürnberg | 21.–23. Juli 2020
Hamburg | 13.–15.Oktober 2020
Ansible AWX (Tower)
Nürnberg | 24. Juli 2020
Hamburg | 16. Oktober 2020
Icinga & Puppet Workshop
Nürnberg | 22.–23. September 2020
Fundamentals for Puppet
Online | 30. Juni – 2. Juli 2020
Nürnberg | 20.–22. Oktober 2020
Foreman
Nürnberg | 8.–9. September 2020

LOGGING & METRICS TRAININGS

Für Sammler und Sondierer: Hier erfährst Du, wie Du Log-Daten von Anwendungen, Betriebssystemen oder Netzwerkinfrastrukturen zentral sammelst, verarbeitest, verwaltest, analysierst und visualisierst. Mehrwertgenerierung garantiert!

Elastic Stack
Online | 23.–25. Juni 2020
München | 15.–17. September 2020
Graphite & Grafana
Online | 26.–27. Mai 2020

Berlin | 29.–30. September 2020
Graylog
Nürnberg | 30. Juni – 1. Juli 2020
Nürnberg | 27. – 28. Oktober 2020

ADMINISTRATION TRAININGS

Geballte Admin-Power: Hier lernst Du ein unabhängiges Linux-System zu administrieren und wiederkehrende Aufgaben zu automatisieren oder die Vorzüge unserer liebsten, flexiblen und erweiterbaren relationalen Datenbank kennen. Das und noch viel mehr. Jetzt anmelden!

Linux Basics
Nürnberg | 27.–29. Oktober 2020

PostgreSQL Fundamentals
Nürnberg | 14.–16. Juli 2020
PostgreSQL Advanced
Nürnberg | 8.–11. September 2020

DEVELOPMENT TRAININGS

Softwareentwicklung bedarf heute mehr denn je einer ganzheitlichen Betrachtung des DevOps-Lifecycles. Reine Source Code-Verwaltung wird dem nicht mehr gerecht und der gesamte Prozess von Planung bis hin zu Continuous Integration und Deployment benötigt eine technische Abbildung. GitLab ist das Tool dafür!

GitLab
Online | 14.–15. Juli 2020
Nürnberg | 15.–16. Dezember 2020

Das sagen unsere Teilnehmer*innen

“Man hat auf jeden Fall gemerkt, dass der Trainer sehr viel praktische Erfahrung mit der Software hat und weiß, wo er ansetzen muss.” – Feedback Ansible Online Training

“Eine neue Erfahrung, etwas anstrengender als in einer Präsenzschulung, aber mit viel technischem Hintergrund. Hat Spaß gemacht.” – Feedback Ansible Online Training

“Sehr gute Umsetzung einer neuen Schulungsmöglichkeit, auf jeden Fall für die Zukunft sehr interessant.” – Feedback GitLab Online Training

“Sehr gut organisiertes Online-Training, kompetenter und sympathischer Trainer. Alle Fragen wurden beantwortet. Absolut zu empfehlen!” – Feedback GitLab Online Training

Und was sagst Du? Wir freuen uns, Dich bald bei uns zu begrüßen! Virtuell oder vor Ort.

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.