- 最新
- 投票最多
- 评论最多
Even with. this limited amount of information, there may be more than one way to skin this particular cat.
One approach (1) is to feed the cloudwatch logs to a Lambda function, Kinesis Data Streams or Firehose through a log group-level subscription filter, let it go through every log message to find the aforementioned JSON response, canonicalize and compare against a last-saved version and determine if it has changed to trigger a notification. On first sight this feels rather expensive in terms of effort and resource utilization.
Assuming that the external service is HTTP or network-based, another approach (2) would be to insert a proxy between the external service and your consumer, and perform the change-detection logic locally. And here we're talking about both an HTTP proxy and the actual proxy microservice design pattern, mind you. This component doesn't need to perform any transformations in the content, just to parrot a request, wait for the response and forward it blindly, and then canonicalize it, compare and trigger the notification when applicable. We're talking about a few lines of python, nodejs or perl in a Lambda. Depending on the level of control you have on the consumer, you may just (a) change the address for that single endpoint, (b) define an HTTP_PROXY environment variable or (c) install an iptables transparent proxy (like squid and mitmproxy do). Please note that (2.a) and (2.b) are a one-afternoon project, but (2.c) might be less cost-effective than approach 1, and it's fair to say that in any case you are adding a moving part that depending on the circumstances can become another possible point of failure.
相关内容
- AWS 官方已更新 2 年前
Thanks Javier for the few approaches which have triggered some other ideas.