OTEL follow up part 2

[stanleypliu]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation
• 🧑‍💻 Refactor
• ✅ Test
• 🤖 Build or CI
• ❓ Other (please specify)

Related Issue

N/A

Describe this PR

Follow up PR for #680 as that was merged before this commit could be pushed. INSTALL_MONITORING variable removed from compose.yaml as it shouldn't be responsible for controlling those deps. Instead, the user is now prompted to pass that along as a build argument.

Screenshots

N/A

Alternative Approaches Considered

N/A

Review Guide

N/A

Checklist before requesting a review

• 📖 Read the HOT Code of Conduct: https://docs.hotosm.org/code-of-conduct
• 👷‍♀️ Create small PRs. In most cases, this will be possible.
• ✅ Provide tests for your changes.
• 📝 Use descriptive commit messages.
• 📗 Update any related documentation and include any relevant screenshots.

[optional] What gif best describes this PR or how it makes you feel?

[spwoodcock]

Do you think we could possibly merge the two env vars into one?

For FieldTM we simply have the MONITORING var present in the prod github env vars - this results in both the dependencies being installed, and sentry being configured at server init

[stanleypliu]

Do you think we could possibly merge the two env vars into one?

For FieldTM we simply have the MONITORING var present in the prod github env vars - this results in both the dependencies being installed, and sentry being configured at server init

We can, although I originally wanted to retain the MONITORING variable just in case we want to have a different backend for sending the traces in future. Unless you think that this is premature optimisation 😄

[spwoodcock]

FieldTM works like this, based on the env:

MONITORING= dont install deps, dont enable monitoring on deploy

MONITORING=sentry install deps, configure sentry

MONITORING=openobserve install deps, configure generic otel openobserve

Would similar make sense here?