Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #2653] Display plugin long output in the host/service history grid #800

Closed
icinga-migration opened this issue May 31, 2012 · 4 comments

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/2653

Created by ossmon on 2012-05-31 12:51:43 +00:00

Assignee: (none)
Status: Rejected (closed on 2013-04-11 08:13:19 +00:00)
Target Version: (none)
Last Update: 2013-04-11 08:13:19 +00:00 (in Redmine)


With the patch of the core #2650 for V1.8, the long plugin output for hosts/services will be store correctly in the table icinga_statehistory.
We need now a possibility to see this data in icinga-web when we click on a host/service history link.
Idea:

  • a new column, but it could be large
  • a special infobox icon on each line as by the hosts/services which will contains at least the output and the long output. In other words a reduce version of the info box of the cronk HostStatus/ServiceStatus.

For us is an implementation for services very interessant. For hosts not so more, but i think the code should be similar.

Changesets

2014-06-20 11:41:10 +00:00 by mhein 14fdf63

LongPluginOutput: Fix missing support of multi line in html

refs #2653

2014-06-26 13:37:43 +00:00 by elippmann 97bf45e

Revert "LongPluginOutput: Fix missing support of multi line in html"

This reverts commit 14fdf6323dde83ba51d61d29f7ff3ee4b23614f4.

The fix actually fixes nothing for the following reasons:

1) The "Long plugin output" field of a host's or service's detail window already has `\n' replaced with the HTML break tag.
This is because the information is gathered via Icinga Web's API which calls `Api_Result_OutputRewriteModel::rewritePluginOutput()'
in the controller `ApiSearchAction'.
Note that the carriage return `\r' is not taken into accout, but that's not a problem here.

2) Grids do not benefit from `Api_Result_OutputRewriteModel::rewritePluginOutput()' as its not being called. The `nl2br()' should've
helped here. According to http://www.ietf.org/rfc/rfc4627.txt the JSON representation of strings must escape control characters which includes the line feed `\n'
and the carriage return `\r'. So '\n', '\r' and '\r\n' become '\\n', '\\r' and '\\r\\n' respectively making them a textual representation of the control characters.
The `nl2br()' implementation however only replaces the unescaped line feed and carriage return which does of course replace nothing in the above case.

3) Introducing `String::nl2br()' while ExtJS provides `Ext.util.Format.nl2br()' is superfluous.

refs #2653

2014-06-26 14:30:11 +00:00 by elippmann 232b5c0

Grid/columns: Replace new lines with the HTML break when `multiLine' is enabled

Example config:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<template match-pattern="icinga-(service-template|.+-service-problems)">
    <fields>
        <field name="plugin_long_output">
            <datasource>
                <parameter name="field">SERVICE_LONG_OUTPUT</parameter>
            </datasource>
            <display>
                <parameter name="visible">true</parameter>
                <parameter name="label">Long output</parameter>
                <parameter name="jsFunc">
                    <parameter>
                        <parameter name="namespace">Cronk.grid.ColumnRenderer</parameter>
                        <parameter name="function">customColumnPerfdataSanitized</parameter>
                        <parameter name="arguments">
                            <parameter name="multiLine">1</parameter>
                        </parameter>
                    </parameter>
                </parameter>
            </display>
            <filter>
                <parameter name="enabled">false</parameter>
            </filter>
            <order>
                <parameter name="enabled">false</parameter>
                <parameter name="default">false</parameter>
            </order>
        </field>
    </fields>
</template>

refs #2653

Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-06 21:51:26 +00:00

how about a patch? the code is already on the core git, so you can play around with the backend.

@icinga-migration
Copy link
Author

Updated by ossmon on 2012-09-07 07:32:12 +00:00

Hi dnsmichi, what do you mean with a Patch? That i write someone. I don't have enough Knowledge to Write a Patch for icinga-Web. I would like but i cannot at the moment.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-11-21 14:23:50 +00:00

  • Status changed from New to Feedback

question arises - does icinga web actually read the statehistory table for that grid view, or would that add another join overhead to the data backend query?

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-04-11 08:13:19 +00:00

  • Status changed from Feedback to Rejected

With 1.9 we will add the proper field for the API queries.

Only a few users would need such a field in the Grid itself, so we want add it as a grid col per default.

I personally only have one customer I know, and he uses it only for a clipboard action. (no display)

The column itself can be added easily to the grid itself via an extension.

If one wants to do it:
See here how the PNP Extension "extends" a grid:
https://git.icinga.org/?p=icinga-web.git;a=blob;f=contrib/PNP\_Integration/templateExtensions/pnp-service-extension.xml;hb=HEAD

But only use the fields part to add a snippet like this:

                HOST_LONG_OUTPUT
            

            
                true
                Long output

                
                    
                        Cronk.grid.ColumnRenderer
                        customColumnPerfdataSanatized
                    
                

            

            
                false
            

            
                false
                false

Feel free to document it in the Wiki ;-)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant