search

Icinga / icinga2

The core of our monitoring platform with a powerful configuration language and REST API.
https://icinga.com/docs/icinga2/latest
GNU General Public License v2.0
2.03k stars 579 forks source link

[dev.icinga.com #11501] Re-evaluate apply rules after runtime config update via API #4084

Open icinga-migration opened 8 years ago

icinga-migration commented 8 years ago

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

Created by buhtik on 2016-04-01 10:43:48 +00:00

Assignee: (none) Status: New Target Version: Backlog Last Update: 2016-11-16 10:07:14 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

After hosts object were updated, service custom variables were not changed.

Example of service definitions:

apply Service "[CONS][OPS] CPU AVG 5 min." { import "generic-service"

check_command = "check_zabbix" vars.ARG1 = host.vars.zabbix_host_id vars.ARG2 = "zabbix_db" vars.ARG3 = "system.cpu.load[,avg5]" vars.ARG4 = host.vars.cpu_load assign where host.vars.cpu_load }

Steps to reproduce:

  1. Creating host with attributes: {'templates': ['generic-host'], 'attrs': {'vars.location': 'dub', 'vars.connection_time_wait': '14<OK<45', 'vars.cpu_load': '2<OK<4', 'vars.zabbix_agent_health': 'OK=1', 'vars.notes': 'to_add', 'vars.disk_space_opt': '20<OK<80<90', 'vars.role': 'app', 'vars.application': 'SM', 'vars.disk_spase_root': '44<OK<110', 'vars.description': 'Not in prod', 'address': '127.0.0.1', 'vars.zabbix_host_id': '11725', 'vars.type': 'virtual', 'vars.connection_established': '20<OK<40', 'vars.swap_used': '1.2<2<OK<4<4'}}

cat /var/lib/icinga2/api/packages/_api/first-1458367266-1/conf.d/hosts/app-02-prod.dub.conf object Host "app-02-prod.dub" { import "generic-host"

address = "127.0.0.1" vars["application"] = "SM" vars["connection_established"] = "20<OK<40" vars["connection_time_wait"] = "14<OK<45" vars["cpu_load"] = "2<OK<4" vars["description"] = "Not in prod" vars["disk_space_opt"] = "20<OK<80<90" vars["disk_spase_root"] = "44<OK<110" vars["location"] = "dub" vars["notes"] = "to_add" vars["role"] = "app" vars["swap_used"] = "1.2<2<OK<4<4" vars["type"] = "virtual" vars["zabbix_agent_health"] = "OK=1" vars["zabbix_host_id"] = "11725" version = 1459503512.559020 }

  1. Updating host with attributes: {'templates': ['generic-host'], 'attrs': {'vars.location': 'dub', 'vars.connection_time_wait': '23<OK<44', 'vars.zabbix_agent_health': 'OK=1', 'vars.notes': 'to_update', 'vars.disk_space_opt': '20<OK<80<90', 'vars.role': 'app', 'vars.application': 'SM', 'vars.disk_spase_root': '44<OK<110', 'vars.description': 'Not in prod', 'address': '127.0.0.1', 'vars.zabbix_host_id': '11725', 'vars.type': 'virtual', 'vars.connection_established': '29<OK<99', 'vars.swap_used': '1.2<2<OK<4<4', 'vars.zabbix_name': 'app-02-prod.dub'}}

Please note: 'vars.cpu_load': '2<OK<4' - - WAS REMOVED 'vars.connection_time_wait': '14<OK<45' - WAS CHANGED to 'vars.connection_time_wait': '23<OK<44' 'vars.connection_established': '20<OK<40' - WAS CHANGED to 'vars.connection_established': '29<OK<99'

API Result: {u'results': [{u'status': u'Attributes updated.', u'code': 200.0, u'type': u'Host', u'name': u'app-02-prod.dub'}]}

'vars.connection_time_wait' and 'vars.connection_established' were changed in HOST Custom variables, but were not changed in Service Custom variables. 'vars.cpu_load' was not removed.

File '/var/lib/icinga2/api/packages/_api/first-1458367266-1/conf.d/hosts/app-02-prod.dub.conf' was not changed.

More details in attached screenshots.

Attachments

Relations:

icinga-migration commented 8 years ago

Updated by mfriedrich on 2016-04-01 10:59:07 +00:00

Updating custom attributes and rolling back and evaluating apply rules ist not supported by the REST API. That is by design.

icinga-migration commented 8 years ago

Updated by buhtik on 2016-04-01 12:12:15 +00:00

Thanks. Are you going to implement this feature?

icinga-migration commented 8 years ago

Updated by mfriedrich on 2016-04-01 12:22:46 +00:00

It's not planned for now. It involves major changes inside the core and api related stuff making time estimates even harder.

icinga-migration commented 8 years ago

Updated by mfriedrich on 2016-04-04 13:40:35 +00:00

icinga-migration commented 8 years ago

Updated by hvhaugwitz on 2016-07-26 17:39:33 +00:00

I second this request.

It would allow one to update the hosts configuration via API on the fly; without the need of time consuming reloads.

Is it possible to schedule this feature for the next release?

icinga-migration commented 8 years ago

Updated by mfriedrich on 2016-07-26 17:46:57 +00:00

Not for 2.5 that's currently in release freeze time (release critical bug fixes only). We'll re-evaluate the importance of remaining issues after the 2.5 release.

icinga-migration commented 8 years ago

Updated by mfriedrich on 2016-08-08 09:15:16 +00:00

icinga-migration commented 8 years ago

Updated by mfriedrich on 2016-08-08 09:19:37 +00:00

icinga-migration commented 8 years ago

Updated by rhillmann on 2016-09-12 16:09:28 +00:00

+1 Host updates doesnt work either custom attributes or natives. Its going to be changed in memory, but not on disk (/var/lib/icinga2/api/packages/). Pretty useless to update objects if its not changed on disk...

icinga-migration commented 8 years ago

Updated by mfriedrich on 2016-09-12 17:19:05 +00:00

FYI modified attributes are stored in a specific globsl location (/var/lib/icinga2/modified-attributes.conf) and not inside the api package. Those events are replicated throughout cluster nodes. Your comment isn't really helpful either except for your interest in this ticket.

We know that many of you demand this feature, making a change and then automatically re-evaluate everything. It is not easy to implement with transactions, rollbacks, dependency maps, expressions and so forth. Once we have time estimate and release target, we'll update the issue. If one says - I can do it - please share your findings and patches here for futher review/discussions.

icinga-migration commented 8 years ago

Updated by gbeutner on 2016-11-02 06:55:05 +00:00

icinga-migration commented 8 years ago

Updated by mfriedrich on 2016-11-16 10:07:14 +00:00

icinga-migration commented 7 years ago

Updated by mfriedrich on 2017-01-09 15:04:22 +00:00

rahulshw commented 6 years ago

Is there any option, by which, I can forcefully re-evaluate apply rules at regular intervals?

dnsmichi commented 6 years ago

Let a cron do a daemon restart which re-reads the entire configuration.

rahulshw commented 6 years ago

@dnsmichi , restarting the daemon doesn't help in my case. I am using API to update services(checks). Here is what I did.

  1. created an apply rule for dependency
  2. created a service via API, such that dependency rule applies
  3. checked to see if the dependency is created. yes, it was there
  4. updated the service via api, such that the dependency parent changes
  5. checked to see if the dependency is updated. no, it was not
  6. restarted icinga2 service
  7. checked to see if the dependency is updated now. no, it was not updated
dnsmichi commented 5 years ago

Discussion on the community forums: https://community.icinga.com/t/using-api-to-change-host-vars/891

mickenordin commented 5 years ago

@dnsmichi I created #7317 and I am not 100% sure that this is the same problem. The icinga2 api notices that the service is removed and since group membership is stored in the service, not in the servicegroup there is no problem for the api here.

What is needed to fix #7317 would instead be to refresh the servicegroup table when a service or host is deleted, or the hostgroup table only if a host is deleted.

Further more, it works when adding hosts or services through the api, livestatus catches that and adds the service to the servicegroup table, so it seems that there is allready code for updating the table, it just isn't run on delete.