Posts by michaeleifel

Ich gehe mal von aus dass die Konfiguration entsprechend auf die internen Interface gelegt ist und nicht rein zufällig doch die public nutzt?

Hatte zuerst glusters, mittlerweile Ceph und kann mich nicht über Performance beschweren. MTR zeigt avg. 0.4ms zwischen den Nodes bei meinen AdHoc Tests:

Hab auch mal in mein altes Ansible Playbook für glusterfs geguckt. Hab dabei immer die Internen IPs und keine Hostnamen etc. verwendet für alle Fälle. Hast du paar Details bereit welches OS, GlusterFS Version etc?

SCD

Hallo Vm Nachbar

pasted-from-clipboard.png

Die Zeiten passen überein mit 1 von meinen Rootserver, beim 1 Ausfall hab ich die 24/7 Hotline angerufen, kurz nach der Bestätigung vom Mitarbeiter kam

dann auch die Netcup Mail.

Gruß

Vielen Dank für das reinschauen in mein Github Issue. Hab leider nicht genug Erfahrugn mit programmierung um das sauber nieder schreiben zu können. Hab auch soeben mal ein Ticket beim Support zu dem Thema aufgemacht.

whoami0501 wrote:

Did you made a reboot to the server, after you had configured it?

Have you told this to the support?

[netcup] Felix P. Because it seems that this is an bigger issue - may we can have a statement of netcup? Are there any other known reasons for this problems?

Yes, the Server were all completely shut down, also with the SCP Button "Power off" after being configured.

Funny things is that it seems random if it works currently or not. Like right now 1 of the 6 servers i can reach with IPv6, even though it takes a few seconds before the first ping comes back. And all of them can do ping6 netcup.de, but this does not mean i can also ping them from my home.

I did not reach out to Support yet for this as i happily don't need to rely on IPv6 only.

Also experiencing the same issue. Sysctl values are set like written in wiki. Noticed this when i was trying to login to an pure ssh shell and not ansible anymore where it used the IPv4. OS is in all 6 Cases Debian Buster. Static IPv4 and IPv6 NIC Configuration like written in the wiki.

Wenn ich die Webseite im Browser aufrufe sehe ich dass es nen selfsigned Certficate ist. Da steht kein CN drin, Zertifikat stammt nicht von einer offiziellen CA ab etc.

Insofern ist die Meldung doch valide.

Den Tick Stack hatte ich vorher auch im Betrieb als ich noch im Versuch war mit 1 zentralen Lösung alles zu erschlagen. Da hatte ich ne ähnliche Konstruktion im Einsatz, allerdings hatte ich am Ende Probleme mit der Skalierbarkeit InfluxDB in der kostenlosen Version. Das aktuelle Setup sieht so aus:

1.) K8S Cluster 1:

- Prometheus mit 2 Tagen Retention, dynamische Konfiguration per ServiceMonitors

- Automatisch provisioniertes Grafana inkl Dashboards mit Prometheus als Datenquelle

2.) K8S Cluster 2:

- Icinga2 mit 2 Mastern und Mysql HA

- InfluxDB für schöne Graphen zu den Werten

- Automatisch provisioniertes Grafana inkl Dashboards mit InfluxDB und Prometheus als Datenquelle

- Prometheus mit 2 Tagen Retention, dynamische Konfiguration per ServiceMonitors

3.) K8S Cluster 3:

- Graylog mit ElasticSearch

- Prometheus mit 2 Tagen Retention, dynamische Konfiguration per ServiceMonitors

- Zentrales Prometheus das alle anderen Prometheus absaugt und dezeit 120 Tage die Daten vorhält. ( braucht so 12 GB Ram momentan alleine....)

- Automatisch provisioniertes Grafana inkl Dashboards mit Prometheusen als Datenquelle

Die Nodes sind Debian preseeded und mit Ansible anschließend standardisiert K8S Deployed. Jedes der Cluster lässt sich dank Backups, Ansible und den ganzen Deployments innerhalb von ~1 - 2 Stunden neu erzeugen.

Leider kann prometheus ja nicht mehrere Instanzen mit gleicher Konfiguration starten und die teilen sich die Arbeit wie bei Icinga2. Evtl ziehe ich noch Icinga2 und das zentrale Prometheus zusammen und lasse die 3 Icinga2 DeadManSwitch miteinander spielen

whoami0501 wrote:

Ich persönlich habe bisher Prometheus+NodeExporter genutzt und steige gerade auf Icinga2 um. Icinga2 ist ein bisschen pain in the Ass bei der Einrichtung und Gewöhnung, aber ich finde das Arbeiten mit Director und Co. sehr entspannt.

Das Datenbackend und die Visualisierung wollte ich eigentlich über InfluxDB und Grafana machen, aber da es noch andere Möglichkeiten gibt, will ich mich da vorher nochmal über die anderen Möglichkeiten informieren.

In Icinga2 kannst du dir dann je nach Anwendungszweck Vorlagen und Templates bauen, die kannst du sowohl für Webhosting, Server, Dienste und alles mögliche nutzen.

Dem kann ich nur zustimmen... Am Anfang hab ich mich sehr schwer getan, nachdem ich dann die Logik verstanden habe macht es nun Spaß in kurzer Zeit neue Checks mit einzubauen. Das Docker setup ist mittlerweile so weit gereift, dass nur noch 7 Dateien applyen muss und es wird automatisch das HA-Cluster mit Icingaweb und Director erzeugt.

m_ueberall wrote:

...

Hier wäre ich aber durchaus sehr an Erfahrungsberichten von "Umsteigern" beider Hilfswerkzeuge auf größere/flexiblere/komplexere freie Lösungen interessiert, welche den obengenannten Einsatz mit mehreren unabhängigen Überwachungs-Instanzen ("Active/Active"-Modus) beibehalten haben.

Wie darf ich mir Active / Active vorstellen? In Prometheus würde ich dann einfach 2mal die gleiche Konfig deployen. Bei Icinga2 teilen sich die Master die Arbeit auf und führen das im Backend dann zum vollständigen Mosaik zusammen.

Prometheus mag ich solange, wie ich innerhalb von Kubernetes bin und mithilfe von ServiceMonitor relativ einfach ans Ziel komme. Auf Hosts selber wäre mir das viel zu viele Ports freischalten und der NodeExporter kann nichtmal BasicAuth von sich aus, so wie die meisten Exporter.

Ich habe meine Umgebung komplett auf HA gebaut und alles läuft in Docker. Hast du mehrere Systeme zur Verfügung oder wie möchtest du das Thema angehen?

Für das Monitoring nutze ich mehrere Wege:

1.) K8S WhiteBox Monitoring:

Prometheus Operator der alle Nodes und ServiceMonitore scraped sowie mehrere externe System die mit dem Blackbox Exporter Performance Metriken liefern

2.) K8S BlackBox Monitoring und weitere Hosts:
HA Cluster in dem Icinga2 mit mehreren Mastern läuft und gegen die alle Server registriert sind. Das Setup ist komplett automatisiert in K8S Deployments und Ansible. Einfach neuen Host angeben und innerhalb von 30 Sekunden ist der mit im Monitoring drinne. Die überwachten Services hab ich mal als Screenshots angehangen. Zu den jeweiligen Diensten gibt's dann direkt Graphen aus InfluxDB welche im Web-Interface angezeigt werden.