I can explain the glue: please see first link of my signature and have a read ...
But it's not a techical description in terms of database relations
Reinhard
Inbound/Outbound Data Source the same after changing templat
Moderators: Developers, Moderators
Re: Inbound/Outbound Data Source the same after changing tem
I have come across the same problem (Outbound Data Sources disappeared). Can a developer please give us the SQL that is executed when someone manually sets that field via the GUI? This will send us in the right direction for building an UPDATE statement that will fix this. I currently have ~1000 interfaces I am monitoring, so doing it manually IS NOT an option.
Thanks, Rock
Thanks, Rock
- gandalf
- Developer
- Posts: 22383
- Joined: Thu Dec 02, 2004 2:46 am
- Location: Muenster, Germany
- Contact:
Re: Inbound/Outbound Data Source the same after changing tem
You should be able to import a pristine traffic graph template to fix the issue
R.
R.
Re: Inbound/Outbound Data Source the same after changing tem
Then 2 questions:
1) Where can I find the original Interface Traffic (bits/second) template? docs.cacti.com/templates only has interface_traffic and interface_traffic95th. I'm not particularly fond of the interface_traffic format.
2) How do I ensure the original template gets completely overwritten? Last thing I want is to replace this problem with the problem of changing the graph template manually for 1000 interfaces.
Thanks, Rock
1) Where can I find the original Interface Traffic (bits/second) template? docs.cacti.com/templates only has interface_traffic and interface_traffic95th. I'm not particularly fond of the interface_traffic format.
2) How do I ensure the original template gets completely overwritten? Last thing I want is to replace this problem with the problem of changing the graph template manually for 1000 interfaces.
Thanks, Rock
- gandalf
- Developer
- Posts: 22383
- Joined: Thu Dec 02, 2004 2:46 am
- Location: Muenster, Germany
- Contact:
Re: Inbound/Outbound Data Source the same after changing tem
Best is to use a test cacti install. Export the traffic template and import to your production machine
R.
R.
-
- Posts: 15
- Joined: Thu Mar 01, 2012 9:56 am
Re: Inbound/Outbound Data Source the same after changing tem
I've come into this problem a couple of times, even after upgrade to 0.8.8.a. Like the others, I have multiple interface graphs that have had their data sources skewered (the actual data sources are fine, but the 'Graph Item' fields somehow got reset.) While the first couple of times I manually corrected, I now have dozens of graphs with the problem. I tried re-importing the graph template, as per earlier posts, but this did not resolve the problem.
I'm trying to understand how to reset these in bulk via the database; While I haven't yet found solution, I've made some interesting observations: For those graphs having issues, the inbound data source oft refers to the 'traffic_out' data source. When resetting this to 'traffic_in', the 'task_item_id' field in the 'graph_templates_item' field almost always decrements by 1 (i.e. 1879, becomes 1878, etc.) Also, the 'task_item_id' for the outbound graph items almost always has a value of '55', that gets set to '0' after changing the inbound data source. Example:
Before:
| id | hash | local_graph_template_item_id | local_graph_id | graph_template_id | task_item_id | color_id | alpha | graph_type_id | cdef_id | consolidation_function_id | text_format | value | hard_return | gprint_id | sequence |
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+------------ -+-----------+----------+
| 13579 | | 19600 | 731 | 121 | 1879 | 0 | FF | 9 | 2 | 1 | Average: | | | 2 | 3 |
| 15249 | | 19605 | 731 | 121 | 55 | 0 | FF | 9 | 2 | 3 | Maximum: | | on | 2 | 8 |
After:
| id | hash | local_graph_template_item_id | local_graph_id | graph_template_id | task_item_id | color_id | alpha | graph_type_id | cdef_id | consolidation_function_id | text_format | value | hard_return | gprint_id | sequence |
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+------------ -+-----------+----------+
| 13579 | | 19600 | 731 | 121 | 1878 | 0 | FF | 9 | 2 | 1 | Average: | | | 2 | 3 |
| 15249 | | 19605 | 731 | 121 | 0 | 0 | FF | 9 | 2 | 3 | Maximum: | | on | 2 | 8 |
As another observation relating to outbound data sources, it is always the 5,6,7,8 sequence numbers that change from '55', to '0', to the proper data_template_rrd.id when set.
And as I type this, I finally see the pattern: Affected graphs most often have their outbound data source set to '55' (or sometimes '0'), while the inbound data sources are set to what the outbound should be (which seems to be the proper 'data_template_rrd.id' - 1) Looking at yet another example, I see that sequence '2' has the right task_item_id/data_template_rrd.id, while sequence numbers 1,3, and 4 have an id of +1. The 5,6,7,8 sequence numbers should be the value of the +1 IDs:
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+-------------+-----------+----------+
| id | hash | local_graph_template_item_id | local_graph_id | graph_template_id | task_item_id | color_id | alpha | graph_type_id | cdef_id | consolidation_function_id | text_format | value | hard_return | gprint_id | sequence |
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+-------------+-----------+----------+
| 15344 | | 19605 | 885 | 121 | 55 | 0 | FF | 9 | 2 | 3 | Maximum: | | on | 2 | 8 |
| 15010 | | 19604 | 885 | 121 | 55 | 0 | FF | 9 | 2 | 1 | Average: | | | 2 | 7 |
| 14676 | | 19603 | 885 | 121 | 55 | 0 | FF | 9 | 2 | 4 | Current: | | | 2 | 6 |
| 14342 | | 19602 | 885 | 121 | 55 | 20 | FF | 4 | 2 | 1 | Outbound | | | 2 | 5 |
| 14008 | | 19601 | 885 | 121 | 2212 | 0 | FF | 9 | 2 | 3 | Maximum: | | on | 2 | 4 |
| 13674 | | 19600 | 885 | 121 | 2212 | 0 | FF | 9 | 2 | 1 | Average: | | | 2 | 3 |
| 12641 | | 19598 | 885 | 121 | 2212 | 22 | FF | 7 | 2 | 1 | Inbound | | | 2 | 1 |
| 12642 | | 19599 | 885 | 121 | 2211 | 0 | FF | 9 | 2 | 4 | Current: | | | 2 | 2 |
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+-------------+-----------+----------+
I don't think MySQL allows for updates in conjunction with a select, but it should be possible to script something.
I'm trying to understand how to reset these in bulk via the database; While I haven't yet found solution, I've made some interesting observations: For those graphs having issues, the inbound data source oft refers to the 'traffic_out' data source. When resetting this to 'traffic_in', the 'task_item_id' field in the 'graph_templates_item' field almost always decrements by 1 (i.e. 1879, becomes 1878, etc.) Also, the 'task_item_id' for the outbound graph items almost always has a value of '55', that gets set to '0' after changing the inbound data source. Example:
Before:
| id | hash | local_graph_template_item_id | local_graph_id | graph_template_id | task_item_id | color_id | alpha | graph_type_id | cdef_id | consolidation_function_id | text_format | value | hard_return | gprint_id | sequence |
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+------------ -+-----------+----------+
| 13579 | | 19600 | 731 | 121 | 1879 | 0 | FF | 9 | 2 | 1 | Average: | | | 2 | 3 |
| 15249 | | 19605 | 731 | 121 | 55 | 0 | FF | 9 | 2 | 3 | Maximum: | | on | 2 | 8 |
After:
| id | hash | local_graph_template_item_id | local_graph_id | graph_template_id | task_item_id | color_id | alpha | graph_type_id | cdef_id | consolidation_function_id | text_format | value | hard_return | gprint_id | sequence |
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+------------ -+-----------+----------+
| 13579 | | 19600 | 731 | 121 | 1878 | 0 | FF | 9 | 2 | 1 | Average: | | | 2 | 3 |
| 15249 | | 19605 | 731 | 121 | 0 | 0 | FF | 9 | 2 | 3 | Maximum: | | on | 2 | 8 |
As another observation relating to outbound data sources, it is always the 5,6,7,8 sequence numbers that change from '55', to '0', to the proper data_template_rrd.id when set.
And as I type this, I finally see the pattern: Affected graphs most often have their outbound data source set to '55' (or sometimes '0'), while the inbound data sources are set to what the outbound should be (which seems to be the proper 'data_template_rrd.id' - 1) Looking at yet another example, I see that sequence '2' has the right task_item_id/data_template_rrd.id, while sequence numbers 1,3, and 4 have an id of +1. The 5,6,7,8 sequence numbers should be the value of the +1 IDs:
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+-------------+-----------+----------+
| id | hash | local_graph_template_item_id | local_graph_id | graph_template_id | task_item_id | color_id | alpha | graph_type_id | cdef_id | consolidation_function_id | text_format | value | hard_return | gprint_id | sequence |
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+-------------+-----------+----------+
| 15344 | | 19605 | 885 | 121 | 55 | 0 | FF | 9 | 2 | 3 | Maximum: | | on | 2 | 8 |
| 15010 | | 19604 | 885 | 121 | 55 | 0 | FF | 9 | 2 | 1 | Average: | | | 2 | 7 |
| 14676 | | 19603 | 885 | 121 | 55 | 0 | FF | 9 | 2 | 4 | Current: | | | 2 | 6 |
| 14342 | | 19602 | 885 | 121 | 55 | 20 | FF | 4 | 2 | 1 | Outbound | | | 2 | 5 |
| 14008 | | 19601 | 885 | 121 | 2212 | 0 | FF | 9 | 2 | 3 | Maximum: | | on | 2 | 4 |
| 13674 | | 19600 | 885 | 121 | 2212 | 0 | FF | 9 | 2 | 1 | Average: | | | 2 | 3 |
| 12641 | | 19598 | 885 | 121 | 2212 | 22 | FF | 7 | 2 | 1 | Inbound | | | 2 | 1 |
| 12642 | | 19599 | 885 | 121 | 2211 | 0 | FF | 9 | 2 | 4 | Current: | | | 2 | 2 |
+-------+------+------------------------------+----------------+-------------------+--------------+----------+-------+---------------+---------+---------------------------+-------------+-------+-------------+-----------+----------+
I don't think MySQL allows for updates in conjunction with a select, but it should be possible to script something.
-
- Posts: 15
- Joined: Thu Mar 01, 2012 9:56 am
Re: Inbound/Outbound Data Source the same after changing tem
Wrote a little repair script that seems to have resolved the issue for my I/F graphs (that are bits/sec, btw.)
Passing it along, but I would recommend anyone trying it, take a snapshot of their database first! The script/method is pretty haphazard, and while it worked, it may have unforeseen consequences.
Passing it along, but I would recommend anyone trying it, take a snapshot of their database first! The script/method is pretty haphazard, and while it worked, it may have unforeseen consequences.
- Attachments
-
- repair_ifgraphs.zip
- repair i/f graphs
- (1.62 KiB) Downloaded 172 times
Re: Inbound/Outbound Data Source the same after changing tem
Hi All,
I'm Currently faces the above problem on all cacti graphs, Please share the steps needed to fix that issue.
Appreciate your fast feedback,
Thanks,
I'm Currently faces the above problem on all cacti graphs, Please share the steps needed to fix that issue.
Appreciate your fast feedback,
Thanks,
Best Regards,
EngOuf
EngOuf
Who is online
Users browsing this forum: No registered users and 4 guests