Hello @YegorKovylyayev . I don't think there should be any reason why the messages should be ignored, unless the account related to the access_key and secret does not have access to read the logs.
It might be other debug logs that could be useful compared to only the 4 lines added to the post, would you mind deleting/moving the existing logfile, starting it up again, and let it run for a few minutes and share the output?
Hi @YegorKovylyayev thanks for the log! Looks like Filebeat is able to see the SQS message but not able to see which S3 bucket/log it is pointing to. Do you have the SQS-S3 setup so when a new log entry gets into S3, a SQS message will be created?
If the SQS-S3 setup is good, then is it possible to send us the actual SQS message content?
Also what version of Filebeat are you running? If you could upgrade to the latest version, it will show more debug level message I believe. Thanks!
Hmm this is odd! Thank you for the SQS message sample! Filebeat should be able to collect the s3 info from this. Could you upgrade to 7.11.0 filebeat and get some debug level logs please? I tested locally with your SQS message and it was fine to determine what's the S3 info from the message. Thanks!!
upgraded and here is full debug log after: Logs after upgrade
maybe I doing something wrong during configuration steps ? here is how I setup AWS part s3 sqs sns setup
thank you for your help
Ahh thanks for sharing the steps you did to setup s3-sqs. I think problem might be there. We are not using SNS at all. Connection should be between S3 and SQS directly. Getting AWS logs from S3 using Filebeat and the Elastic Stack | Elastic Blog shows step by step how to setup. Hopefully this will help!!
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.