Aria Operations for Logs monitoring with Topologix

Monitoring & Observability

Read VMware Aria Operations for Logs (the former vRealize Log Insight) — the vCenter event stream and ESXi syslog your platform already forwards there. Topologix classifies severity itself, so no alert definitions are needed on the appliance. The API answers on the same port 443 as the web UI — the address you open in a browser is the address to enter; Topologix performs the CSRF preflight the appliance's login requires.

Requirements

• HTTP(S) reach from the Topologix server or a proxy agent to the appliance on port 443 — the web UI's port; no separate API port has to be opened. (The dedicated API port 9543 also works if you give it explicitly.) The login is CSRF-protected: Topologix first fetches a token with a GET, then logs in carrying that token and the appliance's cookies. If a reverse proxy sits in front of the appliance it must pass Set-Cookie and X-CSRF-Token through unchanged, or every login answers a 403 page that reads like a rejected password.
• A user on one of the three authentication providers — Local, ActiveDirectory, vIDM — with API access. A Local user with the View role is the recommendation: read access is all this integration needs, and a Local user can never lock a domain identity.
• Self-signed HTTPS is accepted by unticking Verify TLS certificate — the appliance ships VMware’s generic default certificate, with no FQDN in it.

1 · Set up the integration

1. Open the Integrations pageClick Integrations in the toolbar and pick Aria Operations for Logs from the catalogue.
2. Enter the appliance URLE.g. https://loginsight.example.local — the address you use in a browser. No port is added; an explicit port is honoured.
3. Enter the credentials and pick the providerUsername, password, and one of the three providers. Local is the default and the recommended one.
4. Choose the egress (optional)Connect via proxy routes both the test and the collector through a proxy agent — set it when the appliance is only reachable from that network. Test connection follows the same choice, so a passing test means the polling path works.
5. Create, then verifyClick Create, then reopen the integration and click Test. It logs in, reads the version, and probes whether vCenter events and ESXi syslog have actually arrived in the last 24 hours — reporting e.g. “Connected — Operations for Logs 8.18.0 · vCenter events flowing · ESXi syslog flowing”.

2 · Add it to a flow

1. Nothing to wire for the platform layersThe Databases forensic view picks the integration up on its own: the log layer attaches to the OS, VM, ESXi host and vSAN rows of “Where it runs”, matched to vCenter’s forwarded event stream by moref.
2. Add a log-query source for anything elseOn the canvas, click a node, open Metrics, then + Add and choose this integration. Type a query — a Logs constraint path, the same syntax the appliance’s own search URL uses.
3. Choose what to count and over how longCount errors only (the default) or every matching event, and set the window in minutes (default 15 — the same window the platform rows count over, so a card beside one is comparing like with like).
4. SaveOptionally set an alarm threshold, then click Add Source. The card shows the count, the query, and up to three redacted sample lines — an error storm is a spike you can threshold and alert on.

3 · Beyond presets: custom queries & the All-Services alarm

What the appliance is read for

Two streams, both of which a standard vSphere deployment already forwards: vCenter’s own event stream (carrying vc_event_obj_id — the object’s moref — plus its name, type and severity) and the ESXi hosts’ syslog. The moref is what lets a log line be attached to the exact VM, host or cluster a database runs on.

• Nothing is written to the appliance and no alert definitions are created — the integration only ever reads.
• Content-pack presence is inferred from whether the fields those packs extract are actually arriving, because the pack-list endpoint is absent on 8.18. The test reports what it found rather than what is installed.
• A host that has sent nothing in 24 hours is reported as silent, with the reason — never as “0 errors”.

The log layer on “Where it runs”

Every row of the Databases forensic view gains a Logs figure — the operating system, the virtual machine, the ESXi host and the vSAN cluster. The VM, host and cluster rows are matched to vCenter’s forwarded event stream by moref (vc_event_obj_id), the host row additionally by the ESXi’s own syslog sender address, and the OS row by the database machine’s hostname. The figure reads 12 errors · in 15 min · 3 warnings, amber from three errors and red from ten.

• A row that counted zero reads “0 errors · quiet, 15 min” and carries no colour — it is a measurement, and a green would be the log stream claiming the machine is healthy on the strength of an absence.
• A row nothing arrives from reads “no logs” with the reason and the port to point rsyslog at (9000/514). It is amber on the figure only: a gap in coverage is worth seeing, but it is not a fault in the database.
• A VM with no events while vCenter is forwarding is quiet, not a gap — a VM forwards nothing of its own, so “no events about this VM” is the normal state of a healthy one. Only a vCenter that has stopped forwarding its event stream makes those rows a gap, and then the sentence names vCenter.
• An appliance that did not answer reads “unreachable” with the transport error and tones nothing anywhere — the section says “Logs: unreachable” once instead.
• Open the row’s list to see the latest lines with their severity, their timestamps to the second and the sender, plus the exact field and value the row was matched on — so any figure can be reproduced on the appliance.
• A trend panel, Platform log errors per minute, charts all four layers on the database’s own time axis, sharing the hover and click-to-correlate group with the CPU, latency and vSAN panels.

The log-query source

A canvas source that counts events matching a Logs constraint path over a window. The syntax is the appliance’s own: field/OPERATOR value, pairs joined by / — e.g. source/CONTAINS 172.16.30.93 for everything one host sent, or vc_event_obj_id/CONTAINS host-392232 for vCenter’s events about one ESXi host.

