However, this negatively impacts the customer experience by adding ERROR lines to their server.log with a scary-looking stack dump, and if customer is attempting to set up the Cloudtrail input, will be mindful of log lines that we specify to be ERROR.
A more ideal situation would be to parse the message type, and present something like "Cloudtrail validation message encountered, skipping processing for unnecessary message." at reduced log priority than ERROR.
While setting up the Cloudtrail input, customer noted the following ERROR in their server.log:
2022-10-27T13:27:38.655-04:00 ERROR [CloudtrailSNSNotificationParser] Parsing exception. com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'CloudTrail': was expecting ('true', 'false' or 'null') at [Source: (String)"CloudTrail validation message."; line: 1, column: 11] at com.fasterxml.jackson.core.JsonParser._constructError([JsonParser.java:1804](http://jsonparser.java:1804/)) ~[graylog.jar:?]
Per https://github.com/Graylog2/graylog-plugin-aws/issues/80 the Cloudtrail input will skip processing/continue executing past messages it does not understand, and per https://github.com/Graylog2/graylog-plugin-aws/issues/249 we acknowledge that this is an unnecessary message.
However, this negatively impacts the customer experience by adding ERROR lines to their server.log with a scary-looking stack dump, and if customer is attempting to set up the Cloudtrail input, will be mindful of log lines that we specify to be ERROR.
A more ideal situation would be to parse the message type, and present something like "Cloudtrail validation message encountered, skipping processing for unnecessary message." at reduced log priority than ERROR.
HS-1155337333