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

osrm-routed monitoring in the prometheus format #6147

Closed
wants to merge 11 commits into from

Conversation

juliorenner
Copy link

#5180
Endpoint to check OSRM status with monitoring solutions based on prometheus format.
This is a proof of concept implementation that has only several simple options. Additional metrics can be added with ongoing PRs.
Metrics endpoint is a separate thread that listens its own port and doesn't bother worker threads.

#5509 Fixing conflicts

@hoerup
Copy link
Contributor

hoerup commented Oct 15, 2021

Please take a look at the changes in CHANGELOG - it looks weird

@juliorenner
Copy link
Author

@hoerup my formatter is configured to format on save, undone the change

@hoerup
Copy link
Contributor

hoerup commented Oct 15, 2021

@mjbell could you take a look ?

@mjjbell
Copy link
Member

mjjbell commented Oct 15, 2021

@mjbell could you take a look ?

I've looked over this briefly.

  • I'm not a big fan of the scattering of counters around the codebase, it doesn't feel very maintainable.
  • There are good C++ libraries like prometheus-cpp or maybe even opentelemetry-cpp which are worth evaluating as more maintainable alternatives.

If we want to go down the route of having built-in observability, it's probably also worth discussing the options for a more robust server alternative for osrm-routed. The current implementation as pointed out recently is just a copy-paste job from the Boost docs, and not something that was intended to be a highly-available standalone server.

@FiDev20
Copy link

FiDev20 commented Oct 26, 2021

@mjjbell can you suggest any alternatives to export osrm metrics externally. Are we planning to add built-in observability in a future release version with the suggested improvements ?

@mjjbell
Copy link
Member

mjjbell commented Oct 29, 2021

I don't think anyone is planning anything for future releases at this point 🙂 , it's up to the community.

I agree that native observability would be beneficial, but I have reservations specifically about this PR's structure and about investing a lot of time in osrm-routedas mentioned above.

Depending on your exact needs, you might get some immediate benefit from running a proxy like Envoy or Nginx in front of osrm-routed and exporting HTTP request metrics from the proxy instead.

@DennisOSRM
Copy link
Collaborator

closing stale PR. Reopen if still relevant.

@DennisOSRM DennisOSRM closed this May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants