Ich gerate jetzt in das Problem, dass ich Anfang des Jahres auch hatte. Ich hoffte, es würde sich mit mehr Hardware erschlagen lassen.
Ich habe ein ProxmoxCLuster aus 3 Servern. Alle mit einem XEON E3-1220 v3 und 32 GB Ram.
Neben der SSD für Proxmox hat jeder der drei Server noch zwei weitere SSDs für CephFS. Da CephFS Performance braucht, habe ich auf jedem Server 3x1Gbit gebonded und lasse darüber das CephFS-Cluster laufen.
Es laufen 14 LXCs und 2 Virtuelle Maschinen. Auslastung liegt (ohne Checkmk) bei 9% CPU und 32% Ram (über das Cluster gemittelt)
Ich habe jetzt Checkmk auf einer vm installiert und folgende Anleitungen abgearbeitet:
Auf das HW Inventory verzichte ich.
Außerdem die Piggyback Hostname Umschreibung angepasst, damit die Piggybacks von Proxmox richtig zugeordnet werden können.
Checkmk läuft auf einem der Server auf dem lokalen LVM, damit hier kein Verzögerungen durch das CephFs auftreten. 4 CPUs und bis zu 16GB Ram
Auf den drei Proxmox Server und 11 der LXCs habe ich dann den Linux Agent installiert. Alle Dienste als Push deklariert und insgesamt 57 Service in die Überwachung genommen. Ich würde sagen, dass ich noch nicht viel.
Aber: Das Netzwerk gerät ins “Straucheln”: SSH Logins auf verschiedene LXCs oder VMs brauchen auf einmal ewig, bis ich den Prompt bekomme und irgendwas auf der Maschine machen kann.
Schalte ich CheckMK ab, dauert es 3 bis 5 Minuten und alles reagiert wieder sofort.
So brauche ich gar nicht weiter machen.
Irgendwelche Schrauben, an denen ich drehen könnte?
Monitoring für den CMK-Server selbst hast Du eingerichtet? Dann hast Du einen Dienst OMD [sitename] performance - ist da etwas auffällig? Ist in htop irgendetwas auffällig?
Und dann hatten wir letztens soweit ich mich erinnere einen Proxmox User, bei dem irgendwelche Einstellungen der virtualisierten Netwerkkarte dazu geführt daben, dass massig Packet Loss auftrat. Evtl. hast Du etwas ähnliches. Vielleicht mal die Suchfunktion nehmen?
Ich kann nur soviel sagen. Bei läuft das CMK als LXC in nem kleinen Proxmox Cluster und hat keinerlei Probleme. Meine Systeme sind zwar nicht so Uralt wie die hier aber halt auch nur Intel NUCs mit so 12 LXCs welche drauf laufen.
Der LXC vom CMK hat 2Cores und ist im Schnitt so bei 5% CPU Auslastung. Netzwerk ist nicht der Rede werte mit 8-10kB pro Sekunde.
Einzige Einschränkung - mein System hat kein Ceph sondern repliziertes ZFS.
Denke mal Ceph ist hier auch nicht dran Schuld.
Ich habe auf den Proxmox Servern mal netdata zur Überwachung installiert. Sobald ich CMK Instanz hochfahre bekomme ich iowait, dropped Packages auf den Netzwerkinterfaces, CPUWaits
Meldungen übrigens, die ich von CMK nicht bekam. Wenn ich die CMK Instanz wieder abschalte, “Beruhigt” sich alles wieder.
Ich habe jetzt netdata auf alle Maschinen ausgerollt und lasse das in die Netdatacloud schreiben.
Dann habe ich auf allen LXCs die cmk Agents deaktiviert und CMK nochmal hochgefahren. Nach 3h habe ich wieder diverse Alarme auf den Proxmox Servern, die sich abbauen, wenn ich cmk wieder stoppe.
Wie Du schon schriebst. Das ist alte Hardware. Das jetzt zu Debuggen, ist zuviel für meine Freizeit. Wenn mal Geld für neue NUCs da ist, schaue ich mir das nochmal an. die Netdatacloud ist nicht so gut, wie Chmk, aber erstmal reicht es wohl
Die verlorenen Pakete sind wohl auf den Smart Ping von Checkmk zurückzuführen, bzw. auf Bugs in paravirtualisierten Netzwerktreibern, die Nacharbeit erfordern. Das Thema kommt von Zeit zu Zeit auf, aber halt zu selten, um da mal richtig tief einzutauchen.
Wahrscheinlich ist das alles weg, wenn man für “Host Check Command” eine pauschale Regel setzt “Use the status of the Checkmk Agent”. Aber man bekommt da man halt immer erst ne Minute später mit, wenn der Host down ist… IMHO vertretbar, ich würde trotzdem gerne diesen lästigen Bug oder unpassende Default-Config identifiziert wissen.
Wäre es für Euch dann nicht evtl sinnvoll, das direkt mit den Proxmox Leuten zu lösen? Da setzen sich dann von beiden Seiten Leute hin, bauen ne kleine Testumgebung und anschließend könnt ihr das auf beiden Seiten in die Doku packen und noch gegenseitig einen “Zertifiziert-Stempel” ausstellen.
Ich merke, gerade dass mein System für ne Überwachung eigentlich nicht sinnvoll ist: Zwei LXCs machen Updates, ich lösche 3 Snapshots und habe prompt 80 Meldungen wegen Load, diskback.log und CPU. Es wäre also keine Hilfe, wenn ich mit euch nen Videocall mache und wir das gemeinsam herausbekommen.
Kannst Du mal nachschauen, ob das hier das Problem ist? In vielen Fällen fällt die Verwendung der komplett emulierten Netzwerkkarten nicht auf, erst wenn dann viele Interrupts für wenige Pakete anfallen, kippt es.
