Issue #8: Added Linux Connector to Community repository

[alexdgilbert]

• Developed Linux Connector
• Added system.yaml for common grounds with other potential system connectors

[bertysentry]

We're getting there! 😉

[bertysentry]

These 3 metrics need to be merged into a single system.service.status metric.

The stateSet allows for several values of the stateSet to be 1:

• system.service.status{id="PatrolAgent",state="loaded"} 1
• system.service.status{id="PatrolAgent",state="not-found"} 0
• system.service.status{id="PatrolAgent",state="active"} 1
• system.service.status{id="PatrolAgent",state="inactive"} 0
• system.service.status{id="PatrolAgent",state="running"} 1
• system.service.status{id="PatrolAgent",state="dead"} 0
• system.service.status{id="PatrolAgent",state="exited"} 0

Now, considering that a service can be either loaded or not-found, we can drop the not-found state. Similarly, a service is either active or inactive, we can drop the inactive state. If a user wants to find inactive services, they just need to look for system.service.status{state="active"} == 0.

Conclusion: we should have 1 system.service.status metric with stateSet: [ loaded, active, running, dead, exited ].

[NassimBtk]

The stateSet allows for several values of the stateSet to be 1:

Currently it is a oneOf relationship.
If we map a key to a value, then the stateSet won't be able to do that unless we map values like loaded|active and enhance the engine to support it at the time of sending the metric to OTEL.

[NassimBtk]

Otherwise oneOf mapping can be achieved with
system.service.status: <unique_value>
Then additional state metrics can be mapped as follows:
system.service.status{state="active"}: <0 or 1>

[bertysentry]

Yeah @NassimBtk the second suggestion is a good workaround.

I think we still should implement the ability to map several values at once as you suggested loaded|active|running. But on the other hand, such string is quite difficult to produce and requires some string concatenations (say: concatenate $2, $3 and $4).

Another option would be to (optionally) define statesets directly in metrics: mapping, like in the example below:

# Metrics definition: we only define [running, dead, exited]
  system.service.status:
    description: Service Status
    type:
      stateSet:
      - running
      - dead
      - exited

# [...]
mapping:
  metrics:
    system.service.status{state="loaded|not-found"}: $2
    system.service.status{state="active|inactive"}: $3
    system.service.status: $4 # This stateset is already defined at the top

[bertysentry]

So I think for now we'll use @NassimBtk's workaround, which means:

1. Defining only states [running, dead, exited] for system.service.status
2. Translating $2 from [not-found, loaded] to [0, 1]
3. Translating $3 from [inactive, active] to [0, 1], and then:

mapping:
  metrics:
    system.service.status{state="loaded"}: $2
    system.service.status{state="active"}: $3
    system.service.status: $4