Log items

we left ZBXNEXT-1427 open to deal with extracted value graphing

zalex_ua let me disagree See comment below.

I believe this is an issue which should be fixed.
Reopening.

I think we could resolve it: add an additional Javasript pop-up confirmation dialog when user tries to save numeric item with type log.

Does that mean it's limited by the frontend only and not by the corresponding API call?

Marc, no, API doesn't allow to create numeric item with key in log, logrt, eventlog

Then I don't understand how a pop-up may help in this context.
Isn't it the aim of this issue to support numeric 'Information types' for log items in the same way it is advertised for vfs.file.regexp[]?

This functionality is needed quite often and I would appreciate to see it implemented.
By now people write their own (more or less efficient) procedures and send them via zabbix-trapper to fill the gap.

I tried to change "value_type" in "items" table from 2 (log) to 3 (unsigned integer) directly in database.
The key was logrt["e:\log\log.log","([0-9]+)",,,,\1]

An it works (C)!
I was able to build a graph on the item.
Of course after this change zabbix server started to store new values to another table - "history_uint", as supposed.

So seems there isn't any other limitation than a sanity check in frontend to not allow numeric type for log* items.
This check has been introduced before the ZBXNEXT-1653 implementation, so it was ok.

But now we can improve this limitation.
For example replace it by the pop-up I mentioned.

Another approach: if log* item key contains 6th parameter (<output>) then allow to store it as numeric item type.
Seems should be easy to fix it.

It's possible to "hacks" log items (as I mentioned above) at template level.
Then such template can be successfully linked to a host and the item type will be preserved as Numeric.

This improvement is a no brainer in my mind. If you are collecting metrics from a log its great to be able to graph it.

To fix this we'll need to separate log items from other item types. This is not something we can do during bugsquashing.

zalex_ua I don't see much difference with "vfs.file.regexp[file,regexp,<encoding>,<output>]" key which is allowed to be saved as any item type ...

ZBX-7821-2.2.4.patch is a quick'n dirty hack.
it disables checking of type when log's output parameter equals to '\1'

When getting implemented, then something like ZBXNEXT-2387 might be beneficial.

One thing I forgot at all is graphing values with unpredictable interval of values.
In a real case with log* item update interval for example 60 seconds values may come for example with random interval ~300 seconds or more.
In such case zabbix will graph "dots" instead of expected lines.

Of course it's possible to play with definitions:

define('ZBX_GRAPH_MAX_SKIP_CELL',       16);
define('ZBX_GRAPH_MAX_SKIP_DELAY',      4);

(discussed a bit also in https://support.zabbix.com/browse/ZBXNEXT-2230#comment-48469)

But if for example I want to catch *log values as fast possible and set item update interval to 1 second?
Then those definitions should be increased significantly (especially ZBX_GRAPH_MAX_SKIP_DELAY).

Also remember that ZBX_GRAPH_MAX_SKIP_CELL used in an estimation where from to get data - from history or trends.

(1) Removed translation strings:

• Type of information must be "Log" for log key.

oleg.egorov CLOSED

RESOLVED in svn://svn.zabbix.com/branches/dev/ZBX-7821

just for a record - solution is simple - r54000 says "removed restriction for log, logrt and eventlog items to be with information type numeric"

iivs I might've said this incorrectly. What I meant is, I removed the restriction to have log type information for items with key "log", "logrt" and "eventlog". So now those items can now have numeric type of information.

TESTED

Restriction removed. It's now possible to have any type of information for items and item prototypes with key "log", "logrt" and "eventlog"

Fixed in pre-2.5.0 (trunk) r54244

(2) Documented in:

• https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew300#ability_to_graph_log_items
• https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/log_items#configuration

RESOLVED.

sasha Looks good! CLOSED

<richlv> it seems like choosing non-"Log" information type will lead to a loss of local timestamp in case of all log items and also log severity & source in case of the eventlog item. that should be mentioned.

local timestamp is also lost when using output, but that's a separate bugreport - ZBX-9610

martins-v Notes added to:

• https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/log_items#configuration
• https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/zabbix_agent/win_keys

Please review if they're correct.

<richlv> if i read it right, we should probably also mention local timestamp for the eventlog key

martins-v Right, done that: https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/zabbix_agent/win_keys

RESOLVED.

<richlv> thanks, CLOSED

note that this mostly duplicated/implemented ZBXNEXT-89

another thing to note is that the eventlog key does not seem to support 'output' parameter at this time, thus non-log information type for it does not seem to be necessary - but i guess it was simpler to remove the restriction for all log items in one go

Another point which was mentioned on a training - values for such log items may come with very different intervals.
So expect to see direct lines between two values or just dots on such graphs.
But here is nothing to do as for graphing - that's expected and I don't see how it could be solved.

Or for such items we would need to use use the same graphing logic as for trapper items ? ..... I don't know ....

This introduced a bug, see ZBX-10102.