Skip to main content
Glama
io.github.zw008/vmware-log-insight

io.github.zw008/vmware-log-insight

VMware Log Insight

For a read-only check of this skill with your model and agent host, use the shared model-fit self-test in the marketplace root.

Disclaimer: Community-maintained open-source project, not affiliated with, endorsed by, or sponsored by VMware, Inc. or Broadcom Inc. "VMware", "vSphere", and "Aria" are trademarks of Broadcom. Source is publicly auditable under the MIT license.

Read-only log search and aggregation for VMware Aria Operations for Logs (formerly vRealize Log Insight) — the appliance that collects syslog from ESXi hosts, vCenter, and VMs. The centralized-log data source for the VMware skill family. Strictly non-destructive: it queries, it never writes.

Upgrading to 2.0

2.0 renames all 7 MCP tools so every name starts with a verb (e.g. alert_get → get_log_alert, alert_history → get_log_alert_history, alert_list → list_log_alerts). The full old → new table is in RELEASE_NOTES.md. Nothing else changes: same tools, parameters, safety gates and CLI commands. If an agent prompt, script or ~/.vmware/rules.yaml names a tool, update it — though deny rules written with the old names keep working with vmware-policy ≥ 1.18 (vmware-audit policy lists any rule the renames widened), and vmware-pilot ≥ 1.13 translates old names in saved workflows. If an install older than 2.0 shares that rules.yaml, give it vmware-policy ≥ 1.18.2 too: it matches each rule against both the old and the new name, so one file serves both.

Related MCP server: mcp-opensearch

Companion Skills

Need

Skill

Tools

Raw centralized logs + spikes

vmware-log-insight (this)

7

vCenter events & alarms

vmware-monitor

27

Metrics, anomalies, capacity

vmware-aria

28

Incident correlation / root cause

vmware-debug — feed it search_logs output

2

VM lifecycle / operations

vmware-aiops

49

Install

uv tool install vmware-log-insight
mkdir -p ~/.vmware-log-insight
cp config.example.yaml ~/.vmware-log-insight/config.yaml   # edit host/username/provider
echo 'VMWARE_LOG_INSIGHT_PROD_PASSWORD=...' > ~/.vmware-log-insight/.env
chmod 600 ~/.vmware-log-insight/.env
vmware-log-insight doctor

Offline / Air-Gapped Install (from source)

This project uses the modern PEP 517 build system (hatchling), so there is no setup.py by design — that is expected, not a missing file. If you cloned the source and hit ERROR: File "setup.py" or "setup.cfg" not found ... editable mode currently requires a setuptools-based build, your pip is older than 21.3 and cannot do an editable (-e) install with a non-setuptools backend. Editable mode is a developer convenience, not needed to run the tool — do one of:

# From the source tree — a normal (non-editable) install builds a wheel:
pip install .              # NOT  pip install -e .

# ...or upgrade pip first, and editable works too:
pip install --upgrade pip && pip install -e .

For a truly air-gapped host, build the wheels on a connected machine and copy them over — the target then needs no network:

# On a connected machine, collect this package + its dependencies as wheels:
pip wheel . -w dist        # → dist/*.whl   (or: uv build, for just this package)

# Copy dist/ to the air-gapped host, then install offline:
pip install --no-index --find-links dist vmware-log-insight

MCP Tools (7 — all read-only)

Tool

What

search_logs

Search events by time window + text (whole-token match), up to 200 events

aggregate_logs

Count/aggregate over time bins (UCOUNT/AVG/... of a field), with z-score spike detection

list_log_fields

List the appliance's fields (name + type), for aggregate_logs field

get_log_insight_version

Appliance version/build

list_log_alerts / get_log_alert / get_log_alert_history

Query defined alerts and their trigger history

Workflows

  • Find errors fast — vmware-log-insight search -q error -l 1h.

  • Where did logs burst? — vmware-log-insight aggregate -q error -l 6h --bin-ms 300000, read spikes[], then search the spike window.

  • Root cause — pass search_logs results (plus vCenter events from vmware-monitor and metrics from vmware-aria) to vmware-debug build_incident_timeline.

Troubleshooting

  • 401 on /sessions → check username/password/provider and the VMWARE_LOG_INSIGHT_<TARGET>_PASSWORD env var.

  • 503 everywhere → appliance starting up; doctor reports it as a status, not a crash.

  • Empty results → widen --last; text matches whole words, not substrings (try word*); default API port is 9543 (set port if different).

  • UCOUNT needs a field → pass --field (names from fields); COUNT and SAMPLE take none.

Security

Read-only by construction. Credentials in ~/.vmware-log-insight/.env (chmod 600); plaintext passwords auto-obfuscated to grep-safe b64: (obfuscation, not encryption — inject from a secret manager for real secrecy). TLS on by default. See SECURITY.md.

Remote access (HTTPS) and limiting tools

By default vmware-log-insight mcp speaks stdio to one local client and offers every tool. Two options change that (vmware-policy ≥ 1.21.0).

Serve over HTTPS so clients on other machines can connect. Every caller needs a bearer token:

