PoC: Telemetry for Data.read

[Akirathan]

Part of #12090

Pull Request Description

Add dummy telemetry logs to the Data.read component. Telemetry.log is heavily inspired by Standard.Base.Enso_Cloud.Internal.Audit_Log.

Important Notes

Tried that inside the staging environment:

• Build IDE with ./run --skip-version-check ide build --mode staging
• Launch the generated executable.
• Open a project with Data.read component.
• The logs can be seen inside telemetry-logs index: https://discord.com/channels/401396655599124480/1344272214953951332/1347270621649965106

Note that Telemetry.log uses $HOME/.enso/credentials file for getting the access token. And this file is created by the IDE. That is why you need to test it inside the Electron app, and not via browser.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[JaroslavTulach]

Refactoring seems fine. Just try to increase encapsulation little bit.

[JaroslavTulach]

Isn't this slightly over engineered? Why have a type for LogMessage at all, when each object has toString()?

[JaroslavTulach]

• I'd suggest to delete LogMessage and use ch.qos.logback.classic.spi.ILoggingEvent instead!
• then just extend AppenderBase
• implement append(ILoggingEvent ev) method
• and we'll have the appender I want!

[radeusgd]

Isn't this slightly over engineered? Why have a type for LogMessage at all, when each object has toString()?

This is not a regular toString. Each log message in the API has some common JSON structure. IIRC the class encapsulates the common parts of that structure. Then the payload method converts the structure into a JSON string. But not any string is accepted and we still need this common logic for generating the JSON somewhere.

[JaroslavTulach]

Do we have any documentation describing the structure of all the messages?

Each log message in the API has some common JSON structure

That's the most important API.

Whether the message content is obtained via payload() or toString() is a niché (but I still suggest to remove LogMessage in the long run).

[radeusgd]

Do we have any documentation describing the structure of all the messages?

I'm afraid we don't. When I was implementing it, I was reading the code of the endpoint that is parsing it to figure it out.

https://github.com/enso-org/cloud-v2/blob/main/src/lambdas/src/lambdas/logs/endpoints/remote.rs#L57-L73

[JaroslavTulach]

Sending home the file path might reveal customer internals we are not interested in. File size and mime type should be generic enough, however.