Haproxy integration: failed fetching haproxy info: not supported

Elastic Stack Beats
1

Hi,

I'm looking at an issue with the haproxy integration. It came up after an update but in this case it might have already been broken before that.

the error message I see is:

elastic-pfsense-input  | {"log.level":"error","@timestamp":"2026-06-12T15:26:45.419Z","message":"Error fetching data for metricset haproxy.info: failed fetching haproxy info: not supported","component.id":"haproxy/metrics-default","component.type":"haproxy/metrics","component.binary":"metricbeat","component.dataset":"elastic_agent.metricbeat","log.source":"haproxy/metrics-default","log.origin":{"file.line":336,"file.name":"module/wrapper.go","function":"github.com/elastic/beats/v7/metricbeat/mb/module.(*metricSetWrapper).handleFetchError"},"service.name":"metricbeat","id":"haproxy/metrics-haproxy.info-f6a07b07-b1dc-45ca-a6b6-1f9153263ed2","ecs.version":"1.6.0","log.logger":"haproxy.info","ecs.version":"1.6.0"}

I have the stats front- and backend set up on the haproxy server and it works, see hre:

elf:/home/pfsense-main/pfsense-sync# curl "http://this-firewall:27370/stats;csv" | head
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
100  11# pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,check_status,check_code,check_duration,hrsp_1xx,hrsp_2xx,hrsp_3xx,hrsp_4xx,hrsp_5xx,hrsp_other,hanafail,req_rate,req_rate_max,req_tot,cli_abrt,srv_abrt,comp_in,comp_out,comp_byp,comp_rsp,lastsess,last_chk,last_agt,qtime,ctime,rtime,ttime,agent_status,agent_code,agent_duration,check_desc,agent_desc,check_rise,check_fall,check_health,agent_rise,agent_fall,agent_health,addr,cookie,mode,algo,conn_rate,conn_rate_max,conn_tot,intercepted,dcon,dses,wrew,connect,reuse,cache_lookups,cache_hits,srv_icur,src_ilim,qtime_max,ctime_max,rtime_max,ttime_max,eint,idle_conn_cur,safe_conn_cur,used_conn_cur,need_conn_est,uweight,agg_server_status,agg_server_check_status,agg_check_status,srid,sess_other,h1sess,h2sess,h3sess,req_other,h1req,h2req,h3req,proto,-,ssl_sess,ssl_reused_sess,ssl_failed_handshake,h2_headers_rcvd,h2_data_rcvd,h2_settings_rcvd,h2_rst_stream_rcvd,h2_goaway_rcvd,h2_detected_conn_protocol_errors,h2_detected_strm_protocol_errors,h2_rst_stream_resp,h2_goaway_resp,h2_open_connections,h2_backend_open_streams,h2_total_connections,h2_backend_total_streams,h1_open_connections,h1_open_streams,h1_total_connections,h1_total_streams,h1_bytes_in,h1_bytes_out,
HAProxyLocalStats,FRONTEND,,,0,0,10000,0,0,0,0,0,0,,,,,OPEN,,,,,,,,,1,2,0,,,,0,0,0,0,,,,0,0,0,0,0,0,,0,0,0,,,0,0,0,0,,,,,,,,,,,,,,,,,,,,,http,,0,0,0,0,0,0,0,,,0,0,,,,,,,0,,,,,,,,,,0,0,0,0,0,0,0,0,,-,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
HAProxyLocalStats,BACKEND,0,0,0,0,1000,0,0,0,0,0,,0,0,0,0,UP,0,0,0,,0,62997,,,1,2,0,,0,,1,0,,0,,,,0,0,0,0,0,0,,,,0,0,0,0,0,0,0,-1,,,0,0,0,0,,,,,,,,,,,,,,http,,,,,,,,0,0,0,0,0,,,0,0,0,0,0,,,,,0,0,0,0,,,,,,,,,,,-,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

note I'm accessing ;csv instead of /stats since the docs very clearly refer to the haproxy CSV output mode.

What I don't get is all the ambiguities / missing info in the docs.
If you look at the integration docs there's this sentence:

The Integration can collect metrics in two datastreams from HAProxy: info and stat. info is not available when using the stats page. For more information, refer to the HAProxy module.

The referenced beat documentation repeates that sentence but gives no explanation. the metricsets have no info besides their structured content.
we don't get to see what input is expected or used.

IMO this documentation can't be used by most people.
After a few rounds of testing and considering I'm now pretty certain that the info metricset is only collected by elastic agent on the OS of the system running haproxy. That is at least plausible and I just turn it off now.
At the same time the setup of the stats IP server on 127.0.0.1 is mildly unneccessary if one enables the Unix socket. So you also can't guess from that setup what the actual ideal or default scenario might be - whilst both docs speak of what's enabled by default.

The even worse part is that normally haproxy is deployed on some dedicated system, most likely not a COTS linux one - so there'll not be an elastic agent. at the same time, the metrics that I do see are the trivial stuff like CPU % and similar which one could in fact often still get via SNMP. So, to cut it short, documentation is not suited to purpose, should be clearer what the input data and sources for the metrics are and what deployment scenarios are expected.

2

Hi there!

I totally understand your frustration you've actually identified a legitimate
documentation gap that many users encounter with the HAProxy integration. Your
testing insights are spot-on.

Here's what's happening:

The HAProxy integration collects metrics from two datastreams: stat and info.
The stat stream works reliably via the CSV endpoint you're accessing, but the
info stream has a critical limitation that the docs don't clearly spell out:
it requires the Elastic Agent to be running on the same host as HAProxy
with OS-level access to collect that data.

In typical HAProxy deployments (dedicated appliances, Docker containers, etc.),
this simply isn't realistic. You're right to disable it.

For clarity on the expected setup:

My recommendation:
Use only the stat metricset for remote HAProxy monitoring it's the reliable
one for your use case. If you need OS-level metrics (CPU%, memory), integrate
SNMP or deploy a sidecar Elastic Agent on the HAProxy host specifically for
that purpose.

This would be solid feedback to post in the Elastic GitHub discussions if you
haven't already!

Cheers!