Documentation is no longer aligned with the code?

[martinr_ubi (Martin R.)]

Hi,

The goal is to follow proper procedure since I believe this is a doc bug and I would like to open an issue.

Heartbeat exported fields doc contain 3 notes saying the timers might not be what they seem to be:

Note: if validator is not reading body or only a prefix, this number does not fully represent the total time needed to read the body.

HTTP monitor fields | Heartbeat Reference [7.1] | Elastic

This was put there by urso in 2017.

Then on Nov 2018, it appear this "special case" was considered a bug in Heartbeat and fixed by Andrew_Cholakian1 in 6.6:

Read whole body on each request

The question is:
What is this note now talking about? (The one in the doc about the timer and validator...)

The meaning of the timers are becoming really important for me currently and the code and doc are now confusing me more so I'm digging

Unrelated but context never hurts:

• Heartbeat 6.7.2
• Elasticsearch 5.6.12 (yes, yes, I know but I had no choice and I'm upgrading soon. )
• Sample of a monitor:

- type: http
  name: alibabacloud_website_internet_https_global_notice
  # List or urls to query
  urls:
    - https://www.alibabacloud.com/notice
  check.request:
    method: GET
  check.response:
    status: 200
  ssl:
    verification_mode: none
  mode: any
  # Configure task schedule
  schedule: '@every 10s'
  # Total test connection and data exchange timeout
  timeout: 25s

[Andrew_Cholakian1 (Andrew Cholakian)]

Thanks for digging into this. We should remove that note, you are correct it is no longer accurate.

I have an open issue to fix / consolidate these fields here: https://github.com/elastic/beats/issues/11476

I haven't had the time to get to it however.

I've also been thinking about there being a better way of doing timing. We currently have a number of timers within the app that can overlap. Understanding the definitions can be confusing.

It may be easier to just have a start/end timer, with offset values in between for various events. In other words, mark events over a span rather than report a bunch of different durations.

WDYT @martinr_ubi?