The site might be a little wonky during the holidays, including reboots and Docker container rebuilds.
I'm splitting the server setup into /woltlab (this forum) and a possible new one (Discourse). Redirects using an Nginx proxy for /cms, /wbb and index.php are in place. / might sometimes show you a different site; I'll write something more detailed once it is production ready.
In case of problems, try clearing your cookies and/or start a fresh browser session.
The site might be a little wonky during the holidays, including reboots and Docker container rebuilds.
I'm splitting the server setup into /woltlab (this forum) and a possible new one (Discourse). Redirects using an Nginx proxy for /cms, /wbb and index.php are in place. / might sometimes show you a different site; I'll write something more detailed once it is production ready.
The site might be a little wonky during the holidays, including reboots and Docker container rebuilds.
I'm splitting the server setup into /woltlab (this forum) and a possible new one (Discourse). Redirects using an Nginx proxy for /cms, /wbb and index.php are in place. / might sometimes show you a different site; I'll write something more detailed once it is production ready.
The site might be a little wonky during the holidays, including reboots and Docker container rebuilds.
I'm splitting the server setup into /woltlab (this forum) and a possible new one (Discourse). Redirects using an Nginx proxy for /cms, /wbb and index.php are in place. / might sometimes show you a different site; I'll write something more detailed once it is production ready.
The site might be a little wonky during the holidays, including reboots and Docker container rebuilds.
I'm splitting the server setup into /woltlab (this forum) and a possible new one (Discourse). Redirects using an Nginx proxy for /cms, /wbb and index.php are in place. / might sometimes show you a different site; I'll write something more detailed once it is production ready.
The site might be a little wonky during the holidays, including reboots and Docker container rebuilds.
I'm splitting the server setup into /woltlab (this forum) and a possible new one (Discourse). Redirects using an Nginx proxy for /cms, /wbb and index.php are in place. / might sometimes show you a different site; I'll write something more detailed once it is production ready.
Icinga is a monitoring tool, no lifecycle management tool which takes care about packages and dependencies. There won't be a plugin sync, such a task needs to be managed with an external tool or your weapon of choice (git, cron, spacewalk, foreman, puppet, ansible, etc.)
.pnp-internal is created by PNP automatically AFAIK, there is no extra configuration for that internal metric directory. Maybe it did not yet right those, or something else is wonky. The debug logs might tell.
Your module has to have a dependency to the monitoring module, as this component provides the IDO backend and specific functions to retrieve values from tables there. That's the first thing to know about these things.
Meaning to say, your e.g. ListController could look like this in application/controllers/ListController.php
Code is stolen from https://github.com/Icinga/icin…ollers/ListController.php for example, but there are also other modules which do implement such.
You also need to ensure to apply restrictions to these calls, otherwise your module will show all data. Best is to e.g. copy the one's the monitoring module would apply itself. Though your module can provide its own restrictions.
In order to simply test the view, add a new html snippet into application/views/scripts/list/index.phtml
Stolen from https://github.com/Icinga/icin…ripts/list/services.phtml in an abstracted way.
Did not test the above, but that's how gather data from controllers and put them into views from my experience. Still learning a lot myself.
JoNe provided a link lately here as well: Einige Fragen zu Modulen/Zend-Syntax im IcingaWeb2
You need to handle such logic inside the eventhandler script itself. There's the possibility to pass literally any runtime macro from Icinga 2 to the script.
This is a requirement by Icinga 2 and is how distributed monitoring works. Helps to read and understand the basic principles: https://www.icinga.com/docs/ic…6-distributed-monitoring/
.pnp-internal adds graphs for PNP's application state. This is populated automatically during NPCD's runtime.
If you want to use a different default graph in Icinga Web 2, modify the module's configuration.
You'll need to figure out which application causes load. There's more hints the docs for that, also monitor the entire instance even more than just "load".
Please use the code tags (</> in your editor) to properly format your configuration. That's highlighted in the FAQ too.
vs
The "notification" custom attribute needs to be set on the host object. Not as separate global definition. Please read the documentation on setting custom attributes for objects too.
Only the setup refers to using the CLI commands as "client" role for the secondary master. The configuration happens as master, similar to the first master role. The main difference is, that there's only one configuration master allowed in HA zones. As said, one needs to have the configuration in zones.d and control just that. Both instances then know that objects are assigned to the "master" zone ("object authority") and automatically balance the check execution.
If you instead plan to deploy each master in conf.d/ they act as standalone instances and will double up checks. This is bad, you don't want that. Use the cluster config sync and and assigned config master instead. The Puppet modules and other tools in this scope encourage you to do so too.
I would suggest to only have one configuration master, which populates /etc/icinga2/zones.d/master with the configuration objects needed for the master zone. The secondary master then just receives the configuration from the first one. It continues to run, if the first master dies.
What exactly does it mean when you are deploying the two master's from a configuration management tool? Does this include the configuration sync inside the cluster, how does it affect your clients/satellites?
Laufen da vielleicht mehrere tote Prozesse die sich gegenseitig in die Quere kommen? Gibt es einen Cronjob der da Dateien wegräumt?
As open source matters, here's the PR: https://github.com/mmarodin/icinga2-plugins/pull/5
The error originates from the fact that perfdata is empty. Just tested this locally.
And while I am at it, another one which improves the error handling. I don't have any Icinga Web 2 nor Grafana setup around, just attempting to run the script with python for checking if it compiles.
https://github.com/mmarodin/icinga2-plugins/pull/6
Bonus: DEBUG=1 as environment variable now prints the HTML output. That helps with standalone debugging.