• CONTAINS is the exact-match operator. = and != do not exist for text fields — they answer 400 — and on an extracted field CONTAINS matches whole tokens, so vm-2740 finds none of the rows vm-274080 finds. That is what makes a moref both matchable and precise.
• Errors are counted by grouping on the appliance’s own severity field (vc_event_severity for vCenter’s events, priority for raw syslog). When no field describes the matched rows well enough to trust, the card says so and reports the total rather than a confident zero.
• The card shows the count, the query, the denominator (“of 18 matching events”) and up to three sample lines — redacted before they leave the network they were collected on.
• value is the metric the threshold machinery reads. An appliance that could not be reached reports no value and an error, never 0: a zero on an “error events matching this query” card is indistinguishable from good news.

Error classification

vCenter events are classified by the appliance’s own vc_event_severity. Raw syslog has no reliable severity field, so two tunables in the Error classification disclosure decide what counts as an error.

• Max severity counted as an error — default 3 (syslog err); 4 is warning, so raising it reclassifies every warning in the estate as an error.
• Error keywords — matched case-insensitively against lines with no severity field. Default error|fail|panic|fatal|timeout|denied|refused|resync|congest.

Per service (non-ESXi logs)

The log-query source’s second mode, Per service: error events counted per service over each check, with the log error baselines of the Graylog All Services source — usual count per weekday and hour, breach rule, new-type warnings, banner, Alerts page and the Catalogue Logs section. Pick the service field (appname, hostname or source) and an optional query (empty = every event); the window is the polling interval.

• Appliance calls per check: at most 6, typically 3–4 — the ungrouped error total (a quiet window stops there, 1 call), the severity-field probe (remembered for an hour once a field covers the rows), one grouped count per error word actually present (≤ 4; the appliance allows one group-by per query) and one 150-event sample for the error types and View logs. When the budget runs out a word is counted whole into (unknown) with a caveat; the sample is skipped first.
• Poll every 120 seconds or slower — a shorter interval is refused (switching the mode raises it to 300 s).
• Severity words are matched with CONTAINS — the only text operator the appliance has — one word per call. Events that lack the service field are dropped by a grouped count, so the difference to the total is reported as the (unknown) service rather than lost.
• Error types are fingerprints of the sampled lines (marked approx); service names keep their case. A service seen in the last 24 hours with no errors reads a measured 0.
• A paused (parked) credential or an unreachable appliance makes the check read no value and an error — never zeros.
• For ESXi hosts and vSAN, use the vCenter instead: a VMware source with scope Host logs reads the error counts the Hypervisors page already collects from this appliance — no extra Logs calls (see the vCenter guide). Per service is for everything else that forwards here.
• Polled through a proxy: proxy 1.218.0 or newer — there is no version gate, and an older proxy does not know this mode, so update the proxy before creating the source there.

ESXi host and vSAN log baselines (vCenter “Host logs”)

The Hypervisors page already asks this appliance, every 5 minutes, how many error lines each ESXi host and vSAN cluster of a vCenter logged in the last 15 minutes. A VMware source with scope Host logs turns those counts into per-host log error baselines — the host is the “service” (a vSAN cluster reads vsan:<cluster>) — with the same breach rule, new-type warnings, banner (Host Log Errors), Alerts page and Catalogue Logs section as the other log sources.

• Zero extra Logs calls: the source reads the Hypervisors pass in memory on the server; it never queries the appliance itself. One source per vCenter covers every host and vSAN cluster of it. It always runs on the server (a proxy picked on it is ignored).
• Needs an Aria Operations for Logs integration visible to the vCenter’s owner and the Hypervisors collector running (HV_COLLECTOR not off). No pass yet, or a pass that is too old, reads no value with the reason.
• Poll every 300 seconds or slower (shorter is refused; the form raises it to 300).
• The value is an estimate: each check reports the 15-minute count scaled to the interval (count × interval / 900, rounded with a carry so the totals over many checks stay right). At a 900-s interval it is the exact count; above 900 s it reports the last 15 minutes, with a caveat.
• A host whose forwarding was probed and that sent nothing reads a measured 0; a host the appliance did not answer for (or that was never probed) is left out and named in the caveat — never counted as 0.
• Error types are approximate: fingerprints of the ≤ 5 newest error lines per host the pass kept (already redacted). View logs shows those lines.
• Use the Per service mode above for logs that are not from ESXi.

Good to know

• A rejected credential is not retried in a loop: the first rejection pauses logins for 15 minutes and each further one doubles, up to 2 hours. Clicking Test after fixing the password clears the pause immediately — it is the only thing that does. A refused connection, a timeout or a server error is not treated as a credential fault and never pauses anything.
• The login session is cached and reused across polls (the appliance issues a 30-minute one), with a single automatic re-login if it is revoked server-side.
• A 403 on Test is the appliance’s CSRF filter refusing the login before any credential was read — the sentence says so and names the reverse-proxy cause. A 401 quotes the appliance’s own reason, which is how a locked account is told apart from a typo.
• Log text is redacted before it is stored or shown, on the same engine and rule set as the rest of the product.
• Advanced → Max Aria calls per 5 min (Hypervisors log refresh) caps the load the Hypervisors page’s log passes put on the appliance — default 250, any whole number from 30 to 2000. A full pass costs roughly one call per host plus a few probes; a pass over the cap slows the log refresh (up to every 15 min) instead of asking the appliance harder.