My setup (moving to Debian soon, hopefully):
OS => CentOS Linux 7 (Core)
icinga2 => 2.13.6 Release 2.el7
icingaweb2 => 2.8.2 Release 1.el7.icinga
icingadirector => 1.7.2
I am currently facing an issue with data fields / custom variables.
There seems to be a limit of 8474 characters for data fields.
I have not figured out which component is causing this limit yet.
I have a custom service that should check a collection of URLs for its current HTTP status code. The service contains multiple data fields. One of the data fields is used to provide a comma separated list of URLs to the executed script.
Any work is done on the web interface.
If the string is 8474 characters long, it is stored correctly.
If the string is 8475 characters long and I hit the save button, the site just reloads and shows the content which was set before.
Is this a common behaviour?
Is there a possibility to increase the allowed string length?
Is the approach itself “best practices” at all or would you recommend another solution? I cannot hardcode the 146 URLs within the script since it is used multiple times for different stakeholders.
I haven’t hit this limit yet.
My guess, you could try to change the size of the field in the director DB.
If this isn’t enough, also try to find the limit in the data definition in PHP.
Maybe work around this by cloning the check_command and splitting the data into two fields and use something like $var_long_url_part_a$/$var_long_url_part_b$ in the check argument to reassemble the URL?
First of all, I want to thank you guys for taking your time to think about that issue!
@rivad
The director database field itself looks good:
MariaDB [director]> show columns from icinga_service_var where Field = 'varvalue';
+----------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+------+------+-----+---------+-------+
| varvalue | text | YES | | NULL | |
+----------+------+------+-----+---------+-------+
A TEXT column with a maximum length of 65,535 (216 - 1 ) characters
As a temporary solution, I did the following (directly on the console):
UPDATE icinga_service_var SET varvalue = '[CommaSeparatedList]' WHERE varname = '[UrlList]' and service_id = [ID];
After that, I went to the web interface and hit There are no pending changes. Deploy anyway. The changes were applied, I can see all 146 URLs now.
Side effect:
I can see the whole string within its data field on the web interface, but I cannot change any service vars for that specific object through the web interface anymore; same behaviour as described before, the site just reloads and does nothing.
@moreamazingnick
Why should I not be able to do so?
It takes around 80 seconds to
Execute the check initially
Check all websites given by the data field, some error handling included
Return the result and performance data to Icinga
My next steps:
I will stop wondering why the content may be loaded but not written back and keep digging.
If I come up with a better solution, I will let you know.
Any suggestions as to which component or setting could cause that behaviour are still highly appreciated.
First, I tested this here, and it works, I could store a string of 9000 characters in a custom variable using Director. So the issue can be solved by upgrading to the lastest version of Icinga and Director.
Second, you can try what I did (but will your old version allow, I am not sure), i.e., define a Data Field of type array, assign it to a service or host template, fill the values, one per URL, create a Service Apply Rule, and use the custom variable as “Apply For”. You will end up with 146 services attached to the same host. You can use $custom_var$ within the service name.
Third,
Any suggestions as to which component or setting could cause that behaviour are still highly appreciated.
Is the Director module’s web interface writing directly into the DB, or does it trigger a REST API call to do that?
In the latter case, I would try to find out what is that REST API call and test it in command line; the problem will probably be there.
Another suggestion would be to go in the MySQL log file and trace if any update statement is being sent to the DB.
