good or bad html "tags" not showing in web page "msgs" report 🔗 link

On Fri, March 13, 2015 4:11 pm, Shawn Heisey wrote:

I have a log entry that looks like this:

[2015-03-02 13:32:43.011110] E
[dht-linkfile.c:213:dht_linkfile_setattr_cbk] 0-mdfs-dht: setattr of
uid/gid on /newscom/mdfs/ZUMA/zumaamericaseight/docs/364/090
:<gfid:00000000-0000-0000-0000-000000000000> failed (Invalid argument)


This is in the gluster NFS log.  I wanted to stop getting alarms on this
log entry, so I looked at what I get when I click on the red icon under
"msgs" in my browser ... only that shows up like this (not exactly the
same log entry, but the format is the same):

.2015-03-13 22:48:18.447034] E
[dht-linkfile.c:213:dht_linkfile_setattr_cbk] 0-mdfs-dht: setattr of
uid/gid on /newscom/mdfs/IS/isphotos/docs/056/515 : failed (Invalid
argument)

The problem is that the browser interpreted the part starting with
"<gfid:" and ending with ">" as an HTML tag, so it didn't display it.  I
did not realize this was happening, so I built an "ignore" line for
client-local.cfg that did not include that part, and I was really
scratching my head as to why my ignore did not work.

Would it be possible to automatically convert characters in log entries
that are special to HTML into their HTML equivalents for display in a
browser?  In this case, < would become &lt; ... > would be %gt; ... and
so on.

Thanks,
Shawn

wrote:

On Fri, March 13, 2015 4:11 pm, Shawn Heisey wrote:

I have a log entry that looks like this:

[2015-03-02 13:32:43.011110] E
[dht-linkfile.c:213:dht_linkfile_setattr_cbk] 0-mdfs-dht: setattr of
uid/gid on /newscom/mdfs/ZUMA/zumaamericaseight/docs/364/090
:<gfid:00000000-0000-0000-0000-000000000000> failed (Invalid argument)


This is in the gluster NFS log.  I wanted to stop getting alarms on this
log entry, so I looked at what I get when I click on the red icon under
"msgs" in my browser ... only that shows up like this (not exactly the
same log entry, but the format is the same):

.2015-03-13 22:48:18.447034] E
[dht-linkfile.c:213:dht_linkfile_setattr_cbk] 0-mdfs-dht: setattr of
uid/gid on /newscom/mdfs/IS/isphotos/docs/056/515 : failed (Invalid
argument)

The problem is that the browser interpreted the part starting with
"<gfid:" and ending with ">" as an HTML tag, so it didn't display it.  I
did not realize this was happening, so I built an "ignore" line for
client-local.cfg that did not include that part, and I was really
scratching my head as to why my ignore did not work.

Would it be possible to automatically convert characters in log entries
that are special to HTML into their HTML equivalents for display in a
browser?  In this case, < would become &lt; ... > would be %gt; ... and
so on.

Thanks,
Shawn

Shawn,

It would require a code change, however this would be possible.
Unfortunately, it would also prevent people from adding their own useable
HTML links into the content (which is either a feature or a bug, I
suppose)

That may specifically be a useful tradeoff in the case of log files,
however.


Regards,

-jc

On 3/13/2015 8:34 PM, Ralph Mitchell wrote:

What if the standard entry was extended:

    log:/var/log/messages:10240
    log:/var/log/file-with-html:10240:html

That would allow any log file to be designated for url-encoding before
being uploaded to Xymon, without breaking existing configurations.

Or did I miss the point of the original question?

On Fri, March 13, 2015 11:27 pm, Shawn Heisey wrote:

On 3/13/2015 8:34 PM, Ralph Mitchell wrote:

What if the standard entry was extended:

    log:/var/log/messages:10240
    log:/var/log/file-with-html:10240:html

That would allow any log file to be designated for url-encoding before
being uploaded to Xymon, without breaking existing configurations.

Or did I miss the point of the original question?

That would be perfect, for the main reason you mentioned:  Existing
configs will see no difference.  The :html config could be included in
sample configs and in documentation ... new users will not be troubled
by the problem I've encountered, and an exiting user can convert their
config if they need that feature.

Tangent question: Is the color status icon for logfile entries generated
by the server, or the client with "&red" or similar text?  If it is
generated by the server, then I don't think logfile HTML conversion
would need to worry about things like &red.

On 3/14/2015 5:35 PM, J.C. Cleaver wrote:

That would help, however it would also cause items that had gotten
URL-encoded to potentially be missed in analysis.d LOG regex's (which
don't URL-unencode).

Given that this is a display issue more than anything else, it might be
better handled as we're creating the status message from xymond_client.
This leaves the raw log message still available, while still protecting
the display from getting interpreted this way.

On Sat, March 14, 2015 5:55 pm, Shawn Heisey wrote:

On 3/14/2015 5:35 PM, J.C. Cleaver wrote:

That would help, however it would also cause items that had gotten
URL-encoded to potentially be missed in analysis.d LOG regex's (which
don't URL-unencode).

Given that this is a display issue more than anything else, it might be
better handled as we're creating the status message from xymond_client.
This leaves the raw log message still available, while still protecting
the display from getting interpreted this way.

Yes, this should definitely be a display-only conversion.  The logs
should be unchanged from what the client sends when they are being
analyzed for potential alarms.

That is a perfect segue into another problem I noticed.  The first
character on all my log lines for this logfile is [, a left square
bracket.  That is being replaced with a . (period) character.  In the
email alarm, every line starts like this:

&red .2015-03-13 23:16:43.386125]