Update EDR_telem_linux.json - Uptycs Service Telemetry

[joshlemon]

EDR Telemetry Pull Request

Contribution Details

Telemetry Validation

Run the following search in Uptycs for systemd_units:

select
  upt_time,
  id,
  description,
  load_state,
  active_state,
  sub_state,
  object_path,
  unit_file_state
from
  systemd_units
where
  upt_day = 20251118
  and upt_hostname = 'hostname'
  and id like '%test_telemetry_service%'
order by
  upt_time ASC

The above search produces the following output in Uptycs systemd_units telemetry:

Documentation or Evidence:

• Official documentation (link: )
• Screenshots attached
• Sanitized logs provided
• Private documentation (will share confidentially)

Type of Contribution

• Adding telemetry information for an existing EDR product
• Adding a new EDR product that meets eligibility criteria
• Proposing new event categories/sub-categories
• Documentation improvement
• Tool enhancement

Validation Details

EDR Product Information

• EDR Product Name: Uptycs
• EDR Version: N/A
• Operating System(s) Tested: Linux

Testing Methodology

Running the provided Linux Telemetry script on a Linux host and reviewing data in the Uptycs platform.

Additional Notes

[joshlemon]

Hey @tsale, just flagging this one again, it should be a fairly quick review.

[tsale]

Thanks for the submission and for taking the time to share the evidence.

After reviewing this, I’m leaning toward not accepting the PR in its current form. What’s being shown here is an interpretation of service state (for example, inferring lifecycle changes from systemd unit data), rather than explicit telemetry events generated at the time a service is created, modified, or deleted.

For these categories, I’m specifically looking for first-class, event-based telemetry that records the action itself with clear semantics and timestamps tied to the operation. Deriving lifecycle activity from inventory or state data, even if the interpretation is reasonable, does not meet that bar.

If you’re able to provide evidence of explicit service lifecycle events rather than inferred behavior, I’m happy to revisit this.

[joshlemon]

Thanks @tsale .

You can also get this data via the dbus_events.

select
  upt_time,
  upt_hostname,
  dbus_path,
  interface,
  member,
  type,
  sender,
  pid,
  Exe_name,
  cmdline,
  ancestor_list
from
  dbus_events
where
  upt_day = 20251113
  and upt_hostname = 'HOSTNAME'
  AND upt_time BETWEEN TIMESTAMP '2025-11-13 09:05:00' AND TIMESTAMP  '2025-11-13 09:10:00'
  AND cmdline = 'python3 lnx_telem_gen.py ServiceManagement'
  order by
    upt_time DESC

Which provides this type of output.

[tsale]

Thanks for sharing the screenshot.

Even in this example, what’s visible is the command line execution, not an explicit telemetry event representing the service creation, modification, or deletion itself. The conclusion about the service lifecycle is still inferred rather than recorded as a first-class event.

Since this does not meet the requirement for explicit service lifecycle telemetry, I’ll be closing this PR for now. Feel free to re-open it in the futur.