A company has centralized all its logs into one Amazon CloudWatch Logs log group. The SysOps Administrator is to alert different teams of any issues relevant to them. What is the MOST efficient approach to accomplish this?
A.
Write an AWS Lambda function that will query the logs every minute and contain the logic of which team to notify on which patterns and issues.
B.
Set up different metric filters for each team based on patterns and alerts. Each alarm will notify the appropriate notification list.
C.
Redesign the aggregation of logs so that each team's relevant parts are sent to a separate log group, then subscribe each team to its respective log group.
D.
Create an AWS Auto Scaling group of Amazon EC2 instances that will scale based on the amount of ingested log entries. This group will pull log streams, look for patterns, and send notifications to relevant teams.
I would go with B. A is gonna be very expensive solution, and the question asking for MOST efficient solution, C and D too are no that cheap solutions.
Still think is A though: Customers can subscribe to real-time CloudWatch Logs event feeds which they can either process themselves with Amazon Kinesis and AWS Lambda, or deliver directly to Amazon ES using an AWS-provided Lambda function that connects CloudWatch Logs to Amazon ES (see Real-time Processing of Log Data with Subscriptions in the Amazon CloudWatch Logs User Guide).
I agree, B seems to be the MOST efficient solution. I have used this feature, to capture all the CloudTrail events and filter out only relevant ones to trigger a lambda function for further processing.
By setting up different metric filters for each team based on relevant patterns and alerts, you can customize the notifications sent to each team when specific log events occur. This approach allows for fine-grained control over which team receives alerts for specific issues.
Correct answer is B. The key requirement here is alerting different team. C is not completed solution, each team must use their owned filter.
https://aws.amazon.com/blogs/mt/using-amazon-cloudwatch-metric-filters-and-alarms-to-monitor-logs-on-sonicwall-firewall/
B
C is wrong because , Subscription for log group is only for lambda , Kinesis and elasticsearch ..
but using filters enable us from creating alarm for which target can send SNS to admins
B. Set up different metric filters for each team based on patterns and alerts. Each alarm will notify the appropriate notification list.
Seems right for me
Read everyone's comments...The SysOps Administrator is to alert different teams of any issues relevant to them. = What is the MOST efficient approach to accomplish this? Not what is the most way to decentralize logs and then alert different teams (like C would suggest). With B, setting up different metric filters is a centralized way of lowering cost because you are controlling the alarm condition (albeit micromanaging). This is the most efficient approach to alerting different teams with your centralized approach (which is not part of the last question).
With C you'd have to not only 'redesign' aggregation of logs etc, but then you'd have to subscribe each team to it's respective log group. The first sentence in this problem is not part of the desired solution. Answer B
I do not believe that A is the MOST effiecient, that leaves us with B and C.
These 2 answers seem to be correct however i am leaning more towards C based on reading some of the links that others posted.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
white_shadow
Highly Voted 2 years, 7 months agoawsnoob
2 years, 7 months agosmplysam
2 years, 7 months agoAWS_Noob
Highly Voted 2 years, 7 months agoalbert_kuo
Most Recent 9 months, 3 weeks agogulu73
1 year, 2 months agoszl0144
2 years, 3 months agoHuy
2 years, 5 months agomisako
2 years, 6 months agoDrey
2 years, 6 months agoDrey
2 years, 6 months agoKimle
2 years, 6 months agosasquatchshrimp
2 years, 6 months agoabhishek_m_86
2 years, 6 months agojerry19
2 years, 6 months agokenkct
2 years, 6 months agojackdryan
2 years, 6 months agoMFDOOM
2 years, 6 months agogilbertlelancelo
2 years, 6 months agogilbertlelancelo
2 years, 6 months ago