I have a very strange behaviour of Icinga Web 2 or the plugin (not sure who is causing the problem):
My bet would be that the plugin is sending this message because Icinga Web 2 is set to english language but the server is german so that’s probably also the reason why the message is german.
This happened after uninstalling and reinstalling Icinga 2 on that server (Icinga service stopped immediately after starting it and the logs and reconfiguring showed no problem). The other plugins went OK just fine but this one gave me this message.
The check is the build-in (shipped with icinga) CPU Load check for Windows.
Any idea would be helpful.
Hi,
what happens if you query this service via the REST API at /v1/objects/services?
Also, please share the version of Icinga Web 2 and the database configuration for the IDO resource from resources.ini (obfuscate credentials, I am merely interested in the charset).
Cheers,
Michael
How exactly can I query the service with the REST API?
Like this?:
curl -k -u user:password 'https://localhost:5665/v1/objects/services'
Icinga Web 2 is running v2.6.3 and the IDO resource lloks like this:
[icinga_ido]
type = "db"
db = "mysql"
host = "localhost"
port = ""
dbname = "..."
username = "..."
password = "..."
charset = ""
use_ssl = "0"
So it seems like there is no charset set. Same is with the icingaweb_db. The other resources have a charset set.
I’m not always adding the doc URLs, that’s an exercise left to the reader 
Here’s what I am referring to, your attempt is good but likely you want to use a filter e.g. on service.name == ....
Prior to analysing what’s inside the IDO database, I’d like to know whether the core already received UTF8 garbage from the plugin. That’s why the API call.
Cheers,
Michael
Sorry for the long time, had some problems querying it.
Here is the output of curl -k -u user:password 'https://localhost:5665/v1/objects/services/<server>!CPU%20Load'
{
"results": [
{
"attrs": {
"__name": "<server>!CPU Load",
"acknowledgement": 1,
"acknowledgement_expiry": 0,
"action_url": "",
"active": true,
"check_attempt": 1,
"check_command": "hx-check-cpu-windows",
"check_interval": 60,
"check_period": "",
"check_timeout": null,
"command_endpoint": "<server>",
"display_name": "CPU Load",
"downtime_depth": 0,
"enable_active_checks": true,
"enable_event_handler": true,
"enable_flapping": false,
"enable_notifications": true,
"enable_passive_checks": true,
"enable_perfdata": true,
"event_command": "",
"flapping": false,
"flapping_current": 0,
"flapping_last_change": 0,
"flapping_threshold": 0,
"flapping_threshold_high": 30,
"flapping_threshold_low": 25,
"force_next_check": false,
"force_next_notification": false,
"groups": [],
"ha_mode": 0,
"host_name": "<server>",
"icon_image": "",
"icon_image_alt": "",
"last_check": 1566983939.531,
"last_check_result": {
"active": true,
"check_source": "<server>",
"command": [
"C:\\Program Files\\ICINGA2\\/sbin/check_load.exe",
"-w",
"92",
"-c",
"97"
],
"execution_end": 1566983939.531,
"execution_start": 1566983939.438,
"exit_status": 3,
"output": "Die angegebene Sprachenkennung f<FC>r die Ressourcen wurde nicht in der Image-Datei gefunden.",
"performance_data": [],
"schedule_end": 1566983939.531,
"schedule_start": 1566983939.531,
"state": 3,
"ttl": 0,
"type": "CheckResult",
"vars_after": {
"attempt": 1,
"reachable": true,
"state": 3,
"state_type": 1
},
"vars_before": {
"attempt": 1,
"reachable": true,
"state": 3,
"state_type": 1
}
},
"last_hard_state": 3,
"last_hard_state_change": 1566887140.720233,
"last_reachable": true,
"last_state": 3,
"last_state_change": 1566887020.720727,
"last_state_critical": 1566821352.127684,
"last_state_ok": 1566886871.852403,
"last_state_type": 1,
"last_state_unknown": 1566983939.541539,
"last_state_unreachable": 1562073714.516742,
"last_state_warning": 1566866861.87836,
"max_check_attempts": 5,
"name": "CPU Load",
"next_check": 1566983999.44,
"notes": "",
"notes_url": "",
"original_attributes": null,
"package": "director",
"paused": false,
"retry_interval": 30,
"severity": 66,
"source_location": {
"first_column": 1,
"first_line": 24,
"last_column": 24,
"last_line": 24,
"path": "/var/lib/icinga2/api/packages/director/9238ce59-761a-4d07-a485-48e3bc392fa3/zones.d/director-global/servicesets.conf"
},
"state": 3,
"state_type": 1,
"templates": [
"CPU Load",
"Windows - CPU",
"agent-service",
"generic-service",
"host var overrides (Director)"
],
"type": "Service",
"vars": {
"advanced_options": false,
"critical": "97",
"notification_receiver": false,
"warning": "92"
},
"version": 0,
"volatile": false,
"zone": "master"
},
"joins": {},
"meta": {},
"name": "<server>!CPU Load",
"type": "Service"
}
]
}
So it already is a localization issue with the plugin returning the output. @Al2Klimov I guess this is also fixed with https://github.com/Icinga/icinga2/issues/7110 ?
1 Like
So how can I fix it? Or do I need to wait for 2.11?
Even though my master is not on 2.11? I thought I have to update master/satellite first and then the clients?
Nothing changed in the way the cluster communicates. The preferred way in upgrade maintenance windows is to keep master > satellite > agents though. This allows to determine functionality and problem detection more easily.
I didn’t say though to roll it on all agents, just one to see whether your problem is solved. Then do a rollback (re-install 2.10.x). Whenever the agent setup detects existing configuration, it doesn’t override it.
After installing the snapshot every check on this machine fails with Check command 'xyz' does not exist.
I checked C:\ProgramData\icinga2\var\lib\icinga2\api\zones\director-global\director\commands.conf and there are the commands.
Still the same after rolling back to 2.10
I checked the logs and there was a warning about some deprecated behaviour and that I shall update my master/satellite.
So I removed everything again and installed 2.10 again and all but the cpu checks work again.
The log entry is there to warn users about the upgrade path. But still, the config sync via the old method should work. The 2.11 sync puts a stage in between and then validates the configuration - this may have failed for some reason. Maybe the check via command_endpoint was fired between the stage sync.