[receiver/elasticsearchreceiver] Add elasticsearch integration test

[Frapschen]

Description:
Add elasticsearch integration test.

[Frapschen]

#10165

[djaglowski]

Were you able to run this receiver locally against the container? (Is that how you generated the result?)

[Frapschen]

yes, I run this reveiver locally and get the result. I have checked the es container by call http://localhost:9200,its seem running well.

[djaglowski]

If it's working for you locally, then I suspect this is an issue with not using a "wait strategy" to verify that the application is ready. Without a wait strategy, the container may start, but the application within it may not be ready to respond by the time the scraper tries to query it.

Here's an example of a typical wait strategy.

Here's an example of a custom wait strategy.

[Frapschen]

thx ,I will have a try...

[djaglowski]

If it's working for you locally, then I suspect this is an issue with not using a "wait strategy" to verify that the application is ready. Without a wait strategy, the container may start, but the application within it may not be ready to respond by the time the scraper tries to query it.

Here's an example of a typical wait strategy.

Here's an example of a custom wait strategy.

[Frapschen]

I figure out what is going on, this line set cfg.Endpoint="localhost:9200", actullay, we need http://localhost:9200.

[Frapschen]

hi, after that problem, I scraped the data from es container, and the CompareMetrics() get two errors in it return

missing expected resource with attributes: map[elasticsearch.cluster.name:docker-cluster elasticsearch.node.name:917e13e55eed]

extra resource with attributes: map[elasticsearch.cluster.name:docker-cluster elasticsearch.node.name:db6ca60ce36f]

I think, its probably fine for the test. pls review :)

[Frapschen]

@djaglowski

[djaglowski]

@Frapschen A similar issue has prompted #10129.

For this immediate problem, I am ok with the fact that the resource attribute is unpredictable. However, the test will of course need to pass. One way to make this work immediately would be to override the attribute in either the expected or actual resource, or both.

[Frapschen]

One way to make this work immediately would be to override the attribute in either the expected or actual resource, or both.

@djaglowski I can override the expected resource, but I don't know that can achieve the test purpose, or we just write the actual resource and ignore the err?

[djaglowski]

@Frapschen, I think in this case it is ok to overwrite the randomly generated value of elasticsearch.node.name. We cannot predict this attribute value, but we can validate the rest of the result. This is a similar concept to how we ignore the metric values, since they are often not predictable in a live environment.

[Frapschen]

@djaglowski I override the elasticsearch.node.name with the expected one, none err occur.

[djaglowski]

@Frapschen, #10828 was just merged, which should provide you with a CompareOption to ignore the attribute value (rather than having to overwrite it). Will you please switch to using that?

[Frapschen]

@djaglowski used IgnoreResourceAttributeValue and get none error.

[djaglowski]

Thank you @Frapschen!

[djaglowski]

Looks like we need to figure out what's going on with this test on windows:

=== CONT  TestElasticsearchIntegration/Running_elasticsearch_7.9
    integration_test.go:91: 
        	Error Trace:	integration_test.go:91
        	            				integration_test.go:50
        	Error:      	Received unexpected error:
        	            	Error response from daemon: could not find plugin bridge in v1 plugin registry: plugin not found: failed to create container
        	Test:       	TestElasticsearchIntegration/Running_elasticsearch_7.9
--- FAIL: TestElasticsearchIntegration (0.00s)
    --- FAIL: TestElasticsearchIntegration/Running_elasticsearch_7.9 (15.12s)