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

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?

Ralph Mitchell


On Fri, Mar 13, 2015 at 10:10 PM, J.C. Cleaver <user-87556346d4af@xymon.invalid>
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