[READ] List defined Log Insight alerts.

Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {id, name, enabled, info}. Start here, then pass an id to get_log_alert or get_log_alert_history. total is the real count matching name_filter, so truncated answers whether more exist; raise limit or narrow name_filter when true. Read-only — this skill never creates/edits/deletes alerts.

[READ] Get the stored definition of one alert. Use this after list_log_alerts.

Returns the same sanitized {id, name, enabled, info} projection as an list_log_alerts row plus 'raw_keys' — the sorted key names the appliance actually sent — so you can see what else the definition carries without this skill guessing at its shape. For when the alert fired, use get_log_alert_history. Read-only.

[READ] List recent trigger-history records for an alert.

Use this for when an alert fired, not how it's defined. Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {timestamp_ms (when it fired), acknowledged, message_count, messages: [{timestamp_ms, text}]} with at most 3 of the record's events (verified on 8.18.7). An alert that never fired returns an empty list, not an error. The appliance pages history, so a page shorter than limit is the whole history (real total); a full page has total null and truncated true. Read-only.

[READ] Search Log Insight events within a time window.

WHEN: to find the actual log lines behind an incident (e.g. what vmkernel logged during a storage event). For "where did logs burst?" use aggregate_logs instead; for vCenter alarms use vmware-monitor.

RETURNS: {count, complete (False if truncated), constraints, events: [{timestamp_ms, text, fields}]}, plus 'note' when limit was lowered. 'fields' is a flat {name: value} dict — hostname, appname, procid, source, facility and the other static fields the appliance attached (content-pack fields are not included: the query does not ask for them). Feed events to vmware-debug build_incident_timeline to correlate across sources. Read-only.

[READ] Aggregate matching events into a time series and detect spikes.

WHEN: to find when/whether log volume burst without pulling raw events. Follow up with search_logs on the spike window.

RETURNS: {aggregation, field, bin_width_ms, constraints, bins:[{timestamp_ms, end_ms, value}] oldest first, spikes:[{timestamp_ms, end_ms, value, zscore}]}, plus 'note' when an empty series has a likely cause. For SAMPLE each bin's value is one example event {timestamp_ms, text, fields}, and no spikes are computed. The appliance omits bins with no events; for COUNT and UCOUNT those are added back as 0 (filled_empty_bins: true) so a burst after a quiet stretch still stands out. On a sparse series (a few events in an hour) that makes most non-empty bins spikes — read them as "events happened here", not as bursts. A bin is flagged as a spike when it sits at least 2 standard deviations above the mean; a series of fewer than 3 bins, or a flat one, reports no spikes rather than calling everything a spike — so an empty 'spikes' list is not evidence of calm when the window is short. Read-only.

[READ] List the fields this appliance knows (static and extracted).

Use this to pick a 'field' for aggregate_logs, or to learn what a key in a search_logs event's 'fields' means. Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {name, internal_name, type}; a content-pack field adds 'display_name' and 'content_pack', and its 'name' is qualified ("com.vmware.vsphere:"); 'unresolved': true (with a 'note') means its pack's namespace is unknown, so that name will match nothing. 'name' is what aggregate_logs takes; 'type' (STRING, NUMBER, ...) says which functions apply. No limit — every matching field is returned. An 8.18.7 appliance with the default content packs has ~340 fields (~15k tokens unfiltered), so pass name_filter. Read-only.

[READ] Return the Log Insight appliance version/build (diagnostics and query-syntax compatibility). Returns {version, release_name, build}. Use this first when a query behaves unexpectedly, to confirm the appliance version before trusting search_logs. Read-only.