TL;DR · Key Takeaways
- Metrics tell you when and where a problem started. Logs tell you what happened. Reach for logs at the why step, after a metric has handed you a time window and an object, not before.
- Log Management is what Aria Operations for Logs became. In VCF Operations 9.1 it runs as a containerized core service inside the VCF Management Services Platform, not a separate appliance you log into on the side.
- Syslog ingests on 514/UDP, 514/TCP and 1514/TCP for SSL. The ingestion API listens on 9000/TCP and 9543/TCP for SSL. Point your sources at the right channel once and stop fiddling.
- Ingested events are searchable within seconds. When the index disk reaches 97 percent, the oldest data is deleted first, so your retention window is a setting you own, not a promise the tool makes.
- Filter and mask at ingest. On one site, dropping info-level guest chatter cut ingest from about 12,000 to 4,200 events per minute and the signal got much easier to find.
- Content packs still load, but they are being phased out. Build new dashboards, alerts and saved queries as management packs.
I get paged, I open a dashboard, and the metric tells me a cluster went sideways at 14:30. That is where a lot of engineers stop and start guessing. I have learned to treat the metric as the address and the log as the story. The metric hands me a time and an object. The log tells me what that object was actually doing at that second.
This part is about wiring logs into the day-2 workflow you already run in VCF Operations, so a jump from a metric spike to the log line that explains it takes seconds instead of a context switch into a separate tool. I run this for real environments, and the gap between a five-minute diagnosis and a two-hour one is almost always whether the logs were ready before the incident, not scrambled together after it.
Where logs fit in the workflow, and where they don’t
Metrics and logs answer different questions, and mixing them up wastes time. A metric is a number sampled on a schedule: CPU ready, datastore latency, ingest rate. It is great at showing you that something changed and roughly when. A log is a discrete event a component chose to write: a task started, a path went away, a service restarted. It is terrible at trend but perfect at cause. The handoff between them is the whole skill here.
My rule is simple. I start in metrics because they narrow the window fast. Once a metric points me at a time and an object, I ask one question: is this contention, or is it a state change or failure? If it is contention, I stay in metrics and follow the pattern I covered in the performance part of this series. If something changed state or failed, I pivot straight to logs and filter to that object and that minute.
When to stay in metrics
Not every problem has a log worth reading. A VM that is simply oversubscribed will not write an error, because nothing failed. Its neighbors are just louder. Pull logs for that and you will find nothing, then blame the tool. The table below is the cheat sheet I keep in my head: a metric symptom on the left, and the log that usually explains it on the right, or a note that logs will not help.
| Metric symptom | Where the answer lives |
|---|---|
| CPU ready climbing on a group | Usually contention, stay in metrics. Check logs only if a host event lines up. |
| Datastore latency spike | Storage and host logs: path events, all-paths-down, SCSI sense codes. |
| VM will not power on | vpxd and hostd task events, the exact failure reason. |
| NSX traffic dropping | NSX and firewall logs: rule hits, dropped flows, edge events. |
| Memory ballooning steadily | Usually contention, no error to read. Right-size instead. |
What VCF Operations for Logs is in 2026
The name has changed more than the job has. This is the product that used to be Log Insight, then vRealize Log Insight, then Aria Operations for Logs through the 8.x line as a standalone appliance. In VCF 9.0 the logs experience was folded into the VCF Operations console under the name Operations-Logs, while the logs platform itself still ran as its own tier. In 9.1 Broadcom finished the job: Log Management is now a containerized core service running natively inside the VCF Management Services Platform, and the whole experience, from deployment lifecycle to access control to alerting, sits inside VCF Operations.
Practically, that means in a current VCF-licensed environment you do not deploy a separate Log Insight appliance and bolt it on. You activate Operations-Logs from Fleet Management under VCF Management, and it comes up as part of the platform. On a vSphere Foundation license the story is different: there you still deploy the VCF Operations for Logs virtual appliance through vSphere. Knowing which of those two paths you are on changes almost every answer about scaling and lifecycle.
Which version are you actually on?
Before you quote anyone a capability, check the build. A 9.0 environment still treats the logs platform as a separate tier under the converged UI, so some lifecycle steps land in a different place than the docs for 9.1 describe. On 9.1 the service is containerized and managed as part of the platform, and content that assumed a standalone appliance no longer maps cleanly. I have watched two engineers argue for ten minutes because one was reading 9.0 behavior and the other 9.1. Confirm the version first, then talk.
The other thing to settle early is content packs versus management packs. Content packs, the old bundles of dashboards and queries, still load in 9.0 for backward compatibility. They are on the way out. If you are building anything new, build it as a management pack so you are not migrating it next year.
Getting logs in without drowning the index
Ingestion is boring until it is not. Sources push events in over two families of channel: plain syslog, and the ingestion API. The table below is the one I paste into runbooks, because every wrong-port ticket traces back to someone guessing. Note the two operational numbers at the bottom, because they matter more than the ports: search is available within seconds, and deletion is first-in-first-out once the index disk crosses 97 percent.
| Channel | Port and protocol | Use it for |
|---|---|---|
| Syslog | 514/UDP | Lossy but simple, fine for chatty low-value sources |
| Syslog | 514/TCP | Reliable delivery for infrastructure sources |
| Syslog SSL | 1514/TCP | Encrypted transport where policy requires it |
| Ingestion API | 9000/TCP | Agents and app feeds with structured fields |
| Ingestion API SSL | 9543/TCP | Encrypted agent and app feeds |
| Search availability | ~ seconds | Events queryable almost as soon as they land |
| FIFO deletion | 97% disk | Oldest data dropped first, set retention before this bites |
The lifecycle behind those numbers is worth knowing. An event is generated on a device, collected by an agent or written directly over syslog or the API, received and routed to a node by the integrated load balancer, then processed: a keyword index is built, machine learning clusters similar events, and the raw event is stored compressed. From there it is searchable in seconds and later archived or deleted by retention. The 97 percent line is the part people forget, so I plot my index headroom against it and keep an eye on the trend.
Filter and mask before it costs you
Here is where I disagree with common advice. The usual line is forward everything, you never know what you will need. In practice everything-at-info floods the index, drives you toward the 97 percent cliff faster, and buries the twenty events that matter under a million that do not. I filter aggressively at ingest and mask sensitive fields before they are indexed. Guest OS info-level chatter is the first thing I drop. If a source has never once helped an investigation, it is a candidate for filtering, not archiving.
Retention is the other half. Index partitions let you set different retention per source class, so audit-relevant firewall logs live for the window compliance needs while noisy debug feeds roll off in days. Set that up on day one. The default, if you set nothing, is that the oldest data leaves when the disk fills, and it will not ask first.
From alert to log in one move
The payoff of having logs inside VCF Operations is that the pivot is short. A log-based alert fires, you open Explore Logs on that query, you filter to the source and the minute, and you read what happened. Runtime field extraction pulls structured fields out of raw lines with a regex, and the one-click extract saves you from writing that regex by hand for common patterns. Save the query, pin the chart to a dashboard, and the next person who sees that alert lands on the same view instead of starting cold.
Explore Logs is the workspace. You search by timestamp, text, source or extracted field, chart the result, and pin it. Package the alert, the query and the dashboard into a management pack and it travels between environments. That packaging is the difference between one clever engineer knowing the trick and the whole team having it.
Saved queries and field extraction in practice
Field extraction is where Explore Logs stops being a text search and becomes structured. Take the all-paths-down line from the incident below. A runtime extraction on the pattern that captures the device identifier, the naa token followed by its hex string, turns every matching line into a field I can group by. Now the 40 events sort by device and I can see they all point at one LUN rather than three, which tells me it is a single path problem and not a fabric-wide one. The one-click extract handles the common shapes so I am not writing regex under incident pressure. I save it as a named query, pin its chart, and the next storm of the same kind is a two-click investigation instead of a fresh dig.
Across more than one site, forwarders carry the load. A forwarder cluster at a remote site ships its logs to the main cluster, so a single Explore Logs view covers the whole fleet instead of one datacenter, and cross-forwarding mirrors two main clusters for redundancy. If you run VCF across sites, plan the forwarder topology alongside the same multi-site thinking you use for capacity and recovery, and revisit it when you upgrade, because the platform integration changed between 9.0 and 9.1. I walk through that jump in the VCF 9.1 upgrade series.
A worked example
At 14:30 a group of VMs on one cluster went slow. Metrics showed CPU ready on the group climbing to 9 percent, which looks like contention and tempts you to go hunting for a noisy neighbor. It was a symptom. I opened Explore Logs, filtered the source to the two affected hosts and set the window to 14:26 through 14:38. Error volume jumped from a baseline near 4 events per minute to 180 at 14:32, the exact point plotted above. Filtering that spike to storage events, I found 40 all-paths-down events on a single datastore across three minutes.
The CPU ready was VMs retrying I/O against a datastore that had lost its path, not a scheduling fight. Fix the path, the APD events stop, ready falls back to its baseline, and the whole thing reads as a five-minute diagnosis instead of an afternoon of chasing the wrong metric. The log did not tell me when. The metric did. The log told me why, and only the pairing solved it.
Common questions
Do I still deploy a separate Log Insight appliance?
On a VCF license, no. You activate Operations-Logs from Fleet Management under VCF Management and it comes up as part of the platform. On a vSphere Foundation license you do deploy the VCF Operations for Logs virtual appliance through vSphere. Check your license path before you plan the deployment.
Should I keep using content packs?
Only for what already exists. They still load in 9.0, but they are being phased out. Build anything new as a management pack so you are not migrating dashboards and alerts later.
Why are my old logs disappearing?
Almost always the 97 percent FIFO deletion. When the index disk fills, the oldest data goes first. If your retention window matters for audit, set index partitions with explicit retention rather than trusting the default.
UDP or TCP for syslog?
TCP on 514 for anything you care about, because UDP on 514 drops under load. Use 1514 for SSL where policy requires encryption, and the ingestion API on 9000 or 9543 for agents and structured app feeds.
When should I not bother with logs?
When the metric says contention and no component failed. An oversubscribed VM writes no error. Right-size it and move on rather than hunting for a log that was never written.
« Previous: Part 10 | VCF 9 Operations Complete Guide | Next: Part 12 »
References
- VCF 9.1 Infrastructure Operations: Overview of Log Management
- VCF 9.1 Infrastructure Operations: Configuring and Analyzing Logs
- VCF 9.0 Infrastructure Operations: Log Analysis
About The Author
DrJha