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.

Sign up for GitHub

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

Jump to bottom

[feature request] OpenTelemetry endpoint in the backend #13

Open
erdnaxe opened this issue Oct 13, 2022 · 1 comment
Open

[feature request] OpenTelemetry endpoint in the backend #13

erdnaxe opened this issue Oct 13, 2022 · 1 comment

Comments

@erdnaxe
Copy link
Contributor

erdnaxe commented Oct 13, 2022 •
edited

This needs discussion as we mostly don't want to bloat Tulip.
It would be nice to have a /metrics endpoint in the backend following the OpenTelemetry format.
This could allow teams to monitor their instance and be alerted when something very wrong is happening (before the scoreboard).

Metrics wishlist:

  • (Counter per service) Total count of TCP flows in the MongoDB
  • (Counter per service) Total size in bytes of all payloads in the MongoDB
  • (Counter per service) Total amount of FLAG OUT / IN
  • (Counter) Total amount of backend API requests
  • (Gauge) Average duration of backend API response time

I don't believe we should expose per-TCP flow information as the Tulip frontend is already made for that.
@ItsShadowCone
Copy link
Member

massive +1

i would go further than just "health" checks, i agree with no per-TCP flow information, but we should also group by:

  • relevant data per-tick, probably also per-service, maybe rolling counters so it can be properly ingested into time-series database
  • relevant data per-tag, per-service and optionally also per-tick. not just flag in and out.

RickdeJager added a commit that referenced this issue Nov 2, 2022
@RickdeJager
Feature/rdj assembler limit (#13)
b286bd3 
Simplify data format, remove hex data from flow item.

The old format is terribly inefficient, and moving it to gridFS is
slow and clunky, even if you were to manually handle appends.

Data is capped at 15 MB, to stay well under the document limit
of 16MB. Any data beyond that is discarded, but the start
of the session will remain searchable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@erdnaxe @ItsShadowCone