[vSphere] grok patter issue

[stefans-elastic]

There are log entry formats that are failed to parse with grok patterns.
Example of such logs:

<166>1 2024-09-18T21:30:05.155Z esxihost01 Hostd: info vsansystem[21254123] [vSAN@1234 sub=AccessChecker opId=011a11e2-7123] SSL thumbprint logged in as VMware-client/6.5.0

<110>1 2025-09-10T01:01:25.113Z PC-ESXI-VSAN-P01 envoy 21004234 - [proxy.disconnect@2345 key2=\"\\\"CP\\\"\" subject=\"\" ip=\"127.0.0.1\" priority=\"info\" vmw_vcenter=\"prod-vc02.sphere.com\" vmw_vcenter_id=\"550e8400-e29b-41d4-a716-446655440000\" vmw_vr_ops_id=\"b5cb8b7e-f1d8-4191-a5fe-391af4d592c3\" result=\"success\" vmw_cluster=\"PROD-VM01\" vmw_datacenter=\"TestCenter\" vmw_object_id=\"host-112233\" port=\"45296\" facility=\"13\" object=\"proxy\"]

<134>1 2025-09-10T15:43:11.026Z prod-vc01 vpxd-main - - [Originator@6884 key2=\"\\\"CP\\\"\" vmw_cluster=\"PROD-P01\" vmw_datacenter=\"TestCenter\" vmw_object_id=\"vm-112233\" vmw_host=\"esxi-p01.sphere.com\" priority=\"info\" vmw_vcenter=\"prod-vc01.sphere.com\" vmw_vcenter_id=\"550e8400-e29b-41d4-a716-446655440000\" facility=\"local1\" vmw_vr_ops_id=\"b5cb8b7e-f1d8-4191-a5fe-391af4d592c3\"] 2025-09-10T03:34:13.023+08:00 info vpxd[07317] [Originator@6875 sub=vpxLri opID=6598c432] [VpxLRO] -- FINISH lri-111222333

<166>1 2025-09-10T12:15:33.834Z PC-ESXI-HCI-P01.sphere.com envoy-access 2188123 [Originator@6534 key2=\"\\\"CP\\\"\" vmw_cluster=\"PROD-VM01\" vmw_datacenter=\"TestCenter\" vmw_object_id=\"host-007\" priority=\"info\" vmw_vcenter=\"prod-vc02.sphere.com\" vmw_vcenter_id=\"550e8400-e29b-41d4-a716-446655440000\" facility=\"local1\" vmw_vr_ops_id=\"b5cb8b7e-f1d8-4191-a5fe-391af4d592c3\"] POST /sdk 200 via_upstream - 452 256 gzip 0 0 0 127.0.0.1:60792 HTTP/1.1 TLSv1.2 127.0.0.1:443 127.0.0.1:57833 HTTP/1.1 - 127.0.0.1:8307 - \"QueryNetworkHint\"

Error produced by the integration:
Provided Grok expressions do not match field value: ...

In my analysis I've found out that adding this pattern: <%{NONNEGINT:log.syslog.priority:long}>%{INT} %{TIMESTAMP_ISO8601:_tmp.timestamp}%{SPACE}%{HOST}%{SPACE}%{NOTSPACE:process.name}%{SPACE}(%{POSINT:process.pid:long}|-)( -)( -)?%{SPACE}%{GREEDYDATA:message} in ingest pipeline should resolve the problem.