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

Feature: Automatic Central Registration of Instances #30

Closed
1 task done
y-eight opened this issue Dec 6, 2023 · 0 comments · Fixed by #51
Closed
1 task done

Feature: Automatic Central Registration of Instances #30

y-eight opened this issue Dec 6, 2023 · 0 comments · Fixed by #51
Assignees
Labels
area/target-manager Issues/PRs related to the TargetManager feature Introduces a new feature request/internal Indicates an internal feature request
Milestone

Comments

@y-eight
Copy link
Member

y-eight commented Dec 6, 2023

Is there an existing feature request for this?

  • I have searched the existing issues

Problem Description

Sparrow instance can be spawned automatically. Other instances need to be configured (runtime config for checks) to know about this newly spawned instance.

Solution Description

Not 100% defined yet. A list needs to be available with all running sparrow instances incl. domain names. The checks should perform health & latency checks to all instances.

After a brainstorming session we came to the following conclusion:

  • Use git to manage a centralized targets configuration, which the Sparrow will read & update (registration & liveness update) periodically. Those will serve as a list of globalTargets for each Check.
    • This will eventually make the Sparrow only able to do DNS, TCP, UDP, ICMP, gRPC, HTTP protocols
    • There shouldn't be any merge conflicts, if each sparrow pushes a file with its health report/ registration info
    • possible format {"url": "pipapo", "lastSeen": "goland timestamp UTC"}
    • The pull & push procedure should be resilient & not deadlock the Sparrow. It should just fail after a few retries and try again later.
  • The Sparrow will either pass the globalTargets periodically down to the Check instances, OR the Check instances will get the globalTargets from the Sparrow themselves (possibly before running the check).
  • The Sparow should decide whether a globalTarget is healthy/not and remove it from the in-memory list it has.
  • The repository with the global targets should be maintained by a simple pipeline, that removes old targets, which haven't updated their registration in a while.
  • The Check instances should still define extraTargets, to add more targets to themselves.

Who can address the issue?

Devs

Additional Context

No response

@y-eight y-eight added the feature Introduces a new feature label Dec 6, 2023
@y-eight y-eight changed the title Feature: Automatical Central Registration of Instances Feature: Automatic Central Registration of Instances Dec 6, 2023
@y-eight y-eight added request/internal Indicates an internal feature request and removed feature Introduces a new feature labels Dec 6, 2023
@puffitos puffitos added this to the 0.2.0 milestone Dec 12, 2023
@puffitos puffitos self-assigned this Dec 12, 2023
This was referenced Dec 14, 2023
@puffitos puffitos linked a pull request Dec 28, 2023 that will close this issue
4 tasks
@lvlcn-t lvlcn-t added area/target-manager Issues/PRs related to the TargetManager feature Introduces a new feature labels Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/target-manager Issues/PRs related to the TargetManager feature Introduces a new feature request/internal Indicates an internal feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants