Hello Solarwinds Team,
Audit logs are a vital tool for our team, providing critical visibility into who is modifying objects, when these changes occur, and what specific updates are made — particularly for custom properties. This information is essential for accountability, troubleshooting, and maintaining the integrity of our monitoring environment.
While testing the system, I’ve identified inconsistencies in how audit logs are generated for custom property updates. These inconsistencies vary depending on the object type and the method used to make the changes - either through the Custom Property Editor or the default method of editing an object’s properties. Although the Custom Property Editor is an excellent tool for efficiently handling bulk updates, the lack of uniform audit logging across all objects and methods creates gaps in our ability to track changes effectively. Below, I’ve outlined the current state of audit logging based on my observations:
1. Custom Property Editor
- Functional:
- Nodes: Audit logs accurately record the specific custom property and the value changed.
- Volumes: Audit logs accurately record the specific custom property and the value changed.
- Not Functional:
- Applications: No audit logs are generated for changes to application custom properties.
- Transactions: No audit logs are generated for changes to transaction custom properties.
- Interfaces: No audit logs are generated for changes to interface custom properties.
- Alerts: No audit logs are generated for changes to alert custom properties.
- Groups: No audit logs are generated for changes to group custom properties.
2. Editing Custom Properties via Object Properties (Default Method)
- Functional:
- Nodes: Audit logs accurately record the specific custom property and the value changed.
- Volumes: Audit logs accurately record the specific custom property and the value changed.
- Not Functional:
- Transactions: No GUI option exists to update custom properties outside of the Custom Property Editor.
- Interfaces: Audit logging is not enabled for interface custom properties.
- Applications: Audit logs indicate that the application was modified but do not specify which custom property or the new value.
- Groups: Audit logs indicate that the group was modified but do not specify which custom property or the new value.
- Alerts: When a custom property is changed, the audit log records an unrelated action (Ex: ActionTypeID:61 - "Alert integration state for AlertID [The alertID] was set to 'Enabled' by [User]"), suggesting that audit logging may not be properly enabled for alert custom properties.
Impact of These Issues
These inconsistencies significantly impair our ability to maintain a clear audit trail. For example, when using the Custom Property Editor, we cannot verify changes to applications, transactions, interfaces, alerts, or groups due to the absence of audit logs. Similarly, when updating custom properties through an object’s properties, the lack of detailed logging for certain objects makes it difficult to identify exactly what was changed. This is particularly problematic for alerts, where the audit log generates misleading information unrelated to the custom property update.
Thank you in advance for considering this request. I truly appreciate the capabilities of tools like the Custom Property Editor and am eager to see audit logging functionality brought to the same level of reliability across the platform. I look forward to your response and any insights you can share about plans to address these issues.
Thank you,
=swql
