1. 23
  1.  

  2. 2

    The tag show means this was developed by you? If yes, thanks. Very cool idea! I will try it out. One of the major problems of Cloudwatch Logs in my opinion is its bad UI. I don’t expect much from logs, but Cloudwatch even fails to fulfill my few expectations (search, scroll, and live follow). I was perfectly happy with journalctl when we still had only a few servers.

    In Cloudwatch I can do “Search all”, enter my search term, narrow down the time span, and then wait for annoying seconds or even minutes. And then it only shows me the log lines that match the search. To see the context, I have to click on the instance ID and open that in a new tab. Or perform another search with the correct correlation ID.

    And exporting to S3 with the Cloudwatch UI is also quite annoying. I once looked into creating export jobs with the command line interface (to automate it once per day), but also that seemed to be more work than 5 minutes of programming.

    So even if the virtual filesystem is slow (which I expect, because is has to call the same APIs that the Cloudwatch UI probably uses), I hope that it can make my debugging sessions a whole lot more fun. In the worst case I can execute cat some-log-files > my-cached-log to fetch all logs from the relevant time span and then happily grep my way through the cached log. Yay!

    1. 5

      Disclaimer: I work for AWS, and my opinions are my own and not my employer’s.

      I think CloudWatch Logs (CWL) is an awesome service. One of the services I maintain at work outputs 5 MiB/s of logs in a large region that I can slowly but effortlessly search over. There is an internal-only predecessor to CWL that is sometimes so slow that internal teams rule out being able to search over logs in large regions. With CWL there is no such concern. In some regions I happily see CWL stating its search throughput as multiple GiB/s.

      cwl-mount is partially a need for me to be able to grep --context over logs. I also used it as an opportunity to experiment with FUSE and asynchronous Rust. I’m pleased with the proof-of-concept stage of cwl-mount and can use it both for side-projects and at work.

      One of the major problems of Cloudwatch Logs in my opinion is its bad UI. I don’t expect much from logs, but Cloudwatch even fails to fulfill my few expectations (search, scroll, and live follow). I was perfectly happy with journalctl when we still had only a few servers.

      I agree that sometimes a command-line interface is preferable to a graphical user interface, and that logs is one of those times. That being said, personally I find CWL’s UI OK. If you would like to leave feedback for the CWL team I can connect you with someone internally.

      In Cloudwatch I can do “Search all”, enter my search term, narrow down the time span, and then wait for annoying seconds or even minutes. And then it only shows me the log lines that match the search. To see the context, I have to click on the instance ID and open that in a new tab. Or perform another search with the correct correlation ID.

      Yes, this is precisely the (narrow) use-case that cwl-mount fills. Sometimes I know very precisely where to expect logs but I also need context.

      And exporting to S3 with the Cloudwatch UI is also quite annoying. I once looked into creating export jobs with the command line interface (to automate it once per day), but also that seemed to be more work than 5 minutes of programming.

      Yes, especially with S3 bucket permissions this is not a quick feature to set up, and I agree this would take more than 5 minutes to set up. Again this is a gap that cwl-mount fills. That being said, for some customers they value cost efficiency and are willing to set up something to call CreateExportTask to S3 so that they can e.g. ingest it somewhere else, post-process it, etc. That is not my use-case.

      So even if the virtual filesystem is slow (which I expect, because is has to call the same APIs that the Cloudwatch UI probably uses), I hope that it can make my debugging sessions a whole lot more fun. In the worst case I can execute cat some-log-files > my-cached-log to fetch all logs from the relevant time span and then happily grep my way through the cached log.

      cwl-mount is slow mostly because FilterLogEvents has a maximum quota of 5 transactions per second per account per region and this limit cannot be changed. In practice, you can burst above this limit and CWL will honor it for a while. However, cwl-mount for now is cautious and sticks to 5 TPS. I’ll make it configurable soon.

      Please let me know, or cut GitHub issues, for any comments or feedback that you have about cwl-mount. Thank you!