Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] type [ip] not supported, cannot convert field #6646

Closed
sbillo opened this issue Mar 13, 2023 · 5 comments
Closed

[BUG] type [ip] not supported, cannot convert field #6646

sbillo opened this issue Mar 13, 2023 · 5 comments
Assignees
Labels
bug Something isn't working distributed framework

Comments

@sbillo
Copy link

sbillo commented Mar 13, 2023

Describe the bug
Hi, I need to create an Ingest Pipeline where the input data is in this format: “winlog.event_data.DestinationIp”, using the processor convert I should get the format: “destination ip” whose type is: “type”: “ip”, but I get the error: “type [ip] not supported, cannot convert field”, although consulting the Opensearch documentation, the “type”:“ip” is an expected field.

To Reproduce
Place this convert in json pipeline to send to opensearch:

“convert”: {
“field”: “winlog.event_data.DestinationIp”,
“ignore_failure”: true,
“ignore_missing”: true,
“target_field”: “destination.ip”,
“type”: “ip”
}

The error is:

“type”: “parse_exception”,
“reason”: “[type] type [ip] not supported, cannot convert field.”,
“processor_type”: “convert”,
“property_name”: “type”
…

NOTE: if use “string” instead of “ip”, all works fine. But i need “ip” 🥲

@sbillo sbillo added bug Something isn't working untriaged labels Mar 13, 2023
@msfroh
Copy link
Collaborator

msfroh commented Mar 21, 2023

@sbillo, could you please clarify the high-level behavior you're observing and the desired behavior?

My understanding is that the ip field type accepts string values, and indexes them as IP addresses. So, with the string converter, I believe that valid IP addresses should get indexed correctly, if the field mapping specifies that the field has the ip type.

Is your goal to use the convert processor as a way to only do the conversion if the value is a valid IP address? (I'm assuming that's the case, given the "ignore_failure" : true part.) If that's the case, it's a gap in the convert processor that we should fix.

Thanks!

@msfroh msfroh self-assigned this Mar 21, 2023
@mingshl
Copy link
Contributor

mingshl commented Apr 3, 2023

@sbillo, trying to follow up with the question above?

@sbillo
Copy link
Author

sbillo commented Apr 4, 2023

Hi msfroh, sorry for the delay in replying.
I confirm that the problem is converting the value into IP address, through the "processor".
Even passing the directive: "ignore_failure" : true, it returns the error: type [ip] not supported.
If I pass the value to the processor and ask for an output string, there are no problems, but I need the parsed field as a real "IP"

@msfroh
Copy link
Collaborator

msfroh commented Apr 4, 2023

@sbillo What is the field type in your mapping? Did you define a mapping for your index up front or is the goal here to auto-create the field with type IP?

If you pass a string value to a field defined with type IP in the mapping, it should get parsed as an IP value, since that behavior should come from the field type, not the processor. In that case, I don't think a convert processor with type IP would actually do any converting, but rather it could validate that the given input is a valid IP before copying it over to the target field. Functionally, it would behave like the string processor, but with validation.

Sorry for all the questions -- I just want to make sure that we fix this the right way!

@msfroh
Copy link
Collaborator

msfroh commented Aug 30, 2023

Assuming converting to string works.

@sbillo, please feel free to reopen if you still need something to be able to convert to an ip field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working distributed framework
Projects
Status: Done
Development

No branches or pull requests

5 participants