Hy Michi
Ich habe diesbez noch kein Ticket eröffnet, da ich noch am recherchieren bin.
Bis jetzt sind einige Tickets im Umlauf aber leider noch keine 100%ige Lösung. 
Es schaut so aus als wenn zwischen dem Reload etwas länger gewartet werden müsste damit der Port wieder freigegeben wird. Die neue Instanz gestartet werden kann. Vermutlich ist dir das besser bekannt als mir.
Hoffe mal auf eine baldige Lösung, da ich doch viele Unknown State dadurch erhalte
sg
Hallo Michi
Genau um diese Dependencies zu umgehen und den Host auch via ping zu überwachen, hab ich mich für die Clusterzone entschieden.
Ich muss mir hierzu nochmals genau die Dependencies ansehen. (Derzeit verwende ich nur die Standardsettings laut Doku)
Vielen Dank erst mal, leider muss ich mir bevor ich dann dieses Thema angehen noch schnell ansehen warum nach einem Reload manche Agents nicht mehr hoch kommen. Hier habe ich bei 2 Clients (mit aktuellsten Agent 2.6.3.2) noch das Socket Problem:
Wird auch hier behandelt:
https://github.com/Icinga/icinga2/issues/4867#note-19
sg
Roland
Hy
Der Aufbau sollte natürlich flexibel sein, kommt ein Host hinzu soll dieser auch mit überwacht werden.
Die Überwachung mit snmp kommt neu hinzu darum auch der Linux Server. Bis jetzt kam ich mit den Windowshosts immer gut aus.
Wie angesprochen habe ich 2 Satelliten Server in eine Zone gesteckt um vom Master zu erkennen ob der Service icinga2 gestoppt ist oder der Server down ist. (Leider habe ich noch das Problem, dass manche Services nach einem reload nicht mehr hoch kommen, muss noch checken warum)
Meine letzte Frage:
Wie kann ich bei einem "Satelliten in der Mitte" diesen überwachen? Wenn der Service icinga2 down ist, gehen alle weiteren Hosts/Services auf unknown.
Hast du hierzu noch ein Tipp?
Danke
Hy Michi
Ich habe die beiden Satelliten in die gleiche Zone gesteckt, damit sich diese gegenseitig via ping überwachen.
Ohne icmp (ping) vom Master zu den Satelliten kann ich ansonsten nicht erkennen ob der Host oder nur der icinga2-Service down ist
Ist es möglich, dass sich 2 getrennte Satelliten-Zonen gegenseitig via ping überwachen.
In meinem Fall slmonp01.spr.loca und swadsp01.spr.local?
Danke für deine Hilfe!
Roland
Hy Michi!
Unten findest du ein Bild wie die Hosts miteinander verbunden sind.
Beim Server slmonp01.spr.local handelt es es sich um ein Testserver für snmp.
(Vorher war nur der Server swadsp01.spr.local im Netzwerk vorhanden. Da auf einem WindowsAgent keine snmp checks funktionieren, kam slmonp01.spr.local dazu)
+ Grund warum slmonp01.spr.local und swadsp01.spr.local in der gleichen Zone sind:
Zwischen dem Master und der Kunden "SPR" besteht kein VPN. Die Agents *spr.local verbinden sich zum Master.
Die Hosts slmonp01.spr.local und swadsp01.spr.local sind in der gleichen Zone, sodass diese sich gegenseitig via Ping überwachen können.
+ SNMP Service
Der Service snmp-uptime ist ein erster Test, darum hab ich diesen (quick&dirty) beim Kunden (spr) erstellt.
Der Check snmp-uptime soll für den Host sw01.spr.local am Host slmonp01.spr.local abgefeuert werden
Frage: Kann die doppelten Definition der Grund sein warum "command_endpoint = "slmonp01.spr.local" nicht gezogen hat?
Sorry für die Namensgleichheit des Masters u Linux Agents, der Kollege hat hier schnell einen Standardserver erstellt und dieser heisst eben so
Hy Michi!
Erst mal danke für deine Hilfe, anbei die Konfig:
Interessanterweise steht beim LinuxServer (slmonp01.spr.local) immer "is reachable" aber auch "Check result is late"
Anmerken möchte ich, dass der Master kein direkten Zugang zu den Endpoints hat, der Aufbau findet nur vom Agent zum Master statt
Anbei die Konfig:
/etc/icinga2/zones.conf am master
zones.conf am slmonp01.spr.local
zones.conf am swadsp01.spr.local
icinga2 object list --type Service --name *uptime-snmp*
Hy Kevin!
Danke für deine Antwort. An die Zonen habe ich auch schon gedacht.
Nachdem mein Master keine Verbindung zu den Satelliten aufbauen kann, habe ich an jedem Standort 2 Satelliten um Ausfälle besser zu erkennen.
So erkenne ich ob der icinga2 Service gestoppt ist oder wirklich der Host IP-technisch nicht antwortet.
Wenn ich nun den Linux Client in eine eigene Zone gebe, kann ich diese dann noch gegenseitig via Ping überwachen?
Noch ein anderes Argument warum es vlt nicht an der Zone liegt:
Gebe ich beim Service als command_endpoint direkt den Linux Host an "command_endpoint = "linuxsatellite.domain.local" " wird der check richtig ausgeführt.
Das Problem besteht nur wenn ich "command_endpoint = host.vars.remote_client" verwende
thx
Roland
Hallo NG
Ich darf euch mal wieder um eure Unterstützung bitten.
Kurz zu meiner Umgebung:
Bei uns im Haus steht ein icinga2 Master an welchen Standorte angebunden sind. Zwischen dem Master und Standorten existiert kein vpn.
In den Standorten befinden sich WindowsServer auf welchen der icinga2 Agent läuft (Auf 2 Servern als Satellite und weiter Server die an diese die Satelliten angebunden sind)
Angedacht ist die Erweiterung der Überwachung mit snmp (switch, nas...).
Dazu möchte ich am Standort ein Linux Agent installieren und zusammen mit einem WindowsServer als Satelliten einsetzen (2 Satelliten je Standort -> in diesem Fall 1x Linux, 1x Windows)
Auf allen Hosts wird icinga2 Version r2.6.3-1 (Windows 2.6.3-x86_x64) eingesetzt
Zum Problem:
Beim snmp check gebe ich als command_endpoint mittels "vars.remote_client" den Linux Satelliten an.
Leider wird der check trotzdem über den Windows Satelliten getriggert (Windows kann keine snmp checks)
Gebe ich beim Service unter check_command direkt den Hostnamen des Linuxservers ein wird der check am richtigen Host ausgeführt
Konfig:
Hallo NG
Anbei noch de Command um eine Minimalconfig des NSClients zu installieren.
Meiner Meinung nach sollte die für icinga2 ausreichen.
Danach tausche ich noch die nsclient.ini um ein Passwort zu setzen und die nich benötigten Plugins zu deaktivieren (dass diese nicht versucht werden zu starten)
msiexec /q /i nscp.msi ADDLOCAL=ALL REMOVE=Documentation,WEBPlugins,DotNetPluginSupport,LuaScript,PythonScript,SampleConfig,Shortcuts,NRPEPlugins,NSCAPlugin,NSCPlugins"
Hallo Michi!
Danke u sorry für die "dumme" Frage
Ich dachte der Parameter --endpoint ist hierfür zuständig. einfach nochmals --cn mitangeben ist ja einfach (und ich stand auf der Leitung)
Für NSClient 0.5 gibs folgende Doku, welche ich noch nicht ganz durchschaut habe.
http://docs.nsclient.org/manual/windows_installer.html
Werd mich damit noch weiter befassen und posten wenns was neues gibt
Danke
Roland
Hallo NG
Ich bin eben dabei die Clientinstallation für Windows zu automatisieren. Dabei hänge ich derzeit an 2 Problemen wo ich hoffe ihr könnt mir weiterhelfen.
1) Node Setup schlägt fehl bei Generierung des Master ca-Files
Grund ist, dass ich das Ticket gerne für alle Hosts in Kleinbuchstaben ausstellen möchte.
Der folgende Command zieht jedoch die Variable HOSTNAME heran, diese liest den Namen teilweise in Großbuchstaben aus.
Kann man den CN bei beim diesem Command mitangeben?
Output bei Ausführen des Commands:
Fehler weil HOSTNAME.domain.local <> hostname.domain.local
2) NSClient
Da ich mit der Icinga2-ITL arbeite benötige ich von NSCLient keinerlei zusätzliche Funktionen wie "Webserver" "nrpe" usw.
Kennt jemand die Parameter der 0.5 Version mit welchen nur nsca.exe Funktionalität installiert wird?
Danke u sg
Roland
hy rainbow_75
ich wäre ja für alles offen solange ich vars+= abbilden kann, denn derzeit kann ich mit dem direkor wenig weitermachen.
es würden zuviele services entstehen welche in meiner alten config nur aus 1 service bestehen
vlt gibts ja irgendwelche infos bis wann man mit einer lösung/workaround rechnen könnte.
danke
OH sorry
if und set_if
stimmt set_if habe ich mal gelesen, danke für den tipp
sorry
roland
Hallo Leute!
Nun darf ich euch noch eine Frage stellen:
Bei meiner manuellen Config (ohne director) habe ich gerne mit Configvariablen ( vars += config )gearbeitet.
Wie kann ich eine solche im Director abbilden?
Beispiel:
Hier wird wenn am Host " vars.disks["Disk C"]" existiert eine Service mit Überwachung von C hinzugefügt. Die Schwellwerte konnte ich so variable mitpflegen
Danke & sg
Roland
Hallo
Leider hatte wohl niemand die gleichen Voraussetzungen wie ich.
Mittlerweile habe ich mich entschlossen die Config neu zu bauen, anbei meine Erfahrungen. Für Hilfe/Tipps bin ich jederzeit offen 
1
Die Hosts (Testgerät = Windows Host) welche vom Director aus via IP (Ping) erreichbar sind habe ich als Hosts eingebunden. Als Vorlage dient ein Template in welchen Agent auf yes steht.
Die Hostüberwachung erfolgt via hostalive und funktioniert (master kann agent per ping erreichen)
Am Director wurde für den Hosts keine eigene Zone erstellt, am Hosts ist die Zone <FQDN> des Clients vom Kickstart-Script erstellt worden.
2)
Hosts (diesmal ein Windows und ein Linux Host) stehen in einem Kundennetz das vom Master nicht erreichbar ist.
Der Master ist vom Kundennetz unter einem anderen Hostnamen als den FQDN erreichbar. (Der öffentliche Name <> FQDN des Masters)
In meiner manuellen Konfig habe ich die beiden Hosts in einer gemeinsame Zone erstellt. So konnten sich diese gegenseitig per Ping überwachen.
Die Möglichkeit, 2 Hosts einer Zone zuzuweisen konnte ich via dem Director noch nicht nachstellen -> Wie Tom sagt möchte ich soweit es geht das Zonenkonzept dem Director überlassen.
Hier warte ich auf: https://dev.icinga.com/issues/12268
Da ich jedoch mal weiterkommen muss, kann ich auch damit leben jeden dezentralen Hosts per eigener Zone anzusteueren und als Hostcheck "cluster-zone" zu verwenden.
aufgetretene Fehler:
Das Kickstartsctipt schlägt aufgrund der unterschiedlichen FQDN und Hostnamen unter welchen der Master erreichbar ist fehl:
Lösung:
Im Kickstartscript Zeile 892 den Hostnamen anpassen
Nach einem Restart des Icinga2-Service am Host schlug die Konfigüberprüfung fehl. Das lag daran, dass in der icinga2.conf und in der global-director die Zone global-director definiert war.
Ich habe diese aus der icinga2.conf gelöscht, der Host ist derzeit online.
2 Fragen:
- Ist/wird es möglich sein 2 Host in einer Zone zu definieren, sodass sich diese per PING überwachen können? -> Wenn bereis möglich bin ich über ein Tipp sehr dankbar
- Mache ich mit meiner Kickstartinstallation etwas komplett falsch sodass diese Fehler auftreten?
Danke & sg Roland
Hallo
If wirds in Director nicht geben, es kommen Funktionen. Sind jedoch noch nicht implementiert
https://monitoring-portal.org/…nt-im-director-abbileden/
sg
hy kevin!
werde neu beginnen, danke für deine unterstützung!
sg
roland
hy
leider funkt das auskommentieren nicht da der director das aus der DB erstellt und somit "überschrieben wird"
Derzeit bin ich am überlegen die ganze config nochmals zu löschen und sauber im director abzubilden. is zwar arbeit aber dann sauber
sg
Hallo NG
Aus Dummheit habe ich ein Command welcher bereits als "external Command" definiert ist nochmals im director erstellt. Seitdem kann ich die Config aufrund von "duplicate Command" nicht deploy'n
Wenn ich den Command löschen will, wird der von mir im director erstellte Command ebenfalls als "extern" angezeigt und lässt sich nicht löschen.
Des weiteren markieren sich in der GUI (unter Commands) beim anklicken eines der beiden Commands beide.
Meine Frage: Wie bekomme ich den doppelten Eintrag wieder aus der Config?
Anbei noch 2 Screenshots
Danke
Roland
