introducing: log.type #3469
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| # Use this changelog template to create an entry for release notes. | ||
| # | ||
| # If your change doesn't affect end users you should instead start | ||
| # your pull request title with [chore] or use the "Skip Changelog" label. | ||
|
|
||
| # One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
| change_type: enhancement | ||
|
|
||
| # The name of the area of concern in the attributes-registry, (e.g. http, cloud, db) | ||
| component: log | ||
|
|
||
| # A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
| note: "Introduce `log.type` attribute to classify log entries by type." | ||
|
|
||
| # Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists. | ||
| # The values here must be integers. | ||
| issues: [ 3429 ] | ||
|
|
||
| # (Optional) One or more lines of additional information to render under the primary note. | ||
| # These lines will be padded with 2 spaces and then inserted directly into the document. | ||
| # Use pipe (|) for multiline entries. | ||
| subtext: |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| name: sync-fork | ||
| on: | ||
| schedule: | ||
| - cron: '4 2 * * 4,2' | ||
| workflow_dispatch: | ||
| jobs: | ||
| sync-fork: | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: write | ||
| steps: | ||
| - run: gh repo sync $REPOSITORY -b $BRANCH_NAME | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.SYNC_FORK_TOKEN }} | ||
| REPOSITORY: ${{ github.repository }} | ||
| BRANCH_NAME: ${{ github.ref_name }} |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -43,12 +43,22 @@ These attributes may be used for identifying a Log Record. | |
| | --- | --- | --- | --- | --- | --- | | ||
| | [`log.record.original`](/docs/registry/attributes/log.md) |  | `Opt-In` | string | The complete original Log Record. [1] | `77 <86>1 2015-08-06T21:58:59.694Z 192.168.2.133 inactive - - - Something happened`; `[INFO] 8/3/24 12:34:56 Something happened` | | ||
| | [`log.record.uid`](/docs/registry/attributes/log.md) |  | `Opt-In` | string | A unique identifier for the Log Record. [2] | `01ARZ3NDEKTSV4RRFFQ69G5FAV` | | ||
| | [`log.type`](/docs/registry/attributes/log.md) |  | `Opt-In` | string | The type or category of the log record. See below for a list of well-known values. | `audit`; `app` | | ||
|
|
||
| **[1] `log.record.original`:** This value MAY be added when processing a Log Record which was originally transmitted as a string or equivalent data type AND the Body field of the Log Record does not contain the same value. (e.g. a syslog or a log record read from a file.) | ||
|
|
||
| **[2] `log.record.uid`:** If an id is provided, other log records with the same id will be considered duplicates and can be removed safely. This means, that two distinguishable log records MUST have different values. | ||
| The id MAY be an [Universally Unique Lexicographically Sortable Identifier (ULID)](https://github.com/ulid/spec), but other identifiers (e.g. UUID) may be used as needed. | ||
|
|
||
| --- | ||
|
|
||
| `log.type` has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used. | ||
|
|
||
| | Value | Description | Stability | | ||
| | --- | --- | --- | | ||
| | `app` | Default regular application log - everything which is NOT audit relevant |  | | ||
| | `audit` | Audit log recording security-relevant activities for compliance and forensics. When log.type='audit', the log record MUST not get lost and body not changed. |  | | ||
|
Contributor
There was a problem hiding this comment. Do you have a prototype of this in practice? I'm nervous that since this is so low in the hierarchy, otel will naturally batch data by resource/scope and that means audit logs and regular logs are all mixed together. Should we try to make sure we batch/send this data in a separate channel or some how do not automatically bundle app + audit logs in the same channel?
Author
There was a problem hiding this comment.
Not yet. If you could point me to an example of what you would expect, I can try to create a prototype accordingly.
Yes, unfortunately that’s correct.
That would actually be great! My impression so far, however, is that introducing a new channel might be considered a rather large request and likely won't get accepted by the OTel code owners. Their last responses were along the lines of: "We have no time/interest to work on audit logging and are currently focusing solely on stabilization." Given that audit logging is not currently on the roadmap, I'm investigating other mechanisms to clearly differentiate between non-essential and security-relevant log messages.
Contributor
There was a problem hiding this comment.
How would we enforce this? Should this be a spec change?
Author
There was a problem hiding this comment.
I've updated the wording as you suggested. Nevertheless, the intention is indeed to implement some of the consequences you have in mind within the otel-collector itself — potentially as a dedicated We're also evaluating whether we can add certain integrity‑validation mechanisms, so that audit logs can be verified downstream without requiring the collector to enforce immutability strictly. |
||
|
|
||
| <!-- prettier-ignore-end --> | ||
| <!-- END AUTOGENERATED TEXT --> | ||
| <!-- endsemconv --> | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.