Update text formatting for trap OIDs#911
Open
WinstonLobo wants to merge 1 commit intoCheckmk:masterfrom
Open
Conversation
ec: split SNMP trap varbinds across visual lines in event message Trap events created from incoming SNMP traps concatenate all OID/value pairs into a single long line, which makes the Event Console message column hard to read when a trap carries many varbinds (typical for hardware traps from Dell iDRAC, HP iLO, Microsoft, VMware, etc.). Use the existing "\x01" line-break marker convention instead of ", " as the separator between varbinds. The GUI painter for the event_text column already converts "\x01" into "<br>" at render time (see cmk/gui/mkeventd/views.py), so this produces a visual line break per varbind in the Event Console without changing the on-disk format in any incompatible way. scrub_string() is applied per varbind rather than to the joined string, because it strips "\x01" (along with other control characters) to keep the line-oriented history files safe. Applying it before the join preserves the separator while still sanitising each individual OID/value pair. Note for rule authors: rules matching the previous ", " separator in trap message text need to be updated, as varbinds are now separated by "\x01" internally.
|
I have read the CLA Document and I hereby sign the CLA or my organization already has a signed CLA. You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ec: split SNMP trap varbinds across visual lines in event message
Trap events created from incoming SNMP traps concatenate all OID/value pairs into a single long line, which makes the Event Console message column hard to read when a trap carries many varbinds (typical for hardware traps from Dell iDRAC, HP iLO, Microsoft, VMware, etc.).
Use the existing "\x01" line-break marker convention instead of ", " as the separator between varbinds. The GUI painter for the event_text column already converts "\x01" into "
" at render time (see cmk/gui/mkeventd/views.py), so this produces a visual line break per varbind in the Event Console without changing the on-disk format in any incompatible way.
scrub_string() is applied per varbind rather than to the joined string, because it strips "\x01" (along with other control characters) to keep the line-oriented history files safe. Applying it before the join preserves the separator while still sanitising each individual OID/value pair.
Note for rule authors: rules matching the previous ", " separator in trap message text need to be updated, as varbinds are now separated by "\x01" internally.
Thank you for your interest in contributing to Checkmk!
Consider looking into Readme regarding process details.
General information
Please give a brief summary of the affected device, software or appliance.
Keep in mind that we are experts in monitoring, but we cannot be experts on all supported devices.
A little context will help us assess your proposed change.
Bug reports
Please include:
Proposed changes
Sometimes it is hard for us to assess the quality of a fix.
While it may work for you, it is our job to ensure that it works for everybody.
These are some ways to help us: