Files
supermq/bootstrap
b1ackd0t b3e2f41194 NOISSUE - Add Alarms (#106)
* WIP: alarms service

* fix(alarms): remove rule entity since it is not stored here

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* test(alarms): add tests cases for invalid alarms

* feat(alarms): add authorization

* feat(alarms): add docker deployment files

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix: update go mod file

* feat(alarms): support filtering by resolved_by, updated_by and severity

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* style: fix linter errors

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): provide correct otel naming for create alarm

Fixes https://github.com/absmach/magistrala/pull/106#discussion_r2030151971

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): group routes appropriately

Resolves https://github.com/absmach/magistrala/pull/106#discussion_r2030160891

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): extract alarm id from url path rather than query params

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): add all status to help in decoding

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* style(alarms): maintain consistent import as naming for supermq api package

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* refactor(alarms): update supermq dependecy to the latest

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): Add domains gRPC service config to alarms service

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* test(alarms): all CRUD operations from the service

Return empty results instead of nil

This standardizes error responses across alarm endpoints to return empty
result structs rather than nil. Also renames entityReq to alarmReq and
adds HTTP status codes for created/deleted alarms.

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* test(alarms): fix failing tests due to introduction of context on sdk

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): remove channel id

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): standardize error handling across CRUD operations

Updated error responses to use specific repository errors for consistency

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): add assignment fields to Alarm model and database

Introduced AssignedAt and AssignedBy fields to the Alarm struct and updated the database schema accordingly. Enhanced the UpdateAlarm function to handle these new fields, ensuring proper assignment tracking in the alarms system.

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): enhance Alarm model with measurement attributes

Updated the Alarm struct to include Measurement, Value, Unit, and Cause fields. Modified the validation logic to ensure these fields are present. Adjusted logging and tracing middleware to reflect the new attributes. Updated database schema and related functions to accommodate these changes, ensuring comprehensive alarm data management.

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): consume events from pubsub for creation of alarms

Removed session dependencies from CreateAlarm method and enhanced alarm validation to ensure all required fields are present

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* style(alarms): add newline at the end of docker compose

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): Add assignee id and metadata fields when consuming messages

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): add acknowledged field

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): Add threshold value for the specific measurement

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): Add channel, thing, and subtopic fields to Alarm model

This change adds required fields for tracking alarm sources and reorganizes
alarm-related fields for better grouping. Alarms now track the channel,
thing, and subtopic that triggered them, along with domain and rule info.

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* test(alarms): add service layer tests

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): consume created at from message rather than creating it

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): ready alarm as a gob encoded object

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): read alarms from alarms queue and remove transformer

g

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): update version of supermq

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* feat(alarms): add gob transformer

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): rename thing id to client id

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): create alarms stream

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): check on logic to create new alarm

create new alarm if severity, status, subtopic changes
enhance logging with additional details for alarms management

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* remove conusmer and use pubsub

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>

* fix(alarms): use build tags for rabbitmq and nats

* fix(alarms): add health and metrics endpoint

* fix(magistrala): use supermq as build flags to see version and commit

* fix(alarms): use js config

* fix(alarms): remove validation when updating an alarm

fix authorization too

---------

Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>
2025-04-15 19:32:09 +02:00
..
2025-04-15 19:32:09 +02:00
2025-04-01 10:41:26 +02:00
2025-04-01 10:41:26 +02:00
2025-04-15 19:32:09 +02:00
2025-04-15 19:32:09 +02:00

BOOTSTRAP SERVICE

New devices need to be configured properly and connected to the Magistrala. Bootstrap service is used in order to accomplish that. This service provides the following features:

  1. Creating new Magistrala Clients
  2. Providing basic configuration for the newly created Clients
  3. Enabling/disabling Clients

Pre-provisioning a new Client is as simple as sending Configuration data to the Bootstrap service. Once the Client is online, it sends a request for initial config to Bootstrap service. Bootstrap service provides an API for enabling and disabling Clients. Only enabled Clients can exchange messages over Magistrala. Bootstrapping does not implicitly enable Clients, it has to be done manually.

In order to bootstrap successfully, the Client needs to send bootstrapping request to the specific URL, as well as a secret key. This key and URL are pre-provisioned during the manufacturing process. If the Client is provisioned on the Bootstrap service side, the corresponding configuration will be sent as a response. Otherwise, the Client will be saved so that it can be provisioned later.

Client Configuration Entity

Client Configuration consists of two logical parts: the custom configuration that can be interpreted by the Client itself and Magistrala-related configuration. Magistrala config contains:

  1. corresponding Magistrala Client ID
  2. corresponding Magistrala Client key
  3. list of the Magistrala channels the Client is connected to

Note: list of channels contains IDs of the Magistrala channels. These channels are pre-provisioned on the Magistrala side and, unlike corresponding Magistrala Client, Bootstrap service is not able to create Magistrala Channels.

Enabling and disabling Client (adding Client to/from whitelist) is as simple as connecting corresponding Magistrala Client to the given list of Channels. Configuration keeps state of the Client:

State What it means
Inactive Client is created, but isn't enabled
Active Client is able to communicate using Magistrala

Switching between states Active and Inactive enables and disables Client, respectively.

Client configuration also contains the so-called external ID and external key. An external ID is a unique identifier of corresponding Client. For example, a device MAC address is a good choice for external ID. External key is a secret key that is used for authentication during the bootstrapping procedure.

Configuration

The service is configured using the environment variables presented in the following table. Note that any unset variables will be replaced with their default values.

