Pass results as objects, not as strings.

[htgoebel]

To be done after pull-request #566 has been applied.

Currently results are passed to the broker as strings. This means, the string is formated at the senders site and parsed/split at the broker. This is done even if both sides are running in the same process, e.g. in livestatus-broker.

I propose passing either tuples or even "Results"-objects instead.

This can easily be implemented after pull-request #566, since sending the result no longer relies on the logging-mechanism.

Tuples are cheaper to transport, while "Result"-objects are more mighty and more flexible.

[naparuba]

What results? You means logs?

[htgoebel]

I mean results. Currently "logs" are misused for passing results.

I admit, that sending around log-messages is an easy way to pass results from external commands. But it produces overhead (formatting and splitting) when passing within shinken. You can see what I mean at https://github.com/naparuba/shinken/blob/master/shinken/modules/livestatus_broker/log_line.py#L100

[naparuba]

I think the whole point is here. They are logs, and only logs. They are not a tool for looking at states or something like that. for this usage there are classic broks, update_host_state/service that got far more data. I think we should not try to change logs to be like theses one, because they are already sent, and if such data is need, the dev must look at them, not in parsing logs.

The whole thing here is about reporting (if it was just for looking at logs, it do not need parsing), and I think that the current way of doing it is not the perfect way. Yes of course parsing logs is working, but the good solution should be to create a dedicated module for this, create a CUBE database, with a real reporting shema (aggregation and co).

So I think we should work on this core issue becore complexify logs into objects, that will duplicate already existing structured data (update_*_broks).

Jean

On Thu, Sep 6, 2012 at 9:30 PM, Hartmut Goebel notifications@github.comwrote:

I mean results. Currently "logs" are misused for passing results.

I admit, that sending around log-messages is an easy way to pass results from external commands. But it produces overhead (formatting and splitting) when passing within shinken. You can see what I mean at https://github.com/naparuba/shinken/blob/master/shinken/modules/livestatus_broker/log_line.py#L100

— Reply to this email directly or view it on GitHubhttps://github.com/naparuba/shinken/issues/585#issuecomment-8344356.

[xkilian]

Not applicable. These are already objects.

[htgoebel]

Results are send as strings. The sensors are formatting stings which are parsed into values in the receiver. Just because the transport-mechanism for these strings are "broks" does not make the results into objects.

Please reopen!

[xkilian]

Ok, so the focus of this issue is for?

• logs
• passive results from receiver to Scheduler
• results from scheduler to broker.
• others?

Based on what Nap and you have said it would seem door number two is what is pertinent. Passive results from Receivers to Schedulers.

[Seb-Solon]

If I understand well this case, it related to logging.

The idea is not to call the logger in the naglog_result function on log.py and use "object" instead.

I assume you suggest to create a new class for that and so this code : https://github.com/shinken-monitoring/mod-livestatus/blob/master/module/log_line.py wuold be greatly simplified.

It may be related to @000420175b9945624a619cf475401c73043d7874 actually (https://github.com/naparuba/shinken/blob/master/shinken/misc/logevent.py). Here we have a first simple class that parses the log and create an object.

@htgoebel am I right?

[htgoebel]

This is not related to logging, but to passing events/results back to the broker.

When I files this issue two years ago, results are passed back to the broker using the logging mechanism. This was easy to implement since log messages are send to the broker anyway. So the broker needed to decide if this is a real log message or a result. AFSIR a Brok object was send in both cases, stating the type (result or message).

But results have been passes as ''string'', not as tuple (or such like). So the broker has had to parse this string to actually get the result. My point is: '''Do not pass a string around, but a tuple.'''

I did not work on shinken since about when i files this issue. Thus I can not find code reference anymore. Sorry. Maybe it is obsolete as pyro is no longer used.

[Seb-Solon]

Yeah so it's realted to log because this still is how result are send to broker (with a brok using your BrokHandler).

I think we are pointing the same thing but not using the same word :). IMO the solution mentionned above can do it. Instead of sending Brok (that contains string) we could send LogEvent object which is basically a parsed log line.

I'll work on how to implment that but I don't think it will be ready for 2.2