feat(logging)_: enable runtime logs configuration #6210
Conversation
Jenkins BuildsClick to see older builds (24)
|
|
Functional test results: Running pytest with args: ['-p', 'vscode_pytest', '--status_backend_urls=http://localhost:42995', '--rootdir=/path/to/status-go/tests-functional', '/path/to/status-go/tests-functional/tests/test_logging.py::TestLogging::test_logging']
============================= test session starts ==============================
platform linux -- Python 3.11.9, pytest-6.2.4, py-1.11.0, pluggy-0.13.1 -- /bin/python
cachedir: .pytest_cache
rootdir: /path/to/status-go/tests-functional, configfile: pytest.ini
plugins: dependency-0.6.0
collecting ... collected 1 item
tests/test_logging.py::TestLogging::test_logging
-------------------------------- live log call ---------------------------------
INFO root:status_backend.py:39 Sending POST request to url http://localhost:42995/statusgo/InitializeApplication with data: {
"apiLogging": true,
"dataDir": "/tmp/pytest-of-myself/pytest-85/test_logging0",
"logEnabled": true,
"logLevel": "DEBUG"
}
INFO root:signals.py:121 Connection opened
WARNING websocket:_logging.py:66 websocket connected
INFO root:status_backend.py:41 Got response: b'{"accounts":null,"centralizedMetricsInfo":{"enabled":false,"userConfirmed":false}}'
INFO root:status_backend.py:47 Got response: b'{"accounts":null,"centralizedMetricsInfo":{"enabled":false,"userConfirmed":false}}'
INFO root:status_backend.py:39 Sending POST request to url http://localhost:42995/statusgo/CreateAccountAndLogin with data: {
"customizationColor": "primary",
"displayName": "Mr_Meeseeks",
"kdfIterations": 256000,
"logEnabled": true,
"logLevel": "DEBUG",
"password": "Strong12345",
"rootDataDir": "/tmp/pytest-of-myself/pytest-85/test_logging0"
}
INFO root:status_backend.py:41 Got response: b'{"error":""}'
INFO root:status_backend.py:47 Got response: b'{"error":""}'
INFO root:status_backend.py:39 Sending POST request to url http://localhost:42995/statusgo/SetLogLevel with data: {
"logLevel": "ERROR"
}
INFO root:status_backend.py:41 Got response: b'{"error":""}'
INFO root:status_backend.py:47 Got response: b'{"error":""}'
INFO root:status_backend.py:39 Sending POST request to url http://localhost:42995/statusgo/SetLogNamespaces with data: {
"logNamespaces": "test1.test2:debug,test1.test2.test3:info"
}
INFO root:status_backend.py:41 Got response: b'{"error":""}'
INFO root:status_backend.py:47 Got response: b'{"error":""}'
INFO root:rpc.py:54 Sending POST request to url http://localhost:42995/statusgo/CallRPC with data: {
"id": null,
"jsonrpc": "2.0",
"method": "wakuext_logTest"
}
INFO root:rpc.py:58 Got response: {
"id": null,
"jsonrpc": "2.0",
"result": null
}
INFO root:status_backend.py:39 Sending POST request to url http://localhost:42995/statusgo/Logout with data: {}
INFO root:status_backend.py:41 Got response: b'{"error":""}'
INFO root:status_backend.py:47 Got response: b'{"error":""}'
INFO root:status_backend.py:39 Sending POST request to url http://localhost:42995/statusgo/LoginAccount with data: {
"kdfIterations": 256000,
"keyUid": "0x42d81d7344e88629b9bf94536a732680683a8a0f42d1422cf8f24a0b5699bdb7",
"password": "Strong12345"
}
INFO root:status_backend.py:41 Got response: b'{"error":""}'
INFO root:status_backend.py:47 Got response: b'{"error":""}'
INFO root:rpc.py:54 Sending POST request to url http://localhost:42995/statusgo/CallRPC with data: {
"id": null,
"jsonrpc": "2.0",
"method": "wakuext_logTest"
}
INFO root:rpc.py:58 Got response: {
"id": null,
"jsonrpc": "2.0",
"result": null
}
PASSED
============================== 1 passed in 12.55s ==============================
Finished running tests!
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #6210 +/- ##
===========================================
- Coverage 53.25% 53.19% -0.07%
===========================================
Files 834 834
Lines 134104 134153 +49
===========================================
- Hits 71413 71358 -55
- Misses 54816 54901 +85
- Partials 7875 7894 +19
Flags with carried forward coverage won't be shown. Click here to find out more.
|
osmaczko
force-pushed
the
chore/setup-logging-at-runtime
branch
3 times, most recently
from
ee0feaa to
a46fe30
Compare
| return logutils.OverrideRootLoggerWithConfig(b.config.LogSettings()) | ||
| } | ||
|
|
||
| func (b *GethStatusBackend) SetLogNamespaces(namespaces string) error { |
There was a problem hiding this comment.
@osmaczko is there a reason to not expose a data structure based API to clients instead of the string based approach like in test1.test2:debug,test1.test2.test3:info?
There was a problem hiding this comment.
That's a great question. I don't believe having a data structure-based API in this case is feasible, as there are numerous namespaces, sub-namespaces, sub-sub-namespaces, and so on. Moreover, there is no single entity that can know all the registered namespaces. I attempted to address this but eventually stopped, as it would have required significant effort. I want developers (this utility is intended for developers) to have the freedom to configure namespaces however they see fit. I can imagine a developer adjusting namespace settings ad hoc to suit their needs for a specific task or during bug investigations.
As for the Waku debug toggle, I understand it is not ideal, as both clients would need to know the exact namespace. Maybe for that case, SetWakuLogLevel could be introduced as a helper, so the knowledge of the namespace is hidden in status-go?
There was a problem hiding this comment.
Ah okay @osmaczko, you considered this option already 👍🏼
In any case, I was imagining something simple and easy to serialize, example payload:
{
"logNamespaces": [
{"name": "test1.test2", "level": "debug"},
{"name": "test1.test2.test3", "level": "info"}
]
}Maybe the convenience of using a string vs a data structure is related to the programming language in question? The string approach requires more knowledge about how namespaces are used internally. For example, the dev should know the namespaces are splittable by a comma and that the log level should be separated by a colon. The log level type is a bit more opaque and the dev may need to manually find the regex that validates it deeper down in logutils.
Nothing too important, thanks for considering it.
There was a problem hiding this comment.
Thanks @ilmotta, that's a nice proposition.
Maybe the convenience of using a string vs a data structure is related to the programming language in question?
Not at all. The whole idea of namespaces was inspired by: go-log. The idea behind using a string is to potentially enable configuration through environment variable.
There was a problem hiding this comment.
The idea behind using a string is to potentially enable configuration through environment variable.
👍🏼 If namespaces are meant to be also configurable by env vars then that is indeed a good argument in favor of using a string as input.
Add endpoints for log level and namespaces configuration to `status.go` and deprecate equivalents from service. Endpoints are defined in `status.go`, as it has access to `statusBackend`, the only entity capable of manipulating node configuration without requiring a restart.
osmaczko
force-pushed
the
chore/setup-logging-at-runtime
branch
from
a46fe30 to
f8ad1da
Compare
Add endpoints for log level and namespaces configuration to
status.goand deprecate equivalents from service.Endpoints are defined in
status.go, as it has access tostatusBackend, the only entity capable of manipulating node configuration without requiring a restart.