Umlaute in Local Checks führen zu Status 'UNKN'

[herzkerl (Ben)]

Hallo zusammen,

wir überwachen mit Checkmk unter anderem auch den Status von BigBlueButton-Instanzen.

Ein anderer Checkmk-Nutzer hat folgendes Skript zur Verfügung gestellt: https://codeberg.org/DigitalSouveraeneSchule/bbb_checkmk/src/branch/master/checkbbb.py

Ich habe dieses geändert, sodass in Zeile 65 statt des bbb-origin-server-name der Raumname verwendet wird. Wann immer ein solcher Raumname einen Umlaut enthält, ist der Status UNKN.

Lokal kann das Skript ausgeführt werden, weshalb ich einen Fehler in Checkmk vermute.
Ist hier etwas bekannt? In der Doku zu Local Checks habe ich hierzu nichts gefunden…

Danke für euer Feedback!

[anonymous15]

Kannst du eine Beispiel output der lokalen check teilen mit umlaut?

[anonymous15]

Ich habe einige Tests mit meinem BiBluebutton auf einem Docker Container gemacht. Natürlich habe ich deinen Code ein wenig modifiziert, indem ich folgendes ersetzt habe

#p = m.getElementsByTagName(“bbb-origin-server-name”)[0]
p = m.getElementsByTagName(“meetingID”)[0]

[herzkerl (Ben)]

Ich habe gerade getestet, ob es eventuell an der Kombination aus Umlauten und Leerzeichen liegt und die Leerzeichen im Raumnamen entfernt – leider ohne Erfolg. Die Ausgabe ist:

0 BigBlueButton numMeetings=1|numAttendees=0|numWithVoice=0|numWithVideo=0|numListeners=0 [ServerSum M:1 Att:0 Vid:0 Voi:0 Lis:0] [Testraum-mit-Ümlaut-ohne-Läärzeichen M:1 Att:0 Vid:0 Voi:0 Lis:0]

Wobei ich wie gesagt den meetingName verwende, denn meetingID ist bei unseren Systemen eine lange Zeichenkette, die nichtssagend ist. Könntest du es mal mit meetingName testen?

[anonymous15]

Mit meetingName dieser Zeit und Gleichem wert

[herzkerl (Ben)]

Danke für den Test! Sehr komisch… Hast du zufällig eine Idee? Ich kann es mir nicht erklären…

[herzkerl (Ben)]

Eine Idee hätte ich – eventuell liegt es an der locale des Systems?

Bei mir sind sowohl der Monitoring-Server als auch die betroffene Maschine auf Englisch:

LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[anonymous15]

Ja. Das könnte sein. Ich habe das gleiche locale en_US.UTF-8 sowohl auf dem Monitoring Server als auch auf dem zu überwachenden Host.

[simonm (Simon)]

Ruf doch mal cmk --debug -vv --checks thecheckname hostname auf. Der debug-Schalter sorgt dafür, dass auch der Python-Stacktrace sichtbar ist. An dem kannst Du dann erkennen, weshalb und wo der Check crasht bzw. das Problem eingrenzen.