vmware-audit token create alice          # prints the token once; give it to alice
vmware-audit token list                  # names only
vmware-audit token revoke alice          # refused from its next request, no restart
vmware-log-insight mcp --transport https --host 0.0.0.0 --port 8443 \
    --cert /etc/vmware-mcp/server.pem --key /etc/vmware-mcp/server-key.pem \
    --public-name mcp.example.com

Connect a client (Claude Code shown; any MCP client that supports streamable HTTP and custom headers works):

claude mcp add --transport http vmware-log-insight https://mcp.example.com:8443/mcp \
    --header "Authorization: Bearer $VMWARE_MCP_TOKEN"
{
  "mcpServers": {
    "vmware-log-insight": {
      "type": "http",
      "url": "https://mcp.example.com:8443/mcp",
      "headers": { "Authorization": "Bearer ${VMWARE_MCP_TOKEN}" }
    }
  }
}
  • The server will not start without a token, refuses Host/Origin values outside --public-name, and checks before it binds that unauthenticated requests get 401. Use a certificate your clients trust for those names.

  • Behind a TLS-terminating reverse proxy on the same machine use --transport http --host 127.0.0.1 --public-name mcp.example.com and pass the Authorization header through.

  • Behind a load balancer or gateway on another machine, keep --transport https (a self-signed certificate is fine), list in --public-name the host name the balancer sends as Host, and have it forward Authorization. Its health probe can use GET /healthz, which needs no token and returns only {"status": "ok"} (vmware-policy ≥ 1.23.0).

  • Send traceparent or X-Request-ID with each request to have it stored on the audit row; vmware-audit log --correlation-id ID then finds the calls behind one platform request.

  • The audit log records each caller as token:<name>. Calls run side by side, with or without a target: each target keeps up to VMWARE_MCP_POOL_SIZE sessions (default 2), and each session is a login on the target. A call that finds them all busy waits at most 300 s for one.

  • Everyone who can reach the endpoint acts with this server's account. Tokens identify callers; they grant nothing on the platform. Run one endpoint per privilege level.

  • Several people or roles on one endpoint: run vmware-audit roles enable once, then give each token a role (vmware-audit token create NAME --role reader, or a role in roles.yaml naming tools and targets; vmware-policy ≥ 1.24.0). A role limits what the token may call on this endpoint; it cannot grant more than the account has. See vmware-policy's README, "Roles for network callers".

Limiting tools: every tool of this server is read-only, so --expose read changes nothing here; it exists for the write-capable skills. Least privilege comes from the account the server uses.

Details: skills/vmware-log-insight/references/setup-guide.md ("Serving MCP over HTTPS", "Limiting which tools are offered").

System proxy bypass

The Log Insight REST client honors the operating system proxy bypass list for the configured origin. TLS verification still follows verify_ssl, and CA environment settings such as SSL_CERT_FILE remain active. Other origins retain their normal proxy routing.

License

MIT.

Available Tools

7 tools
aggregate_logsA
Read-onlyIdempotent

[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.

Inputs: last, text, field, end_ms, +4 more.

get_log_alertA
Read-onlyIdempotent

[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.

Inputs: alert_id (required), target.

get_log_alert_historyA
Read-onlyIdempotent

[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.

Inputs: alert_id (required), limit, target.

get_log_insight_versionA
Read-onlyIdempotent

[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.

Inputs: target.

list_log_alertsA
Read-onlyIdempotent

[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.

Inputs: limit, target, name_filter.

list_log_fieldsA
Read-onlyIdempotent

[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.

Inputs: target, name_filter.

search_logsA
Read-onlyIdempotent

[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.

Inputs: last, text, limit, end_ms, +2 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 7 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose: alert listing vs. alert definition vs. alert history vs. raw log search vs. aggregation vs. field catalog vs. version. The descriptions explicitly cross-reference each other to steer selection, so overlap is minimal.

    Naming Consistency5/5

    All seven names use snake_case with consistent verb_noun phrasing (list_/get_/search_/aggregate_), and the alert tools share the log_alert prefix predictably.

    Tool Count5/5

    Seven tools is well-scoped for a read-only Log Insight query/inspection server; each tool covers a distinct need and none feel redundant.

    Completeness4/5

    The read-only surface covers the core workflow (alerts, history, search, aggregate, fields, version), but get_log_alert returns only raw key names rather than full definition values, and there is no way to inspect alert definitions beyond a sanitized projection. Minor gaps remain for deep alert-definition analysis, though the main query paths are covered.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      D
      maintenance
      MCP server for querying and analyzing logs from VMware Aria Operations for Logs, enabling log search, incident detection, and vROps correlation.
      6
      4
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      Read-only MCP server for exploring and searching OpenSearch clusters, enabling log analysis, index exploration, and query execution.
      8
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      A read-only MCP server for querying Sumo Logic logs, enabling AI assistants to search and investigate application logs with opinionated tools and secure credential handling.
      5
      17 npm
      1
      MIT
    • F
      license
      Not graded
      quality
      D
      maintenance
      Read-only MCP server for Elasticsearch log querying. Enables natural language search, filtering, context retrieval, and aggregation of logs.
      -