Zabbix configuration to keep historical

[yngvith]

I've got a problem with Zabbix graphs.
Zabbix graph has only 6 hours of historical data.
Although the setting are to keep data for 7 (history) days, and trend for 365 days. it's different from server to server. some server will have data for 365 days, but others for 3 hours.
Zabbix agent version is
v2.4.7 (revision 56694) (12 November 2015)
LInux version
Linux 2.6.32-573.22.1.el6.centos.plus.x86_64 #1 SMP Wed Mar 23 17:51:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
regards
Yngvi

[allexpetrov]

Hi there,

We don't owe a magic ball here as well as we are not Vangas apprentice. Expand the issue - which graph, which item, items configuration, last 500 values, paste a screenshot or have you checked the database for those items in history* table?

Regards,
Alex!

[yngvith]

Zabbix configuration to keep historical

ok, I'm adding 2 screenshots. Normally I get the 'Zoom' as for the cpu load.
i.e. I can choose from1h to 6m or All.
but for some graphs, like for the tsg.delf.pr Depth I can only view upto 3h.

For the history data for a particular graph, I've got the graphid from the web gui.
How should I relate the graphid to the data in the history table, (or even the trends table)?

[yngvith]

when I check the database for some items like those, which have the same settings for history and trend (7 and 365) , the data is however quite different.

mysql> select itemid,type,hostid,delay,history,trends,data_type, templateid from items where name like '%AUTR%';
+--------+------+--------+-------+---------+--------+-----------+------------+
| itemid | type | hostid | delay | history | trends | data_type | templateid |
+--------+------+--------+-------+---------+--------+-----------+------------+
| 537139 | 2 | 10288 | 0 | 7 | 365 | 0 | NULL |
| 537152 | 2 | 10288 | 0 | 7 | 365 | 0 | NULL |
| 578837 | 2 | 10324 | 0 | 7 | 365 | 0 | NULL |
| 578874 | 2 | 10324 | 0 | 7 | 365 | 0 | NULL |
| 585473 | 2 | 10217 | 0 | 7 | 365 | 0 | NULL |
| 585539 | 2 | 10217 | 0 | 7 | 365 | 0 | NULL |
| 590885 | 2 | 10216 | 0 | 7 | 365 | 0 | NULL |
| 590925 | 2 | 10216 | 0 | 7 | 365 | 0 | NULL |
| 658976 | 2 | 10508 | 0 | 7 | 365 | 0 | NULL |
| 659016 | 2 | 10508 | 0 | 7 | 365 | 0 | NULL |
| 662077 | 2 | 10215 | 0 | 7 | 365 | 0 | NULL |
| 662124 | 2 | 10215 | 0 | 7 | 365 | 0 | NULL |
| 668837 | 2 | 10384 | 0 | 7 | 365 | 0 | NULL |
| 668865 | 2 | 10384 | 0 | 7 | 365 | 0 | NULL |
| 670972 | 2 | 10562 | 0 | 7 | 365 | 0 | NULL |
| 671018 | 2 | 10562 | 0 | 7 | 365 | 0 | NULL |
| 674110 | 2 | 10165 | 0 | 7 | 365 | 0 | NULL |
| 674172 | 2 | 10165 | 0 | 7 | 365 | 0 | NULL |
+--------+------+--------+-------+---------+--------+-----------+------------+
18 rows in set (0.03 sec)

mysql>
mysql> select count(history_uint.clock) from history_uint where itemid=662077;
+---------------------------+
| count(history_uint.clock) |
+---------------------------+
| 2010 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select count(history_uint.clock) from history_uint where itemid=590885;
+---------------------------+
| count(history_uint.clock) |
+---------------------------+
| 1009 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select count(history_uint.clock) from history_uint where itemid=674110;
+---------------------------+
| count(history_uint.clock) |
+---------------------------+
| 99 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select count(trends_uint.clock) from trends_uint where itemid=34769 ;
+--------------------------+
| count(trends_uint.clock) |
+--------------------------+
| 8730 |
+--------------------------+
1 row in set (0.53 sec)

mysql>
mysql> select count(trends_uint.clock) from trends_uint where itemid=590885 ;
+--------------------------+
| count(trends_uint.clock) |
+--------------------------+
| 3759 |
+--------------------------+
1 row in set (0.28 sec)

mysql> select count(trends_uint.clock) from trends_uint where itemid=674110 ;
+--------------------------+
| count(trends_uint.clock) |
+--------------------------+
| 4 |
+--------------------------+
1 row in set (0.00 sec)

[yngvith]

I found out something interesting. The variable in question changes itemid.
It seems it changes on a 6hour interval, so no wonder the graph is only available for 3-6 hours back!
Since yesterday this variable has now had those itemid values:
itemid=675216;
itemid=675776;
itemid=676140;

Has anybody idea what's going on ??

[Linwood]

Are these LLD items and you may be getting new items all the time due to index changes? So it's creating and losing items? Guessing.

[yngvith]

I have several customers in Zabbix.
One zabbix db for all. Same tables (shared) for all customers.
Still this 'funny thing' only happens for the itemsid's for one particular customer!

My only guess now, it has to be something linked with the discovery? for this customer/server , whith this particular data?

[yngvith]

I've checked for indexing in the db. There is no re-indexing. So that can't be the reason.

[Linwood]

I've checked for indexing in the db. There is no re-indexing. So that can't be the reason.

If they are getting new item id's, then something is causing them to be recreated. You might want to try to watch them in a script, so you can tell how often and when they are changing, and see if you can tie that to some event. If it's not LLD (and that's still my guess) then tying it to an event will at least give you a place to look.

[yngvith]

I just noticed that we have a local cronjob on one server , which runs this cronjob, which is a discovery script:

*/5 * * * * /apps/opt/zabbix_scripts/zabbix_system_run_shell.sh "/apps/opt/zabbix_scripts/zabbix_discovery_run_job.sh" cust-label > /dev/null 2>&1

and the same seems to be configured in the traditionaly way in the Zabbix gui.
The interval in the gui is set for 600 s.
Is it's possible this 'multiple discovery' will have this strange effect?