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] Add number_of_workers and latency to all CloudWatch Logs based integrations #5794

Merged
merged 4 commits into from
Apr 12, 2023

Conversation

zmoog
Copy link
Contributor

@zmoog zmoog commented Apr 5, 2023

Motivation

Number of workers

When users set up the integration to collect logs from a single log group, the default value (1) for number_of_workers is adequate to fetch the log events at each iteration.

However, when users utilize log_group_name_prefix to collect log events from multiple log groups, according to elastic/beats#29695, the number_of_workers should be increased to reach the number of log groups matching the prefix.

Latency

The latency can be required on the busiest log groups to deal with potential latency.

Conclusion

All the CloudWatch Logs-based integration should have these options available to them.

Change description

Updates the configuration template and integration variables to make these Filebeat configuration options available to the integration settings UI.

It also added a new "Advanced options" section under the "Setup" section to give more details about these options. I plan to add leverage this and other new sections to explain how the integration works.

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.

How to test this PR locally

I created four logs groups with plain text data:

  • test-mbranca-groucho
  • test-mbranca-gummo
  • test-mbranca-harpo
  • test-mbranca-zeppo

And I configured a CloudWatch Logs integration with the following settings:

  • Log Group Name Prefix: test-mbranca
  • Region: <REGION FOR THE LOG GROUPS>
  • All other settings have been left with their default value

The only existing worker will pick up one log group at a time during each iteration.

CleanShot 2023-04-12 at 19 23 59@2x

Each log group will process data every four iterations.

Then I changed the following settings:

  • Number of workers: 4 (previously was unset)

CleanShot 2023-04-12 at 19 28 27@2x

The four available workers will pick up one log group each during each iteration.

Related issues

@zmoog zmoog self-assigned this Apr 5, 2023
@zmoog zmoog added enhancement New feature or request Team:Cloud-Monitoring Label for the Cloud Monitoring team labels Apr 5, 2023
@zmoog zmoog changed the title [AWS] Add number_of_workers and latency to all CloudWatch Logs based integrations [AWS] Add number_of_workers and latency to all CloudWatch Logs based integrations Apr 5, 2023
@elasticmachine
Copy link

elasticmachine commented Apr 5, 2023

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2023-04-07T17:01:08.327+0000

  • Duration: 47 min 41 sec

Test stats 🧪

Test Results
Failed 0
Passed 190
Skipped 4
Total 194

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

@elasticmachine
Copy link

elasticmachine commented Apr 5, 2023

🌐 Coverage report

Name Metrics % (covered/total) Diff
Packages 100.0% (15/15) 💚
Files 93.75% (15/16) 👎 -3.073
Classes 93.75% (15/16) 👎 -3.073
Methods 85.921% (238/277) 👎 -6.198
Lines 85.925% (7387/8597) 👎 -5.349
Conditionals 100.0% (0/0) 💚

@zmoog zmoog marked this pull request as ready for review April 5, 2023 15:40
@zmoog zmoog requested a review from a team as a code owner April 5, 2023 15:40
@zmoog zmoog force-pushed the zmoog/add-number-of-workers-option-to-cloudwatch-input branch from 5881d11 to a7046f6 Compare April 6, 2023 14:35
zmoog added 4 commits April 7, 2023 18:58
All the CloudWatch Logs based integration should have these options
available to them.

The `number_of_workers` is essential to increase the workers when
users decide to use `log_group_name_prefix`.

The `latency` can be required on the busiest log groups to deal with
potential latency.
@zmoog zmoog force-pushed the zmoog/add-number-of-workers-option-to-cloudwatch-input branch from a7046f6 to e7de53c Compare April 7, 2023 17:00
@zmoog zmoog merged commit fe8795c into main Apr 12, 2023
@zmoog zmoog deleted the zmoog/add-number-of-workers-option-to-cloudwatch-input branch April 12, 2023 17:40
@elasticmachine
Copy link

Package aws - 1.33.3 containing this change is available at https://epr.elastic.co/search?package=aws

Copy link

@TheLastHarpCo TheLastHarpCo left a comment

Choose a reason for hiding this comment

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

I don't know what I am doing or who Harpo is

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Integration:aws_logs Custom AWS Logs Integration:aws AWS Team:Cloud-Monitoring Label for the Cloud Monitoring team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants