Hi,
recently I came up into elasticsearch parsing exception. Dump is attached below.
It only happens when it processes data from Blueliv Crimeserver and Shadowserver-Open-XDMCP collectors.
Not so far ago my elasticsearch output bot didn't throw that exception.
Currently I'm using intelmq 1.0.2 and intelmq-manager 0.3.1, all installed from .deb package and python client elasticsearch 6.0.0.
Anyone experienced the same?
Thanks for the efforts.
Regards,
Could it be that ES does not have a definition for extra.status (which gets translated to extra_status)?
On 02 Jan 2018, at 20:52, Tomislav Protega tomislav.protega@cert.hr wrote:
Hi,
recently I came up into elasticsearch parsing exception. Dump is attached below.
It only happens when it processes data from Blueliv Crimeserver and Shadowserver-Open-XDMCP collectors.
Not so far ago my elasticsearch output bot didn't throw that exception.
Currently I'm using intelmq 1.0.2 and intelmq-manager 0.3.1, all installed from .deb package and python client elasticsearch 6.0.0.
Anyone experienced the same?
Thanks for the efforts.
Regards,
-- Tomislav <elasticsearch_exception.txt>-- Listen-Einstellungen: https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-users
-- // L. Aaron Kaplan kaplan@cert.at - T: +43 1 5056416 78 // CERT Austria - https://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg
ES probably has mapped extra.status to an object and in the given case, extra.status is text. Please see the existing mappings for extra_status.
On Wed, Jan 3, 2018 at 1:44 AM, kaplan@cert.at kaplan@cert.at wrote:
Could it be that ES does not have a definition for extra.status (which gets translated to extra_status)?
On 02 Jan 2018, at 20:52, Tomislav Protega tomislav.protega@cert.hr
wrote:
Hi,
recently I came up into elasticsearch parsing exception. Dump is attached below.
It only happens when it processes data from Blueliv Crimeserver and Shadowserver-Open-XDMCP collectors.
Not so far ago my elasticsearch output bot didn't throw that exception.
Currently I'm using intelmq 1.0.2 and intelmq-manager 0.3.1, all installed from .deb package and python client elasticsearch 6.0.0.
Anyone experienced the same?
Thanks for the efforts.
Regards,
-- Tomislav <elasticsearch_exception.txt>-- Listen-Einstellungen: https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-users
-- // L. Aaron Kaplan kaplan@cert.at - T: +43 1 5056416 78 // CERT Austria - https://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
issue is solved. Under "flatten_fields" of ES bot parameter, next to the default "extra", I added "status" and now there's no exception.
flatten_fields: extra,status
Regards,
- -- Tomislav
On 03.01.2018 07:23, Navtej Singh wrote:
ES probably has mapped extra.status to an object and in the given case, extra.status is text. Please see the existing mappings for extra_status.
On Wed, Jan 3, 2018 at 1:44 AM, kaplan@cert.at kaplan@cert.at wrote:
Could it be that ES does not have a definition for extra.status (which gets translated to extra_status)?
On 02 Jan 2018, at 20:52, Tomislav Protega tomislav.protega@cert.hr
wrote:
Hi,
recently I came up into elasticsearch parsing exception. Dump is attached below.
It only happens when it processes data from Blueliv Crimeserver and Shadowserver-Open-XDMCP collectors.
Not so far ago my elasticsearch output bot didn't throw that exception.
Currently I'm using intelmq 1.0.2 and intelmq-manager 0.3.1, all installed from .deb package and python client elasticsearch 6.0.0.
Anyone experienced the same?
Thanks for the efforts.
Regards,
-- Tomislav <elasticsearch_exception.txt>-- Listen-Einstellungen: https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-users
-- // L. Aaron Kaplan kaplan@cert.at - T: +43 1 5056416 78 // CERT Austria - https://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg