Identificar e Solucionar Problemas da CDL (Common Data Layer, Camada Comum de Dados)
Contents
1. Introdução
Este artigo abordará os fundamentos da solução de problemas da CDL (Common Data Layer, Camada Comum de Dados) em ambientes SMF. Documentação que você pode encontrar neste link.
2. Panorâmica
A Cisco Common Data Layer (CDL) é uma camada de armazenamento de dados KV (valor-chave) de próxima geração e alto desempenho para todos os aplicativos nativos de nuvem.
A CDL é usada atualmente como um componente de gerenciamento de estado com funções HA (alta disponibilidade) e Geo HA.
O CDL oferece:
- Uma camada comum de armazenamento de dados em diferentes funções de rede (NFs).
- Leitura e gravação de baixa latência (em armazenamento de sessão de memória)
- Notifique as NFs para bloquear o assinante quando for relatado um ataque de negação de serviço (DoS) na mesma sessão.
- Alta disponibilidade - redundância local com pelo menos duas réplicas.
- Redundância geográfica com 2 locais.
- Nenhum conceito primário/secundário para todos os slots disponíveis para operações de gravação. Melhora o tempo de failover, já que não ocorre nenhuma eleição principal.
3. Componentes
- Ponto de extremidade: (cdl-ep-session-c1-d0-7c79c87d65-xpm5v)
- O endpoint CDL é um POD Kubernetes (K8s). Ele é implantado para expor o gRPC sobre a interface HTTP2 em relação ao cliente NF para processamento de solicitações de serviço de banco de dados e atua como um ponto de entrada para as aplicações de ligação norte.
- Slot: (cdl-slot-session-c1-m1-0)
- O ponto final do CDL suporta vários microsserviços de slot. Esses microsserviços são K8s POD implantados para expor a interface gRPC interna em direção ao Cisco Data Store
- Cada Slot POD contém um número finito de sessões. Essas sessões são os dados reais da sessão em formato de matriz de bytes
- Índice: (cdl-index-session-c1-m1-0)
- O microsserviço Índice contém os dados relacionados à indexação
- Esses dados de indexação são usados para recuperar os dados da sessão real dos microsserviços de slot
- ETCD: (etcd-smf-etcd-cluster-0)
- O CDL usa o ETCD (um armazenamento de valores de chave de código aberto) como a descoberta de serviços de banco de dados. Quando o EP do Cisco Data Store é iniciado, eliminado ou desligado, isso resulta na adição de um evento pelo estado de publicação. Portanto, as notificações são enviadas a cada um dos PODs inscritos nesses eventos. Além disso, quando um evento-chave é adicionado ou removido, ele atualiza o mapa local.
- Kafka: (kafka- 0)
- O POD Kafka replica dados entre as réplicas locais e entre sites para indexação. Para replicação entre locais, o Kafak usa o MirrorMaker.
- Criador de Espelhos: (mirror-maker-0)
- O POD do Mirror Maker replica geograficamente os dados de indexação para os locais remotos do CDL. Ele pega dados dos sites remotos e os publica no site local do Kafka para que as instâncias de indexação apropriadas sejam selecionadas.
Exemplo:
master-1:~$ kubectl get pods -n smf-smf -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES cdl-ep-session-c1-d0-7889db4d87-5mln5 1/1 Running 0 80d 192.168.16.247 smf-data-worker-5 <none> <none> cdl-ep-session-c1-d0-7889db4d87-8q7hg 1/1 Running 0 80d 192.168.18.108 smf-data-worker-1 <none> <none> cdl-ep-session-c1-d0-7889db4d87-fj2nf 1/1 Running 0 80d 192.168.24.206 smf-data-worker-3 <none> <none> cdl-ep-session-c1-d0-7889db4d87-z6c2z 1/1 Running 0 34d 192.168.4.164 smf-data-worker-2 <none> <none> cdl-ep-session-c1-d0-7889db4d87-z7c89 1/1 Running 0 80d 192.168.7.161 smf-data-worker-4 <none> <none> cdl-index-session-c1-m1-0 1/1 Running 0 80d 192.168.7.172 smf-data-worker-4 <none> <none> cdl-index-session-c1-m1-1 1/1 Running 0 80d 192.168.24.241 smf-data-worker-3 <none> <none> cdl-index-session-c1-m2-0 1/1 Running 0 49d 192.168.18.116 smf-data-worker-1 <none> <none> cdl-index-session-c1-m2-1 1/1 Running 0 80d 192.168.7.173 smf-data-worker-4 <none> <none> cdl-index-session-c1-m3-0 1/1 Running 0 80d 192.168.24.197 smf-data-worker-3 <none> <none> cdl-index-session-c1-m3-1 1/1 Running 0 80d 192.168.18.107 smf-data-worker-1 <none> <none> cdl-index-session-c1-m4-0 1/1 Running 0 80d 192.168.7.158 smf-data-worker-4 <none> <none> cdl-index-session-c1-m4-1 1/1 Running 0 49d 192.168.16.251 smf-data-worker-5 <none> <none> cdl-slot-session-c1-m1-0 1/1 Running 0 80d 192.168.18.117 smf-data-worker-1 <none> <none> cdl-slot-session-c1-m1-1 1/1 Running 0 80d 192.168.24.201 smf-data-worker-3 <none> <none> cdl-slot-session-c1-m2-0 1/1 Running 0 80d 192.168.16.245 smf-data-worker-5 <none> <none> cdl-slot-session-c1-m2-1 1/1 Running 0 80d 192.168.18.123 smf-data-worker-1 <none> <none> cdl-slot-session-c1-m3-0 1/1 Running 0 34d 192.168.4.156 smf-data-worker-2 <none> <none> cdl-slot-session-c1-m3-1 1/1 Running 0 80d 192.168.18.78 smf-data-worker-1 <none> <none> cdl-slot-session-c1-m4-0 1/1 Running 0 34d 192.168.4.170 smf-data-worker-2 <none> <none> cdl-slot-session-c1-m4-1 1/1 Running 0 80d 192.168.7.177 smf-data-worker-4 <none> <none> cdl-slot-session-c1-m5-0 1/1 Running 0 80d 192.168.24.246 smf-data-worker-3 <none> <none> cdl-slot-session-c1-m5-1 1/1 Running 0 34d 192.168.4.163 smf-data-worker-2 <none> <none> cdl-slot-session-c1-m6-0 1/1 Running 0 80d 192.168.18.119 smf-data-worker-1 <none> <none> cdl-slot-session-c1-m6-1 1/1 Running 0 80d 192.168.16.228 smf-data-worker-5 <none> <none> cdl-slot-session-c1-m7-0 1/1 Running 0 80d 192.168.16.215 smf-data-worker-5 <none> <none> cdl-slot-session-c1-m7-1 1/1 Running 0 49d 192.168.4.167 smf-data-worker-2 <none> <none> cdl-slot-session-c1-m8-0 1/1 Running 0 49d 192.168.24.213 smf-data-worker-3 <none> <none> cdl-slot-session-c1-m8-1 1/1 Running 0 80d 192.168.16.253 smf-data-worker-5 <none> <none> etcd-smf-smf-etcd-cluster-0 2/2 Running 0 80d 192.168.11.176 smf-data-master-1 <none> <none> etcd-smf-smf-etcd-cluster-1 2/2 Running 0 48d 192.168.7.59 smf-data-master-2 <none> <none> etcd-smf-smf-etcd-cluster-2 2/2 Running 1 34d 192.168.11.66 smf-data-master-3 <none> <none> georeplication-pod-0 1/1 Running 0 80d 10.10.1.22 smf-data-master-1 <none> <none> georeplication-pod-1 1/1 Running 0 48d 10.10.1.23 smf-data-master-2 <none> <none> grafana-dashboard-cdl-smf-smf-77bd69cff7-qbvmv 1/1 Running 0 34d 192.168.7.41 smf-data-master-2 <none> <none> kafka-0 2/2 Running 0 80d 192.168.24.245 smf-data-worker-3 <none> <none> kafka-1 2/2 Running 0 49d 192.168.16.200 smf-data-worker-5 <none> <none> mirror-maker-0 1/1 Running 1 80d 192.168.18.74 smf-data-worker-1 <none> <none> zookeeper-0 1/1 Running 0 34d 192.168.11.73 smf-data-master-3 <none> <none> zookeeper-1 1/1 Running 0 48d 192.168.7.47 smf-data-master-2 <none> <none> zookeeper-2
Arquitetura CDL
4. Passo a Passo da Configuração
smf# show running-config cdl cdl system-id 1 /// unique across the site, system-id 1 is the primary site ID for sliceNames SMF1 SMF2 in HA GR CDL deploy cdl node-type db-data /// node label to configure the node affinity cdl enable-geo-replication true /// CDL GR Deployment with 2 RACKS cdl remote-site 2 db-endpoint host x.x.x.x /// Remote site cdl-ep configuration on site-1 db-endpoint port 8882 kafka-server x.x.x.x 10061 /// Remote site kafka configuration on site-1 exit kafka-server x.x.x.x 10061 exit exit cdl label-config session /// Configures the list of label for CDL pods endpoint key smi.cisco.com/node-type-3 endpoint value session slot map 1 key smi.cisco.com/node-type-3 value session exit slot map 2 key smi.cisco.com/node-type-3 value session exit slot map 3 key smi.cisco.com/node-type-3 value session exit slot map 4 key smi.cisco.com/node-type-3 value session exit slot map 5 key smi.cisco.com/node-type-3 value session exit slot map 6 key smi.cisco.com/node-type-3 value session exit slot map 7 key smi.cisco.com/node-type-3 value session exit slot map 8 key smi.cisco.com/node-type-3 value session exit index map 1 key smi.cisco.com/node-type-3 value session exit index map 2 key smi.cisco.com/node-type-3 value session exit index map 3 key smi.cisco.com/node-type-3 value session exit index map 4 key smi.cisco.com/node-type-3 value session exit exit cdl datastore session /// unique with in the site label-config session geo-remote-site [ 2 ] slice-names [ SMF1 SMF2 ] endpoint cpu-request 2000 endpoint go-max-procs 16 endpoint replica 5 /// number of cdl-ep pods endpoint external-ip x.x.x.x endpoint external-port 8882 index cpu-request 2000 index go-max-procs 8 index replica 2 /// number of replicas per mop for cdl-index, can not be changed after CDL deployement.
NOTE: If you need to change number of index replica, set the system mode to shutdown from respective ops-center CLI, change the replica and set the system mode to running index map 4 /// number of mops for cdl-index index write-factor 1 /// number of copies to be written before a successful response slot cpu-request 2000 slot go-max-procs 8 slot replica 2 /// number of replicas per mop for cdl-slot slot map 8 /// number of mops for cdl-slot slot write-factor 1 slot metrics report-idle-session-type true features instance-aware-notification enable true /// This enables GR failover notification features instance-aware-notification system-id 1 slice-names [ SMF1 ] exit features instance-aware-notification system-id 2 slice-names [ SMF2 ] exit exit cdl kafka replica 2 cdl kafka label-config key smi.cisco.com/node-type-3 cdl kafka label-config value session cdl kafka external-ip x.x.x.x 10061 exit cdl kafka external-ip x.x.x.x 10061 exit
5. Solucionar problemas
5.1 Falhas de Pod
A operação do CDL é direta Chave > Banco de dados de valor.
- Todas as solicitações chegam aos pods do endpoint de cdl.
- Nos pods de índice cdl armazenamos chaves, round robin.
- No slot cdl, armazenamos valor (informações da sessão), round robin.
- Definimos backup (número de réplicas) para cada mapa de pod (tipo).
- Kafka pod é usado como ônibus de transporte.
- o fabricante de espelhos é usado como barramento de transporte para rack diferente (redundância geográfica).
A falha de cada um poderia ser traduzida como, isto é, se todos os pods deste tipo/mapa fossem desativados ao mesmo tempo:
- cdl-endpoint - erros de comunicação com o CDL
- cdl-index - perda de chaves para dados de sessão
- cdl-slot - perda de dados de sessão
- Kafka - Perdendo a opção de sincronização entre os mapas do tipo pod
- criador de espelho - perdendo sincronização com outro nó geo redudand
Sempre podemos coletar logs de pods relevantes, pois os logs de pods de cdl não são transferidos tão rapidamente, portanto, há um valor extra para coletá-los.
Remamber tac-debug coleta instantâneo em tempo enquanto os logs imprimem todos os dados desde que são armazenados.
Descrever pods
kubectl describe pod cdl-ep-session-c1-d0-7889db4d87-5mln5 -n smf-rcdn
Coletar logs de pod
kubectl logs cdl-ep-session-c1-d0-7c79c87d65-xpm5v -n smf-rcdn
5.2 CDL Como obter informações de sessão a partir das chaves de sessão
Dentro da CDL, cada sessão tem um campo chamado unique-keys que identifica essa sessão.
Se compararmos a impressão de sessão de show subscriber supi e cdl show sessions summary slice-name slice1 db-name session filter
- endereço de sessão ipv4 combinado com supi = "1#/#imsi-123969789012404:10.0.0.3"
- ddn + endereço ip4 = "1#/#lab:10.0.0.3"
- endereço de sessão ipv6 combinado com supi = "1#/#imsi-123969789012404:2001:db0:0:2::"
- ddn + endereço ipv6 da sessão = "1#/#lab:2001:db0:0:2::"
- smfTeid também N4 Session Key = "1#/#293601283" Isso é realmente útil ao solucionar erros em UPF, você pode pesquisar logs de sessão e encontrar informações relacionadas à sessão.
- supi + ebi = "1#/#imsi-123969789012404:ebi-5"
- supi + ddn= "1#/#imsi-123969789012404:lab"
[smf/data] smf# cdl show sessions summary slice-name slice1 db-name session filter { condition match key 1#/#293601283 }
Sun Mar 19 20:17:41.914 UTC+00:00
message params: {session-summary cli session {0 100 1#/#293601283 0 [{0 1#/#293601283}] [] 0 0 false 4096 [] [] 0} slice1}
session {
primary-key 1#/#imsi-123969789012404:1
unique-keys [ "1#/#imsi-123969789012404:10.0.0.3" "1#/#lab:10.0.0.3" "1#/#imsi-123969789012404:2001:db0:0:2::" "1#/#lab:2001:db0:0:2::" "1#/#293601283" "1#/#imsi-123969789012404:ebi-5" "1#/#imsi-123969789012404:lab" ]
non-unique-keys [ "1#/#roaming-status:visitor-lbo" "1#/#ue-type:nr-capable" "1#/#supi:imsi-123969789012404" "1#/#gpsi:msisdn-22331010101010" "1#/#pei:imei-123456789012381" "1#/#psid:1" "1#/#snssai:001000003" "1#/#dnn:lab" "1#/#emergency:false" "1#/#rat:nr" "1#/#access:3gpp" access "1#/#connectivity:5g" "1#/#udm-uecm:10.10.10.215" "1#/#udm-sdm:10.10.10.215" "1#/#auth-status:unauthenticated" "1#/#pcfGroupId:PCF-dnn=lab;" "1#/#policy:2" "1#/#pcf:10.10.10.216" "1#/#upf:10.10.10.150" "1#/#upfEpKey:10.10.10.150:10.10.10.202" "1#/#ipv4-addr:pool1/10.0.0.3" "1#/#ipv4-pool:pool1" "1#/#ipv4-range:pool1/10.0.0.1" "1#/#ipv4-startrange:pool1/10.0.0.1" "1#/#ipv6-pfx:pool1/2001:db0:0:2::" "1#/#ipv6-pool:pool1" "1#/#ipv6-range:pool1/2001:db0::" "1#/#ipv6-startrange:pool1/2001:db0::" "1#/#id-index:1:0:32768" "1#/#id-value:2/3" "1#/#chfGroupId:CHF-dnn=lab;" "1#/#chf:10.10.10.218" "1#/#amf:10.10.10.217" "1#/#peerGtpuEpKey:10.10.10.150:20.0.0.1" "1#/#namespace:smf" ]
flags [ flag3:peerGtpuEpKey:10.10.10.150:20.0.0.1 session-state-flag:smf_active ]
map-id 2
instance-id 1
app-instance-id 1
version 1
create-time 2023-03-19 20:14:14.381940117 +0000 UTC
last-updated-time 2023-03-19 20:14:14.943366502 +0000 UTC
purge-on-eval false
next-eval-time 2023-03-26 20:14:14 +0000 UTC
session-types [ rat_type:NR wps:non_wps emergency_call:false pdu_type:ipv4v6 dnn:lab qos_5qi_1_rat_type:NR ssc_mode:ssc_mode_1 always_on:disable fourg_only_ue:false up_state:active qos_5qi_5_rat_type:NR dcnr:disable smf_roaming_status:visitor-lbo dnn:lab:rat_type:NR ]
data-size 2866
}
[smf/data] smf#
Se compararmos com a impressão do SMF:
[smf/data] smf# show subscriber supi imsi-123969789012404 gr-instance 1 namespace smf
Sun Mar 19 20:25:47.816 UTC+00:00
subscriber-details
{
"subResponses": [
[
"roaming-status:visitor-lbo",
"ue-type:nr-capable",
"supi:imsi-123969789012404",
"gpsi:msisdn-22331010101010",
"pei:imei-123456789012381",
"psid:1",
"snssai:001000003",
"dnn:lab",
"emergency:false",
"rat:nr",
"access:3gpp access",
"connectivity:5g",
"udm-uecm:10.10.10.215",
"udm-sdm:10.10.10.215",
"auth-status:unauthenticated",
"pcfGroupId:PCF-dnn=lab;",
"policy:2",
"pcf:10.10.10.216",
"upf:10.10.10.150",
"upfEpKey:10.10.10.150:10.10.10.202",
"ipv4-addr:pool1/10.0.0.3",
"ipv4-pool:pool1",
"ipv4-range:pool1/10.0.0.1",
"ipv4-startrange:pool1/10.0.0.1",
"ipv6-pfx:pool1/2001:db0:0:2::",
"ipv6-pool:pool1",
"ipv6-range:pool1/2001:db0::",
"ipv6-startrange:pool1/2001:db0::",
"id-index:1:0:32768",
"id-value:2/3",
"chfGroupId:CHF-dnn=lab;",
"chf:10.10.10.218",
"amf:10.10.10.217",
"peerGtpuEpKey:10.10.10.150:20.0.0.1",
"namespace:smf",
"nf-service:smf"
]
]
}
Verifique o status do CDL no SMF:
cdl show status
cdl show sessions summary slice-name <slice name> | more
5.3 Os pods do CDL não estão ativos
Como identificar
Verifique a saída de descrever pods (contêineres/membro/estado/razão, eventos).
kubectl describe pods -n <namespace> <failed pod name>
Como corrigir
- Os pods estão em estado pendente Verifique se algum nó k8s com valores de rótulo iguais ao valor de cdl/tipo de nó número de réplicas é menor ou igual ao número de nós k8s com valores de rótulo iguais ao valor de cdl/tipo de nó
kubectl get nodes -l smi.cisco.com/node-type=<value of cdl/node-type, default value is 'session' in multi node setup)
- Os pods estão em estado de falha CrashLoopBackOff. Verifique o status dos pods etcd. Se os etcd pods não estiverem em execução, corrija os problemas de etcd.
kubectl describe pods -n <namespace> <etcd pod name>
- Os pods estão no estado de falha ImagePullBack Verifique se o repositório do leme e o registro da imagem estão acessíveis. Verifique se os servidores proxy e dns necessários estão configurados.
5.4 Os pods do Mirror Maker estão no estado init
Verifique a saída descreva pods e logs pod
kubectl describe pods -n <namespace> <failed pod name> kubectl logs -n <namespace> <failed pod name> [-c <container name>]
Como corrigir
- Verifique se os IPs externos configurados para Kafka estão corretos
- Verificar a disponibilidade de kafka de local remoto através de IPs externos
5.5 O índice de CDL não é replicado corretamente
Como identificar
Os dados que são adicionados em um site não podem ser acessados de outro site.
Como corrigir
- Verifique a configuração de ID de sistema local e a configuração de site remoto.
- Verifique a acessibilidade dos endpoints CDL e kafka entre cada site.
- Verifique o mapa, a réplica do índice e o slot em cada site. Ele pode ser idêntico em todos os locais.
5.6 As operações do CDL estão falhando, mas a conexão foi bem-sucedida
Como corrigir
- Verifique se todos os pods estão no estado pronto e em execução.
- Os pods de índice estarão no estado pronto somente se a sincronização for concluída com a réplica de mesmo nível (local ou remota, se disponível)
- Os pods de slot estarão no estado pronto somente se a sincronização for concluída com a réplica correspondente (local ou remota, se disponível)
- Os endpoints NÃO estarão no estado pronto se pelo menos um slot e um pod de índice não estiverem disponíveis. Mesmo que não esteja pronta, a conexão grpc será aceita do cliente.
5.7 A notificação para a limpeza do registro foi recebida antecipadamente/atrasada do CDL
Como corrigir
- Em um cluster k8s, todos os nós podem ter o tempo sincronizado
- Verifique o status de sincronização do NTP em todos os nós k8s. Se houver algum problema, corrija-o.
chronyc tracking chronyc sources -v chronyc sourcestats -v
6. Indicações
| ALARME |
severity |
summary |
|---|---|---|
| cdlLocalRequestFailure |
crítico |
Se a taxa de êxito de solicitações locais for inferior a 90% por mais de 5 minutos, acionará o alarme |
| cdlRemoteConnectionFailure |
crítico |
Se as conexões ativas do pod do ponto final para o local remoto atingirem 0 por mais de 5 minutos , o alarme será acionado (somente para o sistema ativado por GR) |
| cdlRemoteRequestFailure |
crítico |
Se a taxa de êxito de solicitações remotas de entrada for menor que 90% por mais de 5 minutos, acionará o alarme (somente para o sistema ativado por GR) |
| cdlReplicationError |
crítico |
Se a proporção de solicitações de replicação de saída para solicitações locais no namespace global do cdl tiver sido inferior a 90% por mais de 5 minutos (somente para o sistema habilitado para GR). Esses alertas são esperados durante a atividade de atualização e, portanto, você pode ignorá-los. |
| cdlKafkaRemoteReplicationDelay |
crítico |
Se o atraso na replicação do kafka para o local remoto passar de 10 segundos por mais de 5 minutos, então o alarme é acionado (somente para o sistema ativado por GR) |
| cdlOverloaded - principal |
principal |
Se o sistema CDL atingir a porcentagem configurada (padrão 80%) de sua capacidade, o sistema acionará o alarme (somente se o recurso de Proteção contra Sobrecarga estiver ativado) |
| cdlOverloaded - crítico |
crítico |
Se o sistema CDL atingir a porcentagem configurada (padrão de 90% )de sua capacidade, o sistema acionará o alarme (somente se o recurso de Proteção contra sobrecarga estiver ativado) |
| cdlKafkaConnectionFailure |
crítico |
Se os pods do índice CDL forem desconectados do kafka por mais de 5 minutos |
7. Problemas mais comuns
7.1 cdlReplicationError
Este alerta é geralmente visto durante a ativação do centro de operações ou atualização do sistema, tentar encontrar CR para ele, tentar verificar a ocorrência CEE do alerta e já foi apagado.
7.2 cdlRemoteConnectionFailure & GRPC_Connections_Remote_Site
A explicação se aplica a todos os alertas "cdlRemoteConnectionFailure" e "GRPC_Connections_Remote_Site".
Para alertas cdlRemoteConnectionFailure:
Nos registros de endpoint do CDL, vemos que a conexão com o host remoto do endpoint pod do CDL foi perdida:
2022/01/20 01:36:18.852 [ERROR] [RemoteEndointConnection.go:572] [datastore.ep.session] Connection to remote systemID 2 has been lost
Podemos ver o pod do endpoint do CDL tentando se conectar ao servidor remoto, mas ele foi recusado pelo host remoto:
2022/01/20 01:37:08.730 [WARN] [checksum.go:836] [datastore.checksum.session] Could not get checksum from remote for systemID: 2, clot: 8, Instance: 2 : rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 10.10.10.141:8882: connect: connection refused"
2022/01/20 01:37:08.732 [WARN] [checksum.go:836] [datastore.checksum.session] Could not get checksum from remote for systemID: 2, clot: 8, Instance: 1 : rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 10.10.10.141:8882: connect: connection refused"
2022/01/20 01:37:08.742 [WARN] [checksum.go:836] [datastore.checksum.session] Could not get checksum from remote for systemID: 2, clot: 8, Instance: 1 : rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 10.10.10.141:8882: connect: connection refused"
2022/01/20 01:37:08.742 [WARN] [checksum.go:836] [datastore.checksum.session] Could not get checksum from remote for systemID: 2, clot: 8, Instance: 2 : rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 10.10.10.141:8882: connect: connection refused"
2022/01/20 01:37:08.752 [WARN] [checksum.go:836] [datastore.checksum.session] Could not get checksum from remote for systemID: 2, clot: 7, Instance: 2 : rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 10.10.10.141:8882: connect: connection refused"
2022/01/20 01:37:08.754 [WARN] [checksum.go:836] [datastore.checksum.session] Could not get checksum from remote for systemID: 2, clot: 7, Instance: 1 : rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 10.10.10.141:8882: connect: connection refused"
Como o host remoto continuou inacessível por 5 minutos, o alerta foi gerado conforme abaixo:
alerts history detail cdlRemoteConnectionFailure f5237c750de6
severity critical
type "Processing Error Alarm"
startsAt 2025-01-21T01:41:26.857Z
endsAt 2025-01-21T02:10:46.857Z
source cdl-ep-session-c1-d0-6d86f55945-pxfx9
summary "CDL endpoint connections from pod cdl-ep-session-c1-d0-6d86f55945-pxfx9 and namespace smf-rcdn to remote site reached 0 for longer than 5 minutes"
labels [ "alertname: cdlRemoteConnectionFailure" "cluster: smf-data-rcdn_cee" "monitor: prometheus" "namespace: smf-rcdn" "pod: cdl-ep-session-c1-d0-6d86f55945-pxfx9" "replica: smf-data-rcdn_cee" "severity: critical" ]
annotations [ "summary: CDL endpoint connections from pod cdl-ep-session-c1-d0-6d86f55945-pxfx9 and namespace smf-rcdn to remote site reached 0 for longer than 5 minutes" "type: Processing Error Alarm" ]
A conexão com o host remoto foi bem-sucedida às 02:10:32:
2022/01/20 02:10:32.702 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
2022/01/20 02:10:38.923 [WARN] [RemoteEndointConnection.go:563] [datastore.ep.session] Cdl status changed - new version 283eb1e86aa9561c653083e6b691c919, old version f81478148c9e1ccb28f3ec0d90ca04e1. Reloading connections
2022/01/20 02:10:38.927 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
2022/01/20 02:10:38.934 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
2022/01/20 02:10:38.934 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
2022/01/20 02:10:38.935 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
Configuração presente no SMF para o local remoto do CDL:
cdl remote-site 2
db-endpoint host 10.10.10.141
db-endpoint port 8882
kafka-server 10.10.19.139 10061
exit
kafka-server 10.10.10.140 10061
exit
exit
Para o Alerta GRPC_Connections_Remote_Site:
A mesma explicação é aplicável para "GRPC_Connections_Remote_Site", pois também é do mesmo pod de endpoint do CDL.
alerts history detail GRPC_Connections_Remote_Site f083cb9d9b8d
severity critical
type "Communications Alarm"
startsAt 2025-01-21T01:37:35.160Z
endsAt 2025-01-21T02:11:35.160Z
source cdl-ep-session-c1-d0-6d86f55945-pxfx9
summary "GRPC connections to remote site are not equal to 4"
labels [ "alertname: GRPC_Connections_Remote_Site" "cluster: smf-data-rcdn_cee" "monitor: prometheus" "namespace: smf-rcdn" "pod: cdl-ep-session-c1-d0-6d86f55945-pxfx9" "replica: smf-data-rcdn_cee" "severity: critical" "systemId: 2" ]
A partir dos registros de pod do ponto final do CDL, o alerta começou quando a conexão ao host remoto foi recusada:
2022/01/20 01:36:18.852 [ERROR] [RemoteEndointConnection.go:572] [datastore.ep.session] Connection to remote systemID 2 has been lost
O alerta foi apagado quando a conexão com o site remoto foi bem-sucedida:
2022/01/20 02:10:32.702 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
2022/01/20 02:10:38.923 [WARN] [RemoteEndointConnection.go:563] [datastore.ep.session] Cdl status changed - new version 283eb1e86aa9561c653083e6b691c919, old version f81478148c9e1ccb28f3ec0d90ca04e1. Reloading connections
2022/01/20 02:10:38.927 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
2022/01/20 02:10:38.934 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
2022/01/20 02:10:38.934 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
2022/01/20 02:10:38.935 [WARN] [RemoteEndointConnection.go:437] [datastore.ep.session] Stream to remote site successful
8. Grafana
O painel CDL faz parte de todas as implantações de SMF.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
04-Oct-2023 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)