Azure / Azure/azure-cli

Usability issues with az monitor activity-log list

Open
#25,620 5 comments 0 reactions 1 assignee Claimed by @AllyW View on GitHub
act-observability-squad Auto-Assign Azure CLI Team customer-reported feature-request Monitor
Dominant language
Python
Stars
4.6k
Forks
3.5k
Avg merge
3d 2h
Merged PRs (30d)
60

Description

## Describe the bug

I am trying to write a script to pull all activity-log entries going back to a beginning timestamp, regardless of how many entries there are. (This means fetching entries in a loop, since the API limits the number of entries that can be returned at once.) I've spent more time trying to understand the behavior of `az monitor activity-log list` than I have debugging the script itself, because the command-line options seem to be broken and/or ambiguous in a few ways:

1. Specifying `--offset` sometimes pauses for a really long time, and then returns zero results, even when I know results are there to be found. Querying the same time window with `--start-time` returns results, however. (This issue is intermittent and I'm not always able to reproduce it, so I'm not actually sure if this is an Azure CLI issue or a back-end service issue.)
2. Specifying `--start-time` causes entries OLDER than the time specified to be returned, rather than NEWER entries (contrary to what the documentation implies, and contrary to what the word "start" means).
3. And, it turns out, `--end-time` does the same thing, but somehow returns different (older) entries???
4. Nowhere in the `--help` documentation does it say that entries are returned in _reverse_ chronological order, which is the opposite of what I would expect and the opposite of how most logging systems usually work on UNIXy operating systems.

**Command Name**
`az monitor activity-log list`

## To Reproduce:
I wasn't able to repro (1) after seeing it for a while today; `--offset` suddenly started returning results again.

(2)/(3) are trivially reproducible:

```
❯ az monitor activity-log list --max-events 5 --start-time 2023-01-29T13:59:56.636141+00:00 |jq -c '.[]|{eventTimestamp}'
{"eventTimestamp":"2023-01-29T19:59:56.586322+00:00"}
{"eventTimestamp":"2023-01-29T19:59:56.582215+00:00"}
{"eventTimestamp":"2023-01-29T19:59:56.574379+00:00"}
{"eventTimestamp":"2023-01-29T19:59:56.312512+00:00"}
{"eventTimestamp":"2023-01-29T19:59:56.278495+00:00"}
```

Note how all the returned event timestamps are older than the timestamp requested.

Even more concerning, however, is what happens when I swap `--start-time` with `--end-time`—I _still_ get events older than the timestamp, but this time they seem to be _different_ events with _different_ timestamps (and no, I did not switch subscriptions in between or anything like that; these commands were run consecutively):

```
❯ az monitor activity-log list --max-events 5 --end-time 2023-01-29T13:59:56.636141+00:00 |jq -c '.[]|{eventTimestamp}'
{"eventTimestamp":"2023-01-29T13:59:56.517164+00:00"}
{"eventTimestamp":"2023-01-29T13:59:56.506204+00:00"}
{"eventTimestamp":"2023-01-29T13:59:56.491555+00:00"}
{"eventTimestamp":"2023-01-29T13:59:56.442120+00:00"}
{"eventTimestamp":"2023-01-29T13:59:56.441386+00:00"}
```

So at this point, I have no idea how to make sure I've fetched _all_ the events within a particular time window, since I'm not confident Activity Log is actually showing me everything that's in between the first and last returned events.

## Expected Behavior

* Use option names that are unambiguous (`--newer-than` and `--older-than` instead of `--start-time` and `--end-time`, which seem to mean the opposite of what they say)
* `--offset` should not reverse its behavior depending on whether `--start-time` or `--end-time` is specified; these should be two separate options. For example, `journalctl` on Linux uses `--since` and `--until` for these two concepts.
* Sort returned entries oldest-first by default, OR provide an option to sort oldest-first, OR at least make it clear in `--help` output that entries are sorted newest-first.
* Return _all_ the events in the time window requested, up to the `--max-events` limit, properly-sorted by timestamp so that I can fetch the next batch of events by narrowing the time window accordingly.

## Environment Summary
```
macOS-13.1-x86_64-i386-64bit, Darwin 22.2.0
Python 3.10.10
Installer: HOMEBREW

azure-cli 2.45.0
```
## Additional Context

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.