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

Dedicated collection for synthetic monitoring #6722

Open
1 task done
weavDarwin opened this issue Dec 19, 2024 · 2 comments
Open
1 task done

Dedicated collection for synthetic monitoring #6722

weavDarwin opened this issue Dec 19, 2024 · 2 comments
Assignees
@weavDarwin
Labels
feature request

Comments

@weavDarwin
Copy link

weavDarwin commented Dec 19, 2024 •
edited
Loading

Describe your feature request

We would like a dedicated collection for synthetic monitoring tools to use when performing actions against the database, to provide a well-known path for operators and avoid comingling synthetic data with actual data.

This could be as simple as a reserved name (i.e. Wellknown_synthetic) documented somewhere (i.e. in schema docs), and we let the synthetic monitor create the collection if it doesn't exist.

Or we could have the database create the collection on startup, provide ways to hide it in organic reads and reject organic writes, etc.

Code of Conduct
@weavDarwin weavDarwin self-assigned this Dec 19, 2024
@kavirajk
Copy link
Contributor

I love this idea.

my 2 cents,

  1. something like _fake_tenant_* and _fake_collection_* (to avoid Weaviate taking good names :) for tenant and collection)
  2. Would prefer reserving "prefixes" rather than actual name so that we can run concurrent/parallel testing without conflict (__fake_tenant_123, __fake_tenant_176` can exist happily).
  3. something to avoid system_tenant, system_collection (or combination of those). Because people may think it's some critical tenant/collection (similar to system namespace in k8 for example).

@etiennedi
Copy link
Member

etiennedi commented Dec 20, 2024 •
edited
Loading

I love this. My only 2 cents: I would ensure that all synthetic collections and tenants are hidden in all API endpoints by default (including summaries and aggregations) to avoid confusing unknowing users. I think this works well with a defined prefix that can be reserved and hidden by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@weavDarwin weavDarwin

Labels
feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kavirajk @etiennedi @weavDarwin