Posts by dnsmichi

Please read about the latest changes and upgrade.
Please note that your newly registered account needs to be manually activated by an admin. Just be patient, you cannot post to any forum before this happens. This is thanks to the unfortunate event of spammers recently. More details here.

    Die Konfiguration nicht händisch mit vim & co pflegen, sondern verwalten zu lassen. Etwa von Config Management Tools wie Puppet, oder exportiert aus einer CMDB, oder gar mit dem Director?

    Mit der Dependency wirst du zwar die Checks unterdrücken, aber was wenn der Service Critical wird bevor der Host Down ist? Dann stimmt dein Dashboard kurz, und danach wird nix mehr gecheckt. Da sehe ich dann eher bestimmte Filter im Dashboard in Aktion. Die "severity" column berücksichtigt Services deren Host Down ist, bereits. Das wird auch defaultmässig verwendet um in Icinga Web 2 die Problem Views zu sortieren. Du kannst das aber natürlich auch explizit filtern und ausblenden (am besten versuchen via Filter-Editor).

    The columns which are used from Icinga Web 2 should be found inside the the hoststatus and servicestatus tables.



    As such you may extract and compare the last_check and next_check values, I'd also suggest to query the REST API for live data and see how things are updated. On the other hand, OnNewCheckResult will trigger a) DB IDO b) API Event Streams - the latter might also be worthwhile to check if both events happen at the same time and how they're processed correctly.

    Ja, das übliche Gschmarri mit den Leuten die ned 2x Geld ausgeben wollen und was Gscheites bauen ;-) Hast du vor diese Kisten dann auch gleich zu provisionieren, oder willst du /etc/icinga2 eh auf ein DRBD/shared Device legen?

    Ich habe bisher keinerlei solcher Setups in Kundenumgebungen oder in der Community gesehen, dort läuft alles HA-enabled oder standalone. Ich denke aber dass man sich an den Icinga1-Setups damit orientieren kann, inkl. retention.dat -> icinga2.state file auf einem DRBD/NFS Device und was man halt sonst noch so braucht. Finde ich den Aufwand dafür allerdings nicht gerechtfertigt im Vergleich zum active/active out-of-the-box.

    Das sieht das aktuelle Cluster-Design nicht vor, dass sich Instanzen unterschiedlich verhalten in der HA-Zone. Ein Cold-Standby mit Quorum und Co können Tools wie Corosync/Pacemaker deutlich besser. Da braucht man das Rad nicht neu erfinden.

    The migration hints only refers to the command endpoint top down mode, which applies to be simpler and easier to understand. If you want to go the route of syncing the config from the master to the client (which involves having zones.d/client1-zone-name/*.conf) you'll have to deal with that on your own.

    Depends. Puppet uses the agent concept, which is kind of nice having them send reports and restoring the behaviour each time a user tries to change something (i.e. the right configs in place, apache vhosts, monitoring config, etc.). Ansible follows a different approach with a central server using ssh as bridge. I haven't looked much in Chef or Salt myself yet.


    In terms of config management, I'd suggest to look into Foreman as management interface as well. That works pretty good in combination with Puppet and Ansible. We're using Foreman and Puppet for a long time here at NETWAYS, and are happy users and contributors.

    Mainly because CLIENT_MULTI_STATEMENT will save you a lot of round trips. Take the following example: You'll have 10000 SQL queries. Now your database driver runs execute, wait for result, process result one by one in a loop. The MySQL server just executes one query in a transaction, and then returns the result. In comparison to that, multiple queries in one request message will reduce the round trip time, and as such, the MySQL server will process multiple queries, and thus return multiple results.


    The handling of such results is the root cause for the bug you've hit. Unfortunately a fix for that a while ago introduced another problem, which is why this one stays on the TODO list.


    Note: /var/lib/...../comments is just the local storage. The daemon already processed those files into memory, the IDO database update runs independent from that reading. The final object activation in memory triggers database updates, which is quite huge at some point. You won't hit the bug with host or service objects, just with downtimes/comments. There's special query handling involved to emulate "replace into" instead of "delete" - users whining that the interface is empty - "insert" - "commit" - users happy again.


    You might add your thoughts on the issue, it will certainly help to consider solutions and priority.

    Kommt drauf an, welche Aussage wichtiger ist. Antwortet ein Host auf Ping, bedeutet das nicht notwendigerweise dass der Icinga2-Client auch noch läuft. Umgekehrt betrachtet - was bedeutet "Erreichbarkeit eines Hosts" für dich? Das kann ping, http, cluster check, tcp, etc. sein.

    You'll need to store that info somewhere. If you prefer to keep multiple apply rules, you can do so as well. I found the way to define such things on the host level, more central and comfortable. Especially since this allows for generating that information, e.g. from a CMDB, Puppet/Foreman, Director, etc.

    Naja, nimms mir nicht übel, aber wie man einen Webserver einrichtet, die System-Logs abzieht und die Informationen aufbereitet, halte ich für Linux-Basis-Wissen und Grundvoraussetzung wenn du einen Dienst darauf betreiben willst. Wenn du dich gar nicht mit dem System an sich beschäftigst, wirst du es immer schwer haben, Fehler zu finden oder gar zu lösen. Ich denke, hier im Forum zum Thema Monitoring wird ein gewisses Grundwissen auch vorausgesetzt, und man darf das ruhigen Gewissens auch erwarten.


    Also, steht im Syslog etwas interessantes zum Apachen, wenn du diesen direkt neu startest?