fix: record auditlog ng telemetry on client initialization#139
Conversation
| # Changelog | ||
|
|
||
| ## [0.20.2] - 2026-05-26 | ||
|
|
||
| ### Fixed | ||
|
|
||
| - Record ALS v3 (`auditlog_ng`) capability telemetry when `AuditClient` is | ||
| initialized, including direct `AuditClient(config)` construction. The | ||
| `send()` and `send_json()` APIs remain uninstrumented so the metric continues | ||
| to represent client initialization rather than audit event volume. |
There was a problem hiding this comment.
I think we're not doing this file anymore.
There was a problem hiding this comment.
Removed CHANGELOG.md from this PR.
| ) | ||
|
|
||
| from sap_cloud_sdk.core.telemetry import Module, Operation, record_metrics | ||
| from sap_cloud_sdk.core.telemetry import Module, Operation, record_error_metric |
There was a problem hiding this comment.
Nice fix overall.
One small thing: record_error_metric is an internal telemetry helper, and importing it without an underscore alias means it ends up in this module's public namespace, reachable as sap_cloud_sdk.core.auditlog_ng.record_error_metric even if it is not in __all__. A private alias would keep that intent clear:
from sap_cloud_sdk.core.telemetry import Module, Operation, record_error_metric as _record_error_metric
Then update the call site below to match:
_record_error_metric(
Module.AUDITLOG_NG,
_telemetry_source,
Operation.AUDITLOG_CREATE_CLIENT,
)
wdyt?
There was a problem hiding this comment.
Fixed by importing record_error_metric as _record_error_metric and updating the test patch target accordingly.
2 participants
Description
Moves the ALS v3 (
auditlog_ng)AUDITLOG_CREATE_CLIENTcapability metric from the public factory wrapper to the sharedAuditClientinitialization path. This keeps the signal as client/capability initialization rather than audit-event volume, while ensuring directAuditClient(config)construction emits the same SDK usage telemetry ascreate_client(config=...).The factory still records error metrics for validation/configuration failures that happen before
AuditClientcan be initialized, preserving the previous error telemetry behavior. The package version is bumped to0.20.2.Related Issue
Internal tracking: AFSDK-3392
Type of Change
Please check the relevant option:
How to Test
uv run pytest tests/core/unit/test_version.py tests/core/unit/auditlog_ng/unit/test_create_client.py tests/core/unit/auditlog_ng/unit/test_client.py tests/core/unit/telemetry/test_metrics_decorator.py -quv run pytest tests -m 'not integration' -quv run ruff check pyproject.toml src/sap_cloud_sdk/core/auditlog_ng/__init__.py src/sap_cloud_sdk/core/auditlog_ng/client.py src/sap_cloud_sdk/core/telemetry/metrics_decorator.py tests/core/unit/auditlog_ng/unit/test_create_client.py tests/core/unit/auditlog_ng/unit/test_client.py tests/core/unit/telemetry/test_metrics_decorator.pyuv run ty checkuv builduv run pytest tests/core/integration/auditlog -quv run pytest tests -m integration --ignore=tests/destination/integration -qExpected result: direct
AuditClient(config)and factory-created clients both record exactly oneauditlog_ng/create_clientcapability metric on successful initialization, without instrumentingsend()orsend_json().Checklist
Before submitting your PR, please review and check the following:
Breaking Changes
None.
Additional Notes
send()andsend_json()remain uninstrumented intentionally. The dashboard signal should represent ALS v3 capability/client initialization, not audit event volume.Local verification performed:
53 passedfor focused version/auditlog NG/telemetry tests.2098 passed, 125 deselectedfor non-integration tests.21 passedfor AuditLog integration tests with configured bindings.65 passed, 31 skippedfor integration tests excluding Destination.uv run ty checkcompleted with only pre-existing DMS integration warnings.uv buildproducedsap_cloud_sdk-0.20.2sdist and wheel.Full integration was also executed; remaining failures were limited to known Destination integration scenarios and are unrelated to ALS v3 telemetry.