3 ms·
How do you enforce the read-only guarantee across language runtimes and probe types? Is there a policy layer that rejects expressions with side effects before i
by xms17189 2mo ago
How do you enforce the read-only guarantee across language runtimes and probe types? Is there a policy layer that rejects expressions with side effects before instrumentation, and do you expose an audit trail showing exactly what each agent probe captured?
- karanraina 2mo agoby defalut, probes basically tell the fileName/className and lineNo/methad name to attach to (in additon to metadata like serviceId, environemnt name etc) This is readonly and safe by default. expressions come into play for conditonal probes read only safety guarantees here depend on the runtime NodeJS: handled implicitly by using `throwOnSideEffect: true` any side possible effects are prevented using this Python and Java: As of now, we don't let conditions have method invocations at all and only allow a subset of comparator operators. no assignment allowed usually property can invoke getter which usually should be safe to execute by design, but since we cant guarantee how it would have been written, we dont allow that as well for now. order.total > 50 => not allowed total > 50 => allowed to get around this we use multiple probes, agrregated by the current context's traceId (if avaliable) we plan to eliminate this problem by adding a custom DSL + AST parsing which can act as the policy layer to dissallow condtional probes Audit trail is in our roadmap. As of now, you can delete the data that's collected by probes. the only problem we have with audit trail is what if you capture something sensitive and that remains in your audit trail.. so we need some immutability that registers audit trails.. but then have enough flexibility to remove the data collected.. can be done