Variable Description Default
SMQ_BOOTSTRAP_LOG_LEVEL Log level for Bootstrap (debug, info, warn, error) info
SMQ_BOOTSTRAP_DB_HOST Database host address localhost
SMQ_BOOTSTRAP_DB_PORT Database host port 5432
SMQ_BOOTSTRAP_DB_USER Database user magistrala
SMQ_BOOTSTRAP_DB_PASS Database password magistrala
SMQ_BOOTSTRAP_DB_NAME Name of the database used by the service bootstrap
SMQ_BOOTSTRAP_DB_SSL_MODE Database connection SSL mode (disable, require, verify-ca, verify-full) disable
SMQ_BOOTSTRAP_DB_SSL_CERT Path to the PEM encoded certificate file ""
SMQ_BOOTSTRAP_DB_SSL_KEY Path to the PEM encoded key file ""
SMQ_BOOTSTRAP_DB_SSL_ROOT_CERT Path to the PEM encoded root certificate file ""
SMQ_BOOTSTRAP_ENCRYPT_KEY Secret key for secure bootstrapping encryption 12345678910111213141516171819202
SMQ_BOOTSTRAP_HTTP_HOST Bootstrap service HTTP host ""
SMQ_BOOTSTRAP_HTTP_PORT Bootstrap service HTTP port 9013
SMQ_BOOTSTRAP_HTTP_SERVER_CERT Path to server certificate in pem format ""
SMQ_BOOTSTRAP_HTTP_SERVER_KEY Path to server key in pem format ""
SMQ_BOOTSTRAP_EVENT_CONSUMER Bootstrap service event source consumer name bootstrap
SMQ_ES_URL Event store URL nats://localhost:4222
SMQ_AUTH_GRPC_URL Auth service Auth gRPC URL localhost:8181
SMQ_AUTH_GRPC_TIMEOUT Auth service Auth gRPC request timeout in seconds 1s
SMQ_AUTH_GRPC_CLIENT_CERT Path to the PEM encoded auth service Auth gRPC client certificate file ""
SMQ_AUTH_GRPC_CLIENT_KEY Path to the PEM encoded auth service Auth gRPC client key file ""
SMQ_AUTH_GRPC_SERVER_CERTS Path to the PEM encoded auth server Auth gRPC server trusted CA certificate file ""
SMQ_CLIENTS_URL Base URL for Magistrala Clients http://localhost:9000
SMQ_JAEGER_URL Jaeger server URL http://localhost:4318/v1/traces
SMQ_JAEGER_TRACE_RATIO Jaeger sampling ratio 1.0
SMQ_SEND_TELEMETRY Send telemetry to magistrala call home server true
SMQ_BOOTSTRAP_INSTANCE_ID Bootstrap service instance ID ""

Deployment

The service itself is distributed as Docker container. Check the bootstrap service section in docker-compose file to see how service is deployed.

To start the service outside of the container, execute the following shell script:

# download the latest version of the service
git clone https://github.com/absmach/magistrala

cd magistrala

# compile the servic e
make bootstrap

# copy binary to bin
make install

# set the environment variables and run the service
SMQ_BOOTSTRAP_LOG_LEVEL=info \
SMQ_BOOTSTRAP_DB_HOST=localhost \
SMQ_BOOTSTRAP_DB_PORT=5432 \
SMQ_BOOTSTRAP_DB_USER=magistrala \
SMQ_BOOTSTRAP_DB_PASS=magistrala \
SMQ_BOOTSTRAP_DB_NAME=bootstrap \
SMQ_BOOTSTRAP_DB_SSL_MODE=disable \
SMQ_BOOTSTRAP_DB_SSL_CERT="" \
SMQ_BOOTSTRAP_DB_SSL_KEY="" \
SMQ_BOOTSTRAP_DB_SSL_ROOT_CERT="" \
SMQ_BOOTSTRAP_HTTP_HOST=localhost \
SMQ_BOOTSTRAP_HTTP_PORT=9013 \
SMQ_BOOTSTRAP_HTTP_SERVER_CERT="" \
SMQ_BOOTSTRAP_HTTP_SERVER_KEY="" \
SMQ_BOOTSTRAP_EVENT_CONSUMER=bootstrap \
SMQ_ES_URL=nats://localhost:4222 \
SMQ_AUTH_GRPC_URL=localhost:8181 \
SMQ_AUTH_GRPC_TIMEOUT=1s \
SMQ_AUTH_GRPC_CLIENT_CERT="" \
SMQ_AUTH_GRPC_CLIENT_KEY="" \
SMQ_AUTH_GRPC_SERVER_CERTS="" \
SMQ_CLIENTS_URL=http://localhost:9000 \
SMQ_JAEGER_URL=http://localhost:14268/api/traces \
SMQ_JAEGER_TRACE_RATIO=1.0 \
SMQ_SEND_TELEMETRY=true \
SMQ_BOOTSTRAP_INSTANCE_ID="" \
$GOBIN/magistrala-bootstrap

Setting SMQ_BOOTSTRAP_HTTP_SERVER_CERT and SMQ_BOOTSTRAP_HTTP_SERVER_KEY will enable TLS against the service. The service expects a file in PEM format for both the certificate and the key.

Setting SMQ_AUTH_GRPC_CLIENT_CERT and SMQ_AUTH_GRPC_CLIENT_KEY will enable TLS against the auth service. The service expects a file in PEM format for both the certificate and the key. Setting SMQ_AUTH_GRPC_SERVER_CERTS will enable TLS against the auth service trusting only those CAs that are provided. The service expects a file in PEM format of trusted CAs.

Usage

For more information about service capabilities and its usage, please check out the API documentation.