[process-agent] Refactor status build and add it to core agent

[mbotarro]

What does this PR do?

Currently process-agent exposes an agent/status endpoint that is used only to fetch the core status from the main pkg/status library. It's up to the ./process-agent status process to fetch the core status, fetch the expvars, build the final status and render the status template.

This PR refactors this architecture to encapsulate the status build inside /agent/status. By doing so, ./process-agent status needs only to call the endpoint and render the status template. It also makes it easier to reuse the same endpoint in the core agent to include process-agent in its status output.

This PR introduces the following main changes:

• Move status build logic to a dedicated pkg/process/util/status.go file
• cmd/process-agent/api uses the GetStatus build function from pkg/process/util
• cmd/process-agent/app fetches the status from the process-agent API server
• core agent fetches the process-agent status from the process-agent API server
• Move process-agent status template to pkg/status so it can be used by both core and process agents.

Motivation

Add status command to process-agent and improve agent flare.

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

The following tests need to be performed on a linux host, docker, k8s cluster, windows and macOS.

Set the following settings on the datadog.yaml file

process_config:
  enabled: "disabled"
  process_discovery:
    enabled: false

Run

./agent status

and

./process-agent status

Make sure that the output contains a message saying that the process-agent is not running or is unreachable.

Update datadog.yaml to enable the process-agent

process_config:
  enabled: "true"
#  process_discovery:
#    enabled: false

Re-run

./agent status

and

./process-agent status

Make sure that we're showing relevant and correct runtime information for process-agent.

Reviewer's Checklist

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• The appropriate team/.. label has been applied, if known.
• Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
• A release note has been added or the changelog/no-changelog label has been applied.
• Changed code has automated tests for its functionality.
• Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
• If applicable, docs team has been notified or an issue has been opened on the documentation repo.
• If applicable, the need-change/operator and need-change/helm labels have been applied.
• If applicable, the config template has been updated.

[just-chillin]

Looks great! I love the changes you made

[just-chillin]

Do we know that the path for this will still be valid after we build and install the agent?

[mbotarro]

Other agents are using this same pattern to render the status template e.g. security-agent:

datadog-agent/pkg/status/render.go

Line 134 in 105db35

renderStatusTemplate(b, "/header.tmpl", stats)

Since the files are located in the templates folder in the status package, I believe that they're compiled with the agent so they're always available.

[xornivore]

Great work! 🔥

[just-chillin]

This looks great! 🔥

[djmitche]

Looks good from agent-core :)