Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metrics pass over FTL #1988

Open
9 of 15 tasks
alecthomas opened this issue Jul 5, 2024 · 3 comments
Open
9 of 15 tasks

Metrics pass over FTL #1988

alecthomas opened this issue Jul 5, 2024 · 3 comments
Labels
epic An umbrella topic

Comments

@alecthomas alecthomas added the epic An umbrella topic label Jul 5, 2024
@github-actions github-actions bot added the triage Issue needs triaging label Jul 5, 2024
@ftl-robot ftl-robot mentioned this issue Jul 5, 2024
@bradleydwyer bradleydwyer added the next Work that will be be picked up next label Jul 8, 2024
@github-actions github-actions bot removed the triage Issue needs triaging label Jul 8, 2024
@bradleydwyer
Copy link
Collaborator

Consider how to test this locally without deployment / deployment of FTL.

@github-actions github-actions bot removed the next Work that will be be picked up next label Jul 8, 2024
@deniseli
Copy link
Contributor

deniseli commented Jul 9, 2024

Initial breakdown of tasks that we'll sync with the team on:

  1. Implement just otel - should run otel collector in a docker container to collect local logs/metrics/traces/spans and show the stream as they come in in the terminal tab. This way, we can run ftl dev, trigger the events we plan to log, and see them come through the terminal window in real(ish) time.
  2. Chat with PFI about whether there's anything they expect to work that isn't. (relates to the next task)
  3. Make sure everything existing actually WAI
  4. Add these attributes to all signals:
    1. project_name: from ftl-project.toml
    2. is_user_service: We have the serviceName set here, which currently will be one of ftl-controller, ftl-runner, or <module name>. Technically, we could use ftl-controller || ftl-runner but it would be good to be a bit more explicit.
      1. Add bool flag isInternal to observability.Config so that Init’s callers can configure whether it’s user code or not.
    3. trace_id: do we know if the trace_id that otel provides is already instrumented correctly such that it can be used to trace verb-to-verb calls like the trace_id in our request headers, or better yet if they’re actually the same trace_id? If not, then we need to make the one in the request headers available.
      1. Q: should we persist all the header values to attrs? A: we should check if any is done by default. Also, check if there’s any sensitive data (e.g. auth tokens)
  5. Plan out new signals + their attributes (incl. pubsub as described in the ticket desc) (reminder: queue depth)
  6. Change the go-runtime SDK to use a constant string (or configurable?). It's opt-in, so not a huge deal.

@deniseli
Copy link
Contributor

deniseli commented Jul 9, 2024

Just finished updating the ticket description. Everyone, feel free to assign tasks to yourself. I'll take the first one. Please do not take the two marked low priority until the others are closed (and maybe not even then!)

The original PubSub notes in the ticket description are now in #2025, along with @bradleydwyer 's reminders (feel free to add more in that ticket ;) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic An umbrella topic
Projects
None yet
Development

No branches or pull requests

4 participants