good or bad html "tags" not showing in web page "msgs" report
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 < ... > would be %gt; ... and so on.
Thanks, Shawn
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 < ... > 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
What if the standard entry was extended:
log:/var/log/messages:10240
log:/var/log/file-with-html:10240:htmlThat 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 <cleaver at terabithia.org> 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 < ... > 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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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:htmlThat 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.
Thanks, Shawn
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:htmlThat 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.
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.
Regarding your other question, the '&red/yellow/green' interpretation is done by the CGI displaying the status, but is generated after the message comes in (by xymond_client), so there wouldn't be an issue there.
Regards,
-jc
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]
As expected, on the web page, the red indicator icon replaces &red.
Thanks, Shawn
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]
This, unfortunately, is not a display issue but a necessity to prevent corrupted messages.
The "client" message uses [bracketed] sections as delimiters, so logfetch does this intentionally to prevent initial lines with brackets from confusing downstream parsers.
Regards,
-jc
participants (3)
-
cleaver＠terabithia.org
-
hobbit＠elyograg.org
-
ralphmitchell＠gmail.com