lincheney / journald-2-cloudwatch Goto Github PK

View Code? Open in Web Editor NEW

4.0 5.0 8.0 66 KB

Send journald logs to AWS CloudWatch

Home Page: https://hub.docker.com/r/lincheney/journald-2-cloudwatch/

License: MIT License

Python 98.58% Dockerfile 1.42%

journald aws-cloudwatch docker

journald-2-cloudwatch's People

Contributors

Stargazers

Watchers

Forkers

ticosax lock8 rtlong goodguide jaladis blueyed pruthvireddypuresoftware odidev

journald-2-cloudwatch's Issues

Support InstanceIdentityDocument variables

See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html
These variables could be used in constructing group/stream names

Remove __CURSOR from messages sent to CloudWatch?

I think this helps with reducing the amount of data altogether.

Done in our fork: lock8@d4ce6c3

(it also has more types to be included)

Require images for ARM64

Hi Team,

I am trying to use this image on the arm64 platform, but it seems it does not have an arm64 supported tag available in the docker hub.

I have built the image successfully in travis-CI on both amd64 and arm64 platform but I am getting the below error while installing moto in Dockerfile.test:

Collecting cryptography>=3.3.1 (from moto)
  Could not find a version that satisfies the requirement cryptography>=3.3.1 (from moto) (from versions: 0.1, 0.2, 0.2.1, 0.2.2, 0.3, 0.4, 0.5, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.6, 0.6.1, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2, 0.9, 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 1.1.2, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.4, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.6, 1.7, 1.7.1, 1.7.2, 1.8, 1.8.1, 1.8.2, 1.9, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2, 2.2.1, 2.2.2, 2.3, 2.3.1, 2.4, 2.4.1, 2.4.2, 2.5, 2.6, 2.6.1, 2.7, 2.8, 2.9, 2.9.1, 2.9.2, 3.0, 3.1, 3.1.1, 3.2, 3.2.1)
No matching distribution found for cryptography>=3.3.1 (from moto)
The command '/bin/sh -c pip3 --no-cache-dir install moto coverage coveralls' returned a non-zero code: 1

Do you have any plans in releasing arm64 images?

If interested, I will add changes in Travis-CI and raise a PR for the same.

Error uploading logs spanning > 24 hours

Uploading a batch of logs spanning > 24 hours fails. This can occur if the server has been down for a few days.
The log uploader will need to be more intelligent and split up the batch appropriately.

Traceback:

Traceback (most recent call last):
File "/main.py", line 181, in <module>
client.log_messages(log_stream, list(messages))
File "/main.py", line 97, in log_messages
self._log_messages(log_stream, messages[i : (i+chunk)])
File "/main.py", line 106, in _log_messages
self.put_log_messages(log_stream, messages)
File "/main.py", line 91, in put_log_messages
**kwargs
File "/usr/local/lib/python3.4/dist-packages/botocore/client.py", line 228, in _api_call
return self._make_api_call(operation_name, kwargs)
File "/usr/local/lib/python3.4/dist-packages/botocore/client.py", line 492, in _make_api_call
raise ClientError(parsed_response, operation_name)
botocore.exceptions.ClientError: An error occurred (InvalidParameterException) when calling the PutLogEvents operation: The batch of log events in a single PutLogEvents req

Could you add a license, please? I'd like to use this on a private project, if you are open to that. Also, I have some changes to the docker file which you might want to consider, not sure how you are using.

Infinite hang on grouping

https://github.com/lincheney/journald-2-cloudwatch/blob/master/main.py#L166

Process can hang here indefinitely if the same group and stream names are always used.

Support environment variables in the format spec

Then you could do:

X=123 main.py -g '{$X}' ...

Determine AWS region from EC2 metadata

See https://stackoverflow.com/questions/4249488/find-region-from-within-an-ec2-instance

This will remove the need to use the AWS_DEFAULT_REGION variable.

Cache seq tokens

Currently the seq token is looked up before every upload, but the put_log_events response returns the next token to use.

Fork for expansion of features scope

Hi @lincheney
I'd like to let you know that I forked journald-2-cloudwatch project, because we are going into a direction where journald-2-cloudwatch will stop being a lean command line tool. Indeed we will need to configure subscriptions for the log_group that journald-2-cloudwatch is creating. Adding support of such functionality requires to switch from command line arguments to config files... Which is a burden to maintain and use.

If you are also interested by those features, let me know and I'll be more than glad to push pull request here and keep your repo as upstream.

Thank you for all the big work and please tell me what are your thoughts on this.

HTTP 500 from cloudwatch API causes service to fail

Hi Cheney,

We noticed this morning that there seemed to be a few hiccups with the AWS cloudwatch API. This lead to the service being marked as failed.

Jul 27 02:19:43 ... systemd[1]: Started journald_wrapper.
Jul 27 23:58:29 ... docker[1079]: Traceback (most recent call last):
Jul 27 23:58:29 ... docker[1079]: File "/main.py", line 195, in <module>
Jul 27 23:58:29 ... docker[1079]: client.log_messages(log_stream, list(messages))
Jul 27 23:58:29 ... docker[1079]: File "/main.py", line 111, in log_messages
Jul 27 23:58:29 ... docker[1079]: self._log_messages(log_stream, chunk)
Jul 27 23:58:29 ... docker[1079]: File "/main.py", line 120, in _log_messages
Jul 27 23:58:29 ... docker[1079]: self.put_log_messages(log_stream, messages)
Jul 27 23:58:29 ... docker[1079]: File "/main.py", line 82, in put_log_messages
Jul 27 23:58:29 ... docker[1079]: seq_token = self.get_seq_token(log_stream)
Jul 27 23:58:29 ... docker[1079]: File "/main.py", line 133, in get_seq_token
Jul 27 23:58:29 ... docker[1079]: streams = self.client.describe_log_streams(logGroupName=self.log_group, logStreamNamePrefix=log_stream, limit=1)
Jul 27 23:58:29 ... docker[1079]: File "/usr/local/lib/python3.4/dist-packages/botocore/client.py", line 262, in _api_call
Jul 27 23:58:29 ... docker[1079]: return self._make_api_call(operation_name, kwargs)
Jul 27 23:58:29 ... docker[1079]: File "/usr/local/lib/python3.4/dist-packages/botocore/client.py", line 552, in _make_api_call
Jul 27 23:58:29 ... docker[1079]: raise ClientError(parsed_response, operation_name)
Jul 27 23:58:29 ... docker[1079]: botocore.exceptions.ClientError: An error occurred (500) when calling the DescribeLogStreams operation: Internal Server Error
Jul 27 23:58:29 ... systemd[1]: journald_wrapper.service: Main process exited, code=exited, status=1/FAILURE
Jul 27 23:58:29 ... docker[2461]: journald_wrapper
Jul 27 23:58:29 ... docker[2467]: journald_wrapper
Jul 27 23:58:29 ... systemd[1]: journald_wrapper.service: Unit entered failed state.
Jul 27 23:58:29 ... systemd[1]: journald_wrapper.service: Failed with result 'exit-code'.

Would it be better to handle a 500 or other HTTP errors and just log the failure somewhere so the service is tolerant to AWS problems?