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

[AWS] AWS Health metricbeat module #38370

Merged
merged 77 commits into from
Apr 16, 2024
Merged

Conversation

agithomas
Copy link
Contributor

@agithomas agithomas commented Mar 18, 2024

Proposed commit message

AWS Health assists in effectively managing ongoing events by offering continuous insight into the performance of your resources and the availability of your AWS services and accounts. By leveraging AWS Health events, users obtain valuable insights into how service and resource modifications may impact their applications hosted on AWS.

The AWS Health integration with Elastic will retrieve the following information:

  • DescribeEvents operation
  • DescribeEventDetails operation
  • DescribeAffectedEntities operation

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

  • [ ]

How to test this PR locally

  • Integration testing

Related issues

elastic/integrations#8907

Use cases

Screenshots

Logs

agithomas and others added 30 commits May 18, 2022 11:10
…lastic#31628)

This prevents "monitored" from being written into event.outcome which
does not allow this value according to ECS.
successSet := eventDetails.SuccessfulSet
for x := range successSet {
for y := range healthDetailsTemp {
if awssdk.ToString(successSet[x].Event.Arn) == healthDetailsTemp[y].EventArn {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't have to do this now, but perhaps for a future refactor, i wonder if it's simpler to maintain a map of ARNs to metric events, instead of having these comparisons in multiple places.

Copy link
Collaborator

@kush-elastic kush-elastic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Contributor

@zmoog zmoog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

I have only one question. This metricset has a collection period of 24 hours: does it collect the same events again if Filebeat/Agent restarts the metricset beforehand?

@tommyers-elastic
Copy link
Contributor

I have only one question. This metricset has a collection period of 24 hours: does it collect the same events again if Filebeat/Agent restarts the metricset beforehand?

could this be the reason for the ID generation code that encoded the date in the ID?

@agithomas
Copy link
Contributor Author

I have only one question. This metricset has a collection period of 24 hours: does it collect the same events again if Filebeat/Agent restarts the metricset beforehand?

Yes, the same events will be retrieved. 24h is the recommended frequency of run because the scheduled updates may happen at some time during the day .

image

However, if the user chooses to receive frequent updates on the affected resources under an Event, he may choose a smaller frequency.

@agithomas
Copy link
Contributor Author

could this be the reason for the ID generation code that encoded the date in the ID?

In the latest code, ID is auto-generated.

@agithomas
Copy link
Contributor Author

/test

@tommyers-elastic
Copy link
Contributor

In the latest code, ID is auto-generated.

in the old code where the ID was being generated by hand, it included a date. could the sub-24hr duplication be the reason why?

@agithomas
Copy link
Contributor Author

in the old code where the ID was being generated by hand, it included a date. could the sub-24hr duplication be the reason why?

I think it is.

I took reference of AWS billing to include the ID. For AWS billing, the bill amount for the specific day remains the same. Also, having duplicate values have a significant effect. Also, the timestamp is always 00:00:00.

In the case of AWS health, the status of affected entities might vary across a day. The last() value represents the most recent status of all scheduled events.

@agithomas
Copy link
Contributor Author

@elastic/elastic-agent-data-plane team,

Requesting code owner approval for this PR.

@pierrehilbert pierrehilbert added the Team:Elastic-Agent Label for the Agent team label Apr 16, 2024
Copy link
Contributor

@faec faec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving for data plane

@agithomas agithomas merged commit c2a2b6b into elastic:main Apr 16, 2024
163 of 171 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Team:Elastic-Agent Label for the Agent team Team:Integrations Label for the Integrations team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants