-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initial version of logging feature request #206
base: main
Are you sure you want to change the base?
Conversation
30e0936
to
3d6a578
Compare
We will try to bring our comments #68 (comment) here.. |
Logging has to support the following features: | ||
- Timestamping | ||
- Log/serverity levels | ||
- Log priorisation in case of ressource conflicts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let us detail out what the actual use case is. When will prioritization be needed. What kind of resource conflicts are considered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
later clarification
Log Sources | ||
----------- | ||
|
||
- raw sensor data e.g. video streams |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With something as large as a video stream - is this really logging, or rather data recording? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
E.g. how does this match line 86:
Logs shall appear on stdout when running unit tests
I rather agree with a definition of logging as small status messages from running applications, which can be shown on stdout or sent to another sink. But raw sensor data sounds rather like data recording to me than logging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion "- raw sensor data e.g. video streams" belongs to replay.
source https://eclipse-score.github.io/score/requirements/stakeholder/index.html#STKH_REQ__290
STKH correction needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
STKH will be corrected (split in two)
- Runtime ressources | ||
- Low impact on overall performance ---> QoS for handling overflows/dropping log messages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, in a language like Rust, logging messages should be possible without allocations for individual logs.
Using the defacto standard log
crate as facade, implementors of this facade should not allocate to write / forward log messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design decision for detailed design => copy there
------- | ||
|
||
- Supported operating system: QNX, Linux (encapsulation via OSAL) | ||
- Supported programming languages: C++, Rust, Python (e.g. for tests) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For Rust, we would like to be able to use the log crate. It provides an (allocation-free) facade without forcing a specific logger implementation. Advantages of using this facade:
- We stay with language best-practices.
- New contributors directly feel at home with the logging.
- Any library dependency which we might use probably logs against this facade. So we would get logs of dependencies for free by using it as well and implementing a logger for the facade.
There might be comparable defacto standards for C++ and Python.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design decision for detailed design => copy there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Python comes with logging out of the box and the concepts are similar to Rust, where you can add custom 'handlers'.
C++ doesn't really have such a standardized interface. There are libraries like log4cplus or spdlog or even boost logging which are all more or less common. But nothing as standardized as with the other two.
Thank you for the suggestion @arsibo ! In general, I can recommend this typo checked which works incredibly fast even on large codebases (and also typo-checks variable names etc.): https://github.com/crate-ci/typos?tab=readme-ov-file#typos
|
|
||
Norms/Standards | ||
--------------- | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Standardized protocol specified in AUTOSAR Classic Platform for Diagnostic Log and Trace (DLT): https://www.autosar.org/fileadmin/standards/R19-11/CP/AUTOSAR_SWS_DiagnosticLogAndTrace.pdf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- check for IP
- compatibility to DLT has to be add
- Log priorisation in case of ressource conflicts | ||
- logging of early startup envents | ||
- log filtering | ||
- message loss detection |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Message loss detection use cases:
- discarded log messages in case of internal buffer full
- lost messages detection based on global message counter (e.g.
MCNT
from DLT protocol)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hint: prio logic needs to define late
- logging of early startup envents | ||
- log filtering | ||
- message loss detection | ||
- Component specific log level activation ??? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Component specific log level activation ??? | |
- Entity specific configuration (at build time / at startup / at runtime), e.g., change the entity specific log level at runtime |
- raw sensor data e.g. video streams | ||
- user application | ||
- component features & platform | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Log Sources (additional)
- Networking (e.g., CAN, DBUS, MOST, IPC)
- Files (e.g., crash reports)
- Processes
- different types of system traces (depending on the OS) which need to be routed as standardized log messages (e.g., traces from the Bootloader, from the Kernel, from the native logger of the Operating System, from
stdin
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- covert by using of logging APIs in Application Layer and MW Layer applications.
- record in-/out-put states of an application belongs to recompute/replay
- not scope of logging
- log collection is not part of basis logging system
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- File logging means a feature like https://github.com/COVESA/dlt-daemon/blob/master/doc/dlt_filetransfer.md
- Logging FR can be extended later by that sub feature (additional feature request)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed in the workshop today:
[the logs from] the Kernel, from the native logger of the Operating System
can be provided via the interfaces specified here in 0.5 by implemeting a bridge that is reading the sys level logs on the one side and writing them into score on the other side.
It does not have to be part of the specification for 0.5.
- Storage size | ||
- Permission settings | ||
- log filter | ||
- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Configuration (additional)
- Logging entity ID (e.g., ECU ID, Application ID, Context ID such as in DLT)
- Log storage device
- Log storage strategy (e.g., on system shutdown, on each message, on demand, on file size, on cache size, with circular or linear buffer)
- On-demand functionality (e.g., enable / disable the log storage)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
take over
------- | ||
|
||
- Supported operating system: QNX, Linux (encapsulation via OSAL) | ||
- Supported programming languages: C++, Rust, Python (e.g. for tests) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Context (additional)
- Supported shell scripting (depending on OS)
- Supported documentation tools (e.g., Doxygen, Confluence)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+plantuml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not in scope of logging. belongs to Process / Docu / Tools
.. note:: | ||
A Feature Request shall specify the stakeholder requirements as part of our platform/project. | ||
Thereby the :need:`RL_technical_lead` will approve these requirements as part of accepting the Feature Request (e.g. merging the PR with the Feature Request). | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tracing Features needs
System tracing
Capture different types of system traces, parse and convert them if needed, and route them as standardized messages.
Types of system traces:
- from Bootloader
- from Kernel
- from the native logger of the Operating System
- from the virtualization solution in case of virtualized system
- from stdin.
Multi Node tracing
- Capture traces from different passive nodes (ECUs/Partitions running on different Operating Systems and possibly w/o physical external connections) and route them as standardized messages to a common central tracing output of a gateway node (with physical external connection).
- Control the passive nodes tracing from the central gateway node.
Exception handling support
- Enable and capture OS native core/crash dumps,
- extract relevant info for debugging purpose,
- collect additional system info,
- create crash report archive,
- persistently store the crash report or transfer it as standardized messages on PC side for offline analysis or for integration into development toolchain
.. document:: Logging | ||
:id: DOC_Logging | ||
:status: draft | ||
:safety: ASIL_D |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FFI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Safety: ASIL_B
- Log/serverity levels | ||
- Log priorisation in case of ressource conflicts | ||
- logging of early startup envents | ||
- log filtering |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Log filtering at Source and Sink
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to specify in details.
Maybe filtering at source & sinks reasons
- scope of interest
- Resource consumption shall be taken into account
- e.g. Bandwith, Processor load
- Supported operating system: QNX, Linux (encapsulation via OSAL) | ||
- Supported programming languages: C++, Rust, Python (e.g. for tests) | ||
|
||
Ressource consumtion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Performance measurements and benchmark tests
|
||
- The interface should support the ASIL level of the user function. | ||
- Dependent on the Safety concept of the over all system, the logging should be classified accordingly. | ||
That could be the case if the logging informations are part of the verification strategy.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Include Assumptions of Use
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussion with safety expert needed
Tracing | ||
------- | ||
|
||
Example - User need to correlate kernel traces to user traces for debugging , analysing etc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-verbose logging
- Motivation is efficient Bandwidth usage
- Really trace out raw structs and efficiently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discuss next week
The created documentation from the pull request is available at: docu-html |
4 similar comments
The created documentation from the pull request is available at: docu-html |
The created documentation from the pull request is available at: docu-html |
The created documentation from the pull request is available at: docu-html |
The created documentation from the pull request is available at: docu-html |
e55a956
to
382de3c
Compare
The created documentation from the pull request is available at: docu-html |
Abstract | ||
======== | ||
|
||
This feature request proposes the development of a safe, efficient and robust logging framework for embedded systems. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we general enough that 'embedded system' applies here, or do we just focus on score?
- This feature request proposes the development of a safe, efficient and robust logging framework for embedded systems.
+ This feature request proposes the development of a safe, efficient and robust logging framework within score.
|
||
- message loss detection | ||
|
||
- optional functionality for logging. Important for tracing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am really not sure, if it is a good idea to have message loss detection only optional for logging. How trustworthy is a log that has for example only every second message in it? Or misses like 10 messages inbetween without a notice. And me, as a log consumer, I have no clue about it? I think this is the complete log.
|
||
- user application | ||
- component features & platform | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about
- early startup
as a log source also? We did mention it in the Functionality section.
- File system | ||
|
||
- local | ||
- external mounted PCIe Drive |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd not be specific to 'PCIe' here. Also drive is maybe not the right term?
- external mounted PCIe Drive | |
- external mounted storage |
|
||
- local | ||
- external mounted PCIe Drive | ||
- Cloud native drive via network |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Cloud native drive via network | |
- cloud storage via network |
|
||
- Buffer size | ||
- Storage size (e.g. storage size of log files) | ||
- Permission settings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We did not mention 'permission' until here.
What is meant by permission? If we want to have permissions, should we add it to the functionality section as well then?
------- | ||
|
||
- Supported operating system: QNX, Linux (encapsulation via OSAL) | ||
- Supported programming languages: C++, Rust, Python (e.g. for tests) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think C is a score supported language also. Should we have it also on our radar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kinda relates to https://github.com/eclipse-score/score/pull/206/files#r1952715564 as it probably would be convenient to have a logging interface that works with c++ and c or is at least similar
================= | ||
|
||
How to Use: Logging Guideline | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
============================= |
.. | ||
# ******************************************************************************* | ||
# Copyright (c) 2024 Contributors to the Eclipse Foundation | ||
# | ||
# See the NOTICE file(s) distributed with this work for additional | ||
# information regarding copyright ownership. | ||
# | ||
# This program and the accompanying materials are made available under the | ||
# terms of the Apache License Version 2.0 which is available at | ||
# https://www.apache.org/licenses/LICENSE-2.0 | ||
# | ||
# SPDX-License-Identifier: Apache-2.0 | ||
# ******************************************************************************* | ||
|
||
This document includes the detailed design findings from the feature request review. | ||
|
||
Logging | ||
####### | ||
|
||
Specification | ||
============= | ||
Context | ||
------- | ||
.. related feature from feature request | ||
- Supported programming languages: C++, Rust, Python (e.g. for tests) | ||
|
||
.. detailed design finding | ||
For Rust, we would like to be able to use the log crate. It provides an (allocation-free) facade without forcing a specific logger implementation. Advantages of using this facade: | ||
|
||
We stay with language best-practices. | ||
New contributors directly feel at home with the logging. | ||
Any library dependency which we might use probably logs against this facade. So we would get logs of dependencies for free by using it as well and implementing a logger for the facade. | ||
There might be comparable defacto standards for C++ and Python. | ||
|
||
|
||
Resource consumption | ||
-------------------- | ||
.. related feature from feature request | ||
- Runtime ressources | ||
- Low impact on overall performance ---> QoS for handling overflows/dropping log messages | ||
|
||
.. detailed design finding | ||
Ideally, in a language like Rust, logging messages should be possible without allocations for individual logs. | ||
Using the defacto standard log crate as facade, implementors of this facade should not allocate to write / forward log messages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of this file? It does not seem to be referenced from somewhere.
####### | ||
|
||
.. document:: Tracing | ||
:id: DOC__Your_Feature_Name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:id: DOC__Your_Feature_Name | |
:id: DOC_Tracing |
Feature Request: Logging
- squash of review finding commits to fix Gitlint checks Update docs/features/analysis-infra/logging/mw-fr_logging.rst Co-authored-by: Philipp Ahmann <[email protected]> Signed-off-by: arsibo <[email protected]> Update docs/features/analysis-infra/logging/mw-fr_logging.rst Co-authored-by: Philipp Ahmann <[email protected]> Signed-off-by: arsibo <[email protected]> Update docs/features/analysis-infra/logging/mw-fr_logging.rst Co-authored-by: Philipp Ahmann <[email protected]> Signed-off-by: arsibo <[email protected]> Update docs/features/analysis-infra/logging/mw-fr_logging.rst Co-authored-by: Paula Grosu <[email protected]> Signed-off-by: arsibo <[email protected]> Update docs/features/analysis-infra/logging/mw-fr_logging.rst Co-authored-by: Paula Grosu <[email protected]> Signed-off-by: arsibo <[email protected]> Update docs/features/analysis-infra/logging/mw-fr_logging.rst Co-authored-by: simon-acc <[email protected]> Signed-off-by: arsibo <[email protected]> Update docs/features/analysis-infra/logging/mw-fr_logging.rst Co-authored-by: simon-acc <[email protected]> Signed-off-by: arsibo <[email protected]> Update docs/features/analysis-infra/logging/mw-fr_logging.rst Co-authored-by: simon-acc <[email protected]> Signed-off-by: arsibo <[email protected]>
- merge review finding in logging FR - add detailed design findings to an additional file (mw-fr_logging_DD_inputs.rst
382de3c
to
62b6801
Compare
The created documentation from the pull request is available at: docu-html |
initial version of feature request #68