Oathkeeper needs to be setup to listen to requests to /api/prom/push and check for the existence of a valid Access Token emitted by Big Brother's Hydra.

The token should be present at the HTTP Authorization header with a Bearer: prefix.

All PRs should be directed to the multi-tenancy branch.

From labbsr0x/servlet-monitor#31

Only more advanced users of Prometheus metrics really uses buckets/histograms. By removing metrics buckets, we will reduce in over 60% the amount of processing and byte output in our metrics endpoint with no loss in quality.

Currently we have something like this for each metrics/label combination:

request_seconds_bucket 1
request_seconds_bucket 2
request_seconds_bucket 3
request_seconds_bucket 4
request_seconds_bucket +inf
request_seconds_sum
request_seconds_count
response_size_bytes

By removing buckets, we would reduce to something like

request_seconds_sum
request_seconds_count
response_size_bytes

Proposal

• Buckets metrics made optional for request_seconds and dependency_request_seconds
• Disable buckets output by default (will only generate _sum and _count metrics for each request)
• Only enable buckets if configured explicitly using existing param "buckets" with values like "0.1,0.3,2,10" for example

As suggested by @werberson in another discussion, we need to evaluate if the protocol should standardize machine resource usage metrics.

If so, what should be the format?

A python flask library to instrument metrics.

To enable a simpler architecture with cortex, as proposed by @gutorc92 in #7, the way BB Promster's get registered to the ETCD should follow a structure that the Bot Service can use to recognize new apps, allowing bot users to list and subscribe to apps without having to explicitly add them through the bot.

Important: BB Promster easy federation abilities should not be lost with this integration.

the Big Brother repo should be central for all the components, by holding them as submodules.

Each component should have its own automated release cycle using Github actions. For that, each component should have it's own Github repo.

The cortex ruler microservice should be configured to launch alerts based on the already written alerting rules at the monitor folder. After that, the monitor folder should be removed from the project.

The PR should be open to the cortex branch.

Big Brother should also be able to work with the RemoteWrite to Cortex, instead of just Federation.

When user requests the creation of a new app via Telegram, the Bot Service should:

• 1. register the client at Hydra;
• 2. perform a client_credentials flow to get a valid Access Token;
• 3. The access token must be informed to the user as a result.

All PRs should be directed to the cortex branch.

Given the new components landscape for Big Brother, we should review our docker-compose and README.

Marcelo Rubim and I, made a quarkus extension for Big Brother, it is in Rubim repo
We use the servlet-monitor as example to create this extension.
We think to move this project to labbsr0x repo, but some adjustments maybe necessary.
Could you look if this project is suitable for Big Brother ?

Eu e o Marcelo Rubim fizemos uma extensão do quarkus para o Big Brother, esse projeto esta no repo do Rubim.
Usamos o servlet-monitor como exemplo para criar essa extensão.
Estamos pensando em mover esse projeto para o repositório do labbsr0x, talvez precise de alguns ajustes.
Vocês poderiam dar uma olhada no projeto e ver se ele esta de acordo com o padrões do Big Brother ?

A python django library would be very useful to have

Google's golden signal

To support the latest computing trends, Big Brother should have a k8s folder with all the deployment, statefulsets and service configs to run Big Brother in a k8s environment

BB-Promster is closely related to Big-Brother but today it is only referenced in our Readme.

Hello,

I was wondering if the fibre-monitor this repo could be an official monitor for Big Brother.

Thank you!

According to the big-brother protocol, the application version info is set as histogram and counter labels.
e.g.

request_seconds_bucket{type="http",status="404",method="GET",addr="/app", version="1.0.1",isError="true",le="1.0",} 2.0

GO and other systems use a pattern to collect and expose the application version, collecting as a gauge metric with the version info label and the gauge value set to 1.
The pattern is described in this post.

e.g.

application_info{version="v1.0.1"} 1

I think It would be interesting to big-brother follows the same pattern.

Avaliar a possibilidade de adicionar descrição no resultado de DependencyChecker.run(), principalmente se DependencyState for DOWN.

Por exemplo, quando ocorrer uma Exception, na execução de run(), capturar a Exception e usar getMessage() para usar na descrição.

Ou, caso o usuário da api deseje, adicionar mais informação no retorno de DependencyState.

While trying to run docker-compose build, the following error appears:

ERROR: build path /big-brother/alertmanager either does not exist, is not accessible, or is not a valid URL.

The value of the build context inside alertmanager service is outdated.

From #38, we noticed that Big Brother somewhat silently supports both the Prometheus Federation mechanism and also HA with Cortex.

Should we keep supporting both? If yes, we have tons of improvement to make to our Readmes, examples and alerting rules (hosted at BB-Promster vs hosted at Cortex's ruler service).

If not, we should review our readme, prioritize issue #27 and completely remove federation references from both our docker and k8s guidance material (example deployment files, helm charts, docker-compose, README, etc)

Labbs' Whisper project uses a self-created observability lib. We want to use the Big Brother's protocol, but there is no lib available. With that in mind, we should:

1. Create a new labbsr0x repo;
2. Create a valid go module lib that exposes the Big Brother metrics at a configurable endpoint and all the features the other libs provide;
3. When done and tested, add this new lib as a submodule to this repo.

nginx-monitor's acceptance tests are broken:

Fix these tests to work with big-brother metrics.

The bot should have an alertmanager webhook to receive alerts from a Alertmanager instance

As we have made efforts to deploy cortex on k8s, we could create a chart to deploy a stack of test.

This stack will include generator-metrics, bb-promster and etcd.
The chart have to attend to the requirements:

• 1 bb-promster for each generetor-metrics

• 1 etcd deployment and service

• generetor's metrics replicas configurable

The Grafana and it's dashboards as it stands today should be sent to it's own repo and added as a valid dashboard to the grafana.com marketplace

While trying to build the docker-compose file, the following error appears:

ERROR: Service 'example-grafana' depends on service 'example-bb-promster' which is undefined.

Add instructions about how to install the sidecar using Kubernetes: https://github.com/labbsr0x/nginx-monitor#kubernetes

1. create the protocol repo;
2. add the protocol to the readme;
3. add the new repo as a submodule for this repo;

The bb team needs to update targets on prometheus for some projects. This process is done by generating a file and copying it to prometheus container. Eventually, the big brother project will need those targets on a Etcd, a possible solution to help the bb team and keep the targets is create a front-end to interact to Etcd. Bb-bot project already has the endpoints to make operations on Etcd, then a solution will need just add more one endpoint to delete Ips for an app. The front-end solution can be implemented on a lightweight framework like Svelte. The requirements of front-end project will be:

• List apps

• List Ips for an app.

• Add a Ip on the app

• Generete a json file to update prometheus with a giving number of Ips.

Big Brother example docker-compose.yml should have:

• 1. Hydra setup to emit never-expiring access tokens; and
• 2. Oathkeeper checking security rules against the Hydra instance;

All PRs should be directed to the multi-tenancy branch.