Not all streams shown

[GeorgeDewar]

Using the latest version of awslogs, I cannot see all streams in some log groups. For example, aws logs describe-log-streams --log-group-name <my-group-name> returns ten log streams, but awslogs streams <my-group-name> only returns two or three (and it's not consistent).

Similarly, there are some streams I can specify using awslogs get <my-group-name> <my-stream-name>, while other streams which do exist return No streams match your pattern '<my-stream-name>'.

Regardless of this, calling awslogs get <my-group-name> without specifying a stream name always seems to work and return all streams.

Any ideas?

[keichan34]

Try setting the --start XXX parameter, so if you want logs from starting 30 minutes ago, awslogs streams <my-group-name> --start '30m ago'.

[GeorgeDewar]

Sorry for the delayed response - you've nailed it. Thanks!

I'd still suggest a more intuitive way of handling this scenario, but it makes sense.

[GeorgeDewar]

I think there is still a subtle problem here.

I've noticed that sometimes, I'll still get the error even when specifying a start parameter that should include the log entry. I think it might be a timezone issue.

Here is an example (the messages shown are from only a minute ago):

$ awslogs get junction_test test1/task -s '3h ago' --timestamp
junction_test test1/task 2016-12-08T22:19:41.151Z <log message>
junction_test test1/task 2016-12-08T22:20:24.182Z <log message>

$ awslogs get junction_test test1/task -s '2h ago' --timestamp
No streams match your pattern 'test1/task'.

Several minutes later it started working, even with -s '30m ago'... Could be an issue on the AWS end I suppose.

When I get a chance later I may try capturing the traffic to see if it's an awslogs issue or an AWS issue.

[jorgebastida]

I've realised this behaviour might be slightly counterintuitive (filtering streams by date) but I think once the behaviour is understood it becomes more useful in situations where you have a vast amount of them.

About the second issue @GeorgeDewar I would love to get more info on that, as it is either a bug on awslogs or an eventual-consistency glitch on aws.

[whereisaaron]

@jorgebastida if this is the desired behavior you could make '--start' a required option, so it is an error to leave it out. Then this behavior wouldn't be such a surprise.

You could all update 'awslogs streams -h'. Currently it gives no hint of this default filtering, it just says 'List streams'. The filtering start/end options are listed as optional, so you naturally assume there is no filtering period unless you specify one.

What is the current built-in / default filtering period?

[vlcinsky]

I run into the same problem.

Trying to list streams in my logs I got nothing.

There are few options for listing streams:

• "too few": as today: without specifying time range very often no result
• "too many": for streams, always retrieve all streams found in logs.
• "reasonable time range default": agree e.g. on "last one hour" as default time range.

The "too few" is disappointing and surprising. To get good results, one has to find out about time ranges and use them.

"Too many" can go sometime really wild (e.g. on long running AWS Lambda each worker creates new stream), but the result is not so big surprise. Natural reaction after this flood of streams is "can I limit it by time range?" and awslogs gives very good answer to that. In case, someone uses just few streams (as we do for collecting long term data from few sources), the "too many" is not an issue.

"reasonable time range default" sounds good, but it could get tricky. The biggest problem is, that users will often feel "something is not as I expected", but will not find the solution easily as the problem will be partially hidden.

So I would prefer (for listing streams) the "give me all which ever existed" solution (what sometime translates into "too many").

[rwolfson]

Agree that the default behavior here is undesirable in the case of enumerating log streams. It's not the fault of awslogs, but it appears that some log streams that have constantly flowing logs have a delayed "last updated time", seen as a symptom in the awslogs app (not listing all "live" streams) and being reflected in the AWS log web console. A more generous default would help mitigate the effects of this AWS behavior.

It appears the the 5m default start time is written for both "get" and "streams", perhaps those should be separated to allow separate reasonable defaults (i.e., keep 5m for "get" but increase "streams" to 1h).

[jorgebastida]

@rwolfson patch looks good to me. I understand this might not be the best/final solution, but it is a step in the right direction, and the behaviour would be less "bad".

[rwolfson]

Thanks. I realized after I submitted it that 1h may still be undesirable to a lot of folks with "quieter" stream activity, so I can certainly expand the default further if that's desired. This should at least cover the active stream case where AWS does not seem to be updating the last updated time.

[vlcinsky]

Very good (we have now extended time for streams). To me 1h or 1d would seem fine.

Consider adjusting the error message "No stream..." reporting ".. for given time period --".

Such an error message would:

• would be more correct
• would inform the user some time-range stuff is in place and help him to attempt to be explicit in next request

[jorgebastida]

That message update would be great, yes! Does somebody mind sending a pr?

[fantamiracle]

One problem with that is, if you do not pass any timing option, it still returns with empty streams. I'd suggest the right way to do this is:

1) make the --start a required option (as suggested by @whereisaaron) 2) show all the streams as aws logs does anyway. If the concerns is outputing too many streams, we can have an error message to tell the user it is too long and make him to add --start option.