[dev.icinga.com #9440] Allow sending vars up to master node

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/9440

Created by Anonymous on 2015-06-17 20:23:14 +00:00

Assignee: (none) Status: Rejected (closed on 2015-06-17 20:39:36 +00:00) Target Version: (none) Last Update: 2015-06-17 20:39:36 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

---

To make icinga2 even more powerful and utilize the power of apply rules, I think that Icinga2 should have the ability to send data from itself(agent) to upstream, for example vars.inventory.* to upstream. With this feature it will be possible to run scripts/applications to discover configuration/applications/services and other properties based on the discovery applications/scripts, like IIS websites, IIS appools, Apache/NGnix vhosts and so on. With this you can generate monitoring based on the returned data that might otherwise be overlooked/Forgotten. It can be a manual step to run discovery when the server is in "functional" mode, so it reports correctly what is enabled and what is disabled (to monitor they stay that way!)

This already works to some extent locally already with auto apply rules and manually writing in the data on the host object, which has already shown to be quite awesome, however by sending it upstream you can also gain visibility to what you are not monitoring (yet) but have available from the remote agents discovery scripts, eg if you have wierd highports in IIS that you have not setup monitoring yet, this can also ensure remote connectivity to those are working, valid certificate and so on.

Example of data that could be visible upstream:

vars.inventory.windows_service["RpcSs"] = {
    service_name = "SomeService"
    display_name = "SomeService"
    type = "non-standard"
    startup = "automatic-delayed"
    description = "The SomeService Service is a Service that is a service to your Some Service."
    runas = "AD\serviceaccount"
}
vars.inventory.windows_service["RpcSs"] = {
    service_name = "RpcSs"
    display_name = "Remote Procedure Call (RPC)"
    type = "core-os"
    startup = "automatic"
    description = "The RPCSS service is the Service Control Manager for COM and DCOM servers. It performs object activations requests, object exporter resolutions and distributed garbage collection for COM and DCOM servers. If this service is stopped or disabled, programs using COM or DCOM will not function properly. It is strongly recommended that you have the RPCSS service running."
    runas = "network service"
}

vars.inventory.windows_service["Windows Update"] = {
    service_name = "wuauserv"
    display_name = "Windows Update"
    type = "support-service"
    startup = "automatic"
    description = "Enables the detection, download, and installation of updates for Windows and other programs. If this service is disabled, users of this computer will not be able to use Windows Update or its automatic updating feature, and programs will not be able to use the Windows Update Agent (WUA) API."
    runas = "local system"
}
vars.inventory.iisapppool["DefaultAppPool"] = {
    name = "DefaultAppPool"
    dotnetclr = "v4.0.30319"
    pipeline = "classic"
    identity = "ApplicationPoolIdentity"
    applications = "3"
}

vars.inventory.iiswebsite["Default Web Site"] = {
    name = "Default Web Site"
    apppool = "DefaultAppPool"
    path = "%SystemDrive%\inetpub\www"
    bindings = [
        {
            type = "http"
            port = "80"
        },
        {
        type = "https"
            port = "443"
            sslFlags = "0"
        },
        {
            type = "net.tcp"
            binding_information = "808:*"
        },
        {
            type = "net.pipe"
            binding_information = "*"
        },
        {
            type = "net.msmq"
            binding_information = "localhost"
        },
        {
            type = "msmq.formatname"
            binding_information = "localhost"
        }
    ]
}

Based on this, its trivial to create apply rules for services (even have a template library for this, so you can select if you want to only monitor foreign services that are not standard to windows, core services or also role services (AD DS for example). Its also easy to apply monitoring to every binding of IIS of type http and https to automatically generate checks for these (trivial ones, still an improvement over today!).

The idea/thought is to run this when you have changed the server so it will only monitor what was then, if you want to rediscover the discovery cycle has to run again (manually triggered) so you do not by mistake remove some monitoring or add in some new when its being maintained/reconfigured. It might also be possible with a feature like this to expose the "discovered" inventory to a (web)frontend to allow the end user/operator to enable monitoring of these (with an extra attribute applied centrally) and now you have self-serviced monitoring! No magic to it really!

[icinga-migration]

Updated by mfriedrich on 2015-06-17 20:39:25 +00:00

• Duplicates set to 9332

[icinga-migration]

Updated by mfriedrich on 2015-06-17 20:39:36 +00:00

• Status changed from New to Rejected

[icinga-migration]

Updated by mfriedrich on 2017-01-14 13:08:12 +00:00

• Duplicates deleted 9332