Posts by TomGelf

This forum was archived to /woltlab and is now in read-only mode.

    Just in case anyone looking to a solution for whatever kind of problem stumbles over this thread: NO, chmod 777 is NEVER a good idea. Guess arryxyz will find out the root cause of his problem and share it afterwards ;-)

    Für jene die mitlesen und die hier erschrecken: keine Sorge, unter RHEL/CentOS sollte es diese Probleme nicht geben. Die Umgebung die ich grad vor mir hab ist zwar noch auf Icinga 2.5.4, nutzt aber dieselben Pakete für alle RHEL 6 respektive RHEL 7 Varianten. Laut Cube läuft der Agent auf über 2000 RHEL-Servern mit 6.5, 6.6, 6.7, 6.8, 7.1, 7.2 und 7.3 - ohne Probleme. Eine dreistellige SLES-Anzahl ist auch dabei, 11.4 und 12.1.


    @Gunnar: SLES hat leider ein anderes Verständnis von Langzeitsupport als RedHat. Die groben Änderungen die sie teilweise fahren haben sie sich ganz klar selbst zuzuschreiben, sind aber halt auch mit ein Grund warum es sich nicht immer überall so leicht upgraden lässt. Kann Skap81 da voll verstehen. Sind die Unterschiede zwischen SLES12SP1 und SLES12SP2 wirklich so groß sind, dass wir sie nicht mit einem Build abdecken können dann sollten wir darüber nachdenken sie separat zu bauen und bereitzustellen. Supported ist SP1 ja auch offiziell noch, bis Mai oder so.


    Das Problem sind hier weniger Icinga Master Systeme, da ist es vertretbar zu sagen "Sorry, du brachst ein aktuelles SLES". Problematischer sehe ich das beim Icinga 2 Agent, vor allem in Umgebungen mit hunderten oder tausenden von Systemen. Die bringst nie und nimmer dazu, alle rechtzeitig upzugraden...


    lg
    tom

    Dann geb ich erst mal ab an die Kollegen vom Core :-) Mir ist zwar die von dir beschriebene Historie noch leicht suspekt, aber im Grunde haben wir eine Config die auf den ersten Blick gut aussieht, die Objekte tun es auch, die Checks laufen nicht. Vermutlich überseh ich was, aber ich denke mich brauchts da vorerst nicht mehr.

    ist der command_endpoint also nicht die Einsteellung, die bewirkt, dass der Check von eben diesem Satelliten ausgeführt wird?

    Im Director steht bei dem Feld für den command_endpoint: "Setting a command endpoint allows you to force host checks to be executed by a specific endpoint. Please carefully study the related Icinga documentation before using this feature". Ja, du kannst damit Checks an genau einen Knoten pinnen, aber nein, das ist nicht der richtige Schalter für Satelliten. Grundsätzlich können in einer Zone auch mehrere Satelliten hängen, command_endpoint würde da deine schöne Redundanz aushebeln. Es reicht, wenn du die Zone wählst.

    Sollten mit dem Master verbundene Satelliten eigentlich direkt beim Kickstart mit importiert werden, oder ist da immer "handarbeit" angesagt?

    Kickstart reicht. Momentan musst wenn neue Satelliten dranhängst den Kickstart selbst nochmal antriggern, das soll in Zukunft automatisch vorgeschlagen werden.

    Vielleicht hat ja dnsmichi oder jemand anderes noch eine Idee

    Hast du es ohne command_endpoint schon probiert? Es wäre interessant zu wissen ob das etwas ändert.

    Es handelt sich hier um einen Bug im der Signal-Behandlung von Icinga 2.6.0. Das Problem tritt überall dort auf, wo nicht systemd benutzt wird. Im verlinkten Ticket gibt es einen Workaround, bitte testen und Feedback ins Ticket.


    Besten Dank
    Thomas

    Removing a specific property or variable can be achieved by POSTing (not PUTting) that single property or variable with a null value. So to remove the address and the "location" var you would use:


    Code
    1. POST director/host?name=localhost


    ...with a payload such as:

    JavaScript
    1. { "address": null, "vars.location": null }

    However, "groups" is just a single property, so your assumptions are right. DELETE wouldn't work, as it always refers a single object. So, the downside of all this is that you cannot remove a single group without knowing which other groups that host had beforehand. Implementing something like a "subtract a group" feature would be easy, finding the correct naming and usage pattern is trickier. Could you please open a feature request for this in our issue tracker?


    And please also create one for "Modify multiple objects at once using a filter", those together should allow you to remove a single group from specific objects at once.

    Hmmm... also für mich sieht das soweit gut aus. Die Config wird vom Director generiert, landet auf dem Master, wird zum Agent repliziert, das Objekt ist da - ich glaube der Director ist da erst mal raus. Überflüssig finde ich auf den ersten Blick den command_endpoint, den würde ich weglassen. Trotzdem dürfte er nicht falsch sein.

    Your description is correct and reflects what the code should do. I wrote above sentence, however I'm not a native speaker. So I wouldn't be surprised in case it wouldn't make any sense :-) This "unless the next deployment should take place" should refer to the grace period. Could you please try to write a description using your own words? Because to me this sentence still makes sense, but you know... there's a reason for this :D

    Just for the records, in case anyone is running into a similar problem: read_eagle manually tweaked a hard-coded limit in Sync.php. It has initially been added to slightly increase the available memory while syncing. Just, in case you allowed your PHP to use more memory (as you may need to sync A LOT of objects), this leads to an artificial restriction of 768MB - which is pointless.


    Anyone interested in the final fix for this can follow the related issue we created today. For those facing similar issues please also consider upgrading to PHP 7.x, as it is much faster and safes lots of memory. The environment mentioned above still uses 5.x, which also works fine - but it costs more. It's always great to hear that Icinga behaves fine in large environments. And that's not the ending, next year we want to get even faster - and easier to scale.


    Btw, just to throw in some more numbers: today I worked with an environment with 2,5k hosts and 72k services. All hosts and 10k services are synced via Director one by one from various sources (PuppetDB, AWS, AD). The rest (62k services, 121k notification objects) is generated by apply rules. Director renders the config in slightly more than 12 seconds, also still on PHP 5. 2,2k of those hosts are running the Icinga 2 Agent, everything with just two masters, no satellite involved. Satellites would definitively reduce the load, but hey, it's running fine.


    Great to hear that even syncing 37k hosts at once is not an issue. At least not once we toggle artificial limitations ;-)

    Läuft seit 16:21 wieder. Hat ein wenig länger gedauert, weil's recht komplex war. Im Grunde fehlten in der Migration 123 zwei kleine Wörter die zur Folge hatten dass die 124 unter den meisten MySQL-Versionen und -Derivaten auf die Schnauze fiel, das aber abhängig davon ob man mit der 123 begonnen hatte oder aber eine ältere Version migriert hatte - und dann gab es noch den ein oder anderen der versuchte das manuell geradezubiegen.


    Naja, und nachdem MySQL über ein paar nette Features die MariaDB z.B. hätte nicht verfügt war es ein ziemliches Gemetzel das so geradezubiegen, dass in all den so entstandenen Varianten ein simples git pull && "Migration anwenden" alles sauber auflöst und wieder vereinheitlicht. Hat zwei fette Commits gebraucht, aber dann lief's.


    Sorry für die Umstände, soll nicht wieder vorkommen. Ich versuch's wenigstens ;-)

    In der DB ein "DELETE FROM icinga_service WHERE id = <wasauchimmer>" ist vollkommen legal, das kannst machen. Es steht dann halt nicht in deiner History, so what. Alles was sonst mit dran hängt wird sauber mit rausgebügelt.


    Aber lass uns das erst mal anschauen, das kann eigentlich alles nicht sein. Was unter /var/lib/irgendwas liegt ist Schnuppe, was zählt ist das was in der GUI bei den Deployments rausgefeuert wird wenn es neu deployest. Dort findest die Dateien die er dafür generiert, und dort zeigst mir bitte mal den entsprechenden Ausschnitt aus der service_apply.conf. Zudem dann noch einen Screenshot deiner Service-Liste mit passenden/ähnlichen Namen, ggf auch gerne einen Ausschnitt von SELECT id, host_id, object_type, object_name FROM icinga_service WHERE object_name LIKE '%wasauchimmer%';


    Maskiere ggf was man public nicht sehen soll, aber bitte so dass man den Kontext noch versteht.


    lg
    tom