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

EnvoyProxy Integration #9383

Closed
SubhrataK opened this issue Mar 19, 2024 · 7 comments · Fixed by #11215
Closed

EnvoyProxy Integration #9383

SubhrataK opened this issue Mar 19, 2024 · 7 comments · Fixed by #11215
Assignees
Labels
New Integration Issue or pull request for creating a new integration package.

Comments

@SubhrataK
Copy link

This issue is to migrate the EnvoyProxy module from beats to agent-based integration.

@SubhrataK SubhrataK self-assigned this Mar 19, 2024
@tehbooom
Copy link
Member

Started development of this integration. For metrics will be following a similar model as the Airflow package.

PR to follow.

@tehbooom tehbooom mentioned this issue Apr 30, 2024
4 tasks
@tehbooom
Copy link
Member

Metrics currently a blocker per

elastic/beats#39473

@ritalwar
Copy link
Contributor

Just a quick question: I see we already have an EnvoyProxy Beats module, and we just want to create an agent-based integration for it. Why are we planning to use StatsD instead of using the existing EnvoyProxy Beats module for creating this integration?

@tehbooom
Copy link
Member

@ritalwar The way our module was collecting the logs was simply doing a request to /stats with maybe 20 or so fields.

Envoy does support Statsd and states it's typically how the metrics are collected.

I did try to use the metric beat module but I noticed I was missing a lot of fields and they were in "Statsd format". So I thought it might be best to simply redo the metrics using Statsd or recreate the module using CEL input.

I think Statsd is the way to forward here as it's what envoy is supporting and other applications are using Statsd as an input like DataDog.

@ritalwar
Copy link
Contributor

If statsd seems like the best way forward based on your analysis, let's go with that, although we can update this schema to include more/missing fields if necessary.

@tehbooom
Copy link
Member

I agree that we could update that schema however some of the fields are already histograms like in statsd. I think that would be more work in the long run to basically recreate our statsd module to parse out "statsd like" fields.

@ritalwar
Copy link
Contributor

ritalwar commented May 16, 2024

I think that would be more work in the long run to basically recreate our statsd module to parse out "statsd like" fields.

Agree! let's modify the existing one(statsd) for this integration unless there's a better solution suggested.

@andrewkroh andrewkroh added the New Integration Issue or pull request for creating a new integration package. label Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New Integration Issue or pull request for creating a new integration package.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants