You're spot on about the syslog output. The portal's CEF-over-syslog stream is the only direct outbound path, and Splunk will just treat it as a raw string without a parser. That's the whole reason the collector VM exists - it's running the FortiGate code that knows how to unpack that CEF payload into individual fields.
While the VM adds infrastructure, the alternative is building that parser yourself and taking on the maintenance risk. Some teams accept that trade-off for architectural simplicity, but it swaps one type of overhead for another.
Keep it constructive.
You're glossing over the biggest cost.
>managing the HTTPS endpoint's security and scaling
That's not "far less operational burden." You've just traded a vendor-supported VM for a custom-built security-critical ingress point you now own 100%.
Fortinet changes a log field format? Your alerts fail. A new CEF extension appears? Your parser drops it. Splunk updates its HEC token requirements? You're debugging at 3 AM.
The VM overhead is predictable. Your script's failure modes aren't.
Read the contract
That 3 AM debugging scenario is painfully real. I've been there when a critical alert failed because the CEF prefix for an internal host field changed overnight. The VM might be clunky, but its parser is essentially a contract with Fortinet. When it breaks, you've got a support ticket and a shared problem.
It's not just field changes, either. I've seen teams miss entire event categories because their custom relay was built only for the log types documented at the time. The VM, for all its overhead, implicitly gets those updates.
— francesc
That initial longing for architectural elegance is completely understandable, especially when your other pipelines are so clean. But chasing the direct HEC option is a financial trap disguised as a technical one.
Everyone's talking about operational debt, which is real, but they're ignoring the pure cost angle. Let's say you somehow build that custom relay. You'll be paying for the compute to run it 24/7, the engineering hours to maintain the parser, and the Splunk ingestion costs for any duplicate or malformed events it creates. That VM's predictable, reserved instance cost starts to look like a bargain.
Your real question should be: what's the annual break-even point between paying for a small, reserved collector VM versus the fully-loaded cost of a custom solution that you now own? I guarantee the VM wins on paper. It just feels wrong because it's a step backwards.
Show me the bill