ServiceControl é o cérebro de monitoramento da Plataforma de Serviços Particulares, que inclui NServiceBus e ferramentas para construir, monitorar e depurar sistemas distribuídos. O ServiceControl coleta dados sobre cada mensagem que flui pelo sistema (Fila de Auditoria), erros (Fila de Erros), bem como informações adicionais sobre sagas, pulsações de endpoints e verificações personalizadas (Fila de Controle). As informações são então expostas ao ServicePulse e ServiceInsight por meio de uma API HTTP e notificações SignalR.
Consulte a documentação do ServiceControl para obter mais informações.
ServiceControl, ServiceControl.Audit e ServiceControl.Monitoring podem ser executados/depurados localmente seguindo estas etapas:
app.config
do tipo de instância que precisa ser executado/depurado para selecionar qual transporte e persistência usar.Um vídeo de demonstração mostrando como configurá-lo está disponível no canal Particular do YouTube:
Todos os contêineres são criados em cada compilação e enviados para o registro de contêiner do GitHub, onde os vários tipos de instância podem ser acessados por seus nomes e executados localmente.
Se a instância for executada pela primeira vez, ela deverá configurar a infraestrutura necessária. Para fazer isso, depois que a instância estiver configurada para usar o transporte e a persistência selecionados, execute-a no modo de configuração. Isso pode ser feito usando o perfil de inicialização Setup {instance name}
definido no arquivo launchSettings.json
de cada instância. Quando iniciada no modo de configuração, a instância iniciará normalmente, executará o processo de configuração e sairá. Neste ponto, a instância pode ser executada normalmente usando o perfil de inicialização não configurado.
Para ajudar nos testes locais, o transporte Learning foi adicionado à lista de transportes disponíveis ao configurar uma nova instância no SCMU. Para que fique disponível, uma variável de ambiente ServiceControl_IncludeLearningTransport
precisa ser criada com um valor true
.
O teste usando o fluxo de trabalho de CI depende dos segredos a seguir, que devem ser definidos para segredos de Ações e Dependabot. Os valores específicos para esses segredos são armazenados na nota segura chamada ServiceControl Repo Secrets .
LICENSETEXT
: Texto de licença de software específicoAWS_ACCESS_KEY_ID
: Para testar SQSAWS_SECRET_ACCESS_KEY
: Para testar SQSAWS_REGION
: Para testar SQS Executar todos os testes o tempo todo exige muitos recursos. Os testes são filtrados com base na variável de ambiente ServiceControl_TESTS_FILTER
. Para executar apenas um subconjunto, por exemplo, testes de transporte SQS, defina a variável como ServiceControl_TESTS_FILTER=SQS
. A lista a seguir contém todos os valores possíveis de ServiceControl_TESTS_FILTER
:
Default
- executa apenas testes não específicos de transporteAzureServiceBus
AzureStorageQueues
MSMQ
RabbitMQ
SqlServer
SQS
NOTA: Se nenhuma variável for definida todos os testes serão executados.
Passos:
Construa a solução
Abra o PowerShell 7
Importe o módulo especificando o caminho para a pasta do repositório git do ServiceControl deployPowerShellModulesParticular.ServiceControl.Management
Import-Module - Name S:ServiceControldeployPowerShellModulesParticular.ServiceControl.Management - Verbose
Set-ExecutionPolicy Unrestricted
Agora que o módulo foi importado com sucesso, insira qualquer um dos scripts do ServiceControl PowerShell para testá-los. Por exemplo: o seguinte cria uma nova instância ServiceControl
$serviceControlInstance = New-ServiceControlInstance `
- Name ' Test.DEV.ServiceControl ' `
- InstallPath C:ServiceControlBin `
- DBPath C:ServiceControlDB `
- LogPath C:ServiceControlLogs `
- Port 44334 `
- DatabaseMaintenancePort 44335 `
- Transport ' RabbitMQ - Direct routing topology (quorum queues) ' `
- ConnectionString ' host=localhost;username=guest;password=guest ' `
- ErrorQueue errormq `
- ErrorRetentionPeriod 10 : 00 : 00 : 00 `
- Acknowledgements RabbitMQBrokerVersion310